elopment
can be integrated as you want.
best regards,
Luc
A similar situation is: When I post a message on the ML, asking
whether there are objections to some proposed work, how long should
I wait before implementing the suggested solution?
Example:
http://markmail.org/thread/ywdfvyq6hmb
e and vote.
> This vote will close no sooner than 72 hours from now, i.e. after 2200
> GMT 23-Mar 2016
>
> [X] +1 Release these artifacts
Luc
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
>
> Thanks!
Le 21/03/2016 13:54, Evan Ward a écrit :
> Hi,
>
> Can a Math PMC member add our release data to the database? I don't have
> the necessary permissions.
Now that we have 3 PMC, I have updated the database.
You can continue with the process.
best regards,
Luc
&g
Le 21/03/2016 16:42, Gilles a écrit :
> On Mon, 21 Mar 2016 10:29:48 -0400, Evan Ward wrote:
>> On 03/21/2016 09:18 AM, Luc Maisonobe wrote:
>>> Le 21/03/2016 13:44, Evan Ward a écrit :
>>>> The vote passes with three votes in favor and none against.
>>> We
Le 21/03/2016 13:44, Evan Ward a écrit :
> The vote passes with three votes in favor and none against.
Well, in fact I am not sure it passes yet ...
As far as I know, there are only 2 PMC members who voted: Oliver and myself.
Could a third PMC member look at it?
best regards,
Luc
>
&g
+1 for new component.
Luc
Le 21/03/2016 09:57, Bernd Eckenfels a écrit :
> +1 Accept Chimera as new Apache Commons Component
>
>
> Gruss
> Bernd
>
> Von: Benedikt Ritter
> Gesendet: Montag, 21. März 2016 09:45
> An: Commons Developers List
> Cc: Hadoop Common
&g
hat in fact should rather be step 0.
best regards,
Luc
Best Regards,
Evan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: de
commons-1142/org/apache/commons/commons-math3/3.6.1/
>
> [X] +1 Release it.
+1.
For some reason, the schell scripts I use to check some boring stuff
(diffs between zip/tar.gz/tag) didn't work. I did it manually, and
everything was fine.
best regards,
Luc
> [ ] +0 Go ahead; I don'
Le 2016-03-15 20:04, Gary Gregory a écrit :
I will file this ASAP. If you feel something should be added, do let me
know.
## Description: Report from the Apache Commons Project [Gary D.
Gregory]
The Apache Commons project focuses on all aspects of reusable Java
components.
The Apache Common
* Signal changes to "master" in a more prominent way, e.g. with an
>> appropriately strong email "subject" (?)
>
> I guess that there is a document that explains how to achieve this; but
> where
>
Thanks,
> Gilles
>
> P.S. Git experts, please check that I did not make any mistake...
I have checked the branches, everything looks find to me.
best regards,
Luc
>
>
> -
> To unsubscribe,
Le 2016-02-04 23:30, Phil Steitz a écrit :
We have the following volunteers for the new TLP, which we have
decided to call "Apache Math"
Bill Barker
Otmar Ertl
Gary Gregory
Luc Maisonobe
Thomas Neidhart
Gilles Sadowski
Phil Steitz
We need to name an initial chair for the PMC. I will
Epsilon
> Erdos
> Euclid
> Euler
> Gauss
> JAML
> Math
> MathBlocks
> MathComponents (or Math Components)
> Mathelactica
> MathModules
> Megginson
> modMath
> Nash
> Newton
Hi Gilles,
Le 26/01/2016 20:07, Gilles a écrit :
> Hello Luc.
>
> On Tue, 26 Jan 2016 09:47:20 +0100, Luc Maisonobe wrote:
>> Le 26/01/2016 01:13, Gilles a écrit :
>>> Hi.
>>
>> Hi Gilles,
>>
>>>
>>> In CM, a base class "BitsStrea
seeds.
On the other hand, too much compatibility really is a pain, we
feel it constantly, so I would say that as soon as we need to
change the sequence, we can just do it, and check all the tests
we know of (i.e. those of our own library) still pass and we
go forward.
best regards,
Luc
>
com/Nabla.html>.
Luc
On Mon, Jan 25, 2016 at 6:41 AM sebb wrote:
On 25 January 2016 at 09:28, luc wrote:
> Le 2016-01-25 08:52, Benedikt Ritter a écrit :
>>
>> Hi,
>>
>> I very much like the idea of taking the name of a famous mathematician.
In which case i
de facto an umbrella
project as modularizing it seems in the current mood.
best regards,
Luc
Hearkens back to HttpComponents, which has worked pretty well.
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
Le 24/01/2016 21:54, Phil Steitz a écrit :
> Please respond to this thread if you are a Commons Committer
> interested in joining the PMC for the new TLP based on [math].
I would be honored to join the new PMC.
best regards,
Luc
>
> Thank
e BUILDING.txt file, so a "mvn
install"
rather than my traditional "mvn clean compile site" was sufficient. So
this is OK to me.
best regards,
Luc
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Thanks!
--
Le 17/01/2016 20:19, Gilles a écrit :
> Hi Luc.
>
> [Thanks for handling the "revert" chores!]
>
> In my local "git", I've created a branch, called "long-rng",
> initially, as the name indicates, for testing "long"-based
> RNG i
Le 17/01/2016 18:45, Phil Steitz a écrit :
> On 1/17/16 9:33 AM, Luc Maisonobe wrote:
>> Le 17/01/2016 16:31, Phil Steitz a écrit :
>>> On 1/17/16 6:34 AM, Gilles wrote:
>>>> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>>>>> Le
Le 17/01/2016 16:31, Phil Steitz a écrit :
> On 1/17/16 6:34 AM, Gilles wrote:
>> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>>> Le 16/01/2016 16:51, Gilles a écrit :
>>>> Hi.
>>>>
>>>> Context: nobody gave an opinion on
seen positively by anyone.
So I would suggest that rather than adding a parallel rng package,
which reminds me of the difficulties we get with the two optim and
optimization packages, you continue doing your changes directly
in the random package as you started to do, but in a feature branch.
>
se. All are welcome to vote.
>
> [X] +1 I am in favor of this action
Luc
> [ ] +0 I am OK with this
> [ ] -0 OK, but...
> [ ] -1 I oppose this action because...
>
> This VOTE will run a little longer than usual - closing at 20 Jan
&g
tringent constraints about releases,
mainly related to stuff that is not stabilized. We could also accept
some ideas that were rejected up to now as not fitting in commons
scope (higher level stuff like the expression parser that was sub
t I usually do for looking in large history with several branches
at once is "git log -30 --branches --oneline --decorate --graph",
of course any number of commits other than 30 can be used.
For any git command, like log, you can display its documentation
by adding a "--help"
Hi Sebb,
Le 07/01/2016 04:21, sebb a écrit :
> On 7 January 2016 at 01:48, Gilles wrote:
>> On Wed, 6 Jan 2016 18:42:06 +0100, Luc Maisonobe wrote:
>>>
>>> Le 06/01/2016 15:56, Gilles a écrit :
>>>>
>>>> Hi.
>>>>
>>>
his is what
was done for the field-doe (and the branch is still there).
best regards,
Luc
>
>
> Best regards,
> Gilles
>
> On Wed, 6 Jan 2016 14:49:09 +0100, Luc Maisonobe wrote:
>> Hi all,
>>
>> As discussed a few weeks ago, I ported the new field-based ode
r less important
than others opinions. Putting zero weight to it arbitrarily is not
better than putting a 10x weight on it.
>
> A useful policy will help in avoiding that high level questions
> (such as "Backwards-compatibility or not?") constantly pollute
> development iss
and an end commit and listing the
intermediate ones with the following command:
git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1 --reverse
I put this list in a file for later looping over this.
Then I wrote a small script that extracted from one commit identifier
the commit message
submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Math website:
http://commons.apache.org/proper/commons-math/
Luc Maisonobe, on behalf of the Apache Commons community
-
To unsubscribe, e-mail
d now?
I noticed the same thing when staging [math] artifacts on Nexus.
I only had to remove the bin and src zip and tar.gz files.
best regards,
Luc
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: d
Le 02/01/2016 21:15, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 2.
This vote has PASSED, with the following votes:
+1:
- Phil Steitz (binding)
- Thomas Neidhart
- Gilles Sadowski (binding)
- Luc Maisonobe (binding)
Le 05/01/2016 19:59, Gilles a écrit :
> On Sat, 2 Jan 2016 21:15:32 +0100, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 2.
>>
>> Tag name:
>> MATH_3_6_RC2 (signature can be checked from git
Le 05/01/2016 19:58, Gilles a écrit :
> On Tue, 5 Jan 2016 17:48:59 +0100, Luc Maisonobe wrote:
>> Le 05/01/2016 17:42, Gary Gregory a écrit :
>>> On Tue, Jan 5, 2016 at 7:51 AM, Gilles
>>> wrote:
>>>
>>>> Hi Luc.
>>>>
>>>> O
Le 05/01/2016 17:07, Thomas Neidhart a écrit :
> On 01/02/2016 09:15 PM, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 2.
>>
>> Tag name:
>> MATH_3_6_RC2 (signature can be checked from git using 'gi
Le 05/01/2016 17:42, Gary Gregory a écrit :
> On Tue, Jan 5, 2016 at 7:51 AM, Gilles wrote:
>
>> Hi Luc.
>>
>> On Tue, 5 Jan 2016 09:44:09 +0100, Luc Maisonobe wrote:
>>
>>> Hi all,
>>>
>>> Please remind this vote will close in less than
Hi all,
Please remind this vote will close in less than 12 hours.
Only 2 votes have been cast by now, we need at least 3
from PMC members for this to succeed.
best regards,
Luc
Le 02/01/2016 21:15, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from rele
Le 02/01/2016 21:15, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 2.
>
> Tag name:
> MATH_3_6_RC2 (signature can be checked from git using 'git tag -v')
>
> Tag URL:
>
> <https://git-wip-us.a
5>
Commit ID the tag points at:
95a9d35e77f70ffc9bd5143880c236a760b42005
Site:
<http://home.apache.org/~luc/commons-math-3.6-RC2-site>
Distribution files:
https://dist.apache.org/repos/dist/dev/commons/math/
Distribution files hashes (SHA1):
8b0b724b91102f63c7211f8de60dec19f94c4
Le 01/01/2016 17:23, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 1.
This vote is canceled, in order to fix some issues with Java 5.
Thanks to thos who reviewed the release.
best regards,
Luc
>
> Tag name:
>
Le 02/01/2016 19:23, Phil Steitz a écrit :
> On 1/2/16 11:04 AM, Luc Maisonobe wrote:
>> Hi Phil,
>>
>>
>> Le 02/01/2016 18:26, pste...@apache.org a écrit :
>>> Repository: commons-math
>>> Updated Branches:
>>> refs/heads/MATH_3_X c5e6ccb
Hi Phil,
Le 02/01/2016 18:26, pste...@apache.org a écrit :
> Repository: commons-math
> Updated Branches:
> refs/heads/MATH_3_X c5e6ccb81 -> 68194a3bf
>
>
> Fixed ant build.
Do you want me to run another RC?
best regards,
Luc
>
>
> Project: http://git-wip-u
ute them. What am I missing? I can't add an exclusion
> for **/Abstract*.java because we have non-abstract test classes
> named that way. Is the surefire runner smart enough to skip these
> by itself somehow?
Perhaps. I could simply rename this base class
AdamsFieldIntegratorAbstract
release process.
I would be happy to drop it too!
Uploading the site is also painfully slow. I think it took about
two hours, for the 7081 files in the site.
best regards,
Luc
>
> Phil
>>
>> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
>> Com
Le 01/01/2016 17:47, Gilles a écrit :
> Hi.
>
> On Fri, 1 Jan 2016 17:23:58 +0100, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 1.
>
> There is a spurious quotation mark in the mail's subject line (ju
6>
Commit ID the tag points at:
2525399e1654530f1eff026cf3a16e473cd07296
Site:
<http://home.apache.org/~luc/commons-math-3.6-RC1-site>
Distribution files:
https://dist.apache.org/repos/dist/dev/commons/math/
Distribution files hashes (SHA1):
a41da1d7e9368132c7273c13ca760b6abaf0d
Hi Rostislav,
Le 31/12/2015 13:43, Rostislav Krasny a écrit :
> On Tue, Dec 29, 2015 at 8:39 PM, Luc Maisonobe wrote:
>> Hi all,
>>
>> A few weeks ago, I proposed to release 3.6. There were two
>> points I wanted to address before that, both related to
>> ODE. Th
as a matrix, but will not use the array by itself
anymore. In this case, transfering ownership of the array to the matrix
instance is not a bad thing, particularly if the array is big.
I agree this case is really specific so it may not be sufficient to keep
this class (or to keep the constr
Le 30/12/2015 20:18, Ole Ersoy a écrit :
> Hi Luc,
>
> On 12/30/2015 03:55 AM, Luc Maisonobe wrote:
>> Le 30/12/2015 06:18, Ole Ersoy a écrit :
>>> Hi,
>> Hi Ole,
>>
>>> RealMatrixPreservingVisitor and RealMatrixChangingVisitor files look
>>>
sed to update
the matrix that is visited, hence the "Changing" nature of the
visitor.
best regards,
Luc
>
> Cheers,
> Ole
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For a
Le 29/12/2015 20:48, Phil Steitz a écrit :
>
>
>> On Dec 29, 2015, at 11:39 AM, Luc Maisonobe
>> wrote:
>>
>> Hi all,
>>
>> A few weeks ago, I proposed to release 3.6. There were two points I
>> wanted to address before that, both related to O
out the library).
What do you think?
best regards,
Luc
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
it has stabilized. It would also be easy for any
developer to switch back and forth between this feature branch
and master to get convinced there are no hidden problems.
> That did not happen before you committed the changes.
> That obligates us to review them. The tests cover only nextInt s
, from which I concluded that the randomness
>>> provider does not care if the request was to create less than 32
>>> random bits.
>>> Taking "nextBoolean()" for example, it looks like a waste of 31
>>> bits (or am I missing something?).
>>
>> Q
es" (and perhaps other
> methods that can be coded in a generic way):
> https://issues.apache.org/jira/browse/MATH-1307
>
> Are there objections?
Go for it.
Luc
>
> Regards,
> Gilles
>
>
> ---
Le 25/12/2015 19:50, Phil Steitz a écrit :
> On 12/25/15 9:29 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> Le 25/12/2015 17:23, l...@apache.org a écrit :
>>> Prevent findbugs false positive.
>> This commit was intended to fix a false positive in findbugs.
>>
Do anyone of you understand why the filter doesn't work? I have
reread 4 times the element and did not see
what I wrote wrong.
Any help would be greatly appreciated.
best regards,
Luc
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apa
Le 25/12/2015 04:46, Gilles a écrit :
> On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:
>>>> [...]
>>>>
>>>> When our users build a large application, they rely on numerous
>>>> different libraries and tools, both open-source and
Le 24/12/2015 14:13, Gilles a écrit :
> On Thu, 24 Dec 2015 09:36:34 +0100, Luc Maisonobe wrote:
>> Le 24/12/2015 01:41, Gilles a écrit :
>>> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>>>> Le 23/12/2015 14:32, Gilles a écrit :
>>>>> He
Le 24/12/2015 01:41, Gilles a écrit :
> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>> Le 23/12/2015 14:32, Gilles a écrit :
>>> Hello.
>>>
>>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>>> Le 2015-12-23 01:41, Gilles a écrit :
>
Le 23/12/2015 14:32, Gilles a écrit :
> Hello.
>
> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>> Le 2015-12-23 01:41, Gilles a écrit :
>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>
hinking - but Spring Boot has an
@ExceptionHandler annotation that allows the developer to wire up an
exception handler. It might be worth exploring something similar for
the purpose of automating I18N requirements.
@ExceptionHandler(MathException.class)
someClientCo
one. After it's caught the type code (Enum) indicates precisely
> what the issue is.
>>
>> In a perfect world, we would be able to extend a regular IAE while
>> implementing a MathRootException, but Throwable in Java is a class,
>> not an interface. Too bad.
> Luc
ult, but the application programmer's.
>>> Meaningful exception messages are a best practice in Java. They are
>>> a very useful aid in debugging and production support.
>>>>
>>>> Please assume that for a moment; then CM could have its algorithms
>>>> thr
binary zip,
not the source and binary jar.
best regards,
Luc
>
> Thanks,
> Pascal
>
> Am 21.12.2015 um 23:24 schrieb Christopher:
>> Why detach them at all? Why not permit them to be uploaded to Maven
>> Central?
>> It may not be as useful for Java builds, but
Le 09/12/2015 19:22, James Ring a écrit :
> On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz wrote:
>> On 12/9/15 9:13 AM, luc wrote:
>>> Le 2015-12-09 16:49, Phil Steitz a écrit :
>>>>> On Dec 9, 2015, at 8:39 AM, luc wrote:
>>>>>
>>>>&g
Le 2015-12-09 16:49, Phil Steitz a écrit :
On Dec 9, 2015, at 8:39 AM, luc wrote:
Hi all,
The development status for the field-ode branch (linked to issue
MATH-1288)
is now stable. I will therefore merge this branch into the MATH_3_X
branch
very soon now.
What about master?
I may merge
branch when
it
is merged into another branch. So the merge will probably generate a
huge
flood of mails to the list, corresponding to all the work done on the
field-ode branch since last month.
I apologize for this flood.
best regards,
Luc
nymore?
best regards,
Luc
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/25de9b78
> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/25de9b78
> Diff: http://git-wip-us
>
> Any objection to add the same for math?
Go for it if you think it is useful.
For the record, there is a pending pull request about travis here:
<https://github.com/apache/commons-math/pull/11>
best regards,
Luc
>
> The travis integration can be quite useful for a RM a
://people.apache.org/builds/commons/collections/4.1/RC2/clirr-report.html
>
> RAT Report:
>
> http://people.apache.org/builds/commons/collections/4.1/RC2/rat-report.html
>
> KEYS:
> https://www.apache.org/dist/commons/KEYS
>
> Please review the release ca
/RC1/rat-report.html
KEYS:
https://www.apache.org/dist/commons/KEYS
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. after
2400
GMT 25-November 2015
[ ] +1 Release these artifacts
+1 for the release
Luc
[ ] +0 OK, but
creators support it.
Could you elaborate on this?
Would this mean we add a dependency?
What does "to make use of" mean, would this be an interface part of the
library that could be compiled only if the glue libraries are available?
Luc
There were some recent and not so recent disc
Le 24/11/2015 14:34, Phil Steitz a écrit :
> On 11/24/15 3:40 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> It seems the new bootstrap method introduced in fbc327e9 in order
>> to solve MATH-1246 creates some random test failures.
>>
>> The reason is that an
generator somewhere and
to configure it with a fixed seed for the Junit tests?
best regards,
Luc
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
with ODE right now
as you have probably noticed.
best regards,
Luc
>
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-m
history does not mentioned (fixed in svn)
>
> ASC OK, MD5 OK, SHA1 OK. Everyone's checking these, right?
Yes. I check this for every release.
Luc
>
> Reports OK.
>
> Tested building with:
>
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-2
mmons/KEYS
>
> Please review the release candidate and vote.
>
>
> Considering that this is a security related release and that RC2 did not
> show any functional problems with the release, I plan to close this vote
> in 24h from now, i.e. after 0100 GMT 14-November 2015
Le 2015-11-12 10:18, Stefan Bodewig a écrit :
On 2015-11-11, Thomas Neidhart wrote:
Please review the release candidate and vote.
+1 for the release.
Luc
+1
Stefan
-
To unsubscribe, e-mail: dev-unsubscr
compilation error when attempting a compilation with maven
3.3.3 and the default JVM on my system (java8 openJDK, on a Debian
stretch machine)
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-s
Le 06/11/2015 14:55, Gilles a écrit :
> Hi Luc.
>
> On Fri, 06 Nov 2015 10:04:23 +0100, luc wrote:
>> Le 2015-11-06 02:34, Gilles a écrit :
>>> On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:
>>>> On 11/5/15 1:58 PM, Luc Maisonobe wrote:
>&
> so 4.0 and 4.1
>> might not be compatible.
>
> Isn't that going to cause JAR hell?
As long as people are aware there are no compliance implied,
then they know what they have to do when they decide to
use this.
best regards,
Luc
>
> Gilles
>
>> We would always
Le 06/11/2015 18:18, sebb a écrit :
> On 6 November 2015 at 16:17, Phil Steitz wrote:
>> Here is an idea that might break our deadlock re backward
>> compatibility, versioning and RERO:
>>
>> Agree that odd numbered versions have stable APIs - basically adhere
>> to Commons rules - no breaks withi
Le 2015-11-06 02:34, Gilles a écrit :
On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:
On 11/5/15 1:58 PM, Luc Maisonobe wrote:
Le 05/11/2015 12:25, Gilles a écrit :
Hello.
On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:
Hi all,
I would like to release 3.6 in the upcoming weeks.
There
o
> PolynomialCurveFitter).
Yes, a new issue would be better.
best regards,
Luc
>
> Bruce
>
>
>
>
> -
>
>
To unsubscribe, e-mail: dev-unsubscr.
Le 05/11/2015 12:25, Gilles a écrit :
> Hello.
>
> On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:
>> Hi all,
>>
>> I would like to release 3.6 in the upcoming weeks.
>> There have been a bunch of bug fixes and a few evolutions that are
>> important to me.
&g
you do the "back-porting"?
Fine, I've done it.
I have also removed the geValue method since it was not needed anymore.
best regards,
Luc
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache
Le 2015-11-04 13:44, Gilles a écrit :
On Tue, 03 Nov 2015 18:07:50 +0100, Luc Maisonobe wrote:
Le 03/11/2015 15:33, Gilles a écrit :
On Tue, 03 Nov 2015 11:06:50 -, l...@apache.org wrote:
Fixed findbugs warning.
When defining compareTo, we should also define equals and hashcode
branch will remain alive and
we could also release other versions later on in the 3.x series.
What do other developers want to have in the 3.6 release?
Of course, I volunteer to be the release manager.
best regards,
Luc
-
To
ch: refs/heads/MATH_3_X
>> Commit: 04454fc0096d5d388e10c5b13024b2a947a4e923
>> Parents: b72d446
>> Author: Luc Maisonobe
>> Authored: Tue Nov 3 11:23:46 2015 +0100
>> Committer: Luc Maisonobe
>> Committed: Tue Nov 3 11:23:46 2015 +0100
>>
>>
>>
e new false positives that triggered
test failures on serialization.
best regards,
Luc
Best regards,
Gilles
[...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons
for non-committers are attached
to the JIRA issue (our mailing list strips attachments).
best regards,
Luc
Shouldn't independent changes be performed in separate commits?
[Referring to "IntegerSequence" and "LaguerreSolver".]
I made edits to the Solver in particular beca
] instead.
Git commands to grab the code:
git clone g...@github.com:NormanShapiro/Naomi.git
git checkout gh-pages
Thanks!
Phil
[1] http://markmail.org/message/imoi5aipf63f7rsa
[X] +1 Yes!
Luc
[ ] +0 OK...
[ ] -0 OK, but...
[ ] -1 We should not do this, because
nity I can submit a pull request when
> I've got it worked up. If someone has already designed such a library I'd
> be grateful if someone mentions it before I get started.
This should be discussed in a separate thread.
best regards,
Luc
>
> Best,
> Eric
>
-
of source folders that are
needed for proper build and test is:
/src/main/java
/src/main/resources
/src/test/java
/src/test/resources
Note also that in the libraries tab in the same wizard, you should also
have the Junit 4 library.
Hope this helps
Luc
>
> Thanks,
> Eric
>
-
Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
> Le 26 sept. 2015 12:07, "Luc Maisonobe" a écrit :
>>
>> Le 26/09/2015 20:59, Ralph Goers a écrit :
>>> I don’t normally participate in Math but I do feel the need to stick my
> nose in here.
>>> 1. Y
does work.
>From what I have seen, if I ever were to choose a logging framework for
any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further is
log4j 2 (without any accurate reason, just a rough feeling).
best regards,
the algo can take, are just some
>>> interesting to log, or all of them?
>>>
>>> the use-cases presented so far were mainly about debugging specific
>>> problems, and I am *strongly* against adding logging information just
>>> for this purpose as
Le 24/09/2015 21:40, Ole Ersoy a écrit :
> Hi Luc,
>
> I gave this some more thought, and I think I may have tapped out to
> soon, even though you are absolutely right about what an exception does
> in terms bubbling execution to a point where it stops or we handle it.
>
&g
1 - 100 of 1770 matches
Mail list logo
