On 11/5/11 10:16 AM, Sébastien Brisard wrote:
>> We are talking about two different things here - 0) configuring the
>> solver and 1) reading its properties (in the present case, as part
>> of internal implementation).
>>
>> Regarding configuration, the current setup where distribution
>> construct
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 11/5/11 6:50 PM, Gilles Sadowski wrote:
> On Sat, Nov 05, 2011 at 12:29:15AM -0700, Phil Steitz wrote:
>> The comments in MATH-701 included a couple of suggestions for
>> refactoring RandomDataImpl.
>>
>> 1) Eliminate the lazy initialization of the non-secure and secure
>> generators. Have the
On 11/5/11 6:38 PM, Gilles Sadowski wrote:
> On Sat, Nov 05, 2011 at 08:47:18AM -0700, Phil Steitz wrote:
>> On 11/5/11 7:04 AM, Luc Maisonobe wrote:
>>> Le 05/11/2011 08:29, Phil Steitz a écrit :
The comments in MATH-701 included a couple of suggestions for
refactoring RandomDataImpl.
>>
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-vfs2-test has an issue affecting its community integration.
This 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-exec-test has an issue affecting its community integration.
This i
On Sat, Nov 05, 2011 at 12:29:15AM -0700, Phil Steitz wrote:
> The comments in MATH-701 included a couple of suggestions for
> refactoring RandomDataImpl.
>
> 1) Eliminate the lazy initialization of the non-secure and secure
> generators. Have the constructor initialize the generators
> instead.
On Sat, Nov 05, 2011 at 08:47:18AM -0700, Phil Steitz wrote:
> On 11/5/11 7:04 AM, Luc Maisonobe wrote:
> > Le 05/11/2011 08:29, Phil Steitz a écrit :
> >> The comments in MATH-701 included a couple of suggestions for
> >> refactoring RandomDataImpl.
> >>
> >> 1) Eliminate the lazy initialization o
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=14182&projectId=108
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 6 Nov 2011 01:33:56 +
Finished at: Sun 6 Nov 2011 01:35:54 +
Total time: 1m 58s
Build Trigger: Schedule
B
Hi,
I'm picking up the discussion on the interface structure for distributions
again.
Now there is consensus on having separate roots for each domain: one for
real-valued distributions and one for integer distributions.
After thinking once more about distributions with densities vs. those
withou
>
> We are talking about two different things here - 0) configuring the
> solver and 1) reading its properties (in the present case, as part
> of internal implementation).
>
> Regarding configuration, the current setup where distribution
> constructors have optional inverse cum absolute accuracy ar
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-vfs2-test has an issue affecting its community integration.
This i
On 11/5/11 7:22 AM, Sébastien Brisard wrote:
>> So the user would first configure the solver and then provide it fully
>> configured to the abstract distribution ?
>>
>> If this is what you propose, then I agree.
>>
>> Luc
>>
> Yes, that's exactly what I had in mind.
We are talking about two diffe
That sounds really interesting indeed! :)
Looking forward to see it in the branch!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Nov 5, 2011 at 4:32 PM, James Carman wrote:
> I a
On 11/5/11 7:07 AM, Luc Maisonobe wrote:
> Le 05/11/2011 09:27, Sébastien Brisard a écrit :
>> Hi,
> Hi Sébastien,
>
>> The addition proposed in MATH-700 was initially triggered by MATH-692.
>> I think people were not too keen on this addition, and I now tend to
>> agree: the implementation I propo
On 11/5/11 7:04 AM, Luc Maisonobe wrote:
> Le 05/11/2011 08:29, Phil Steitz a écrit :
>> The comments in MATH-701 included a couple of suggestions for
>> refactoring RandomDataImpl.
>>
>> 1) Eliminate the lazy initialization of the non-secure and secure
>> generators. Have the constructor initiali
Yes, there is space for a lot of improvements, in both therms of APIs
and performances! :)
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Nov 5, 2011 at 4:27 PM, James Carman wrote:
> Well, with tha
I am playing around with DSL-izing Meiyo a bit more. The code just
seems way too complicated for the general case (at least from what
I've seen browsing the source/tests). I'd like to do something like
this...
ClassScan.scan().threadContextLoader().where().classAnnotated(MyAnnotation.class)
Clas
Well, with that idea, it got me interested in Meiyo. So, now I'm
playing around in a DSL branch trying to improve the API. It seems
too verbose to me at the moment. :)
On Sat, Nov 5, 2011 at 11:21 AM, Simone Tripodi
wrote:
> Hi James!
> I like the idea, the concept reminds me how TestNG's Data
Great! :)
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Nov 5, 2011 at 4:25 PM, wrote:
> Author: jcarman
> Date: Sat Nov 5 15:25:05 2011
> New Revision: 1197970
>
> URL: http://svn.apache.or
Hi James!
ClassScan is a Mark Struberg's proposal, I pinged him on Twitter and
replied they need to clean their code before moving to commons :)
Meiyo actually works with reflection, ClassScan instead reads the
bytecode via ASM - and it's faster.
Ideally we could replicate the same behavior in Mei
Hi James!
I like the idea, the concept reminds me how TestNG's DataProvider and
GoogleGuice Providers.
Looking forward to see it in action!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Nov 5,
Nevermind, I just found "Meiyo"! DUH!
On Sat, Nov 5, 2011 at 10:58 AM, James Carman
wrote:
> I remember us having discussions a while back about a ClassScan API.
> The sandbox/classscan/trunk "directory" is empty, though. Did we give
> it a different name? Did we give up on the idea?
>
-
I remember us having discussions a while back about a ClassScan API.
The sandbox/classscan/trunk "directory" is empty, though. Did we give
it a different name? Did we give up on the idea?
-
To unsubscribe, e-mail: dev-unsubscr..
What if we introduce a @Converter annotation and any method that is
annotated with this annotation is automatically registered as a
converter? It's similar to what I've done in Metastopheles
(http://metastopheles.sourceforge.net/).
On Fri, Nov 4, 2011 at 8:15 AM, Adrian Crum
wrote:
> Agreed. Ple
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-exec-test has an issue affecting its community integration.
This i
>
> So the user would first configure the solver and then provide it fully
> configured to the abstract distribution ?
>
> If this is what you propose, then I agree.
>
> Luc
>
Yes, that's exactly what I had in mind.
Sébastien
-
Le 05/11/2011 09:27, Sébastien Brisard a écrit :
> Hi,
Hi Sébastien,
> The addition proposed in MATH-700 was initially triggered by MATH-692.
> I think people were not too keen on this addition, and I now tend to
> agree: the implementation I proposed does work, but it lacks full
> generality. It
Le 05/11/2011 09:21, Sébastien Brisard a écrit :
> Hi,
> while working on MATH-699 (which was triggered by MATH-692), I found
> some inconsistencies in the use of
> UnivariateRealSolver.getAbsoluteAccuracy() and
> UnivariateRealSolver.getFunctionValueAccuracy() (see the JIRA ticket
> for more detai
Le 05/11/2011 08:29, Phil Steitz a écrit :
> The comments in MATH-701 included a couple of suggestions for
> refactoring RandomDataImpl.
>
> 1) Eliminate the lazy initialization of the non-secure and secure
> generators. Have the constructor initialize the generators
> instead. I am fine with th
Hi Seb!
>> BUGS FROM PREVIOUS RELEASE
>> ===
>
> Does that mean bugs are existing bugs carried over from previous releases?
> That's how I read it initially, but I suspect it means the list of
> bugs fixed since the previous release.
>
> Maybe it should read
>
> BUGS FIXE
On 5 November 2011 10:24, wrote:
> Author: simonetripodi
> Date: Sat Nov 5 10:24:42 2011
> New Revision: 1197917
>
> URL: http://svn.apache.org/viewvc?rev=1197917&view=rev
> Log:
> [DIGESTER-155] ClassLoader reference set to DigesterLoader not set in
> produced Digetser instances
>
> Modified:
Hi,
The addition proposed in MATH-700 was initially triggered by MATH-692.
I think people were not too keen on this addition, and I now tend to
agree: the implementation I proposed does work, but it lacks full
generality. It serves its purpose (MATH-692 and MATH-699), but I think
it should not be w
Hi,
while working on MATH-699 (which was triggered by MATH-692), I found
some inconsistencies in the use of
UnivariateRealSolver.getAbsoluteAccuracy() and
UnivariateRealSolver.getFunctionValueAccuracy() (see the JIRA ticket
for more details).
In short, the current implementation of AbstractContinuo
The comments in MATH-701 included a couple of suggestions for
refactoring RandomDataImpl.
1) Eliminate the lazy initialization of the non-secure and secure
generators. Have the constructor initialize the generators
instead. I am fine with this for the non-secure generator, but
initializing a sec
35 matches
Mail list logo
