Re: [lang] Time for RC3?

[Henri Yandell]

Assuming no one vetos my r1090111 rollback, I think we can go for an
RC4. There are non-API bugs in JIRA, but I'd rather we release with
some bugs and then start fixing/releasing than continually get held
up.

How are you timewise for RC4 Matt? I'm still very kidbound, but
beginning to get some time back.

Hen

On Fri, Jun 17, 2011 at 10:39 PM, Henri Yandell  wrote:
> On Fri, Jun 17, 2011 at 8:17 PM, Matt Benson  wrote:
>> On Fri, Jun 17, 2011 at 9:00 PM, Henri Yandell  wrote:
>>> We had an RC3 vote so shouldn't remove; but I'm very happy if you've
>>> time to do an RC4. I've been managing about enough time to look at the
>>> outstanding issues before I'm back to the diapers.
>>>
>>
>> That's why I asked... I couldn't find the evidence of the RC3 vote for
>> some reason, but I'll take your word for it.
>
> I injected a little confusion by having two threads :)
>
> http://commons.markmail.org/thread/dxmser7yfew37sqb
> http://commons.markmail.org/thread/xk34bmkoz6jctt7g
>
>>> Which is 'what's in JIRA' plus the discussion on the text.translate/Range 
>>> API.
>>
>> JIRA seems clear, no?  Do we need to wait on the other issue, then?
>
> The thread was:
>
> "[LANG] unnecessary boxing in StringEscapeUtils etc"
>
> Sebb had a complaint re: performance concerns with boxing and Stephen
> suggested a solution, while also considering the performance issue
> minor.
>
> I spent some time a week back playing with the API as I disliked the
> overlap between Range and Range. Autoboxing,
> generics and char-int conversion all get fiddly in the API and not
> nice.
>
> I'm tempted to move the current (Range) constructors to a
> static factory method, and then go ahead and release - text.translate
> is not a major part of the Lang API. The reason for doing that is so
> that we can deprecate it later on if desired and not have to worry
> about lots of clashing with the replacement methods.
>
> Hen
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] unnecessary boxing in StringEscapeUtils etc.

[Henri Yandell]

On Thu, May 19, 2011 at 6:30 AM, Gary Gregory  wrote:
> On Thu, May 19, 2011 at 12:47 AM, Henri Yandell  wrote:
>
>> *grumbles that they were ints and a previous RC candidate saw it
>> change to Range* :)
>>
>
>
> Change it back! ;)

Tongue in cheek as it might be, I think this is the right direction.

Forcing it onto the Range API made it less useable, so best to stay
with the original more useable code even if it implies some redundancy
code-wise.

It might imply that we need subclasses to Ranges; but I think int and
char are a wee bit special and it's no reason to doubt the Range
class.

I've rolled back the commit:

svn ci -m "Reverting r1090111 - moving the text.translate escapers
back from using Range to replicating parts of the Range API. See the
list for details ('unnecessary boxing in StringEscapeUtils etc'), the
move to Range was an uncomfortable fit. "

Sendingsrc/main/java/org/apache/commons/lang3/StringEscapeUtils.java
Sending
src/main/java/org/apache/commons/lang3/text/translate/NumericEntityEscaper.java
Sending
src/main/java/org/apache/commons/lang3/text/translate/UnicodeEscaper.java
Sending
src/test/java/org/apache/commons/lang3/text/translate/NumericEntityEscaperTest.java
Sending
src/test/java/org/apache/commons/lang3/text/translate/UnicodeEscaperTest.java
Transmitting file data .
Committed revision 1142151.


Hen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] Release date for common lang 3.0 (Final Release)

[Henri Yandell]

There is no planned release date.

We release when the release is ready and there's currently one
blocking API issue regarding the text.translate package.

Once that issue is resolved then another release candidate can be
proposed; currently no one is working on the issue though.

Hen

On Fri, Jul 1, 2011 at 2:05 AM, Rohan Kadam  wrote:
> Hi,
>
> Please let me know, when common lang 3.0 will be moved from Beta to Final 
> Release?
>
> Thanks,
> Rohan Kadam.
>
>
> "Legal Disclaimer: This electronic message and all contents contain 
> information from Cybage Software Private Limited which may be privileged, 
> confidential, or otherwise protected from disclosure. The information is 
> intended to be for the addressee(s) only. If you are not an addressee, any 
> disclosure, copy, distribution, or use of the contents of this message is 
> strictly prohibited. If you have received this electronic message in error 
> please notify the sender by reply e-mail to and destroy the original message 
> and all copies. Cybage has taken every reasonable precaution to minimize the 
> risk of malicious content in the mail, but is not liable for any damage you 
> may sustain as a result of any malicious content in this e-mail. You should 
> carry out your own malicious content checks before opening the e-mail or 
> attachment." www.cybage.com
>
>
> "Legal Disclaimer: This electronic message and all contents contain 
> information from Cybage Software Private Limited which may be privileged, 
> confidential, or otherwise protected from disclosure. The information is 
> intended to be for the addressee(s) only. If you are not an addressee, any 
> disclosure, copy, distribution, or use of the contents of this message is 
> strictly prohibited. If you have received this electronic message in error 
> please notify the sender by reply e-mail to and destroy the original message 
> and all copies. Cybage has taken every reasonable precaution to minimize the 
> risk of malicious content in the mail, but is not liable for any damage you 
> may sustain as a result of any malicious content in this e-mail. You should 
> carry out your own malicious content checks before opening the e-mail or 
> attachment."
> www.cybage.com
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: (MATH-608) Remove methods from RealMatrix Interface

[Phil Steitz]

