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-jelly-tags-sql has an issue affecting its community integration.
T
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-scxml-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-dbutils has an issue affecting its community integration.
This iss
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-chain2 has an issue affecting its community integration.
This issu
Thanks a lot!
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
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-digester3 has an issue affecting its community integration.
This i
Hi,
testing of special functions involves comparing actual values returned
by CM with expected values as computed with an arbitrary precision
software (I use Maxima [1] for this purpose). As I intend these tests
to be assesments of the overall accuracy of our implementations, the
number of test val
Hello,
2012/8/30 Gilles Sadowski :
> Hello.
>
> To summarize:
> (1) Does anyone disagree with having all CM exceptions inherit
> from a new "MathRuntimeException" which itself will inherit
> from the standard "RuntimeException"?
+0: my background is not good enough.
> (2) Does anyone d
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 8/29/12 3:04 PM, Gilles Sadowski wrote:
> Hello.
>
> To summarize:
> (1) Does anyone disagree with having all CM exceptions inherit
> from a new "MathRuntimeException" which itself will inherit
> from the standard "RuntimeException"?
+0
> (2) Does anyone disagree with all exceptions
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-dbcp2 has an issue affecting its community integration.
This issue
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-dbcp has an issue affecting its community integration.
This issue
Hello
I did some more unit tests. Could you grant me commit rights (Apache
user "chammers") or should I fill your inbox with patches? :-)
BTW, I would have made a git fork but the "$Id$" lines show up in
every diff. Why are they not expanded in the git shadow repo? I thought
that would happen at
Hello.
To summarize:
(1) Does anyone disagree with having all CM exceptions inherit
from a new "MathRuntimeException" which itself will inherit
from the standard "RuntimeException"?
(2) Does anyone disagree with all exceptions being mandatorily
advertized in the "throws" clause of
> > No, you are not missing anything. Having only the javadoc without the
> > declaration in the signature is a pain. I would prefer to keep both.
>
> +1
>
> Just "going boom" with an unadvertised RTE is not acceptable
> behavior. We used to be very good about documenting and advertising
> all
> >> [...]
> > I think we had a discussion a few months ago on how exceptions should
> > be documented. We came to no agreement at that time, although one
> > option (which I followed) was to
> > - remove unchecked exceptions from the method's signature
> > - add the unchecjked exceptions to th
Hello.
> >> [...]
> >> I encountered this need in two different cases. The first one was to
> >> identify very precisely an error type, even with finer granularity than
> >> exception type. Parsing the error message to recognize the exception is
> >> evil, checking the enumerate used in the patter
On 8/29/12 12:11 PM, Luc Maisonobe wrote:
> Le 29/08/2012 20:31, Sébastien Brisard a écrit :
>> Hello,
> Hi Sébastien,
>
>> 2012/8/29 Luc Maisonobe :
>>> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
Hi.
>>> Hello,
>>>
>> [...]
> I think I get your point, but again given transitive /
Le 29/08/2012 20:31, Sébastien Brisard a écrit :
> Hello,
Hi Sébastien,
>
> 2012/8/29 Luc Maisonobe :
>> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
>>> Hi.
>>
>> Hello,
>>
>>>
> [...]
I think I get your point, but again given transitive / nested
dependencies I would not wa
Hello,
2012/8/29 Luc Maisonobe :
> Le 29/08/2012 01:40, Gilles Sadowski a écrit :
>> Hi.
>
> Hello,
>
>>
[...]
>>>
>>> I think I get your point, but again given transitive / nested
>>> dependencies I would not want to depend on it, even if all of the
>>> components have single-rooted exceptio
One example I often use is launch window computation for rockets.
One way to compute them is brute force simulation: you simply try
all launch times and for each one you perform the simulation of the
early orbits phase. If at any time something breaks (a polynomial
that never crosses zero, an optim
How about this:
1. Let's get the digest package to 100% code coverage (or as closed to it
as possible)
2. Clean up the code (removing the "vacuous" code)
Also to do is fix the remaining check styles.
Patches welcome!
Gary
On Tue, Aug 28, 2012 at 2:47 AM, Thomas Neidhart
wrote:
> On 08/28/2012
ping to "Jonny"?
Gary
On Sun, Aug 26, 2012 at 12:05 AM, Ralph Goers wrote:
> I will second what others have said. There really is no way to
> effectively review an 800k patch. If it is that big largely because it is
> including a jackrabbit jar directly into the project I would probably not
>
Le 29/08/2012 01:40, Gilles Sadowski a écrit :
> Hi.
Hello,
>
>>> [...]
>>
>> I think I get your point, but again given transitive / nested
>> dependencies I would not want to depend on it, even if all of the
>> components have single-rooted exception hierarchies. This is
>> especially true if
Le 29/08/2012 00:51, Gilles Sadowski a écrit :
> Hi Luc.
Hi Gilles,
>
> First off, I'd like to make it quite clear that _I_ was fine (and still am)
> about a singly rooted hierarchy of exceptions for CM.
>
> I nevertheless answer to your reply because we differ on the rationale for
> such a cha
26 matches
Mail list logo
