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
No. I never use Java serialization if I can help it.
On Sat, Feb 11, 2012 at 8:57 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> On Sat, Feb 11, 2012 at 08:31:53AM -0800, Ted Dunning wrote:
> > Interesting that you say that because long-term storage of data and
> > communication be
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-digester3 has an issue affecting its community integration.
This i
In this case , I am more prone in an API to provide a Wrapper Class
that provides a Serializable view , rather than make everything
Serializable or not.
Leandro A. Pezzente.
On viernes, 10 de febrero de 2012 at 4:41 PM, Gilles Sadowski
wrote:Hi.
This is an issue raised in relation to this JIRA
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18684&projectId=75
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 12 Feb 2012 00:40:03 +
Finished at: Sun 12 Feb 2012 00:41:12 +
Total time: 1m 9s
Build Trigger: Schedule
B
On 12 February 2012 00:05, wrote:
> Author: henrib
> Date: Sun Feb 12 00:05:26 2012
> New Revision: 1243180
>
> URL: http://svn.apache.org/viewvc?rev=1243180&view=rev
> Log:
> Added function to syntax; updated release notes and changes
>
> Modified:
> commons/proper/jexl/trunk/RELEASE-NOTES.tx
Ciao Claudio,
>
> yes that would work (inverse should be replaced with negate, not
> reciprocal). We actually thought of commons-math before: it would feel like
> home for our little stack of interfaces (Semigroup, Monoid, etc).
>
+1
> However my question was more on the semantics for class and
Hello Axel,
Wouldn't it be better to use the same method signatures like in
commons-math FieldElement?
http://commons.apache.org/math/apidocs/org/apache/commons/math/FieldElement.html#reciprocal%28%29
reciprocal instead of inverse and
add instead of append?
yes that would work (inverse should
On 02/11/2012 09:18 PM, Gilles Sadowski wrote:
I would not draw that conclusion.
As a Java library, it would not be wise for CM to move away from the OO
paradigm. People who choose or use Java are accustomed to this programming
style (or, even, like it ;-).
sure, I did not want to give the impr
On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella <
squar...@dia.uniroma3.it> wrote:
>
> Any preference?
>
Wouldn't it be better to use the same method signatures like in
commons-math FieldElement?
http://commons.apache.org/math/apidocs/org/apache/commons/math/FieldElement.html#reciprocal%
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18678&projectId=75
Build statistics:
State: Failed
Previous State: Failed
Started at: Sat 11 Feb 2012 21:42:00 +
Finished at: Sat 11 Feb 2012 21:42:43 +
Total time: 42s
Build Trigger: Schedule
Bui
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18676&projectId=75
Build statistics:
State: Failed
Previous State: Failed
Started at: Sat 11 Feb 2012 20:20:07 +
Finished at: Sat 11 Feb 2012 20:20:40 +
Total time: 33s
Build Trigger: Schedule
Bui
Ciao Claudio!
I understand and agree with you about your doubts - I don't have a
strong idea, anyway I wouldn't take the *Handler as first choice,
since it does not drive users to an event-handler alike programming
model, rather *Operations makes more sense...
Let's take some time to think about
On Sat, Feb 11, 2012 at 07:35:25PM +0100, Thomas Neidhart wrote:
> On 02/11/2012 06:46 PM, Gilles Sadowski wrote:
>
> >[I still have to understand why objects that represent mathematical
> >algorithms must be serializable. It is quite possible that I miss somehing
> >but a use-case would help. In
Hi,
Maybe one last effort can be made to come up with more understandable
names (e.g. for a user that does not know what a Semigroup or Monoid
is). Suggestions are welcome.
I exhume this thread because I am still convinced that the "weight
architecture" would benefit from a bit of renaming.
Hi Andreas,
Feel free to provide a test and a patch ;)
Gary
On Feb 11, 2012, at 13:39, Andreas Menke wrote:
> Hi,
>
> from BaseNCodec.java:
>
> how does resizeBuffer() know how big 'int size' is? Bug or Feature?
>
>/**
> * Ensure that the buffer has room for size bytes
> *
> *
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18675&projectId=95
Build statistics:
State: Failed
Previous State: Failed
Started at: Sat 11 Feb 2012 19:42:31 +
Finished at: Sat 11 Feb 2012 19:42:59 +
Total time: 27s
Build Trigger: Schedule
Bui
looks wrong to me as well.
On 02/11/2012 12:01 PM, Andreas Menke wrote:
Hi,
from BaseNCodec.java:
how does resizeBuffer() know how big 'int size' is? Bug or Feature?
/**
* Ensure that the buffer has room for size bytes
*
* @param size minimum spare space required
*/
Hi,
from BaseNCodec.java:
how does resizeBuffer() know how big 'int size' is? Bug or Feature?
/**
* Ensure that the buffer has room for size bytes
*
* @param size minimum spare space required
*/
protected void ensureBufferSize(int size){
if ((buffer == null)
On 02/11/2012 06:46 PM, Gilles Sadowski wrote:
[I still have to understand why objects that represent mathematical
algorithms must be serializable. It is quite possible that I miss somehing
but a use-case would help. In principle, I'd think that we must provide
accessors that would enable user c
> [...]
>
> However, adding Serializable still means devising and implementing the
> appropriate unit tests.
>
> ==
>
> I'm not saying don't do it, just that it involves a lot more work than
> might be obvious initially.
[Oh, I said that I would not fight over this... :-#]
But the arguments her
On Sat, Feb 11, 2012 at 08:31:53AM -0800, Ted Dunning wrote:
> Interesting that you say that because long-term storage of data and
> communication between distributed components are exactly what I use
> serialization for. Note that communication between components almost
> automatically implies ve
Interesting that you say that because long-term storage of data and
communication between distributed components are exactly what I use
serialization for. Note that communication between components almost
automatically implies version mismatch in lots of production systems
exactly because you can'
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=18666&projectId=75
Build statistics:
State: Failed
Previous State: Ok
Started at: Sat 11 Feb 2012 15:20:10 +
Finished at: Sat 11 Feb 2012 15:20:45 +
Total time: 34s
Build Trigger: Schedule
Build N
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 11 February 2012 12:29, Luc Maisonobe wrote:
> Le 11/02/2012 11:25, sebb a écrit :
>> On 11 February 2012 09:26, Luc Maisonobe wrote:
>>> Hi,
>>>
>>> Le 11/02/2012 05:10, Bill Barker a écrit :
While the development team has exploded for [MATH], maintaining
Serializable interfaces is
Le 11/02/2012 13:17, Benedikt Ritter a écrit :
> Am 10.02.2012 17:34, schrieb Luc Maisonobe:
>> Le 10/02/2012 15:22, Mladen Turk a écrit :
>>> On 02/07/2012 01:52 PM, Mladen Turk wrote:
Votes, please. This vote will close in 72 hours
[X] +1 Release Daemon 1.0.9
[ ] +0 OK, b
Le 11/02/2012 11:25, sebb a écrit :
> On 11 February 2012 09:26, Luc Maisonobe wrote:
>> Hi,
>>
>> Le 11/02/2012 05:10, Bill Barker a écrit :
>>> While the development team has exploded for [MATH], maintaining
>>> Serializable interfaces is expensive and historically hasn't been kept
>>> up.
>>
>>
Bene,
have a look at http://www.apache.org/foundation/voting.html
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sat, Feb 11, 2012 at 1:17 PM, Benedikt Ritter
wrote:
> Am 10.02.2012 17:34, schrie
Am 10.02.2012 17:34, schrieb Luc Maisonobe:
Le 10/02/2012 15:22, Mladen Turk a écrit :
On 02/07/2012 01:52 PM, Mladen Turk wrote:
Votes, please. This vote will close in 72 hours
[X] +1 Release Daemon 1.0.9
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release beca
On 11 February 2012 09:26, Luc Maisonobe wrote:
> Hi,
>
> Le 11/02/2012 05:10, Bill Barker a écrit :
>> While the development team has exploded for [MATH], maintaining
>> Serializable interfaces is expensive and historically hasn't been kept
>> up.
>
> I don't agree.
>
> Maintaining serialization
Hi,
Le 11/02/2012 05:10, Bill Barker a écrit :
> While the development team has exploded for [MATH], maintaining
> Serializable interfaces is expensive and historically hasn't been kept
> up.
I don't agree.
Maintaining serialization maintainance is hard only if you want to be
able to deserialize
We actually did vote on this matter :-)
"Can the next version major version of a project require Java6? (i.e. drop
Java 1.5)"
Result was "yes".
http://apache-commons.680414.n4.nabble.com/RESULT-VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tt4176593.html
Ch
34 matches
Mail list logo