On 7/1/11 4:26 PM, Gilles Sadowski wrote:
> Hi.
>
>> Luc suggested that I move this discussion to the list. Luc posed the
>> question:
>>
>> "I don't understand how you intend to separate the API.
>> Would that mean users would always have to know beforehand the shape of the
>> matrix they use and manage both the matrix, the data store and the operators
>> in sync ?"
>>
>> I think my longwinded report was not as clear as it should have been. I want
>> to simplify the RealMatrix interface and implementing classes. In my mind's
>> eye, I see the real matrix interface as describing the shape of the data,
>> holding that data and giving the user an indexing scheme to get at an
>> element.
>>
>> My concern with the current interface is that if different shapes of
>> matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the matrix
>> manipulation routines (add, subtract, mult, ...) become very complicated.
>>
>> In my proposal, I argue that we might have another class, say
>> MatrixOperations.
>>
>> It would have routines for Mutlitplication that depend on type. A small
>> subset of the interface might look like:
>>
>> public interface MatrixOpsIface{
>> public SymmetricMatrix selfTimesTranspose( SymmetricMatrix sm );
>> public SymmetricMatrix selfTimesTranspose( GeneralMatrix sm );
>> public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
>> GeneralMatrix gm);
>> public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
>> SymmericMatrix sm2);
>> public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
>> SymmetricMatrix gm);
>> public GeneralMatrix multipy( DiagonalMatrix dm, GeneralMatrix gm);
>> public GeneralMatrix multiply( SymmetricMatrix sm, GeneralMatrix gm);
>> public DiagonalMatrix multiply( DiagonalMatrix dm, DiagonalMatrix dm);
>> }
>>
>> The benefit of doing this would be that you could write highly optimized
>> multiplication routines dependent on the shape of the matrices. All of the
>> complexity would be handled by the compiler. The user would simply
>> instantiate the operations object (maybe these could be static methods), and
>> call multiply. Adding a new matrix shape would be require an two check ins,
>> the code for the new matrix as well as a new set of methods for handling
>> multiplication, etc, with the other types.
> The idea of separating the algorithms from the storage layout sounds nice
> but why would a class implementing "MatrixOpsIface" be more performant, or
> simpler, than adding specialized "mutliply" methods within the RealMatrix
> implementations themselves?

+1

IIRC, we used to have a MatrixUtils class that encapsulated
RealMatrix operations, but we decided in this case (and for Complex)
to re-integrate.   I am not (yet) sold on the proposition that
splitting things back out does anything more than just move the problem.

> E.g.
> ---CUT---
> public class Array2DRowRealMatrix {
>   public Array2DRowRealMatrix multiply(Array2DRowRealMatrix m) { /* ... */ }
>   public Array2DRowRealMatrix multiply(DiagonalRealMatrix m) { /* ... */ }
>   /* ... */
> }
> ---CUT---
>
> Also, there seems to be the problem of exposing the internals (storage
> layout) so that the implementations of "MatrixOpsIface" can actually make
> use of them. This would break encapsulation: The layout would becomes part
> of the interface.
>
> Still, publicizing the operators might be interesting. With generics:
> ---CUT---
> interface MultiplyO extends RealMatrix> {
> public O multiply(M m);
> }
> ---CUT---
>
> Hence, we advertise which operations are type-optimized:
> ---CUT---
> public class Array2DRowRealMatrix
> implements Multiply,
>Multiply {
> // ...
> }
>
> Sorry, if this is all besides the point; without a concrete example, it's
> difficult to figure what must be improved.

Agreed.  I think its best to look at the actual practical examples. 
Above idea is interesting.  Will it solve your problem, Greg?

Phil
> Also, you could have a look at
>   http://www.ojalgo.org
>
>
> Best,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: (MATH-608) Remove methods from RealMatrix Interface

[Phil Steitz]

On 7/1/11 5:31 PM, Ted Dunning wrote:
> On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski 
> wrote:
>
>> This may be a problem. Type erasure might necessitate some tricky use of
>> generics.
>>
> That won't help.  Good coding practice is to declare a variable with as weak
> a type as possible so that libraries have maximum freedom to act.  That
> means that the generics framework has nothing to work with in terms of type
> inferencing.
>
> Also, if I am writing a library function, I want to specify my input as very
> weak types to maximize the generality of my code.  By I want those matrices
> that I am passed to still dispatch to the most efficient implementation for
> matrix operations.  For instance, if I am normalizing a matrix, I want to
> say divide by the norm and have the matrix know how to compute the norm
> quickly and not go scaling all the sparse zeros that may not exist in the
> matrix.  I desperately DON'T want to put restrictive types in my application
> code that is normalizing.
>
>
>
>> On the SVD, if that's a bug, then the method which yields a reference to
>> the
>> data array in realmatrix is also a bug.
>>
> Pretty much.
>
> But I gave up on worrying about API bugs in frozen projects like Math.

Please stop wasting bandwidth with worthless comments like above. 
Specific, implementable, concrete suggestions for improvement to the
[math] API are welcome and have been and will be implemented. 
Patches welcome.  Winging as above, not.

Phil


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

On Fri, Jul 1, 2011 at 4:59 PM, Greg Sterijevski wrote:

> This may be a problem. Type erasure might necessitate some tricky use of
> generics.
>

That won't help.  Good coding practice is to declare a variable with as weak
a type as possible so that libraries have maximum freedom to act.  That
means that the generics framework has nothing to work with in terms of type
inferencing.

Also, if I am writing a library function, I want to specify my input as very
weak types to maximize the generality of my code.  By I want those matrices
that I am passed to still dispatch to the most efficient implementation for
matrix operations.  For instance, if I am normalizing a matrix, I want to
say divide by the norm and have the matrix know how to compute the norm
quickly and not go scaling all the sparse zeros that may not exist in the
matrix.  I desperately DON'T want to put restrictive types in my application
code that is normalizing.



> On the SVD, if that's a bug, then the method which yields a reference to
> the
> data array in realmatrix is also a bug.
>

Pretty much.

But I gave up on worrying about API bugs in frozen projects like Math.

Re: (MATH-608) Remove methods from RealMatrix Interface

[Greg Sterijevski]

This may be a problem. Type erasure might necessitate some tricky use of
generics.

On the SVD, if that's a bug, then the method which yields a reference to the
data array in realmatrix is also a bug.

On Fri, Jul 1, 2011 at 6:53 PM, Ted Dunning  wrote:

> Actually, the compiler can't do the dispatch correctly.
>
> For instance, given the following approximately real code:
>
> Matrix a = new SparseMatrix(...);
> Matrix b = new DiagonalMatrix(...);
>
> This line will not dispatch to a special case method for either
> SparseMatrix
> or DiagonalMatrix:
>
> MatrixOperator.times(a, b)
>
> This is because a and b are just Matrix objects according to the compiler.
>
> You have to invent a way to do runtime dispatching.
>
> On Fri, Jul 1, 2011 at 4:45 PM, Greg Sterijevski  >wrote:
>
> > There is no magic which will remove the elemental complexity of these
> > things. However, the complexity would be concentrated in the operator
> > classes, where it probably should be. Furthermore, the type matching
> would
> > be handled by compiler. Finally, the multiplication routines would grow
> as
> > a
> > need for those operations arises.
> >
>

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

