Hi all,
this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
have accumulated a few bugfixes and at least COMPRESS-264 is pretty
serious.
I've already updated the website from trunk (basically to have the new
skin online) so you can already have a look at the reports.
Before I
On Feb 26, 2014, at 6:23 PM, Bruce A Johnson wrote:
> The NonLinearConjugateGradientOptimizer does a line search for a zero in the
> gradient (see comment from source below), rather than a search for a minimum
> of the function (the latter is what is used in Numerical Recipes and in the
> simp
Hi SCXML and other community members/developers,
After working on the new Commons SCXML 2.0 code base for a few months, doing
some cleaning up and providing minor fixes and improvements, I think we now need
some more serious and drastic changes...
The goal (as it always has been) for Commons
The NonLinearConjugateGradientOptimizer does a line search for a zero in the
gradient (see comment from source below), rather than a search for a minimum of
the function (the latter is what is used in Numerical Recipes and in the simple
discussion on Wikipedia (
http://en.wikipedia.org/wiki/Non
The NonLinearConjugateGradientOptimizer does a line search for a zero in the
gradient (see comment from source below), rather than a search for a minimum of
the function (the latter is what is used in Numerical Recipes and in the simple
discussion on Wikipedia (
http://en.wikipedia.org/wiki/Non
ok.
On Wed, Feb 26, 2014 at 3:00 PM, Mark Thomas wrote:
> On 26/02/2014 19:56, Edmond Kemokai wrote:
> > ok...but the site shows release notes suggesting there was a release:
> > http://commons.apache.org/proper/commons-dbutils/changes-report.html
>
> Looks like (from the svn tags) that there w
On 26/02/2014 19:56, Edmond Kemokai wrote:
> ok...but the site shows release notes suggesting there was a release:
> http://commons.apache.org/proper/commons-dbutils/changes-report.html
Looks like (from the svn tags) that there was a 1.6 RC1 that didn't pass
and the someone updated the website usi
ok...but the site shows release notes suggesting there was a release:
http://commons.apache.org/proper/commons-dbutils/changes-report.html
On Wed, Feb 26, 2014 at 2:52 PM, Mark Thomas wrote:
> On 26/02/2014 19:40, Edmond Kemokai wrote:
> > hi
> >
> > There's no download available for this relea
On 26/02/2014 19:40, Edmond Kemokai wrote:
> hi
>
> There's no download available for this release.
>
That would be because there has not been a 1.6 release.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For addi
hi
There's no download available for this release.
On 26 February 2014 14:26, Mark Thomas wrote:
> On 26/02/2014 13:46, Matt Benson wrote:
>> On Feb 26, 2014 4:35 AM, "Gilles" wrote:
>>>
>>> On Wed, 26 Feb 2014 10:30:00 +, Mark Thomas wrote:
I'm wondering what to do about @since markers. As DBCP2 is in a
completely new package,
On 2/26/14, 6:26 AM, Mark Thomas wrote:
> On 26/02/2014 13:46, Matt Benson wrote:
>> On Feb 26, 2014 4:35 AM, "Gilles" wrote:
>>> On Wed, 26 Feb 2014 10:30:00 +, Mark Thomas wrote:
I'm wondering what to do about @since markers. As DBCP2 is in a
completely new package, arguably everyt
Thanks for pointing this out. However, implementing Get & Put directly
would pose the following problems.
If interface MultiValuedMap extends Get>
the method "values" would be forced to have a signature of
Collection> values()
whereas we would want
Collection values().
This wont be possible a
On 26/02/2014 13:46, Matt Benson wrote:
> On Feb 26, 2014 4:35 AM, "Gilles" wrote:
>>
>> On Wed, 26 Feb 2014 10:30:00 +, Mark Thomas wrote:
>>>
>>> I'm wondering what to do about @since markers. As DBCP2 is in a
>>> completely new package, arguably everything is new for this release. The
>>> e
On Feb 26, 2014 4:35 AM, "Gilles" wrote:
>
> On Wed, 26 Feb 2014 10:30:00 +, Mark Thomas wrote:
>>
>> I'm wondering what to do about @since markers. As DBCP2 is in a
>> completely new package, arguably everything is new for this release. The
>> existing @since markers don't make a lot of sense
Don't forget about the Get/Put/split map concepts from Collections 4. It
would seem you could implement those interfaces and provide that amount of
abstraction anyway.
Matt
On Feb 26, 2014 3:26 AM, "Dipanjan Laha" wrote:
> Hi Thomas,
>
> This sounds great. Moving MultiKeyMap to the new package d
On 2014-02-26, Mark Thomas wrote:
> I'm wondering what to do about @since markers. As DBCP2 is in a
> completely new package, arguably everything is new for this release. The
> existing @since markers don't make a lot of sense. Therefore, I am
> currently considering removing all @since markers fr
On Wed, 26 Feb 2014 10:30:00 +, Mark Thomas wrote:
I'm wondering what to do about @since markers. As DBCP2 is in a
completely new package, arguably everything is new for this release.
The
existing @since markers don't make a lot of sense. Therefore, I am
currently considering removing all @
I'm wondering what to do about @since markers. As DBCP2 is in a
completely new package, arguably everything is new for this release. The
existing @since markers don't make a lot of sense. Therefore, I am
currently considering removing all @since markers from the code base.
They would then be used f
Le 25/02/2014 18:43, Gary Gregory a écrit :
> All of the @author tags need to be removed to follow ASF guidelines. And
> no, you do not need 'permission' from the @author to do this ;)
It doesn't *need* to, it's simply discouraged. And I find it really rude
to remove it without asking.
Emmanuel B
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=28250&projectId=74
Build statistics:
State: Failed
Previous State: Failed
Started at: Wed 26 Feb 2014 09:44:57 +
Finished at: Wed 26 Feb 2014 09:45:15 +
Total time: 18s
Build Trigger: Schedule
Hi Thomas,
This sounds great. Moving MultiKeyMap to the new package does sound like
the way to go ahead. I will start with the implementation of the interface
and the MultiValuedHashMap. I should be able to submit a patch with a basic
implementation and some test cases by the end of this week. I c
Hi Dipanjan,
I was thinking about a name for the new interface, but I actually like your
proposal of MultiValuedMap.
For the package, I think we can stick with multimap, and at some point we
could also move the MultiKeyMap there, which would be logical imho.
The implementation names are also sou
Hi Thomas,
It would be great if we can start the discussion on the new interface for
MultiMap and a new package for the implementations as suggested by you.
Then I'll be able to put some code together for the same.
IMO we can have
1. New Interface for MultiMap with the name MultiValuedMap or Mul
24 matches
Mail list logo
