Assuming no one vetos my r1090111 rollback, I think we can go for an
RC4. There are non-API bugs in JIRA, but I'd rather we release with
some bugs and then start fixing/releasing than continually get held
up.
How are you timewise for RC4 Matt? I'm still very kidbound, but
beginning to get some tim
On Thu, May 19, 2011 at 6:30 AM, Gary Gregory wrote:
> On Thu, May 19, 2011 at 12:47 AM, Henri Yandell wrote:
>
>> *grumbles that they were ints and a previous RC candidate saw it
>> change to Range* :)
>>
>
>
> Change it back! ;)
Tongue in cheek as it might be, I think this is the right directi
There is no planned release date.
We release when the release is ready and there's currently one
blocking API issue regarding the text.translate package.
Once that issue is resolved then another release candidate can be
proposed; currently no one is working on the issue though.
Hen
On Fri, Jul
On 7/1/11 4:26 PM, Gilles Sadowski wrote:
> Hi.
>
>> Luc suggested that I move this discussion to the list. Luc posed the
>> question:
>>
>> "I don't understand how you intend to separate the API.
>> Would that mean users would always have to know beforehand the shape of the
>> matrix they use and
On 7/1/11 5:31 PM, Ted Dunning wrote:
> On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski
> wrote:
>
>> This may be a problem. Type erasure might necessitate some tricky use of
>> generics.
>>
> That won't help. Good coding practice is to declare a variable with as weak
> a type as possible so tha
On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski wrote:
> This may be a problem. Type erasure might necessitate some tricky use of
> generics.
>
That won't help. Good coding practice is to declare a variable with as weak
a type as possible so that libraries have maximum freedom to act. That
mea
This may be a problem. Type erasure might necessitate some tricky use of
generics.
On the SVD, if that's a bug, then the method which yields a reference to the
data array in realmatrix is also a bug.
On Fri, Jul 1, 2011 at 6:53 PM, Ted Dunning wrote:
> Actually, the compiler can't do the dispat
Actually, the compiler can't do the dispatch correctly.
For instance, given the following approximately real code:
Matrix a = new SparseMatrix(...);
Matrix b = new DiagonalMatrix(...);
This line will not dispatch to a special case method for either SparseMatrix
or DiagonalMatrix:
I count that as a bug in the SVD class.
On Fri, Jul 1, 2011 at 4:45 PM, Greg Sterijevski wrote:
> You are correct that moving these operations to an external class would
> expose details of data storage and break encapsulation. However, this is
> done consistently throughout math commons-look at
No sure if this went through originally, sorry if this causes a duplicate to
occur.
-Greg
-- Forwarded message --
From: Greg Sterijevski
Date: Fri, Jul 1, 2011 at 6:45 PM
Subject: Re: (MATH-608) Remove methods from RealMatrix Interface
To: Commons Developers List , d...@commons.a
Hi Gilles,
There is no magic which will remove the elemental complexity of these
things. However, the complexity would be concentrated in the operator
classes, where it probably should be. Furthermore, the type matching would
be handled by compiler. Finally, the multiplication routines would grow
One concrete example where second argument runtime type dispatching is
helpful is the case of multiplying a dense matrix (of any kind) by a sparse
vector. It is preferable to put the smarts for how to do this on in the
sparse vector rather than in the dense matrix, but object oriented dispatch
giv
Hi.
> Luc suggested that I move this discussion to the list. Luc posed the
> question:
>
> "I don't understand how you intend to separate the API.
> Would that mean users would always have to know beforehand the shape of the
> matrix they use and manage both the matrix, the data store and the ope
On Fri, Jul 1, 2011 at 2:35 PM, Greg Sterijevski wrote:
> My request stems from attempting to build a SymmetricRealMatrix which
> stores
> its contents in a packed format. I began implementing multiply and so forth
> and did not relish having a bunch of case statements. This lead me to the
> idea
Double dispatch was the wrong term. I should have said double argument
polymorphism. Double dispatch is a sub-optimal answer to the problem of
double polymorphism.
Apologies for polluting the discussion with a silly error.
On Fri, Jul 1, 2011 at 2:35 PM, Greg Sterijevski wrote:
> Ted,
>
> I am
Ted,
I am not sure why you think there will be double dispatch. If we remove the
multiplication method from the interface then there can only be one call to
multiply. If we want to keep the interface as is and also have a MatrixOps
class, then perhaps that is where we might have such a case. I am
Getting double dispatch this way leads to a pretty ugly API interface.
There is no reason why Matrix.times can't delegate to MatrixOp.times(this,
other), though. That gives you your double dispatch.
The real problem with this design is that adding a new matrix type is no
longer something that a
Hi all guys,
the Digester3 RC1 can be considered failed due to missing release
requirements that Luc reported.
Thanks everybody who put his effort on reviewing, and be ready for the RC2!!!
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri
Hello All,
Luc suggested that I move this discussion to the list. Luc posed the
question:
"I don't understand how you intend to separate the API.
Would that mean users would always have to know beforehand the shape of the
matrix they use and manage both the matrix, the data store and the operator
Le 01/07/2011 15:08, Simone Tripodi a écrit :
Salut Luc,
Hi Simone,
can we close this vote thread in order I can fix the open issues or we
have to wait this evening?
I guess you can cancel it and prepare a new one. I'm pretty sure people
will wait for the next RC to check it.
best regard
Dear OGNL Developers,
This email was sent by an automated system on behalf of the Apache Incubator
PMC.
It is an initial reminder to give you plenty of time to prepare your quarterly
board report.
The board meeting is scheduled for Wed, 20 July 2011, 10 am Pacific. The
report
for your podling
Salut Luc,
can we close this vote thread in order I can fix the open issues or we
have to wait this evening?
Many thanks in advance, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Jul 1, 2011 at 3:06 PM, Luc Maisonobe wrote:
> Le 01/07/2011 15:02,
Le 01/07/2011 15:02, Simone Tripodi a écrit :
Salut Luc!
-1
The gpg signature seems to have been done with key 41A0D191 which is not
your Apache signing key. The Apache signature key present in the KEYS file
is either 19FEA27D or C002CC79.
my bad :/
There are also a few other minor issue
Salut Luc!
>
> -1
>
> The gpg signature seems to have been done with key 41A0D191 which is not
> your Apache signing key. The Apache signature key present in the KEYS file
> is either 19FEA27D or C002CC79.
>
my bad :/
> There are also a few other minor issues:
>
> - a few checkstyle errors, mai
Le 28/06/2011 21:41, Simone Tripodi a écrit :
Hi all guys!
I just deployed the Maven artifacts on Nexus (details below), so
please cast your votes! :)
Vote will be open for next 72 hours and will be closed on July 1st, at 7:40pm.
Many thanks in advance!!!
Simo
Release Notes:
http://people.apach
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=9562&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 1 Jul 2011 12:25:53 +
Finished at: Fri 1 Jul 2011 12:26:28 +
Total time: 34s
Build Trigger: Schedule
Build Numb
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Hi Simone,
Simone Tripodi wrote:
> Hi all guys!
> I just deployed the Maven artifacts on Nexus (details below), so
> please cast your votes! :)
> Vote will be open for next 72 hours and will be closed on July 1st, at
> 7:40pm. Many thanks in advance!!!
> Simo
>
> Release Notes:
>
> http://peopl
Hi,
Please let me know, when common lang 3.0 will be moved from Beta to Final
Release?
Thanks,
Rohan Kadam.
"Legal Disclaimer: This electronic message and all contents contain information
from Cybage Software Private Limited which may be privileged, confidential, or
otherwise protected from
29 matches
Mail list logo