Actually, the compiler can't do the dispatch correctly.

For instance, given the following approximately real code:

 Matrix a = new SparseMatrix(...);
 Matrix b = new DiagonalMatrix(...);

This line will not dispatch to a special case method for either SparseMatrix
or DiagonalMatrix:

 MatrixOperator.times(a, b)

This is because a and b are just Matrix objects according to the compiler.

You have to invent a way to do runtime dispatching.

On Fri, Jul 1, 2011 at 4:45 PM, Greg Sterijevski wrote:

> There is no magic which will remove the elemental complexity of these
> things. However, the complexity would be concentrated in the operator
> classes, where it probably should be. Furthermore, the type matching would
> be handled by compiler. Finally, the multiplication routines would grow as
> a
> need for those operations arises.
>

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

I count that as a bug in the SVD class.

On Fri, Jul 1, 2011 at 4:45 PM, Greg Sterijevski wrote:

> You are correct that moving these operations to an external class would
> expose details of data storage and break encapsulation. However, this is
> done consistently throughout math commons-look at the principal components
> class. The SVD  class asks for a reference to the data array (if memory
> serves me).
>

Fwd: (MATH-608) Remove methods from RealMatrix Interface

[Greg Sterijevski]

No sure if this went through originally, sorry if this causes a duplicate to
occur.

-Greg

-- Forwarded message --
From: Greg Sterijevski 
Date: Fri, Jul 1, 2011 at 6:45 PM
Subject: Re: (MATH-608) Remove methods from RealMatrix Interface
To: Commons Developers List , d...@commons.apache.or


Hi Gilles,

There is no magic which will remove the elemental complexity of these
things. However, the complexity would be concentrated in the operator
classes, where it probably should be. Furthermore, the type matching would
be handled by compiler. Finally, the multiplication routines would grow as a
need for those operations arises.

You are correct that moving these operations to an external class would
expose details of data storage and break encapsulation. However, this is
done consistently throughout math commons-look at the principal components
class. The SVD  class asks for a reference to the data array (if memory
serves me).

 -Greg

Re: (MATH-608) Remove methods from RealMatrix Interface

[Greg Sterijevski]

Hi Gilles,

There is no magic which will remove the elemental complexity of these
things. However, the complexity would be concentrated in the operator
classes, where it probably should be. Furthermore, the type matching would
be handled by compiler. Finally, the multiplication routines would grow as a
need for those operations arises.

You are correct that moving these operations to an external class would
expose details of data storage and break encapsulation. However, this is
done consistently throughout math commons-look at the principal components
class. The SVD  class asks for a reference to the data array (if memory
serves me).

 -Greg

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

One concrete example where second argument runtime type dispatching is
helpful is the case of multiplying a dense matrix (of any kind) by a sparse
vector.  It is preferable to put the smarts for how to do this on in the
sparse vector rather than in the dense matrix, but object oriented dispatch
gives us the option to put the method on the matrix.

On Fri, Jul 1, 2011 at 4:26 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> ...
> The idea of separating the algorithms from the storage layout sounds nice
> but why would a class implementing "MatrixOpsIface" be more performant, or
> simpler, than adding specialized "mutliply" methods within the RealMatrix
> implementations themselves?
> E.g.
> ---CUT---
> public class Array2DRowRealMatrix {
>  public Array2DRowRealMatrix multiply(Array2DRowRealMatrix m) { /* ... */ }
>  public Array2DRowRealMatrix multiply(DiagonalRealMatrix m) { /* ... */ }
>  /* ... */
> }
> ---CUT---
>
> Also, there seems to be the problem of exposing the internals (storage
> layout) so that the implementations of "MatrixOpsIface" can actually make
> use of them. This would break encapsulation: The layout would becomes part
> of the interface.
>
> Still, publicizing the operators might be interesting. With generics:
> ---CUT---
> interface Multiply   O extends RealMatrix> {
>public O multiply(M m);
> }
> ---CUT---
>
> Hence, we advertise which operations are type-optimized:
> ---CUT---
> public class Array2DRowRealMatrix
>implements Multiply,
>   Multiply {
>// ...
> }
>
> Sorry, if this is all besides the point; without a concrete example, it's
> difficult to figure what must be improved.
>
> Also, you could have a look at
>  http://www.ojalgo.org
>
>
>

Re: (MATH-608) Remove methods from RealMatrix Interface

[Gilles Sadowski]

Hi.

> Luc suggested that I move this discussion to the list. Luc posed the
> question:
> 
> "I don't understand how you intend to separate the API.
> Would that mean users would always have to know beforehand the shape of the
> matrix they use and manage both the matrix, the data store and the operators
> in sync ?"
> 
> I think my longwinded report was not as clear as it should have been. I want
> to simplify the RealMatrix interface and implementing classes. In my mind's
> eye, I see the real matrix interface as describing the shape of the data,
> holding that data and giving the user an indexing scheme to get at an
> element.
> 
> My concern with the current interface is that if different shapes of
> matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the matrix
> manipulation routines (add, subtract, mult, ...) become very complicated.
> 
> In my proposal, I argue that we might have another class, say
> MatrixOperations.
> 
> It would have routines for Mutlitplication that depend on type. A small
> subset of the interface might look like:
> 
> public interface MatrixOpsIface{
> public SymmetricMatrix selfTimesTranspose( SymmetricMatrix sm );
> public SymmetricMatrix selfTimesTranspose( GeneralMatrix sm );
> public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> GeneralMatrix gm);
> public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> SymmericMatrix sm2);
> public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> SymmetricMatrix gm);
> public GeneralMatrix multipy( DiagonalMatrix dm, GeneralMatrix gm);
> public GeneralMatrix multiply( SymmetricMatrix sm, GeneralMatrix gm);
> public DiagonalMatrix multiply( DiagonalMatrix dm, DiagonalMatrix dm);
> }
> 
> The benefit of doing this would be that you could write highly optimized
> multiplication routines dependent on the shape of the matrices. All of the
> complexity would be handled by the compiler. The user would simply
> instantiate the operations object (maybe these could be static methods), and
> call multiply. Adding a new matrix shape would be require an two check ins,
> the code for the new matrix as well as a new set of methods for handling
> multiplication, etc, with the other types.

