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
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
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
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 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
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
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 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
>
> 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
-
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
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
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..
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?
>
-
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,
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
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
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
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
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
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
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
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: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
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
>
> 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
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
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
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
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.
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
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 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.
>>
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
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 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
35 matches
Mail list logo
