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
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
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=14211&projectId=129
Build statistics:
State: Failed
Previous State: Failed
Started at: Mon 7 Nov 2011 04:20:55 +
Finished at: Mon 7 Nov 2011 04:23:58 +
Total time: 3m 3s
Build Trigger: Schedule
Bu
Dear Gilles and Phil,
just a quick note to invite you to review the addition I've made to
MATH-699. It turns out I'm struggling with finite precision: it is
difficult to make a consistent use of thresholds. For the time being,
the way I see it is that you are both right, but we can set the design
i
I have started backporting some bug fixes in the 3.0 branch for my
apps that use 2.2. I would like to go ahead and prepare a release
including these fixes and fixes for the misplaced deprecation
warnings. This may take me a while to complete. I will post a
release plan in the next week or so. I
Hello Bean Utilians,
I have just posted three proposals for Apache Commons BeanUtils
DynaBean enhancements as patches in JIRA:
* https://issues.apache.org/jira/browse/BEANUTILS-407: DynaBean & Byte
Code generation, for interoperability
* https://issues.apache.org/jira/browse/BEANUTILS-405: DynaBe
> > [...]
> > If you don't hear from them, maybe it is because you are the only user
> > (which should probably tell you something of how "broadly" useful the
> > functionality is)...
> >
> > Personally, I have _zero_ stake in this issue because I don't use
> > "RandomDataImpl"[1].
>
> Then pl
On Nov 6, 2011, at 2:50 PM, Gilles Sadowski
wrote:
>> [...]
>>> 1. Luc "was happy removing all the stuff".
>>> 2. Sebb was inclined to make the field final.
>>> 3. I agree with both.
>>> That's three to one, if I count correctly.
>>>
>>> I don't have a big problem with keeping the functiona
On Sun, Nov 06, 2011 at 10:47:31AM -0700, Phil Steitz wrote:
> On 11/6/11 10:24 AM, Gilles Sadowski wrote:
> > On Sun, Nov 06, 2011 at 09:28:48AM -0700, Phil Steitz wrote:
> >> On 11/6/11 7:59 AM, Gilles Sadowski wrote:
> >>> On Sun, Nov 06, 2011 at 12:24:03AM -0700, Phil Steitz wrote:
> On 11
> [...]
> > 1. Luc "was happy removing all the stuff".
> > 2. Sebb was inclined to make the field final.
> > 3. I agree with both.
> > That's three to one, if I count correctly.
> >
> > I don't have a big problem with keeping the functionality, if you insist on
> > that point.
> > I just suggested
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=14209&projectId=129
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 6 Nov 2011 19:20:52 +
Finished at: Sun 6 Nov 2011 19:23:48 +
Total time: 2m 56s
Build Trigger: Schedule
B
On 11/06/2011 07:09 PM, Gary Gregory wrote:
Hi All:
Is there a release schedule for 1.0.8 ?
This week if I catch time, next for sure.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For addition
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=14208&projectId=129
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 6 Nov 2011 18:20:40 +
Finished at: Sun 6 Nov 2011 18:23:37 +
Total time: 2m 56s
Build Trigger: Schedule
Build
On 11/6/11 10:20 AM, Gilles Sadowski wrote:
> On Sun, Nov 06, 2011 at 09:27:44AM -0700, Phil Steitz wrote:
>> On 11/6/11 5:44 AM, Gilles Sadowski wrote:
>>> On Sat, Nov 05, 2011 at 11:03:40PM -0700, Phil Steitz wrote:
On 11/5/11 6:38 PM, Gilles Sadowski wrote:
> On Sat, Nov 05, 2011 at 08:
On 11/6/11 10:24 AM, Gilles Sadowski wrote:
> On Sun, Nov 06, 2011 at 09:28:48AM -0700, Phil Steitz wrote:
>> On 11/6/11 7:59 AM, Gilles Sadowski wrote:
>>> On Sun, Nov 06, 2011 at 12:24:03AM -0700, Phil Steitz wrote:
On 11/6/11 12:18 AM, Sébastien Brisard wrote:
>> +1, but your observatio
On Sun, Nov 06, 2011 at 09:28:48AM -0700, Phil Steitz wrote:
> On 11/6/11 7:59 AM, Gilles Sadowski wrote:
> > On Sun, Nov 06, 2011 at 12:24:03AM -0700, Phil Steitz wrote:
> >> On 11/6/11 12:18 AM, Sébastien Brisard wrote:
> +1, but your observation above then leads to the question where are
>
On Sun, Nov 06, 2011 at 09:27:44AM -0700, Phil Steitz wrote:
> On 11/6/11 5:44 AM, Gilles Sadowski wrote:
> > On Sat, Nov 05, 2011 at 11:03:40PM -0700, Phil Steitz wrote:
> >> 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/
On 11/5/11 12:11 PM, cwinter wrote:
> 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
On 11/6/11 8:37 AM, Sébastien Brisard wrote:
>>
>> [I did not follow all the details of this discussion; sorry if I'm
>> slightly off base.] But, if somewhere some _default_ accuracy is
>> needed to pass to a _default_ solver, I'd say: instantiate the
>> solver using its _default_ constructor; thus
On 11/6/11 7:59 AM, Gilles Sadowski wrote:
> On Sun, Nov 06, 2011 at 12:24:03AM -0700, Phil Steitz wrote:
>> On 11/6/11 12:18 AM, Sébastien Brisard wrote:
+1, but your observation above then leads to the question where are
you going to get this value from? There may not be a solver to re
On 11/6/11 5:44 AM, Gilles Sadowski wrote:
> On Sat, Nov 05, 2011 at 11:03:40PM -0700, Phil Steitz wrote:
>> 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 Stei
>
> [I did not follow all the details of this discussion; sorry if I'm slightly
> off base.] But, if somewhere some _default_ accuracy is needed to pass to a
> _default_ solver, I'd say: instantiate the solver using its _default_
> constructor; thus, no need to chase up instance variables used fur
On Sun, Nov 06, 2011 at 12:24:03AM -0700, Phil Steitz wrote:
> On 11/6/11 12:18 AM, Sébastien Brisard wrote:
> >> +1, but your observation above then leads to the question where are
> >> you going to get this value from? There may not be a solver to read
> >> it from. I guess the default impl in
On Sat, Nov 05, 2011 at 11:03:40PM -0700, Phil Steitz wrote:
> 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 i
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=14189&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 6 Nov 2011 07:28:45 +
Finished at: Sun 6 Nov 2011 07:31:19 +
Total time: 2m 33s
Build Trigger: Schedule
Build
On 11/6/11 12:18 AM, Sébastien Brisard wrote:
>> +1, but your observation above then leads to the question where are
>> you going to get this value from? There may not be a solver to read
>> it from. I guess the default impl in the base class could just
>> return BaseAbstractUnivariateRealSolver.
>
> +1, but your observation above then leads to the question where are
> you going to get this value from? There may not be a solver to read
> it from. I guess the default impl in the base class could just
> return BaseAbstractUnivariateRealSolver.DEFAULT_FUNCTION_VALUE_ACCURACY.
>
> Phil
>
Ah,
27 matches
Mail list logo