The idea of separating the algorithms from the storage layout sounds nice
but why would a class implementing "MatrixOpsIface" be more performant, or
simpler, than adding specialized "mutliply" methods within the RealMatrix
implementations themselves?
E.g.
---CUT---
public class Array2DRowRealMatrix {
  public Array2DRowRealMatrix multiply(Array2DRowRealMatrix m) { /* ... */ }
  public Array2DRowRealMatrix multiply(DiagonalRealMatrix m) { /* ... */ }
  /* ... */
}
---CUT---

Also, there seems to be the problem of exposing the internals (storage
layout) so that the implementations of "MatrixOpsIface" can actually make
use of them. This would break encapsulation: The layout would becomes part
of the interface.

Still, publicizing the operators might be interesting. With generics:
---CUT---
interface Multiply {
public O multiply(M m);
}
---CUT---

Hence, we advertise which operations are type-optimized:
---CUT---
public class Array2DRowRealMatrix
implements Multiply,
   Multiply {
// ...
}

Sorry, if this is all besides the point; without a concrete example, it's
difficult to figure what must be improved.

Also, you could have a look at
  http://www.ojalgo.org


Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

On Fri, Jul 1, 2011 at 2:35 PM, Greg Sterijevski wrote:

> My request stems from attempting to build a SymmetricRealMatrix which
> stores
> its contents in a packed format. I began implementing multiply and so forth
> and did not relish having a bunch of case statements. This lead me to the
> idea of removing all operations involving other matrices to a separate
> class.
>

Fair.  I have been approximately the same place.


> I am not clear about why using java's type system is such a bad thing. A
> diagonal is different from a symmetric. Both fall under the "is a"
> condition. Each is an example of a matrix-but different enough to merit its
> own class.
>

Diagonal is different from symmetric, but diagonal is sparse and so is a row
based hashed representation as is a tri-diagonal matrix.  A single
implementation can be used to get decent performance on diagonal,
band-diagonal, random sparse and sequentially accessible sparse
representations.  On the other hand, symmetric matrices can be sparse or
not, but allow separate optimizations.

It is this multiple inheritance that makes the type system unsatisfactory.
 Even worse, the type system dispatches based on the compile-time
declaration, not the runtime type.  Thus, if I have a Matrix which happens
to be a diagonal matrix, Java will pick the general case, not the special
case.

Sadly, a case statement won't even work for this.  All that works, really is
a sequence of if (x instanceof Y) statements.

I will look at Mahout's solution for this. I guess a better question to the
> list would have been: "What is the best way to implement a symmetric matrix
> where only the lower (or upper) triangular portion is kept?"
>

Wow.  Now you are asking a hard question!

(my preference is fancy stride indexing into a single indexed double array
to get a triangular matrix and then a layer to get symmetry.  The triangular
matrix can actually be just an instance of a general dense matrix if you
have sufficiently general striding).

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

Double dispatch was the wrong term.  I should have said double argument
polymorphism.  Double dispatch is a sub-optimal answer to the problem of
double polymorphism.

Apologies for polluting the discussion with a silly error.

On Fri, Jul 1, 2011 at 2:35 PM, Greg Sterijevski wrote:

> Ted,
>
> I am not sure why you think there will be double dispatch. If we remove the
> multiplication method from the interface then there can only be one call to
> multiply. If we want to keep the interface as is and also have a MatrixOps
> class, then perhaps that is where we might have such a case. I am either
> for
> the status quo, or the elimination of the operations I noted in my feature
> request. Supporting both would be a disaster...
>
> My request stems from attempting to build a SymmetricRealMatrix which
> stores
> its contents in a packed format. I began implementing multiply and so forth
> and did not relish having a bunch of case statements. This lead me to the
> idea of removing all operations involving other matrices to a separate
> class.
>
> I am not clear about why using java's type system is such a bad thing. A
> diagonal is different from a symmetric. Both fall under the "is a"
> condition. Each is an example of a matrix-but different enough to merit its
> own class.
>
> As for the second "MatrixOps" class. The utility of such a class is that
> the
> multiply routine is added when there is a need for it. I may have
> GregsZigZagMatrix, whose only user is Greg. If I only multiply
> GregsZigZagMatrix matrix with a diagonal, then that's the only method we
> would implement. In the current schema, I would need to either support all
> existing matrix patterns, support a few and throw exceptions on others, or
> have a default case which is unoptimized and uses the element getter
> method.
>
>
> I will look at Mahout's solution for this. I guess a better question to the
> list would have been: "What is the best way to implement a symmetric matrix
> where only the lower (or upper) triangular portion is kept?"
>
> Thank you,
>
> -Greg
>
>
> On Fri, Jul 1, 2011 at 12:45 PM, Ted Dunning 
> wrote:
>
> > Getting double dispatch this way leads to a pretty ugly API interface.
> >
> > There is no reason why Matrix.times can't delegate to
> MatrixOp.times(this,
> > other), though.  That gives you your double dispatch.
> >
> > The real problem with this design is that adding a new matrix type is no
> > longer something that a user can do and all of your dispatch almost has
> to
> > be done based on Java type structure.  That isn't really what you want.
>  In
> > Mahout, for instance, we have a fair bit of special purpose code that
> uses
> > special indicator methods like isSparse().  In retrospect, I think we
> might
> > have missed a bet and should have used indicator interfaces instead, but
> > the
> > differences aren't huge.
> >
> > The cost is that most of our cleverness lives in AbstractMatrix in the
> form
> > of cascaded if statements rather than nice stylish polymorphism.  This
> > design does, however, allow user written classes to add a layer of their
> > own
> > special casing before delegating to the super class.
> >
> > The question of whether users ever really need to write their own matrix
> > class is difficult to answer.  In Mahout, the answer was thought to be
> no,
> > because users hadn't.  On the other hand, now that users can, they do.
> >  This
> > is partly because Mahout lives on the edge of new parallel paradigms and
> > users need to experiment a lot to get things right before contributing
> > back.
> >  I suspect that they same is true of Commons Math, just on a longer time
> > scale.  The needs for experimentation are less dire than with Mahout, but
> > the pace of change is also glacial.  In my mind, this leads to a similar
> > ratio of need / change-rate and may indicate that a similar solution
> would
> > be a good idea.
> >
> > On Fri, Jul 1, 2011 at 7:36 AM, Greg Sterijevski  > >wrote:
> >
> > > Hello All,
> > >
> > > Luc suggested that I move this discussion to the list. Luc posed the
> > > question:
> > >
> > > "I don't understand how you intend to separate the API.
> > > Would that mean users would always have to know beforehand the shape of
> > the
> > > matrix they use and manage both the matrix, the data store and the
> > > operators
> > > in sync ?"
> > >
> > > I think my longwinded report was not as clear as it should have been. I
> > > want
> > > to simplify the RealMatrix interface and implementing classes. In my
> > mind's
> > > eye, I see the real matrix interface as describing the shape of the
> data,
> > > holding that data and giving the user an indexing scheme to get at an
> > > element.
> > >
> > > My concern with the current interface is that if different shapes of
> > > matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the
> matrix
> > > manipulation routines (add, subtract, mult, ...) become very
> complicated.
> > >
> > > In my proposal, I argue that we

