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-math has an issue affecting its community integration.
This issue
Hi all,
commit 1165155 removed method "solve(double[] b)" from class Solver in
org/apache/commons/math/linear/CholeskyDecompositionImpl.java, but it is
still in the DecompositionSolver interface that the Solver class
implements, thus resulting in an error, as the Solver class now no longer
im
Hi Luc,
question: is there a reason you applied this to StepHandler, but not
FixedStepHandler?
Best regards,
Dennis
l...@apache.org wrote:
Author: luc
Date: Sun Sep 4 14:36:48 2011
New Revision: 1165033
URL: http://svn.apache.org/viewvc?rev=1165033&view=rev
Log:
removed MathUserException
I want to get rid of it extending map. Have it define as asMap()
function instead. Especially since JDK 8 is bringing in extension
methods, which adds new (and default) methods to all collections, it
won't look very nice. Let's make a break now.
On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta wrote:
On Sun, Sep 4, 2011 at 3:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not "auto-cast."
> :)
Blame me for the mi
On Sun, Sep 4, 2011 at 7:02 PM, sebb wrote:
> On 4 September 2011 20:04, Simone Tripodi wrote:
>> Hi all guys,
>> the clirr report has just been updated on my personal ASF space[1],
>> can you review please?
>
> As it stands, 2.0 is not strictly binary compatible with 1.2.
>
> However, it depends
On 09/04/2011 04:00 PM, James Carman wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
> wrote:
>>
>> That is able to 'auto-cast' the retrieved object while Map#get() not.
>>
>
> I believe the feature is actually called "type inference", not "auto-cast."
> :)
Thanks for the explanation.
Bumping hoping to catch someone's attention.
I'll try version checkin history next if this isn't successful.
Cheers
On Tue, Aug 23, 2011 at 5:08 PM, Henri Yandell wrote:
> Switching over to the dev list.
>
> Anyone available to work with Barrie on this?
>
> Thanks,
>
> Hen
>
> -- Forward
On 4 September 2011 20:07, Oliver Heger wrote:
> Am 02.09.2011 17:08, schrieb sebb AT ASF:
>>
>> I've updated to the latest versions of all the plugins.
>>
>> Some of these changes may well cause problems, but the best way to
>> find this out is for various people to try using the POM, so I've
>>
On 4 September 2011 20:04, Simone Tripodi wrote:
> Hi all guys,
> the clirr report has just been updated on my personal ASF space[1],
> can you review please?
As it stands, 2.0 is not strictly binary compatible with 1.2.
However, it depends whether the changes affect the published API, or
are in
On 4 September 2011 18:56, Phil Steitz wrote:
> On 9/4/11 10:45 AM, Phil Steitz wrote:
>> On 9/4/11 5:15 AM, sebb wrote:
>>> The location for the localization resources only appears to be needed
>>> in the method:
>>>
>>> LocalizedFormats.getLocalizedString()
>>>
>>> so it is very easy to change w
I'm all for updating to the latest and greatest of all components.
Gary
On Sep 4, 2011, at 15:41, Oliver Heger wrote:
> This is a vote to release Apache Commons Configuration 1.7 based on the 3rd
> RC.
>
> There have been the following changes since RC2:
> * Some files in the conf directory ha
thanks James!
as you can notice, my English is still poor :)
All the best, have a nice day!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 10:00 PM, James Carman
wrote:
> On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi
> wrote:
>>
>> That is able
+1 to upgrading
Den 4. sep. 2011 21:52 skrev "Simone Tripodi"
følgende:
> Hallo Oliver,
> I'm reviewing the tag and, sorry for not having noticed before, is
> there any reason why the Digester is still at 1.8 version?
> Upgrade to at least 2.1 should be painless enough, even if an upgrade
> to 3.0
Sounds right to me. I think the more generic this kind of code is, the
better. I feel this even in the face of some (but not massive) performance
loss. I don't see that there should be any performance loss here.
On Sun, Sep 4, 2011 at 5:00 AM, Luc Maisonobe wrote:
> Le 04/09/2011 11:14, Sébas
On Sun, Sep 4, 2011 at 3:44 PM, Simone Tripodi wrote:
>
> That is able to 'auto-cast' the retrieved object while Map#get() not.
>
I believe the feature is actually called "type inference", not "auto-cast." :)
-
To unsubscribe,
Hallo Oliver,
I'm reviewing the tag and, sorry for not having noticed before, is
there any reason why the Digester is still at 1.8 version?
Upgrade to at least 2.1 should be painless enough, even if an upgrade
to 3.0 would be nicer :P
Anyway, not a blocker, just the time of reviewing all the stuff
Hi Raman,
What you wrote is not 100% right, since Context *extends Map*, so a correct assignment would be:
Context context = new MyContextImpl();
Context is able to store object identified by a key; let's assume you
store there your DataSource:
DataSource dataSource = ... ;
...
c
This is a vote to release Apache Commons Configuration 1.7 based on the
3rd RC.
There have been the following changes since RC2:
* Some files in the conf directory have been added Apache license
headers. (Note that the majority of files in this folder are simple test
files used by unit tests a
On 09/04/2011 05:22 AM, Simone Tripodi wrote:
> Hi all guys,
> I think that generics could help us on improving the Context class;
> I'm not particularly happy having it extending Map - it is needed
> anyway for backward compatibility - but it is clear that Context is a
> place where storing/retrie
Am 02.09.2011 17:08, schrieb sebb AT ASF:
I've updated to the latest versions of all the plugins.
Some of these changes may well cause problems, but the best way to
find this out is for various people to try using the POM, so I've
uploaded 22-SNAPSHOT to the snapshot repo.
Please report any iss
Hi all guys,
the clirr report has just been updated on my personal ASF space[1],
can you review please?
I think it's time to call a vote to accept the current branch as the
trunk, WDYT?
Many thanks in advance, have anice day!
Simo
[1] http://people.apache.org/~simonetripodi/chain/clirr-report.htm
Couldn't find better words, big +1 to your words James!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 7:30 PM, James Carman wrote:
> To be clear, I am also in favor of this approach. I don't think we
> need to patronize our users by
On 9/4/11 10:45 AM, Phil Steitz wrote:
> On 9/4/11 5:15 AM, sebb wrote:
>> The location for the localization resources only appears to be needed
>> in the method:
>>
>> LocalizedFormats.getLocalizedString()
>>
>> so it is very easy to change where they are, now that the POM uses the
>> standard Mav
On 9/4/11 5:15 AM, sebb wrote:
> The location for the localization resources only appears to be needed
> in the method:
>
> LocalizedFormats.getLocalizedString()
>
> so it is very easy to change where they are, now that the POM uses the
> standard Maven resource location (previously it was using a
On 9/4/11 4:50 AM, Luc Maisonobe wrote:
> Hi Gilles,
>
> Le 04/09/2011 12:28, Gilles Sadowski a écrit :
[...]
> The mathematical question is do we view our class as representing
> the extended complex numbers. If we agree that the answer to
> that
> question is yes,
If yo
To be clear, I am also in favor of this approach. I don't think we
need to patronize our users by trying to hold their hands. A
ClassCastException would be a pretty obvious indicator as to what is
going wrong with something like this.
On Sun, Sep 4, 2011 at 12:13 PM, Matt Benson wrote:
> Obviou
Hi added that feature, see CHAIN-56 for details.
I'll re-upload the site on my p.a.o home so we can continue discussing
about [chain] potential graduation.
Thanks, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 6:26 PM, Simone Tripodi
Hi James!
I remember that thread :(
Hope you have a nice WE, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 2:39 PM, James Carman wrote:
> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (ht
Hi Matt!
indeed, that's thanks to you that the Digester3 has this feature!!! :)
Thanks for the feedback!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sun, Sep 4, 2011 at 6:13 PM, Matt Benson wrote:
> Obviously I've suggested this "auto-cast" or
> whatever-you'd-like-
Obviously I've suggested this "auto-cast" or
whatever-you'd-like-to-call-it trick elsewhere, and am in favor of its
use.
Matt
On Sun, Sep 4, 2011 at 7:39 AM, James Carman wrote:
> Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
> and it was shot down
> (http://apache-commons.
Am 04.09.2011 17:27, schrieb Phil Steitz:
On 9/2/11 2:59 AM, Oliver Heger wrote:
Am 02.09.2011 02:52, schrieb sebb:
On 2 September 2011 01:18, Gary Gregory
wrote:
On Thu, Sep 1, 2011 at 7:55 PM, sebb wrote:
On 1 September 2011 22:42, Gary
Gregory wrote:
On Thu, Sep 1, 2011 at 2:25 PM, s
On 9/4/11 6:01 AM, Gilles Sadowski wrote:
>>> [...]
>> The hit is in the constructor, where every complex instance has to
>> run the code to set the property.
> In fact, not only! If one can trust the mini-benchmark performed with
> "PerfTestUtils", the constructor with the additional flag is 2% sl
On 9/4/11 7:22 AM, Gilles Sadowski wrote:
> Hello Luc.
>
> [...]
>> The mathematical question is do we view our class as representing
>> the extended complex numbers. If we agree that the answer to that
>> question is yes,
> If you say "no", then my understanding is that the "C
On 9/2/11 2:59 AM, Oliver Heger wrote:
> Am 02.09.2011 02:52, schrieb sebb:
>> On 2 September 2011 01:18, Gary Gregory
>> wrote:
>>> On Thu, Sep 1, 2011 at 7:55 PM, sebb wrote:
>>>
On 1 September 2011 22:42, Gary
Gregory wrote:
> On Thu, Sep 1, 2011 at 2:25 PM, sebb wrote:
>
>
Hello Luc.
> >>>[...]
> The mathematical question is do we view our class as representing
> the extended complex numbers. If we agree that the answer to that
> question is yes,
> >>>If you say "no", then my understanding is that the "Complex" class does not
> >>>represent the complex
> > [...]
>
> The hit is in the constructor, where every complex instance has to
> run the code to set the property.
In fact, not only! If one can trust the mini-benchmark performed with
"PerfTestUtils", the constructor with the additional flag is 2% slower.
But using the flag in "divide" makes i
Yeah, I tried that sort of setup with the ArrayUtils.toMap() method
and it was shot down
(http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r983137-commons-proper-lang-trunk-src-main-java-org-apache-commons-lang3-ArrayUtils-jaa-td2317854.html).
Good luck with that. It wasn't worth my time
The location for the localization resources only appears to be needed
in the method:
LocalizedFormats.getLocalizedString()
so it is very easy to change where they are, now that the POM uses the
standard Maven resource location (previously it was using a subdir
only which prevented such a move)
A
Hi Gilles,
Le 04/09/2011 12:28, Gilles Sadowski a écrit :
[...]
The mathematical question is do we view our class as representing
the extended complex numbers. If we agree that the answer to that
question is yes,
If you say "no", then my understanding is that the "Complex" class does not
repr
On 4 September 2011 12:24, Luc Maisonobe wrote:
> Le 04/09/2011 12:59, sebb a écrit :
>>
>> On 4 September 2011 11:23, sebb wrote:
>>>
>>> On 4 September 2011 10:53, Luc Maisonobe wrote:
Le 04/09/2011 04:57, Phil Steitz a écrit :
>
> Same problem under Linux for parent 21.
Le 04/09/2011 12:59, sebb a écrit :
On 4 September 2011 11:23, sebb wrote:
On 4 September 2011 10:53, Luc Maisonobe wrote:
Le 04/09/2011 04:57, Phil Steitz a écrit :
Same problem under Linux for parent 21.
Isn't it related to a problem that arose some weeks ago about the resource
not bein
On 4 September 2011 11:23, sebb wrote:
> On 4 September 2011 10:53, Luc Maisonobe wrote:
>> Le 04/09/2011 04:57, Phil Steitz a écrit :
>>>
>>> Same problem under Linux for parent 21.
>>
>> Isn't it related to a problem that arose some weeks ago about the resource
>> not being copied from source t
> > [...]
> >> The mathematical question is do we view our class as representing
> >> the extended complex numbers. If we agree that the answer to that
> >> question is yes,
> > If you say "no", then my understanding is that the "Complex" class does not
> > represent the complex number concept, un
On 4 September 2011 10:53, Luc Maisonobe wrote:
> Le 04/09/2011 04:57, Phil Steitz a écrit :
>>
>> Same problem under Linux for parent 21.
>
> Isn't it related to a problem that arose some weeks ago about the resource
> not being copied from source tree to classpath ? I think it appeared first
> i
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
On 4 September 2011 07:04, Stefan Bodewig wrote:
> Hi,
>
> I've just committed Converter*Stream implementations for Pack200[1]
> which is a bit unusual in several ways.
>
> First of all it will (by design of the format) only work on compressing
> valid jar files. Actually the result isn't likely
Le 04/09/2011 11:14, Sébastien Brisard a écrit :
Hi,
Hi Sébastien,
In JIRA MATH-653, Gilles initiated a simplification of the RealVector
abstract class, by removing all methods which make use of double[] as
RealVectors.
The logical step is to simplify DecompositionSolver along these lines.
Wh
Le 04/09/2011 04:57, Phil Steitz a écrit :
Same problem under Linux for parent 21.
Isn't it related to a problem that arose some weeks ago about the
resource not being copied from source tree to classpath ? I think it
appeared first in Gump and someone updated the configuration to match
what
Hi all guys,
I think that generics could help us on improving the Context class;
I'm not particularly happy having it extending Map - it is needed
anyway for backward compatibility - but it is clear that Context is a
place where storing/retrieving objects identified by a key.
I propose adding two h
Hi,
In JIRA MATH-653, Gilles initiated a simplification of the RealVector
abstract class, by removing all methods which make use of double[] as
RealVectors.
The logical step is to simplify DecompositionSolver along these lines.
While doing this for CholeskyDecompositionImpl, I initially intended
to
51 matches
Mail list logo
