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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=9562projectId=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
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:
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, mainly
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
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 luc.maison...@free.fr wrote:
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
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
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
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
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
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
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 operators
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
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
No sure if this went through originally, sorry if this causes a duplicate to
occur.
-Greg
-- Forwarded message --
From: Greg Sterijevski gsterijev...@gmail.com
Date: Fri, Jul 1, 2011 at 6:45 PM
Subject: Re: (MATH-608) Remove methods from RealMatrix Interface
To: Commons
I count that as a bug in the SVD class.
On Fri, Jul 1, 2011 at 4:45 PM, Greg Sterijevski gsterijev...@gmail.comwrote:
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
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:
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 ted.dunn...@gmail.com wrote:
Actually, the
On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski gsterijev...@gmail.comwrote:
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
On 7/1/11 5:31 PM, Ted Dunning wrote:
On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski
gsterijev...@gmail.comwrote:
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
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 manage both
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 Thu, May 19, 2011 at 6:30 AM, Gary Gregory garydgreg...@gmail.com wrote:
On Thu, May 19, 2011 at 12:47 AM, Henri Yandell flame...@gmail.com 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
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
25 matches
Mail list logo