Re: (MATH-608) Remove methods from RealMatrix Interface

[Greg Sterijevski]

Ted,

I am not sure why you think there will be double dispatch. If we remove the
multiplication method from the interface then there can only be one call to
multiply. If we want to keep the interface as is and also have a MatrixOps
class, then perhaps that is where we might have such a case. I am either for
the status quo, or the elimination of the operations I noted in my feature
request. Supporting both would be a disaster...

My request stems from attempting to build a SymmetricRealMatrix which stores
its contents in a packed format. I began implementing multiply and so forth
and did not relish having a bunch of case statements. This lead me to the
idea of removing all operations involving other matrices to a separate
class.

I am not clear about why using java's type system is such a bad thing. A
diagonal is different from a symmetric. Both fall under the "is a"
condition. Each is an example of a matrix-but different enough to merit its
own class.

As for the second "MatrixOps" class. The utility of such a class is that the
multiply routine is added when there is a need for it. I may have
GregsZigZagMatrix, whose only user is Greg. If I only multiply
GregsZigZagMatrix matrix with a diagonal, then that's the only method we
would implement. In the current schema, I would need to either support all
existing matrix patterns, support a few and throw exceptions on others, or
have a default case which is unoptimized and uses the element getter method.


I will look at Mahout's solution for this. I guess a better question to the
list would have been: "What is the best way to implement a symmetric matrix
where only the lower (or upper) triangular portion is kept?"

Thank you,

-Greg


On Fri, Jul 1, 2011 at 12:45 PM, Ted Dunning  wrote:

> Getting double dispatch this way leads to a pretty ugly API interface.
>
> There is no reason why Matrix.times can't delegate to MatrixOp.times(this,
> other), though.  That gives you your double dispatch.
>
> The real problem with this design is that adding a new matrix type is no
> longer something that a user can do and all of your dispatch almost has to
> be done based on Java type structure.  That isn't really what you want.  In
> Mahout, for instance, we have a fair bit of special purpose code that uses
> special indicator methods like isSparse().  In retrospect, I think we might
> have missed a bet and should have used indicator interfaces instead, but
> the
> differences aren't huge.
>
> The cost is that most of our cleverness lives in AbstractMatrix in the form
> of cascaded if statements rather than nice stylish polymorphism.  This
> design does, however, allow user written classes to add a layer of their
> own
> special casing before delegating to the super class.
>
> The question of whether users ever really need to write their own matrix
> class is difficult to answer.  In Mahout, the answer was thought to be no,
> because users hadn't.  On the other hand, now that users can, they do.
>  This
> is partly because Mahout lives on the edge of new parallel paradigms and
> users need to experiment a lot to get things right before contributing
> back.
>  I suspect that they same is true of Commons Math, just on a longer time
> scale.  The needs for experimentation are less dire than with Mahout, but
> the pace of change is also glacial.  In my mind, this leads to a similar
> ratio of need / change-rate and may indicate that a similar solution would
> be a good idea.
>
> On Fri, Jul 1, 2011 at 7:36 AM, Greg Sterijevski  >wrote:
>
> > Hello All,
> >
> > Luc suggested that I move this discussion to the list. Luc posed the
> > question:
> >
> > "I don't understand how you intend to separate the API.
> > Would that mean users would always have to know beforehand the shape of
> the
> > matrix they use and manage both the matrix, the data store and the
> > operators
> > in sync ?"
> >
> > I think my longwinded report was not as clear as it should have been. I
> > want
> > to simplify the RealMatrix interface and implementing classes. In my
> mind's
> > eye, I see the real matrix interface as describing the shape of the data,
> > holding that data and giving the user an indexing scheme to get at an
> > element.
> >
> > My concern with the current interface is that if different shapes of
> > matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the matrix
> > manipulation routines (add, subtract, mult, ...) become very complicated.
> >
> > In my proposal, I argue that we might have another class, say
> > MatrixOperations.
> >
> > It would have routines for Mutlitplication that depend on type. A small
> > subset of the interface might look like:
> >
> > public interface MatrixOpsIface{
> >public SymmetricMatrix selfTimesTranspose( SymmetricMatrix sm );
> >public SymmetricMatrix selfTimesTranspose( GeneralMatrix sm );
> >public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> > GeneralMatrix gm);
> >public SymmetricMatrix sandwichProduct( Symmetric

Re: (MATH-608) Remove methods from RealMatrix Interface

[Ted Dunning]

Getting double dispatch this way leads to a pretty ugly API interface.

There is no reason why Matrix.times can't delegate to MatrixOp.times(this,
other), though.  That gives you your double dispatch.

The real problem with this design is that adding a new matrix type is no
longer something that a user can do and all of your dispatch almost has to
be done based on Java type structure.  That isn't really what you want.  In
Mahout, for instance, we have a fair bit of special purpose code that uses
special indicator methods like isSparse().  In retrospect, I think we might
have missed a bet and should have used indicator interfaces instead, but the
differences aren't huge.

