Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Phil Steitz a écrit : > Ted Dunning wrote: >> Phil, I think we have much of the same desires and motivations, but we >> seem >> to come to somewhat, but not entirely different conclusions. >> >> Assuming that (1) can be dealt with and assuming that (3) is already >> dealt >> with, do you still mind the inclusion of *optional*, automatically >> generated >> native code? >> > Part of 3) is having full code available with the package for > inspection. That is part of the reason that we have avoided external > dependencies. I would be open to making our fully self-contained, fully > documented, fully open source library extensible to use other libraries, > including native libraries, but I would not want to distribute anything > associated with external libraries. The reason for this is the > commitment made early on that all numerics and algorithms would be > immediately visible to the user - no chasing down external, possibly > incomplete or ambiguous docs to figure out what our code is doing. I have an additional reason for avoiding native libraries. Pure Java can be processed by external tools for either inspection (think findbugs, cobertura, traceability, auditing) or modification (think Nabla!). The Nabla case is especially important to me, but I am aware this is a corner-case. >> This page has some useful speed comparisons. For matrix-matrix >> multiply up >> to size 50, java is competitive. If you get up to roughly n = 500 or >> 1000, >> then heavily optimized native code can be up to 3x faster. Note the >> line in >> the third graph for colt (a reasonably well written pure java >> implementation) and MTJ (which is running in pure java mode here). In my >> case, I will generally opt for portability, but I like to have a portable >> option for speed. It is also important to remember that numerical codes >> more often need blinding speed than most other applications. >> > As Luc said, commons-math aims to be a general-purpose applied math > package implementing good, well-documented, unencumbered numerical > algorithms. I think this can be done in Java and we are doing it. We > are never going to compete with optimized native code in speed, but > strong numerics, JRE improvements and Moore's law are rapidly shrinking > the class of real-world applications where the 3x difference above is > material. Perhaps we should have some benchmarks including our new linear package. Something more serious than my little experiement with QR decomposition. Unfortunately, I clearly have no time for it now. My current priotity is to publish 2.0 as soon as possible and I am already late on my own schedule. Luc > > Phil > > >> http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html >> >> Is that optional dependency really all that bad? >> >> On Fri, May 15, 2009 at 6:23 PM, Phil Steitz >> wrote: >> >> >>> [math] also has currently zero dependencies. We had two dependencies on >>> other commons components up to version 1.2 and removed them when we started work on version 2.0. Adding new dependencies, and especially dependencies that involve native libraries is a difficult decision that needs lots of discussion. We are currently trying to have 2.0 published very soon now, such a decision would delay the publication several months. >>> -1 for adding dependencies, especially on native code. Commons math >>> needs >>> to remain >>> >>> 1) ASL licensed >>> 2) self-contained >>> 3) fully documented, full open source >>> >> >> >> >> >> > > > - > 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
[LANG] Latest site
I put a 3.0-SNAPSHOT site up at http://people.apache.org/~bayard/commons-lang/3.0-SNAPSHOT/ Let's you see the current backwards compat changes: http://people.apache.org/~bayard/commons-lang/3.0-SNAPSHOT/clirr-report.html Current Javadoc (beware of package.htmls that aren't updated yet): http://people.apache.org/~bayard/commons-lang/3.0-SNAPSHOT/apidocs/index.html All new clean Findbugs report: http://people.apache.org/~bayard/commons-lang/3.0-SNAPSHOT/findbugs.html (very boring, nothing there) Please check out the excludes: http://svn.apache.org/repos/asf/commons/proper/lang/trunk/findbugs-exclude-filter.xml Ignore the RAT report - it includes junk research/patch code from the directory. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Reactivate Commons-Resources...?
i have a patch that uses commons-resources for i18n downstream in james but the component has never had a release and is now inactive. this is a bit of a shame since (in my experience) it is reasonably widely used. some work would be needed to prepare it for a release. the build would need upgrading and all the headers replacing. the dependencies are old and most likely also need upgrading. but the total effort shouldn't be excessive. i'm willing to drive this forward. opinions? anyone else interested? - robert - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
Henri Yandell wrote: On Fri, May 15, 2009 at 6:44 PM, Phil Steitz wrote: Christian Grobmeier wrote: Dear Commons-Folks, Yonik Seeley and I propose the creation of a new Sandbox component within Apache Commons. We would like to name it Commons JSON since it should deal with everything around JSON. Yonik did already implement a JSON-Parser in Apache Labs name Noggit: http://svn.apache.org/repos/asf/labs/noggit/ I have implemented some other JSON-Lib at Google Code: http://code.google.com/p/jjson We would like to join forces since my JSON lib isn't very good at parsing and Noggit lacks of some classes I created. Here is the original proposal from Noggit which also fits to JJSON: There is a need for an "industrial strength" JSON parser for Java with the following features: - Streaming API (StAX/pull-parser like) for both easy and efficient parsing - Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt - Can adhere strictly to the standard (not a superset like existing parsers), preferably by default - Memory efficiency - incremental parsing (Reader-based) in order to handle huge messages - a single byte of state needed per nested object or array - does not read large objects (including primitives) completely into memory unless asked - can eliminate most copying, allowing the user to provide the output buffer for values - no built in size limits for primitives (less than 2GB) - can even handle keys of any size in a map - can handle primitives of *any* size (does not attempt to parse numerics into a certain language primitives unless asked) - Fast! I would like to add: - no dependencies! - Creates JSON Strings of Objects and vice versa - Annotations for creating objects from a JSON string. We believe that a JSON lib will become attention quickly and hope to get more developers attracted soon. Please let us know what you think about it! Sounds great! As a commons committer, you can start things in the sandbox without a formal vote. You should probably execute a grant for the stuff done outside the ASF. Does Yonik have sandbox karma? If not, just ask. Happy hacking! Didn't we resolve that a grant for stuff outside the ASF by someone who has signed a CLA is fine? Whence "probably" - I would not personally complain as long as the non-ASF stuff is the original work of one person, is "clean" from IP standpoint and is not "large". The last is a judegement call. Phil Hen - 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] Re: commons-math, matrix-toolkits-java and consolidation
I've asked Bjorn about an Apache license for MTJ and his reply was "Yes, I don't see why not. The more users/developers, the better." Ted Dunning wrote: > > On Thu, May 14, 2009 at 1:54 PM, Sam Halliday wrote: >> I personally have no problems with my MTJ contributions being released >> Apache. Bjorn-Ove is the person to talk to about the bulk of MTJ. I'll >> ask >> him! >> > > Great. > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23574199.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Luc Maisonobe wrote:
>
> Ted Dunning a écrit :
>> As a start, I'd like to discourage the use of a solid implementation for
>>> SparseReal{Vector, Matrix}... please prefer an interface approach,
>>> allowing
>>> implementations based on the Templates project:-
>
> Maybe SparseRealMatrix was a bad name and should have been
> SimpleSparseRealMatrix to avoid confusion with other sparse storage and
> dedicated algorithms.
>
I give a +1 for renaming SparseReal{Matrix, Vector}! These names should be
reserved for interfaces (which might be method-less) indicating that the
implementation storage needs to be sparse.
Luc Maisonobe wrote:
>
>> Can you say something about the licensing issues if we were to explore,
>> for
>> discussion sake, MTJ being folded into commons-math? MTJ is LGPL while
>> commons has to stay Apache licensed. This licensing issue has been the
>> biggest sticking point in the past.
>
> This is really an issue. Apache projects cannot use LGPL (or GPL) code.
> See http://www.apache.org/legal/resolved.html for the policy.
>
Solved! See other message. Both myself and (more importantly, because he
wrote MTJ) Bjorn are willing to use Apache license.
Luc Maisonobe wrote:
>
> Adding new dependencies, and especially dependencies that involve native
> libraries is a difficult decision that needs lots of discussion.
>
MTJ depends only on netlib-java, *which does not depend on any native libs*.
The option is there to add native optimised libs if the end user wants to.
Luc Maisonobe wrote:
>
> Some benchmarks I did a few weeks ago showed the new [math] linear
> package implementation was quite fast and compared very well with native
> fortran libraries
>
I'm going to call "foul" here :-)
The Java implementation of netlib-java is just as fast as machine-optimised
BLAS/LAPACK... but only for matrices smaller than roughly 1000 x 1000
elements AND ONLY FOR NORMAL DESKTOPS MACHINES! The important distinction
here is that hardware exists with crazy optimisations for the BLAS/LAPACK
API and having the option to use that architecture from within Java is a
great bonus. Consider, for example, a dedicated GPU (or FPGA) card which
comes with a BLAS/LAPACK binary.
Additionally, the BLAS/LAPACK API is universally accepted. It would be a
mistake to attempt to reproduce all the brain power and agreement that has
worked toward it.
Luc Maisonobe wrote:
>
> I am aware that we still lack lots of very efficient linear algebra
> algorithms. Joining efforts with you would be a real gain if we can
> solve the licensing issues and avoid new dependencies if possible.
>
I am very keen to consolidate efforts! I think the next step is perhaps for
you to have a look through the MTJ API and create a wish-list of everything
you think would make sense to appear in commons-math. Even if adopted
"wholesale", I would still strongly recommend a review of the API. e.g. some
interfaces extend Serializable (a mistake) ; I'm not entirely sure how
relevant the distributed package is nowadays; the Matrix Market IO is
difficult to understand/use ; there should perhaps be a "factory pattern" to
instantiating matrices/vectors.
In the meantime, I recommend holding off a 2.0 API release with any new
linear classes. That way we can stabilise the "new" merged API... releasing
that as part of 2.1.
--
View this message in context:
http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23574363.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Ted, thanks for pointing this out... I'd never seen it before. Glad MTJ did so well and I note that this isn't even with the optional native BLAS/LAPACK :-) Ted Dunning wrote: > > http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23574399.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
--- On Sat, 5/16/09, Phil Steitz wrote: > From: Phil Steitz > Subject: Re: New Sandbox Component Proposal: Commons JSON > To: "Commons Developers List" > Date: Saturday, May 16, 2009, 7:24 AM > Henri Yandell wrote: > > On Fri, May 15, 2009 at 6:44 PM, Phil Steitz > wrote: > > > >> Christian Grobmeier wrote: > >> > >>> Dear Commons-Folks, > >>> > >>> Yonik Seeley and I propose the creation of a > new Sandbox component > >>> within Apache Commons. We would like to name > it Commons JSON since it > >>> should deal with everything around JSON. > >>> > >>> Yonik did already implement a JSON-Parser in > Apache Labs name Noggit: > >>> http://svn.apache.org/repos/asf/labs/noggit/ > >>> > >>> I have implemented some other JSON-Lib at > Google Code: > >>> http://code.google.com/p/jjson > >>> > >>> We would like to join forces since my JSON lib > isn't very good at > >>> parsing and Noggit lacks of some classes I > created. Here is the > >>> original proposal from Noggit which also fits > to JJSON: > >>> > >>> There is a need for an "industrial strength" > JSON parser for Java with > >>> the following features: > >>> > >>> - Streaming API (StAX/pull-parser like) for > both easy and efficient > >>> parsing > >>> - Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt > >>> - Can adhere strictly to the standard (not a > superset like existing > >>> parsers), preferably by default > >>> - Memory efficiency > >>> - incremental parsing (Reader-based) in order > to handle huge messages > >>> - a single byte of state needed per nested > object or array > >>> - does not read large objects (including > primitives) completely into > >>> memory unless asked > >>> - can eliminate most copying, allowing the > user to provide the output > >>> buffer for values > >>> - no built in size limits for primitives (less > than 2GB) > >>> - can even handle keys of any size in a map > >>> - can handle primitives of *any* size (does > not attempt to parse > >>> numerics into a certain language primitives > unless asked) > >>> - Fast! > >>> > >>> I would like to add: > >>> - no dependencies! > >>> - Creates JSON Strings of Objects and vice > versa > >>> - Annotations for creating objects from a JSON > string. > >>> > >>> We believe that a JSON lib will become > attention quickly and hope to > >>> get more developers attracted soon. > >>> Please let us know what you think about it! > >>> > >>> > >> Sounds great! > >> > >> As a commons committer, you can start things in > the sandbox without a formal > >> vote. You should probably execute a grant > for the stuff done outside the > >> ASF. Does Yonik have sandbox karma? If > not, just ask. Happy hacking! > >> > > > > Didn't we resolve that a grant for stuff outside the > ASF by someone > > who has signed a CLA is fine? > > > Whence "probably" - I would not personally complain as long > as the > non-ASF stuff is the original work of one person, is > "clean" from IP > standpoint and is not "large". The last is a > judegement call. > I think we did more-or-less "agree", if lazily, that the above was okay. -Matt > Phil > > Hen > > > > > - > > 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: [math] Re: commons-math, matrix-toolkits-java and consolidation
I've somehow missed much of this discussion, which has got a little confused. I'll repeat some key facts here:- - MTJ depends on netlib-java - I'm the maintainer of netlib-java - netlib-java depends on PURE JAVA code, generated by F2J from netlib.org BLAS/LAPACK (and ARPACK). Keith Seymour (author of f2j) deserves all the praise for that magnificent task! The necessary jar is distributed with netlib-java. - BLAS/LAPACK are industry standard APIs. - netlib-java is technically a "translation" of netlib.org's BLAS/LAPACK/ARPACK API, so is therefore BSD licensed - netlib-java can be *optionally* configured at runtime to use a native library instead of the Java implementation. - the java implementation is pretty damn fast and will be more than adequate for most users. However, it will *never* be as fast as native code running on specialist hardware (no matter how much the JVM improves). Being the maintainer of netlib-java, I'd be more than happy to re-license all the bits that aren't technically "translations" of netlib.org, for inclusion in commons-math (in fact, it makes sense to do so). But you'd still need to depend on the f2j translated implementation. They are BSD license. Hell, it makes a *lot* of sense for commons-math to provide the BLAS/LAPACK API... they are industry standards after all, and all reference implementations for linear algebra algorithms make use of them. Luc Maisonobe wrote: > > I have an additional reason for avoiding native libraries. Pure Java can > be processed by external tools for either inspection (think findbugs, > cobertura, traceability, auditing) or modification (think Nabla!). The > Nabla case is especially important to me, but I am aware this is a > corner-case. > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23574535.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Just to let you know, I've contacted the author of this blog post... who has recently written a library called jblas. I've asked him if he wants to be involved with the initiative here, to consolidate efforts for Java Linear Algebra packages. Incidentally... this blog post references a very pervasive, yet abandoned, project named Colt. Colt was a brilliant library in its day (now numerically challenged), although riddled with license issues (depending on non-commercial and ill-defined not-for-military-use middleware). Colt is a reminder of what can happen when a great library is written but not maintained. There might be lessons to learn from their API... I know some projects that use it. It might be worthwhile contacting other Java Linear Algebra package authors, such as JAMA. JAMA is a very small library in comparison (no additional functionality over MTJ or commons-math)... but they might have a different take on APIs than we would have. Ted Dunning wrote: > > http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23574736.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit : > I've somehow missed much of this discussion, which has got a little confused. > I'll repeat some key facts here:- > > - MTJ depends on netlib-java > - I'm the maintainer of netlib-java > - netlib-java depends on PURE JAVA code, generated by F2J from netlib.org > BLAS/LAPACK (and ARPACK). Keith Seymour (author of f2j) deserves all the > praise for that magnificent task! The necessary jar is distributed with > netlib-java. > - BLAS/LAPACK are industry standard APIs. > - netlib-java is technically a "translation" of netlib.org's > BLAS/LAPACK/ARPACK API, so is therefore BSD licensed > - netlib-java can be *optionally* configured at runtime to use a native > library instead of the Java implementation. > - the java implementation is pretty damn fast and will be more than adequate > for most users. However, it will *never* be as fast as native code running > on specialist hardware (no matter how much the JVM improves). > > Being the maintainer of netlib-java, I'd be more than happy to re-license > all the bits that aren't technically "translations" of netlib.org, for > inclusion in commons-math (in fact, it makes sense to do so). But you'd > still need to depend on the f2j translated implementation. They are BSD > license. This is becoming more and more interesting. However, do yo think it would be possible to "include" the source (either manually written or automatically translated) into [math] ? This would allow a self-contained package. We already provide some code which technically comes from translated netlib routines, for example part of the Levenberg-Marquardt or almost everything in the singular value decomposition. The Netlib license allows that and we have set up the appropriate notices (see the javadoc and the NOTICE.txt file). > > Hell, it makes a *lot* of sense for commons-math to provide the BLAS/LAPACK > API... they are industry standards after all, and all reference > implementations for linear algebra algorithms make use of them. I strongly approve that for BLAS. I dream of the BLAS API being mandatory in JVM implementations, but this will probably never happen. Considering LAPACK, I am less convinced because the API is strongly fortran-oriented, not using some of the object-oriented features that are well suited for mathematical concepts. The algorithms and their implementations are very good, and we already use them inside, but with a different API. Luc > > > Luc Maisonobe wrote: >> I have an additional reason for avoiding native libraries. Pure Java can >> be processed by external tools for either inspection (think findbugs, >> cobertura, traceability, auditing) or modification (think Nabla!). The >> Nabla case is especially important to me, but I am aware this is a >> corner-case. >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Luc Maisonobe wrote: Phil Steitz a écrit : Ted Dunning wrote: Phil, I think we have much of the same desires and motivations, but we seem to come to somewhat, but not entirely different conclusions. Assuming that (1) can be dealt with and assuming that (3) is already dealt with, do you still mind the inclusion of *optional*, automatically generated native code? Part of 3) is having full code available with the package for inspection. That is part of the reason that we have avoided external dependencies. I would be open to making our fully self-contained, fully documented, fully open source library extensible to use other libraries, including native libraries, but I would not want to distribute anything associated with external libraries. The reason for this is the commitment made early on that all numerics and algorithms would be immediately visible to the user - no chasing down external, possibly incomplete or ambiguous docs to figure out what our code is doing. I have an additional reason for avoiding native libraries. Pure Java can be processed by external tools for either inspection (think findbugs, cobertura, traceability, auditing) or modification (think Nabla!). The Nabla case is especially important to me, but I am aware this is a corner-case. This page has some useful speed comparisons. For matrix-matrix multiply up to size 50, java is competitive. If you get up to roughly n = 500 or 1000, then heavily optimized native code can be up to 3x faster. Note the line in the third graph for colt (a reasonably well written pure java implementation) and MTJ (which is running in pure java mode here). In my case, I will generally opt for portability, but I like to have a portable option for speed. It is also important to remember that numerical codes more often need blinding speed than most other applications. As Luc said, commons-math aims to be a general-purpose applied math package implementing good, well-documented, unencumbered numerical algorithms. I think this can be done in Java and we are doing it. We are never going to compete with optimized native code in speed, but strong numerics, JRE improvements and Moore's law are rapidly shrinking the class of real-world applications where the 3x difference above is material. Perhaps we should have some benchmarks including our new linear package. Something more serious than my little experiement with QR decomposition. Unfortunately, I clearly have no time for it now. My current priotity is to publish 2.0 as soon as possible and I am already late on my own schedule. +1 for getting 2.0 released ASAP. This is long overdue and we need to stay focussed on getting it out. Phil Luc Phil http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html Is that optional dependency really all that bad? On Fri, May 15, 2009 at 6:23 PM, Phil Steitz wrote: [math] also has currently zero dependencies. We had two dependencies on other commons components up to version 1.2 and removed them when we started work on version 2.0. Adding new dependencies, and especially dependencies that involve native libraries is a difficult decision that needs lots of discussion. We are currently trying to have 2.0 published very soon now, such a decision would delay the publication several months. -1 for adding dependencies, especially on native code. Commons math needs to remain 1) ASL licensed 2) self-contained 3) fully documented, full open source - 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: [math] Re: commons-math, matrix-toolkits-java and consolidation
Luc, if the Apache team are happy to include source generated by f2j (which is therefore BSD license) then there is no reason at all to have a dependency! The generator code from netlib-java need not be distributed as part of the final commons-math binary, it is only needed to generate the .c files which allow for a native library at runtime. I would foresee the .c files being distributed as part of the commons-math binary download, with instructions on how to build the optional native library. The entire mechanism for doing this is entirely up for debate and review. The important thing is that there be a standardised BLAS/LAPACK API available. Luc Maisonobe wrote: > > Sam Halliday a écrit : >> I've somehow missed much of this discussion, which has got a little >> confused. >> I'll repeat some key facts here:- >> >> - MTJ depends on netlib-java >> - I'm the maintainer of netlib-java >> - netlib-java depends on PURE JAVA code, generated by F2J from netlib.org >> BLAS/LAPACK (and ARPACK). Keith Seymour (author of f2j) deserves all the >> praise for that magnificent task! The necessary jar is distributed with >> netlib-java. >> - BLAS/LAPACK are industry standard APIs. >> - netlib-java is technically a "translation" of netlib.org's >> BLAS/LAPACK/ARPACK API, so is therefore BSD licensed >> - netlib-java can be *optionally* configured at runtime to use a native >> library instead of the Java implementation. >> - the java implementation is pretty damn fast and will be more than >> adequate >> for most users. However, it will *never* be as fast as native code >> running >> on specialist hardware (no matter how much the JVM improves). >> >> Being the maintainer of netlib-java, I'd be more than happy to re-license >> all the bits that aren't technically "translations" of netlib.org, for >> inclusion in commons-math (in fact, it makes sense to do so). But you'd >> still need to depend on the f2j translated implementation. They are BSD >> license. > > This is becoming more and more interesting. However, do yo think it > would be possible to "include" the source (either manually written or > automatically translated) into [math] ? This would allow a > self-contained package. > > We already provide some code which technically comes from translated > netlib routines, for example part of the Levenberg-Marquardt or almost > everything in the singular value decomposition. The Netlib license > allows that and we have set up the appropriate notices (see the javadoc > and the NOTICE.txt file). > >> >> Hell, it makes a *lot* of sense for commons-math to provide the >> BLAS/LAPACK >> API... they are industry standards after all, and all reference >> implementations for linear algebra algorithms make use of them. > > I strongly approve that for BLAS. I dream of the BLAS API being > mandatory in JVM implementations, but this will probably never happen. > Considering LAPACK, I am less convinced because the API is strongly > fortran-oriented, not using some of the object-oriented features that > are well suited for mathematical concepts. The algorithms and their > implementations are very good, and we already use them inside, but with > a different API. > > Luc > >> >> >> Luc Maisonobe wrote: >>> I have an additional reason for avoiding native libraries. Pure Java can >>> be processed by external tools for either inspection (think findbugs, >>> cobertura, traceability, auditing) or modification (think Nabla!). The >>> Nabla case is especially important to me, but I am aware this is a >>> corner-case. >>> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575419.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
I think netlib-java might actually be using the CLAPACK version of LAPACK... the biggest problem with C/Fortran is the array indexing is different for double[][]. CLAPACK addresses this. LAPACK is still heavily used in reference implementations of standard algorithms, although admittedly not as *core* as BLAS. The ARPACK API is also worthwhile considering for inclusion (it's part of netlib-java and f2j's translations). Luc Maisonobe wrote: > > I strongly approve that for BLAS. I dream of the BLAS API being > mandatory in JVM implementations, but this will probably never happen. > Considering LAPACK, I am less convinced because the API is strongly > fortran-oriented, not using some of the object-oriented features that > are well suited for mathematical concepts. The algorithms and their > implementations are very good, and we already use them inside, but with > a different API. > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575455.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit : > Luc, if the Apache team are happy to include source generated by f2j (which > is therefore BSD license) then there is no reason at all to have a > dependency! Fine. > > The generator code from netlib-java need not be distributed as part of the > final commons-math binary, it is only needed to generate the .c files which > allow for a native library at runtime. I would foresee the .c files being > distributed as part of the commons-math binary download, with instructions > on how to build the optional native library. The entire mechanism for doing > this is entirely up for debate and review. The important thing is that there > be a standardised BLAS/LAPACK API available. Yes. However, as both Phil and I have said, we still want to have 2.0 out very soon. Adding a complete BLAS API is a huge task so I really prefer to wait after 2.0. We can discuss about it here, of course. You could also open a JIRA issue for requesting the enhancement, targeting 2.1. Thanks Luc > > > Luc Maisonobe wrote: >> Sam Halliday a écrit : >>> I've somehow missed much of this discussion, which has got a little >>> confused. >>> I'll repeat some key facts here:- >>> >>> - MTJ depends on netlib-java >>> - I'm the maintainer of netlib-java >>> - netlib-java depends on PURE JAVA code, generated by F2J from netlib.org >>> BLAS/LAPACK (and ARPACK). Keith Seymour (author of f2j) deserves all the >>> praise for that magnificent task! The necessary jar is distributed with >>> netlib-java. >>> - BLAS/LAPACK are industry standard APIs. >>> - netlib-java is technically a "translation" of netlib.org's >>> BLAS/LAPACK/ARPACK API, so is therefore BSD licensed >>> - netlib-java can be *optionally* configured at runtime to use a native >>> library instead of the Java implementation. >>> - the java implementation is pretty damn fast and will be more than >>> adequate >>> for most users. However, it will *never* be as fast as native code >>> running >>> on specialist hardware (no matter how much the JVM improves). >>> >>> Being the maintainer of netlib-java, I'd be more than happy to re-license >>> all the bits that aren't technically "translations" of netlib.org, for >>> inclusion in commons-math (in fact, it makes sense to do so). But you'd >>> still need to depend on the f2j translated implementation. They are BSD >>> license. >> This is becoming more and more interesting. However, do yo think it >> would be possible to "include" the source (either manually written or >> automatically translated) into [math] ? This would allow a >> self-contained package. >> >> We already provide some code which technically comes from translated >> netlib routines, for example part of the Levenberg-Marquardt or almost >> everything in the singular value decomposition. The Netlib license >> allows that and we have set up the appropriate notices (see the javadoc >> and the NOTICE.txt file). >> >>> Hell, it makes a *lot* of sense for commons-math to provide the >>> BLAS/LAPACK >>> API... they are industry standards after all, and all reference >>> implementations for linear algebra algorithms make use of them. >> I strongly approve that for BLAS. I dream of the BLAS API being >> mandatory in JVM implementations, but this will probably never happen. >> Considering LAPACK, I am less convinced because the API is strongly >> fortran-oriented, not using some of the object-oriented features that >> are well suited for mathematical concepts. The algorithms and their >> implementations are very good, and we already use them inside, but with >> a different API. >> >> Luc >> >>> >>> Luc Maisonobe wrote: I have an additional reason for avoiding native libraries. Pure Java can be processed by external tools for either inspection (think findbugs, cobertura, traceability, auditing) or modification (think Nabla!). The Nabla case is especially important to me, but I am aware this is a corner-case. >> >> - >> 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] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit : > Just to let you know, I've contacted the author of this blog post... who has > recently written a library called jblas. I've asked him if he wants to be > involved with the initiative here, to consolidate efforts for Java Linear > Algebra packages. > > Incidentally... this blog post references a very pervasive, yet abandoned, > project named Colt. Colt was a brilliant library in its day (now numerically > challenged), although riddled with license issues (depending on > non-commercial and ill-defined not-for-military-use middleware). Colt is a > reminder of what can happen when a great library is written but not > maintained. There might be lessons to learn from their API... I know some > projects that use it. > > It might be worthwhile contacting other Java Linear Algebra package authors, > such as JAMA. JAMA is a very small library in comparison (no additional > functionality over MTJ or commons-math)... but they might have a different > take on APIs than we would have. JAMA is a deceased project. We have based our API for decomposition algorithms on the JAMA API, with some extensions we thought were useful (see the class javadoc for the various decomposition interfaces). For example, we have added interfaces instead of using only classes and we have added solvers that could avoid building some large intermediate matrices, thus greatly improving speed. We have compared our results to JAMA. Here are some results I just rerun for this message, with dimensions between 600 and 1000. Once again, beware of the single case, single hardware, single trial effect: the bench is most probably biased due to these characteristics. multiplication: about 1.5 times faster with DenseRealMatrix QR decomposition + solve: about 10 times faster at dimension 600, about 20-25 times faster at dimension 1000 eigen decomposition: about 3 times faster at dimension 600, about 6 times faster at dimension 1000 These results could have been expected: JAMA focused on the API, not on the implementation and almost naive implementations have been used with no consideration to the memory handling. So clearly, JAMA is superseded on both the API, maintenance and efficiency aspects. See for example these messages: http://markmail.org/message/a4d454alexugur2m http://markmail.org/message/h2rmq6wo7nwqzx4w http://markmail.org/message/l4cvopambgumrwbs Luc > > > Ted Dunning wrote: >> http://blog.mikiobraun.de/2009/04/some-benchmark-numbers-for-jblas.html >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
I suspected as much: that makes JAMA and Colt both deceased. Does anyone know how to contact the JAMA authors and ask them to make this explicit in the webpage? Asking to direct users to commons-math would be wise. I have attempted to contact the author/maintainer of Colt on many occasions, but I keep getting bounced mail. It would be good to be able to warn people away from using these dead projects. Do you know of any others? Luc Maisonobe wrote: > > JAMA is a deceased project. > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575637.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
I don't want to hold up a 2.0 release... however it would be a shame to release an API that would restrict further inclusion of MTJ/BLAS, especially in the sparse API. Would it be possible to hold back the linear algebra updates for now? If you'd really like to get 2.0 out as it stands, then can I be involved in an API review to minimise any future problems? This might involve some API changes from today's snapshot (although, no extra features or anything heavy like that). I agree... this is far too big a task for 2.0! Luc Maisonobe wrote: > > However, as both Phil and I have said, we still want to have 2.0 out > very soon. Adding a complete BLAS API is a huge task so I really prefer > to wait after 2.0. We can discuss about it here, of course. You could > also open a JIRA issue for requesting the enhancement, targeting 2.1. > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575674.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
I've had a quick look at the 2.0 API and the only changes I'd like to request
are:-
- create interfaces RealSparse{Matrix, Vector} to indicate a sparse storage
implementation. Can be empty (for now).
- rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
Implement above interfaces.
- implementations should subclass the return type of some methods in the
Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a RealVector,
but could declare that it returns a RealVectorImpl. This will avoid needless
user casts. In future APIs, this could be a powerful way to define the
return type of matrix-matrix computation when the storage classes are
known... e.g. declaring that you return a DiagonalMatrix.
- is it too late to define a Norm enum and take that as a parameter, rather
than explicit methods for each Norm type?
Other than that, looks good and I can't see any obvious conflicts that would
void an MTJ merge! Most of the changes will be internal anyway, depending
primarily on the path forward for BLAS/LAPACK use.
Sam Halliday wrote:
>
> can I be involved in an API review to minimise any future problems? This
> might involve some API changes from today's snapshot (although, no extra
> features or anything heavy like that).
>
--
View this message in context:
http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575831.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit : > I suspected as much: that makes JAMA and Colt both deceased. Does anyone know > how to contact the JAMA authors and ask them to make this explicit in the > webpage? Asking to direct users to commons-math would be wise. This fact appears at least here in this message: http://cio.nist.gov/esd/emaildir/lists/jama/msg01384.html Note that the project cited in this message also already uses commons-math and other mathematical libraries too. > > I have attempted to contact the author/maintainer of Colt on many occasions, > but I keep getting bounced mail. It would be good to be able to warn people > away from using these dead projects. Do you know of any others? At least mantissa is in the same situation, but the link with commons-math is already in the small FAQ. I would personally not try to urge people to switch to our library. They may well be happy with the status of these projects and switching has a time cost for adaptation to new API and validation. > > > Luc Maisonobe wrote: >> JAMA is a deceased project. >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit : > I don't want to hold up a 2.0 release... however it would be a shame to > release an API that would restrict further inclusion of MTJ/BLAS, especially > in the sparse API. Would it be possible to hold back the linear algebra > updates for now? > > If you'd really like to get 2.0 out as it stands, then can I be involved in > an API review to minimise any future problems? This might involve some API > changes from today's snapshot (although, no extra features or anything heavy > like that). Of course you can look at the API and comment on it or suggest changes. If they are wise and can be implemented quickly, we'll probably do it. If you want some changes to be included, your best bet is to explain them on the list and to provide patches for that using JIRA. > > I agree... this is far too big a task for 2.0! > > > Luc Maisonobe wrote: >> However, as both Phil and I have said, we still want to have 2.0 out >> very soon. Adding a complete BLAS API is a huge task so I really prefer >> to wait after 2.0. We can discuss about it here, of course. You could >> also open a JIRA issue for requesting the enhancement, targeting 2.1. >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit :
> I've had a quick look at the 2.0 API and the only changes I'd like to request
> are:-
>
> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse storage
> implementation. Can be empty (for now).
I suppose these interfaces would extend Real{Matrix, Vector} ?
> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
> Implement above interfaces.
I have no opinion on that. What do others think ?
> - implementations should subclass the return type of some methods in the
> Real{Matrix, Vector} API. e.g. RealVectorImpl.copy() returns a RealVector,
> but could declare that it returns a RealVectorImpl. This will avoid needless
> user casts. In future APIs, this could be a powerful way to define the
> return type of matrix-matrix computation when the storage classes are
> known... e.g. declaring that you return a DiagonalMatrix.
I didn't know changing the return type to a subtype was allowed when
implementing an interface! This is for sure a good thing to do and could
probably be used in many other places too.
> - is it too late to define a Norm enum and take that as a parameter, rather
> than explicit methods for each Norm type?
There are many places where we use the same pattern outside of linear
algebra. I'm reluctant to change this because if we extend the enum
later, we may forget to add a new case in all implementations (somewhere
in a switch statement), so we should add an exception for defensive
programming. A method name enforced in an interface prevent such errors,
you cannot compile your implementation if you forget a method.
>
> Other than that, looks good and I can't see any obvious conflicts that would
> void an MTJ merge! Most of the changes will be internal anyway, depending
> primarily on the path forward for BLAS/LAPACK use.
Fine.
Luc
>
>
> Sam Halliday wrote:
>> can I be involved in an API review to minimise any future problems? This
>> might involve some API changes from today's snapshot (although, no extra
>> features or anything heavy like that).
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Luc Maisonobe wrote:
>
>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse
>> storage
>> implementation. Can be empty (for now).
>
> I suppose these interfaces would extend Real{Matrix, Vector} ?
>
Exactly. In future, it might be wise to use the "subclass return trick" here
too, but leaving it blank for now gives the best options for future
releases.
Luc Maisonobe wrote:
>
> I didn't know changing the return type to a subtype was allowed when
> implementing an interface! This is for sure a good thing to do and could
> probably be used in many other places too.
>
Cool, eh? :-) In Joshua Bloch's book, he recommends being as general as
possible in the parameters and as specific as possible in the return type.
The only problem with being specific in the return type is that you are
stuck with it. For that reason, it's probably best not to do this everywhere
just yet. It's one of those little API details that can be open for change
in the future whilst also being fully backwards compatible ;-)
Luc Maisonobe wrote:
>
>> - is it too late to define a Norm enum and take that as a parameter,
>> rather
>> than explicit methods for each Norm type?
>
> There are many places where we use the same pattern outside of linear
> algebra. I'm reluctant to change this because if we extend the enum
> later...
>
OK, that makes sense.
One of the first tasks for MTJ integration can be the inclusion of the many
sparse storage types (and associated numerical optimisations). That's why
I'm keen to have the current sparse implementation be specific about its
"shape" in its name. Otherwise it'll be the odd one out ;-)
--
View this message in context:
http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23576105.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Sam Halliday a écrit :
>
> Luc Maisonobe wrote:
>>> - create interfaces RealSparse{Matrix, Vector} to indicate a sparse
>>> storage
>>> implementation. Can be empty (for now).
>> I suppose these interfaces would extend Real{Matrix, Vector} ?
>>
>
> Exactly. In future, it might be wise to use the "subclass return trick" here
> too, but leaving it blank for now gives the best options for future
> releases.
Perhaps having a single additional method getSparcity() or
getLoadRatio() returning the ratio of elements set to the total number
as a double would be useful ?
>
>
> Luc Maisonobe wrote:
>> I didn't know changing the return type to a subtype was allowed when
>> implementing an interface! This is for sure a good thing to do and could
>> probably be used in many other places too.
>>
>
> Cool, eh? :-) In Joshua Bloch's book, he recommends being as general as
> possible in the parameters and as specific as possible in the return type.
> The only problem with being specific in the return type is that you are
> stuck with it. For that reason, it's probably best not to do this everywhere
> just yet. It's one of those little API details that can be open for change
> in the future whilst also being fully backwards compatible ;-)
>
>
> Luc Maisonobe wrote:
>>> - is it too late to define a Norm enum and take that as a parameter,
>>> rather
>>> than explicit methods for each Norm type?
>> There are many places where we use the same pattern outside of linear
>> algebra. I'm reluctant to change this because if we extend the enum
>> later...
>>
>
> OK, that makes sense.
>
> One of the first tasks for MTJ integration can be the inclusion of the many
> sparse storage types (and associated numerical optimisations). That's why
> I'm keen to have the current sparse implementation be specific about its
> "shape" in its name. Otherwise it'll be the odd one out ;-)
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Luc Maisonobe wrote: > > Perhaps having a single additional method getSparcity() or > getLoadRatio() returning the ratio of elements set to the total number > as a double would be useful ? > Perhaps... but the shape is probably more important than the sparsity score (which doesn't necessarily mean anything, and might actually be difficult to calculate for some implementations). I recommend leaving it empty for now and we can discuss it in much more detail for 2.1 :-) -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23576401.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
+1 on this change. Grand names like SparseRealMatrix should be reserved for
the interfaces.
On Sat, May 16, 2009 at 10:26 AM, Luc Maisonobe wrote:
>
> > - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix, Vector}.
> > Implement above interfaces.
>
> I have no opinion on that. What do others think ?
--
Ted Dunning, CTO
DeepDyve
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
getScarcity is probably still useful. getSparseShapeOrClassOrWhateverItShouldBeCalled would be very, very helpful. On Sat, May 16, 2009 at 11:12 AM, Sam Halliday wrote: > Luc Maisonobe wrote: > > > > Perhaps having a single additional method getSparcity() or > > getLoadRatio() returning the ratio of elements set to the total number > > as a double would be useful ? > > > > Perhaps... but the shape is probably more important than the sparsity score > (which doesn't necessarily mean anything, and might actually be difficult > to > calculate for some implementations). I recommend leaving it empty for now > and we can discuss it in much more detail for 2.1 :-) -- Ted Dunning, CTO DeepDyve
Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
- Original Message -
From: "Ted Dunning"
To: "Commons Developers List"
Sent: Saturday, May 16, 2009 1:01 PM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
+1 on this change. Grand names like SparseRealMatrix should be reserved
for
the interfaces.
I'm +1 on these grounds (and, yes, that means I'm volunteering to do the
work). I could add the getSparcity method as well (the only one that is
useful for 2.0). Could do the getShape which would presumably return an
enum (which would only have one element in 2.0) to ease the pain of
upgrading to 2.1 when there are more.
On Sat, May 16, 2009 at 10:26 AM, Luc Maisonobe
wrote:
> - rename SparseReal{Matrix, Vector} to OpenMapRealSparse{Matrix,
> Vector}.
> Implement above interfaces.
I have no opinion on that. What do others think ?
--
Ted Dunning, CTO
DeepDyve
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reactivate Commons-Resources...?
Hi Robert, 2009/5/16 Robert Burrell Donkin > opinions? > Not sure what others opinions are on this but I have projects that use the component and have been keeping them in check myself, so would be interested in this (see below). > > anyone else interested? I had previously maven-ised this build for myself, for Maven 2, and never got round to doing this as creating a patch was nightmare (any advice on how to handle large patches with multiple deletes/moves/etc would be appreciated). To take it a step further I tried to re-apply my changes against a fresh copy tonight and updated the headers and have uploaded the results to my public space on p.a.o (http://people.apache.org/~dmeikle/commons-resources/ ). As I mentioned above, if we are up for ressurecting this I am happy to lend a hand. Cheers, Dave
Re: Reactivate Commons-Resources...?
Go for it. Dave's an Apache committer nowadays, so get it going in the Sandbox, give Dave some access and away you go :) On Sat, May 16, 2009 at 5:32 PM, Dave Meikle wrote: > Hi Robert, > > 2009/5/16 Robert Burrell Donkin > >> opinions? >> > > Not sure what others opinions are on this but I have projects that use the > component and have been keeping them in check myself, so would be interested > in this (see below). > > >> >> anyone else interested? > > > I had previously maven-ised this build for myself, for Maven 2, and never > got round to doing this as creating a patch was nightmare (any advice on how > to handle large patches with multiple deletes/moves/etc would be > appreciated). > > To take it a step further I tried to re-apply my changes against a fresh > copy tonight and updated the headers and have uploaded the results to my > public space on p.a.o (http://people.apache.org/~dmeikle/commons-resources/ > ). > > As I mentioned above, if we are up for ressurecting this I am happy to lend > a hand. > > Cheers, > Dave > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reactivate Commons-Resources...?
Henri Yandell wrote: > Go for it. > > Dave's an Apache committer nowadays, so get it going in the Sandbox, > give Dave some access and away you go :) +1 > On Sat, May 16, 2009 at 5:32 PM, Dave Meikle wrote: >> Hi Robert, >> >> 2009/5/16 Robert Burrell Donkin >> >>> opinions? >>> >> Not sure what others opinions are on this but I have projects that use the >> component and have been keeping them in check myself, so would be interested >> in this (see below). >> >> >>> anyone else interested? >> >> I had previously maven-ised this build for myself, for Maven 2, and never >> got round to doing this as creating a patch was nightmare (any advice on how >> to handle large patches with multiple deletes/moves/etc would be >> appreciated). > >> To take it a step further I tried to re-apply my changes against a fresh >> copy tonight and updated the headers and have uploaded the results to my >> public space on p.a.o (http://people.apache.org/~dmeikle/commons-resources/ >> ). >> >> As I mentioned above, if we are up for ressurecting this I am happy to lend >> a hand. great :-) it sounds like henri has the right plan: let's get commons karma for dmei...@apache.org then you can just commit the changes. since you have those changes locally, i'll hold off until that arrives - robert - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Reactivate Commons-Resources...?
On Sat, May 16, 2009 at 11:47 PM, Robert Burrell Donkin wrote: > Henri Yandell wrote: >> Go for it. >> >> Dave's an Apache committer nowadays, so get it going in the Sandbox, >> give Dave some access and away you go :) > > +1 > >> On Sat, May 16, 2009 at 5:32 PM, Dave Meikle wrote: >>> Hi Robert, >>> >>> 2009/5/16 Robert Burrell Donkin >>> opinions? >>> Not sure what others opinions are on this but I have projects that use the >>> component and have been keeping them in check myself, so would be interested >>> in this (see below). >>> >>> anyone else interested? >>> >>> I had previously maven-ised this build for myself, for Maven 2, and never >>> got round to doing this as creating a patch was nightmare (any advice on how >>> to handle large patches with multiple deletes/moves/etc would be >>> appreciated). >> >>> To take it a step further I tried to re-apply my changes against a fresh >>> copy tonight and updated the headers and have uploaded the results to my >>> public space on p.a.o (http://people.apache.org/~dmeikle/commons-resources/ >>> ). >>> >>> As I mentioned above, if we are up for ressurecting this I am happy to lend >>> a hand. > > great :-) > > it sounds like henri has the right plan: let's get commons karma for > dmei...@apache.org then you can just commit the changes. since you have > those changes locally, i'll hold off until that arrives Karma granted to commons-sandbox. Which I realize doesn't cover commons/dormant, so I've changed that. Sandbox karma lets you modify the dormant location (which should only be to move things over into sandbox). First step for resources - move to sandbox. Second step - change code. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