The cost is that most of our cleverness lives in AbstractMatrix in the form
of cascaded if statements rather than nice stylish polymorphism.  This
design does, however, allow user written classes to add a layer of their own
special casing before delegating to the super class.

The question of whether users ever really need to write their own matrix
class is difficult to answer.  In Mahout, the answer was thought to be no,
because users hadn't.  On the other hand, now that users can, they do.  This
is partly because Mahout lives on the edge of new parallel paradigms and
users need to experiment a lot to get things right before contributing back.
 I suspect that they same is true of Commons Math, just on a longer time
scale.  The needs for experimentation are less dire than with Mahout, but
the pace of change is also glacial.  In my mind, this leads to a similar
ratio of need / change-rate and may indicate that a similar solution would
be a good idea.

On Fri, Jul 1, 2011 at 7:36 AM, Greg Sterijevski wrote:

> Hello All,
>
> Luc suggested that I move this discussion to the list. Luc posed the
> question:
>
> "I don't understand how you intend to separate the API.
> Would that mean users would always have to know beforehand the shape of the
> matrix they use and manage both the matrix, the data store and the
> operators
> in sync ?"
>
> I think my longwinded report was not as clear as it should have been. I
> want
> to simplify the RealMatrix interface and implementing classes. In my mind's
> eye, I see the real matrix interface as describing the shape of the data,
> holding that data and giving the user an indexing scheme to get at an
> element.
>
> My concern with the current interface is that if different shapes of
> matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the matrix
> manipulation routines (add, subtract, mult, ...) become very complicated.
>
> In my proposal, I argue that we might have another class, say
> MatrixOperations.
>
> It would have routines for Mutlitplication that depend on type. A small
> subset of the interface might look like:
>
> public interface MatrixOpsIface{
>public SymmetricMatrix selfTimesTranspose( SymmetricMatrix sm );
>public SymmetricMatrix selfTimesTranspose( GeneralMatrix sm );
>public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> GeneralMatrix gm);
>public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> SymmericMatrix sm2);
>public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
> SymmetricMatrix gm);
>public GeneralMatrix multipy( DiagonalMatrix dm, GeneralMatrix gm);
>public GeneralMatrix multiply( SymmetricMatrix sm, GeneralMatrix gm);
>public DiagonalMatrix multiply( DiagonalMatrix dm, DiagonalMatrix dm);
> }
>
> The benefit of doing this would be that you could write highly optimized
> multiplication routines dependent on the shape of the matrices. All of the
> complexity would be handled by the compiler. The user would simply
> instantiate the operations object (maybe these could be static methods),
> and
> call multiply. Adding a new matrix shape would be require an two check ins,
> the code for the new matrix as well as a new set of methods for handling
> multiplication, etc, with the other types.
>
> -Greg
>

[CANCEL][VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Simone Tripodi]

Hi all guys,
the Digester3 RC1 can be considered failed due to missing release
requirements that Luc reported.
Thanks everybody who put his effort on reviewing, and be ready for the RC2!!!
Have a nice day, all the best!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Jul 1, 2011 at 4:04 PM, Luc Maisonobe  wrote:
> Le 01/07/2011 15:08, Simone Tripodi a écrit :
>>
>> Salut Luc,
>
> Hi Simone,
>
>> can we close this vote thread in order I can fix the open issues or we
>> have to wait this evening?
>
> I guess you can cancel it and prepare a new one. I'm pretty sure people will
> wait for the next RC to check it.
>
> best regards,
> Luc
>
>
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Jul 1, 2011 at 3:06 PM, Luc Maisonobe
>>  wrote:
>>>
>>> Le 01/07/2011 15:02, Simone Tripodi a écrit :

 Salut Luc!

>
> -1
>
> The gpg signature seems to have been done with key 41A0D191 which is
> not
> your Apache signing key. The Apache signature key present in the KEYS
> file
> is either 19FEA27D or C002CC79.
>

 my bad :/

> There are also a few other minor issues:
>
>  - a few checkstyle errors, mainly misplaced Apache headers
>   (the headers are there, but not at beginning of file),

 it is a false positive, they are detected in package-info.java files -
 I didn't figure out how to put them in the ignore list :( Any
 suggestion?
>>>
>>> Moving them at file start to make checkstyle happy ? Sometimes, I find it
>>> easier to fix false positive rather than fixing the tool configuration.
>>>

>  - a few javadoc warnings when generating the site with
>   "mvn clean site",

 ouch! :(

>  - if I add findbugs in the pom file, it detects four small problems,

 that have definitively be fixed, thanks!

>  - the maven artifacts still contains files with double checksums
>   .asc.md5 and .asc.sha1.

 IIUC they can be deleted also from Nexus, right?
>>>
>>> Yes, this can be done manually. You can select individual files and
>>> delete
>>> them before closing the staging area if I remember correctly.
>>>
>>> Luc
>>>


>
> Luc
>
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

(MATH-608) Remove methods from RealMatrix Interface

[Greg Sterijevski]

Hello All,

Luc suggested that I move this discussion to the list. Luc posed the
question:

"I don't understand how you intend to separate the API.
Would that mean users would always have to know beforehand the shape of the
matrix they use and manage both the matrix, the data store and the operators
in sync ?"

I think my longwinded report was not as clear as it should have been. I want
to simplify the RealMatrix interface and implementing classes. In my mind's
eye, I see the real matrix interface as describing the shape of the data,
holding that data and giving the user an indexing scheme to get at an
element.

My concern with the current interface is that if different shapes of
matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the matrix
manipulation routines (add, subtract, mult, ...) become very complicated.

In my proposal, I argue that we might have another class, say
MatrixOperations.

It would have routines for Mutlitplication that depend on type. A small
subset of the interface might look like:

public interface MatrixOpsIface{
public SymmetricMatrix selfTimesTranspose( SymmetricMatrix sm );
public SymmetricMatrix selfTimesTranspose( GeneralMatrix sm );
public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
GeneralMatrix gm);
public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
SymmericMatrix sm2);
public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
SymmetricMatrix gm);
public GeneralMatrix multipy( DiagonalMatrix dm, GeneralMatrix gm);
public GeneralMatrix multiply( SymmetricMatrix sm, GeneralMatrix gm);
public DiagonalMatrix multiply( DiagonalMatrix dm, DiagonalMatrix dm);
}

The benefit of doing this would be that you could write highly optimized
multiplication routines dependent on the shape of the matrices. All of the
complexity would be handled by the compiler. The user would simply
instantiate the operations object (maybe these could be static methods), and
call multiply. Adding a new matrix shape would be require an two check ins,
the code for the new matrix as well as a new set of methods for handling
multiplication, etc, with the other types.

-Greg

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Luc Maisonobe]

Le 01/07/2011 15:08, Simone Tripodi a écrit :

Salut Luc,


Hi Simone,


can we close this vote thread in order I can fix the open issues or we
have to wait this evening?


I guess you can cancel it and prepare a new one. I'm pretty sure people 
will wait for the next RC to check it.


best regards,
Luc



Many thanks in advance, have a nice day!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Jul 1, 2011 at 3:06 PM, Luc Maisonobe  wrote:

Le 01/07/2011 15:02, Simone Tripodi a écrit :


Salut Luc!



-1

The gpg signature seems to have been done with key 41A0D191 which is not
your Apache signing key. The Apache signature key present in the KEYS
file
is either 19FEA27D or C002CC79.



my bad :/


There are also a few other minor issues:

  - a few checkstyle errors, mainly misplaced Apache headers
   (the headers are there, but not at beginning of file),


it is a false positive, they are detected in package-info.java files -
I didn't figure out how to put them in the ignore list :( Any
suggestion?


Moving them at file start to make checkstyle happy ? Sometimes, I find it
easier to fix false positive rather than fixing the tool configuration.




  - a few javadoc warnings when generating the site with
   "mvn clean site",


ouch! :(


  - if I add findbugs in the pom file, it detects four small problems,


that have definitively be fixed, thanks!


  - the maven artifacts still contains files with double checksums
   .asc.md5 and .asc.sha1.


IIUC they can be deleted also from Nexus, right?


Yes, this can be done manually. You can select individual files and delete
them before closing the staging area if I remember correctly.

Luc






Luc



http://people.apache.org/~simonetripodi/
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Incubator PMC/Board report for July 2011 (dev@commons.apache.org)

[no-reply]

Dear OGNL Developers,

This email was sent by an automated system on behalf of the Apache Incubator 
PMC.
It is an initial reminder to give you plenty of time to prepare your quarterly
board report.

The board meeting is scheduled for  Wed, 20 July 2011, 10 am Pacific. The 
report 
for your podling will form a part of the Incubator PMC report. The Incubator 
PMC 
requires your report to be submitted one week before the board meeting, to 
allow 
sufficient time for review.

Please submit your report with sufficient time to allow the incubator PMC, and 
subsequently board members to review and digest. Again, the very latest you 
should submit your report is one week prior to the board meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report
--

Your report should contain the following:

 * Your project name
 * A brief description of your project, which assumes no knowledge of the 
project
   or necessarily of its field
 * A list of the three most important issues to address in the move towards 
   graduation.
 * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of
 * How has the community developed since the last report
 * How has the project developed since the last report.
 
This should be appended to the Incubator Wiki page at:

  http://wiki.apache.org/incubator/July2011

Note: This manually populated. You may need to wait a little before this page is
  created from a template.

Mentors
---
Mentors should review reports for their project(s) and sign them off on the 
Incubator wiki page. Signing off reports shows that you are following the 
project - projects that are not signed may raise alarms for the Incubator PMC.

Incubator PMC


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Simone Tripodi]

Salut Luc,
can we close this vote thread in order I can fix the open issues or we
have to wait this evening?
Many thanks in advance, have a nice day!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Fri, Jul 1, 2011 at 3:06 PM, Luc Maisonobe  wrote:
> Le 01/07/2011 15:02, Simone Tripodi a écrit :
>>
>> Salut Luc!
>>
>>>
>>> -1
>>>
>>> The gpg signature seems to have been done with key 41A0D191 which is not
>>> your Apache signing key. The Apache signature key present in the KEYS
>>> file
>>> is either 19FEA27D or C002CC79.
>>>
>>
>> my bad :/
>>
>>> There are also a few other minor issues:
>>>
>>>  - a few checkstyle errors, mainly misplaced Apache headers
>>>   (the headers are there, but not at beginning of file),
>>
>> it is a false positive, they are detected in package-info.java files -
>> I didn't figure out how to put them in the ignore list :( Any
>> suggestion?
>
> Moving them at file start to make checkstyle happy ? Sometimes, I find it
> easier to fix false positive rather than fixing the tool configuration.
>
>>
>>>  - a few javadoc warnings when generating the site with
>>>   "mvn clean site",
>>
>> ouch! :(
>>
>>>  - if I add findbugs in the pom file, it detects four small problems,
>>
>> that have definitively be fixed, thanks!
>>
>>>  - the maven artifacts still contains files with double checksums
>>>   .asc.md5 and .asc.sha1.
>>
>> IIUC they can be deleted also from Nexus, right?
>
> Yes, this can be done manually. You can select individual files and delete
> them before closing the staging area if I remember correctly.
>
> Luc
>
>>
>>
>>>
>>> Luc
>>>

 http://people.apache.org/~simonetripodi/
 http://www.99soft.org/

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Luc Maisonobe]

Le 01/07/2011 15:02, Simone Tripodi a écrit :

Salut Luc!



-1

The gpg signature seems to have been done with key 41A0D191 which is not
your Apache signing key. The Apache signature key present in the KEYS file
is either 19FEA27D or C002CC79.



my bad :/


There are also a few other minor issues:

  - a few checkstyle errors, mainly misplaced Apache headers
   (the headers are there, but not at beginning of file),


it is a false positive, they are detected in package-info.java files -
I didn't figure out how to put them in the ignore list :( Any
suggestion?


Moving them at file start to make checkstyle happy ? Sometimes, I find 
it easier to fix false positive rather than fixing the tool configuration.





  - a few javadoc warnings when generating the site with
   "mvn clean site",


ouch! :(


  - if I add findbugs in the pom file, it detects four small problems,


that have definitively be fixed, thanks!


  - the maven artifacts still contains files with double checksums
   .asc.md5 and .asc.sha1.


IIUC they can be deleted also from Nexus, right?


Yes, this can be done manually. You can select individual files and 
delete them before closing the staging area if I remember correctly.


Luc






Luc



http://people.apache.org/~simonetripodi/
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Simone Tripodi]

Salut Luc!

>
> -1
>
> The gpg signature seems to have been done with key 41A0D191 which is not
> your Apache signing key. The Apache signature key present in the KEYS file
> is either 19FEA27D or C002CC79.
>

my bad :/

> There are also a few other minor issues:
>
>  - a few checkstyle errors, mainly misplaced Apache headers
>   (the headers are there, but not at beginning of file),

it is a false positive, they are detected in package-info.java files -
I didn't figure out how to put them in the ignore list :( Any
suggestion?

>  - a few javadoc warnings when generating the site with
>   "mvn clean site",

ouch! :(

>  - if I add findbugs in the pom file, it detects four small problems,

that have definitively be fixed, thanks!

>  - the maven artifacts still contains files with double checksums
>   .asc.md5 and .asc.sha1.

IIUC they can be deleted also from Nexus, right?


>
> Luc
>
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Luc Maisonobe]

Le 28/06/2011 21:41, Simone Tripodi a écrit :

Hi all guys!
I just deployed the Maven artifacts on Nexus (details below), so
please cast your votes! :)
Vote will be open for next 72 hours and will be closed on July 1st, at 7:40pm.
Many thanks in advance!!!
Simo

Release Notes:

http://people.apache.org/builds/commons/digester/3.0/RC1/RELEASE-NOTES.txt

Tag:

http://svn.apache.org/repos/asf/commons/proper/digester/tags/commons-digester3-3.0/

Site:

http://people.apache.org/builds/commons/digester/3.0/RC1/site/

Binaries:

http://people.apache.org/builds/commons/digester/3.0/RC1/binaries/

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-003/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because


-1

The gpg signature seems to have been done with key 41A0D191 which is not 
your Apache signing key. The Apache signature key present in the KEYS 
file is either 19FEA27D or C002CC79.


There are also a few other minor issues:

 - a few checkstyle errors, mainly misplaced Apache headers
   (the headers are there, but not at beginning of file),
 - a few javadoc warnings when generating the site with
   "mvn clean site",
 - if I add findbugs in the pom file, it detects four small problems,
 - the maven artifacts still contains files with double checksums
   .asc.md5 and .asc.sha1.

Luc



http://people.apache.org/~simonetripodi/
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)

[Continuum@vmbuild]

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=9562&projectId=97

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Fri 1 Jul 2011 12:25:53 +
  Finished at: Fri 1 Jul 2011 12:26:28 +
  Total time: 34s
  Build Trigger: Schedule
  Build Number: 324
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_24"
  Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
  Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_24
  Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: luc @ Fri 1 Jul 2011 11:39:28 +
Comment: renamed BracketedSolution into BracketedUnivariateRealSolver and make 
it extend UnivariateRealSolver.

This will allow specifying directly a sub-category of solvers when needed. It 
will be used for example by the ODE events detection mechanism, as it will 
ensure the integrator can automatically go past the event time.

JIRA: MATH-605
Files changed:
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java
 ( 1141905 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BaseBracketedSecantSolver.java
 ( 1141905 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BracketedSolution.java
 ( 1141905 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BracketedUnivariateRealSolver.java
 (from 
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/BracketedSolution.java:1141849)
 ( 1141905 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/RegulaFalsiSolver.java
 ( 1141905 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean install   
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

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 issue affects 1 projects,
 and has been outstanding for 79 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.057 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.157 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

Tests run: 179, Failures: 0, Errors: 1, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 13 seconds
[INFO] Finished at: Fri Jul 01 11:08:28 UTC 2011
[INFO] Final Memory: 24M/58M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml
- Atom: 
http://vmgump.apache.o

Re: [VOTE] Release Apache Commons Digester 3.0 based on RC1 - take2

[Jörg Schaible]

Hi Simone,

Simone Tripodi wrote:

> Hi all guys!
> I just deployed the Maven artifacts on Nexus (details below), so
> please cast your votes! :)
> Vote will be open for next 72 hours and will be closed on July 1st, at
> 7:40pm. Many thanks in advance!!!
> Simo
> 
> Release Notes:
> 
> http://people.apache.org/builds/commons/digester/3.0/RC1/RELEASE-NOTES.txt
> 
> Tag:
> 
> http://svn.apache.org/repos/asf/commons/proper/digester/tags/commons-
digester3-3.0/
> 
> Site:
> 
> http://people.apache.org/builds/commons/digester/3.0/RC1/site/
> 
> Binaries:
> 
> http://people.apache.org/builds/commons/digester/3.0/RC1/binaries/
> 
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-003/
> 
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because

+1

I could build anything from the source package with my compiler zoo. Since I 
am not a digester user, I cannot say a lot about the new API.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[lang] Release date for common lang 3.0 (Final Release)

[Rohan Kadam]

Hi,

Please let me know, when common lang 3.0 will be moved from Beta to Final 
Release?

Thanks,
Rohan Kadam.


"Legal Disclaimer: This electronic message and all contents contain information 
from Cybage Software Private Limited which may be privileged, confidential, or 
otherwise protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is strictly prohibited. If 
you have received this electronic message in error please notify the sender by 
reply e-mail to and destroy the original message and all copies. Cybage has 
taken every reasonable precaution to minimize the risk of malicious content in 
the mail, but is not liable for any damage you may sustain as a result of any 
malicious content in this e-mail. You should carry out your own malicious 
content checks before opening the e-mail or attachment." 
www.cybage.com


"Legal Disclaimer: This electronic message and all contents contain information 
from Cybage Software Private Limited which may be privileged, confidential, or 
otherwise protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is strictly prohibited. If 
you have received this electronic message in error please notify the sender by 
reply e-mail to and destroy the original message and all copies. Cybage has 
taken every reasonable precaution to minimize the risk of malicious content in 
the mail, but is not liable for any damage you may sustain as a result of any 
malicious content in this e-mail. You should carry out your own malicious 
content checks before opening the e-mail or attachment." 
www.cybage.com