Re: svn commit: r1442739 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/ClassLoaderBuilder.java
> But I feel a bit confused now regarding which changes require a a ticket > and which don't. Any modification that have impacts to our users, such as APIs change - in that case - a bug, a new feature, an improvement, ... worths an issue. Any trivial modification such as typos, missing javadoc, if-then-else optimization, internal static imports, ... you can commit directly. Alles Gute! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1443186 - /commons/sandbox/beanutils2/trunk/src/changes/changes.xml
> + > + Implement setMapped on DefaultBeanAccessor > + you can drop the `due-to` field in that case - I used the `due-to` field when you provided patches and I took the task to review and apply, since you worked on that `due-to` in no longer needed. It is like saying "Fixed by Benedikt, thanks to Benedikt that reported it" :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1443186 - /commons/sandbox/beanutils2/trunk/src/changes/changes.xml
Ciao Simo, 2013/2/7 Simone Tripodi > > + due-to="Benedikt Ritter"> > > + Implement setMapped on DefaultBeanAccessor > > + > > you can drop the `due-to` field in that case - I used the `due-to` > field when you provided patches and I took the task to review and > apply, since you worked on that `due-to` in no longer needed. It is > like saying "Fixed by Benedikt, thanks to Benedikt that reported it" > :) > Makes sense :) I'll change that tonight. thanks! > > best, > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: mvn -Prelease deploy fails?
On 7 February 2013 05:24, Mladen Turk wrote: > On 02/06/2013 09:38 PM, sebb wrote: >> >> On 6 February 2013 20:15, Mladen Turk wrote: >>> >>> On 02/06/2013 07:26 PM, Mladen Turk wrote: >> >> >> Perhaps you managed to lock out your account? >> > > OK, I was able to upload using .zip file made manually from > my local ~/.m2. > So given all seems there are some serious infra problems with nexus. > Well, I had no problems uploading a SNAPSHOT yesterday. However that did not include any windows builds so the files were much smaller and fewer. > > Regards > -- > ^TM > > - > 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: mvn -Prelease deploy fails?
On 02/07/2013 12:04 PM, sebb wrote: On 7 February 2013 05:24, Mladen Turk wrote: OK, I was able to upload using .zip file made manually from my local ~/.m2. So given all seems there are some serious infra problems with nexus. Well, I had no problems uploading a SNAPSHOT yesterday. However that did not include any windows builds so the files were much smaller and fewer. Yeah, I presume the size and quantity matters. It starts OK, uploads bunch of files and then stalls after which it times out and continues. Nevertheless our build system should break in case this happens. Having just [WARNING] and stack trace leaves the repo in limbo state. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] release 1.3?
Hi all, Just wondering if there was going to be a 1.3 release, is there any view on when this is likely to be? I'm keen to get the fix for https://issues.apache.org/jira/browse/FILEUPLOAD-145 Thanks, Máirtín From: Gilles To: , Date: 06/02/2013 16:36 Subject:Re: [cli] release 1.3? On Wed, 06 Feb 2013 17:32:06 +0100, Thomas Neidhart wrote: > On 02/06/2013 05:28 PM, Gilles wrote: >> On Wed, 06 Feb 2013 15:48:43 +0100, Thomas Neidhart wrote: >>> Hi, >>> >>> well, I did not work much on cli, but lately I have cleanup up >>> together >>> with sebb the trunk, and I think it is in a state that could be >>> released >>> soon: >>> >>> * there are no open major issues (most issues are related to cli2) >> >> Well, there is this one: >> https://issues.apache.org/jira/browse/CLI-219 >> >> No idea why its "fix version" is set to "1.4". > > looks like a new feature request to me and not a bug report. To me, it looks like it is old enough that a reason should be given as to why the patch is not accepted. Gilles > I would prefer to release 1.3 and then work on promoting cli2 to > proper. > > Thomas > > - > 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] Moving on or not?
On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: On 2/6/13 9:03 AM, Gilles wrote: On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: On 2/5/13 6:08 AM, Gilles wrote: Hi. In the thread about "static import", Stephen noted that decisions on a component's evolution are dependent on whether the future of the Java language is taken into account, or not. A question on the same theme also arose after the presentation of Commons Math in FOSDEM 2013. If we assume that efficiency is among the important qualities for Commons Math, the future is to allow usage of the tools provided by the standard Java library in order to ease the development of multi-threaded algorithms. Maintaining Java 1.5 source compatibility for the reason that we may need to support legacy applications will turn out to be self-defeating: 1. New users will not consider Commons Math's features that are notably apt to parallel processing. 2. Current users might at some point simply switch to another library if it proves more efficient (because it actually uses multi-threading). 3. New Java developers will be turned away because they will want to use the more convenient features of the language in order to provide potential contributions. If maintaining 1.5 source compatibility is kept as a requirement, the consequence is that Commons Math will _become_ a legacy library. In that perspective, implementing/improving algorithms for which a parallel version is known to be more efficient is plainly a waste of development and maintenance time. In order to mitigate the risks (both of upgrading and of not upgrading the source compatibility requirement), I would propose to create a new project (say, "Commons Math MT") where we could implement new features[1] without being encumbered with the 1.5 requirement.[2] The "Commons Math MT" would depend on "Commons Math" where we would continue developing single-thread (and thread-safe) "tasks", i.e. independent units of processing that could be used in algorithms located in "Commons Math MT". In summary: - Commons Math (as usual): * single-thread (sequential) algorithms, * (pure) Java 5, * no dependencies. - Commons Math MT: * multi-thread (parallel) algorithms, * Java 7 and beyond, * JNI allowed, * dependencies allowed (jCuda). What do you think? There are several other possibilities to consider: 0) Implement multithreading using JDK 1.5 primitives 1) Set things up within [math] to support parallel execution in JDK 1.7, Hadoop or other frameworks 2) Instead of a new project, start a 4.x branch targeting JDK 1.7 I think we should maintain a version that has no dependencies and no JNI in any case. Starting a branch and getting concrete about how to parallelize some algorithms would be a good way to start. One thing I have not really investigated and would be interested in details on is what you actually get in efficiency gain (or loss?) using fork / join vs just using 1.5+ concurrency for the kinds of problems we would end up using this stuff for. Thinking about specific parallelization problem instances would also help decide whether 1) makes sense (i.e., whether it makes sense as you mention above to maintain a single-threaded library that provides task execution for a multithreaded version or multithreaded frameworks). One more thing to consider is that for at least some users of [math], having the library internally spawn threads and/or peg multiple processors may not be desirable. It is a little misleading to say that multithreading is the way to get "efficiency." It is really the way to *use* more compute resources and unless there are real algorithmic improvements, the overall efficiency may actually be less, due to task coordination overhead. What you get is faster execution due to more greedy utilization of available cores. Actual efficiency (how much overall compute resource it takes to complete a job) partly depends on how efficiently the coordination itself is done (which JDK 1.7 claims to do very well - I have just not seen substantiation or any benchmarks demonstrating this) and how the parallelization effects overall compute requirements. In any case, for environments where library thread-spawning is not desirable, I think we should maintain a single-threaded version. Unless I missed the point, those reasons are exactly why I propose to have 2 projects/components. One, "Commons-Math", does not fiddle with resources, while the other would provide a "parallelizationLevel" setting for the algorithms written to possibly take advantage of the Java 5+ "task framework". OK, what about the 4.x option? Yes, we could still be good by using only Java 5's concurrency features but the issue I raise is not only about concurrency but about evolution/progress/maintenance, all things that require raising interest from new contributors (unless it's fine that Commons Math be tagged as a "library of the past"...). +1 for experiment
Re: [cli] release 1.3?
Hi Thomas! > looks like a new feature request to me and not a bug report. > > I would prefer to release 1.3 and then work on promoting cli2 to proper. I read the commit history and I think the component has matured enough, so it's time to cut an RC and let it be voted by the PMC. Thanks and congrats for the hard work! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Moving on or not?
On 2/7/13 4:58 AM, Gilles wrote: > On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: >> On 2/6/13 9:03 AM, Gilles wrote: >>> On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: On 2/5/13 6:08 AM, Gilles wrote: > Hi. > > In the thread about "static import", Stephen noted that decisions > on a > component's evolution are dependent on whether the future of the > Java > language is taken into account, or not. > A question on the same theme also arose after the presentation of > Commons > Math in FOSDEM 2013. > > If we assume that efficiency is among the important qualities for > Commons > Math, the future is to allow usage of the tools provided by the > standard > Java library in order to ease the development of multi-threaded > algorithms. > > Maintaining Java 1.5 source compatibility for the reason that we > may need > to support legacy applications will turn out to be > self-defeating: > 1. New users will not consider Commons Math's features that are > notably >apt to parallel processing. > 2. Current users might at some point simply switch to another > library if >it proves more efficient (because it actually uses > multi-threading). > 3. New Java developers will be turned away because they will want > to use >the more convenient features of the language in order to > provide >potential contributions. > > If maintaining 1.5 source compatibility is kept as a > requirement, the > consequence is that Commons Math will _become_ a legacy library. > In that perspective, implementing/improving algorithms for > which a > parallel version is known to be more efficient is plainly a > waste of > development and maintenance time. > > In order to mitigate the risks (both of upgrading and of not > upgrading > the source compatibility requirement), I would propose to > create a > new > project (say, "Commons Math MT") where we could implement new > features[1] > without being encumbered with the 1.5 requirement.[2] > The "Commons Math MT" would depend on "Commons Math" where we > would > continue developing single-thread (and thread-safe) "tasks", i.e. > independent units of processing that could be used in algorithms > located in "Commons Math MT". > > In summary: > - Commons Math (as usual): > * single-thread (sequential) algorithms, > * (pure) Java 5, > * no dependencies. > - Commons Math MT: > * multi-thread (parallel) algorithms, > * Java 7 and beyond, > * JNI allowed, > * dependencies allowed (jCuda). > > What do you think? There are several other possibilities to consider: 0) Implement multithreading using JDK 1.5 primitives 1) Set things up within [math] to support parallel execution in JDK 1.7, Hadoop or other frameworks 2) Instead of a new project, start a 4.x branch targeting JDK 1.7 I think we should maintain a version that has no dependencies and no JNI in any case. Starting a branch and getting concrete about how to parallelize some algorithms would be a good way to start. One thing I have not really investigated and would be interested in details on is what you actually get in efficiency gain (or loss?) using fork / join vs just using 1.5+ concurrency for the kinds of problems we would end up using this stuff for. Thinking about specific parallelization problem instances would also help decide whether 1) makes sense (i.e., whether it makes sense as you mention above to maintain a single-threaded library that provides task execution for a multithreaded version or multithreaded frameworks). One more thing to consider is that for at least some users of [math], having the library internally spawn threads and/or peg multiple processors may not be desirable. It is a little misleading to say that multithreading is the way to get "efficiency." It is really the way to *use* more compute resources and unless there are real algorithmic improvements, the overall efficiency may actually be less, due to task coordination overhead. What you get is faster execution due to more greedy utilization of available cores. Actual efficiency (how much overall compute resource it takes to complete a job) partly depends on how efficiently the coordination itself is done (which JDK 1.7 claims to do very well - I have just not seen substantiation or any benchmarks demonstrating this) and how the parallelization effects overall compute requirements. In any case, for environments where library thread-spawning is not desirable, I think we should maintain
Re: [Math] Moving on or not?
On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote: On 2/7/13 4:58 AM, Gilles wrote: On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: On 2/6/13 9:03 AM, Gilles wrote: On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: On 2/5/13 6:08 AM, Gilles wrote: Hi. In the thread about "static import", Stephen noted that decisions on a component's evolution are dependent on whether the future of the Java language is taken into account, or not. A question on the same theme also arose after the presentation of Commons Math in FOSDEM 2013. If we assume that efficiency is among the important qualities for Commons Math, the future is to allow usage of the tools provided by the standard Java library in order to ease the development of multi-threaded algorithms. Maintaining Java 1.5 source compatibility for the reason that we may need to support legacy applications will turn out to be self-defeating: 1. New users will not consider Commons Math's features that are notably apt to parallel processing. 2. Current users might at some point simply switch to another library if it proves more efficient (because it actually uses multi-threading). 3. New Java developers will be turned away because they will want to use the more convenient features of the language in order to provide potential contributions. If maintaining 1.5 source compatibility is kept as a requirement, the consequence is that Commons Math will _become_ a legacy library. In that perspective, implementing/improving algorithms for which a parallel version is known to be more efficient is plainly a waste of development and maintenance time. In order to mitigate the risks (both of upgrading and of not upgrading the source compatibility requirement), I would propose to create a new project (say, "Commons Math MT") where we could implement new features[1] without being encumbered with the 1.5 requirement.[2] The "Commons Math MT" would depend on "Commons Math" where we would continue developing single-thread (and thread-safe) "tasks", i.e. independent units of processing that could be used in algorithms located in "Commons Math MT". In summary: - Commons Math (as usual): * single-thread (sequential) algorithms, * (pure) Java 5, * no dependencies. - Commons Math MT: * multi-thread (parallel) algorithms, * Java 7 and beyond, * JNI allowed, * dependencies allowed (jCuda). What do you think? There are several other possibilities to consider: 0) Implement multithreading using JDK 1.5 primitives 1) Set things up within [math] to support parallel execution in JDK 1.7, Hadoop or other frameworks 2) Instead of a new project, start a 4.x branch targeting JDK 1.7 I think we should maintain a version that has no dependencies and no JNI in any case. Starting a branch and getting concrete about how to parallelize some algorithms would be a good way to start. One thing I have not really investigated and would be interested in details on is what you actually get in efficiency gain (or loss?) using fork / join vs just using 1.5+ concurrency for the kinds of problems we would end up using this stuff for. Thinking about specific parallelization problem instances would also help decide whether 1) makes sense (i.e., whether it makes sense as you mention above to maintain a single-threaded library that provides task execution for a multithreaded version or multithreaded frameworks). One more thing to consider is that for at least some users of [math], having the library internally spawn threads and/or peg multiple processors may not be desirable. It is a little misleading to say that multithreading is the way to get "efficiency." It is really the way to *use* more compute resources and unless there are real algorithmic improvements, the overall efficiency may actually be less, due to task coordination overhead. What you get is faster execution due to more greedy utilization of available cores. Actual efficiency (how much overall compute resource it takes to complete a job) partly depends on how efficiently the coordination itself is done (which JDK 1.7 claims to do very well - I have just not seen substantiation or any benchmarks demonstrating this) and how the parallelization effects overall compute requirements. In any case, for environments where library thread-spawning is not desirable, I think we should maintain a single-threaded version. Unless I missed the point, those reasons are exactly why I propose to have 2 projects/components. One, "Commons-Math", does not fiddle with resources, while the other would provide a "parallelizationLevel" setting for the algorithms written to possibly take advantage of the Java 5+ "task framework". OK, what about the 4.x option? Yes, we could still be good by using only Java 5's concurrency features but the issue I raise is not only about concurrency but about evolution/progress/maintenance, all things that require raising interest from new contributors (unless it's fi
Re: [Math] Moving on or not?
On 2/7/13 8:04 AM, Gilles wrote: > On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote: >> On 2/7/13 4:58 AM, Gilles wrote: >>> On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: On 2/6/13 9:03 AM, Gilles wrote: > On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: >> On 2/5/13 6:08 AM, Gilles wrote: >>> Hi. >>> >>> In the thread about "static import", Stephen noted that >>> decisions >>> on a >>> component's evolution are dependent on whether the future of >>> the >>> Java >>> language is taken into account, or not. >>> A question on the same theme also arose after the >>> presentation of >>> Commons >>> Math in FOSDEM 2013. >>> >>> If we assume that efficiency is among the important >>> qualities for >>> Commons >>> Math, the future is to allow usage of the tools provided by the >>> standard >>> Java library in order to ease the development of multi-threaded >>> algorithms. >>> >>> Maintaining Java 1.5 source compatibility for the reason >>> that we >>> may need >>> to support legacy applications will turn out to be >>> self-defeating: >>> 1. New users will not consider Commons Math's features that are >>> notably >>>apt to parallel processing. >>> 2. Current users might at some point simply switch to another >>> library if >>>it proves more efficient (because it actually uses >>> multi-threading). >>> 3. New Java developers will be turned away because they will >>> want >>> to use >>>the more convenient features of the language in order to >>> provide >>>potential contributions. >>> >>> If maintaining 1.5 source compatibility is kept as a >>> requirement, the >>> consequence is that Commons Math will _become_ a legacy >>> library. >>> In that perspective, implementing/improving algorithms for >>> which a >>> parallel version is known to be more efficient is plainly a >>> waste of >>> development and maintenance time. >>> >>> In order to mitigate the risks (both of upgrading and of not >>> upgrading >>> the source compatibility requirement), I would propose to >>> create a >>> new >>> project (say, "Commons Math MT") where we could implement new >>> features[1] >>> without being encumbered with the 1.5 requirement.[2] >>> The "Commons Math MT" would depend on "Commons Math" where we >>> would >>> continue developing single-thread (and thread-safe) "tasks", >>> i.e. >>> independent units of processing that could be used in >>> algorithms >>> located in "Commons Math MT". >>> >>> In summary: >>> - Commons Math (as usual): >>> * single-thread (sequential) algorithms, >>> * (pure) Java 5, >>> * no dependencies. >>> - Commons Math MT: >>> * multi-thread (parallel) algorithms, >>> * Java 7 and beyond, >>> * JNI allowed, >>> * dependencies allowed (jCuda). >>> >>> What do you think? >> >> There are several other possibilities to consider: >> >> 0) Implement multithreading using JDK 1.5 primitives >> 1) Set things up within [math] to support parallel execution in >> JDK >> 1.7, Hadoop or other frameworks >> 2) Instead of a new project, start a 4.x branch targeting JDK >> 1.7 >> >> I think we should maintain a version that has no dependencies >> and no >> JNI in any case. >> >> Starting a branch and getting concrete about how to parallelize >> some >> algorithms would be a good way to start. One thing I have not >> really investigated and would be interested in details on is >> what >> you actually get in efficiency gain (or loss?) using fork / >> join vs >> just using 1.5+ concurrency for the kinds of problems we >> would end >> up using this stuff for. >> >> Thinking about specific parallelization problem instances would >> also >> help decide whether 1) makes sense (i.e., whether it makes >> sense as >> you mention above to maintain a single-threaded library that >> provides task execution for a multithreaded version or >> multithreaded >> frameworks). >> >> One more thing to consider is that for at least some users of >> [math], having the library internally spawn threads and/or peg >> multiple processors may not be desirable. It is a little >> misleading >> to say that multithreading is the way to get "efficiency." >> It is >> really the way to *use* more compute resources and unless there >> are >> real algorithmic improvements, the overall efficiency may >> actually >> be less, due to task coordination overhead. What you get is >> faster >> execution due to more greedy utilization of available cores. >> Actual >> efficiency (how much overall compute
Re: [Math] Moving on or not?
On Feb 7, 2013, at 11:05 AM, Gilles wrote: > On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote: >> On 2/7/13 4:58 AM, Gilles wrote: >>> On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: On 2/6/13 9:03 AM, Gilles wrote: > On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: >> On 2/5/13 6:08 AM, Gilles wrote: >>> Hi. >>> >>> In the thread about "static import", Stephen noted that decisions >>> on a >>> component's evolution are dependent on whether the future of the >>> Java >>> language is taken into account, or not. >>> A question on the same theme also arose after the presentation of >>> Commons >>> Math in FOSDEM 2013. >>> >>> If we assume that efficiency is among the important qualities for >>> Commons >>> Math, the future is to allow usage of the tools provided by the >>> standard >>> Java library in order to ease the development of multi-threaded >>> algorithms. >>> >>> Maintaining Java 1.5 source compatibility for the reason that we >>> may need >>> to support legacy applications will turn out to be >>> self-defeating: >>> 1. New users will not consider Commons Math's features that are >>> notably >>> apt to parallel processing. >>> 2. Current users might at some point simply switch to another >>> library if >>> it proves more efficient (because it actually uses >>> multi-threading). >>> 3. New Java developers will be turned away because they will want >>> to use >>> the more convenient features of the language in order to >>> provide >>> potential contributions. >>> >>> If maintaining 1.5 source compatibility is kept as a >>> requirement, the >>> consequence is that Commons Math will _become_ a legacy library. >>> In that perspective, implementing/improving algorithms for >>> which a >>> parallel version is known to be more efficient is plainly a >>> waste of >>> development and maintenance time. >>> >>> In order to mitigate the risks (both of upgrading and of not >>> upgrading >>> the source compatibility requirement), I would propose to >>> create a >>> new >>> project (say, "Commons Math MT") where we could implement new >>> features[1] >>> without being encumbered with the 1.5 requirement.[2] >>> The "Commons Math MT" would depend on "Commons Math" where we >>> would >>> continue developing single-thread (and thread-safe) "tasks", i.e. >>> independent units of processing that could be used in algorithms >>> located in "Commons Math MT". >>> >>> In summary: >>> - Commons Math (as usual): >>> * single-thread (sequential) algorithms, >>> * (pure) Java 5, >>> * no dependencies. >>> - Commons Math MT: >>> * multi-thread (parallel) algorithms, >>> * Java 7 and beyond, >>> * JNI allowed, >>> * dependencies allowed (jCuda). >>> >>> What do you think? >> >> There are several other possibilities to consider: >> >> 0) Implement multithreading using JDK 1.5 primitives >> 1) Set things up within [math] to support parallel execution in >> JDK >> 1.7, Hadoop or other frameworks >> 2) Instead of a new project, start a 4.x branch targeting JDK 1.7 >> >> I think we should maintain a version that has no dependencies >> and no >> JNI in any case. >> >> Starting a branch and getting concrete about how to parallelize >> some >> algorithms would be a good way to start. One thing I have not >> really investigated and would be interested in details on is what >> you actually get in efficiency gain (or loss?) using fork / >> join vs >> just using 1.5+ concurrency for the kinds of problems we would end >> up using this stuff for. >> >> Thinking about specific parallelization problem instances would >> also >> help decide whether 1) makes sense (i.e., whether it makes >> sense as >> you mention above to maintain a single-threaded library that >> provides task execution for a multithreaded version or >> multithreaded >> frameworks). >> >> One more thing to consider is that for at least some users of >> [math], having the library internally spawn threads and/or peg >> multiple processors may not be desirable. It is a little >> misleading >> to say that multithreading is the way to get "efficiency." It is >> really the way to *use* more compute resources and unless there >> are >> real algorithmic improvements, the overall efficiency may >> actually >> be less, due to task coordination overhead. What you get is >> faster >> execution due to more greedy utilization of available cores. >> Actual >> efficiency (how much overall compute resource it takes to >> complete a >> job) partly depends on how efficiently the coordinat
Re: [Math] Moving on or not?
Indeed. In fact, I have found threading of algorithms of very limited utility since I generally have parallelism at a higher level of the system and threading just gets in my way. On Thu, Feb 7, 2013 at 10:45 AM, Konstantin Berlin wrote: > ... > Exactly. So why do this when cleaning up linear algebra and > optimization seems like a much better use of time then trying to > parallelize algorithms? > >
Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java
2013/2/7
> Author: britter
> Date: Thu Feb 7 20:13:23 2013
> New Revision: 1443696
>
> URL: http://svn.apache.org/r1443696
> Log:
> Fixed checkstyle issues - no functional changes
>
> Modified:
>
> commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java
>
> Modified:
> commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java
> URL:
> http://svn.apache.org/viewvc/commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java?rev=1443696&r1=1443695&r2=1443696&view=diff
>
> ==
> ---
> commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java
> (original)
> +++
> commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java
> Thu Feb 7 20:13:23 2013
> @@ -33,14 +33,12 @@ public final class Argument
> {
>
> /**
> - * Factory method for arguments. Creates an argument by taking a
> value and
> - * determining the type of the given value.
> + * Factory method for arguments. Creates an argument by taking a
> value and determining the type of the given value.
> *
> - * @param value the value to be wrapped by the new argument object.
> Must not
> - * be {@code null}! If you want to create a null
> argument use
> - * {@link #nullArgument(Class)} instead.
> + * @param value the value to be wrapped by the new argument object.
> Must not be {@code null}! If you want to create
> + *a null argument use {@link #nullArgument(Class)}
> instead.
> + * @param the type of the argument.
> * @return a new argument of type {@code value.getClass()}
> - * @throws NullPointerException if {@code value} is null
>
How do you feel about this? Checkstyle complains about this, and I think it
is sufficient to tell users that an argument must not be null.
Regards,
Benedikt
> */
> public static Argument argument( A value )
> {
> @@ -51,11 +49,11 @@ public final class Argument
> }
>
> /**
> - * Creates a new null argument of the given type.
> + * Creates a new null argument of the given type. Shortcut for {@code
> argument( type, null )}.
> *
> - * @param type the type of the new argument
> + * @param type the type of the new argument. Must not be {@code null}!
> + * @param the type of argument.
> * @return an argument with {@code value == null}.
> - * @throws NullPointerException if {@code type} is null.
> */
> public static Argument nullArgument( Class type )
> {
> @@ -67,8 +65,9 @@ public final class Argument
> *
> * @param type the type of the new argument. Must not be {@code null}!
> * @param value the value of the new argument.
> + * @param the type of the argument.
> + * @param the type of the value of the argument.
> * @return a new argument of the given type with the given value.
> - * @throws NullPointerException if {@code type} is null
> */
> public static Argument argument( Class type, V
> value )
> {
> @@ -130,11 +129,24 @@ public final class Argument
> this.value = value;
> }
>
> +/**
> + * Returns the argument's type. Note that the type returned maybe a
> super type of the actual type of the value
> + * returned by {@link #getValue()} depending on how the argument was
> created. For example:
> + * {@code argument( Number.class, Integer.valueOf( 4 ) );}
> + * will create an argument with an Integer as Value but Number.class
> as type.
> + *
> + * @return the argument's type
> + */
> public Class getType()
> {
> return type;
> }
>
> +/**
> + * Returns the value of the argument. Maybe {@code null} if this is a
> null argument.
> + *
> + * @return the value of the argument.
> + */
> public T getValue()
> {
> return value;
>
>
>
Re: [Math] Moving on or not?
On Thu, 07 Feb 2013 08:32:46 -0800, Phil Steitz wrote: On 2/7/13 8:04 AM, Gilles wrote: On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote: On 2/7/13 4:58 AM, Gilles wrote: On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: On 2/6/13 9:03 AM, Gilles wrote: On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: On 2/5/13 6:08 AM, Gilles wrote: Hi. In the thread about "static import", Stephen noted that decisions on a component's evolution are dependent on whether the future of the Java language is taken into account, or not. A question on the same theme also arose after the presentation of Commons Math in FOSDEM 2013. If we assume that efficiency is among the important qualities for Commons Math, the future is to allow usage of the tools provided by the standard Java library in order to ease the development of multi-threaded algorithms. Maintaining Java 1.5 source compatibility for the reason that we may need to support legacy applications will turn out to be self-defeating: 1. New users will not consider Commons Math's features that are notably apt to parallel processing. 2. Current users might at some point simply switch to another library if it proves more efficient (because it actually uses multi-threading). 3. New Java developers will be turned away because they will want to use the more convenient features of the language in order to provide potential contributions. If maintaining 1.5 source compatibility is kept as a requirement, the consequence is that Commons Math will _become_ a legacy library. In that perspective, implementing/improving algorithms for which a parallel version is known to be more efficient is plainly a waste of development and maintenance time. In order to mitigate the risks (both of upgrading and of not upgrading the source compatibility requirement), I would propose to create a new project (say, "Commons Math MT") where we could implement new features[1] without being encumbered with the 1.5 requirement.[2] The "Commons Math MT" would depend on "Commons Math" where we would continue developing single-thread (and thread-safe) "tasks", i.e. independent units of processing that could be used in algorithms located in "Commons Math MT". In summary: - Commons Math (as usual): * single-thread (sequential) algorithms, * (pure) Java 5, * no dependencies. - Commons Math MT: * multi-thread (parallel) algorithms, * Java 7 and beyond, * JNI allowed, * dependencies allowed (jCuda). What do you think? There are several other possibilities to consider: 0) Implement multithreading using JDK 1.5 primitives 1) Set things up within [math] to support parallel execution in JDK 1.7, Hadoop or other frameworks 2) Instead of a new project, start a 4.x branch targeting JDK 1.7 I think we should maintain a version that has no dependencies and no JNI in any case. Starting a branch and getting concrete about how to parallelize some algorithms would be a good way to start. One thing I have not really investigated and would be interested in details on is what you actually get in efficiency gain (or loss?) using fork / join vs just using 1.5+ concurrency for the kinds of problems we would end up using this stuff for. Thinking about specific parallelization problem instances would also help decide whether 1) makes sense (i.e., whether it makes sense as you mention above to maintain a single-threaded library that provides task execution for a multithreaded version or multithreaded frameworks). One more thing to consider is that for at least some users of [math], having the library internally spawn threads and/or peg multiple processors may not be desirable. It is a little misleading to say that multithreading is the way to get "efficiency." It is really the way to *use* more compute resources and unless there are real algorithmic improvements, the overall efficiency may actually be less, due to task coordination overhead. What you get is faster execution due to more greedy utilization of available cores. Actual efficiency (how much overall compute resource it takes to complete a job) partly depends on how efficiently the coordination itself is done (which JDK 1.7 claims to do very well - I have just not seen substantiation or any benchmarks demonstrating this) and how the parallelization effects overall compute requirements. In any case, for environments where library thread-spawning is not desirable, I think we should maintain a single-threaded version. Unless I missed the point, those reasons are exactly why I propose to have 2 projects/components. One, "Commons-Math", does not fiddle with resources, while the other would provide a "parallelizationLevel" setting for the algorithms written to possibly take advantage of the Java 5+ "task framework". OK, what about the 4.x option? Yes, we could still be good by using only Java 5's concurrency features but the issue I raise is not only about concurrency but about evolution/progress/mainte
Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java
> How do you feel about this? Checkstyle complains about this, and I think it > is sufficient to tell users that an argument must not be null. sorry, which one? http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Moving on or not?
Sorry, but not of this is making sense to me. We had a long discussion about how the library doesn't test for large scale problem performance. A lot of algorithms probably do not scale well as the result. There was talk of dropping sparse support in linear algebra. So instead of fixing that, you jump to parallelization, which is needed only for large scale problems, which this library does not handle well even in single thread right now. The most significant impact you can have is fixing the linear algebra component. On Feb 7, 2013, at 5:06 PM, Gilles wrote: > On Thu, 07 Feb 2013 08:32:46 -0800, Phil Steitz wrote: >> On 2/7/13 8:04 AM, Gilles wrote: >>> On Thu, 07 Feb 2013 07:01:42 -0800, Phil Steitz wrote: On 2/7/13 4:58 AM, Gilles wrote: > On Wed, 06 Feb 2013 09:46:55 -0800, Phil Steitz wrote: >> On 2/6/13 9:03 AM, Gilles wrote: >>> On Wed, 06 Feb 2013 07:19:47 -0800, Phil Steitz wrote: On 2/5/13 6:08 AM, Gilles wrote: > Hi. > > In the thread about "static import", Stephen noted that > decisions > on a > component's evolution are dependent on whether the future of > the > Java > language is taken into account, or not. > A question on the same theme also arose after the > presentation of > Commons > Math in FOSDEM 2013. > > If we assume that efficiency is among the important > qualities for > Commons > Math, the future is to allow usage of the tools provided by the > standard > Java library in order to ease the development of multi-threaded > algorithms. > > Maintaining Java 1.5 source compatibility for the reason > that we > may need > to support legacy applications will turn out to be > self-defeating: > 1. New users will not consider Commons Math's features that are > notably > apt to parallel processing. > 2. Current users might at some point simply switch to another > library if > it proves more efficient (because it actually uses > multi-threading). > 3. New Java developers will be turned away because they will > want > to use > the more convenient features of the language in order to > provide > potential contributions. > > If maintaining 1.5 source compatibility is kept as a > requirement, the > consequence is that Commons Math will _become_ a legacy > library. > In that perspective, implementing/improving algorithms for > which a > parallel version is known to be more efficient is plainly a > waste of > development and maintenance time. > > In order to mitigate the risks (both of upgrading and of not > upgrading > the source compatibility requirement), I would propose to > create a > new > project (say, "Commons Math MT") where we could implement new > features[1] > without being encumbered with the 1.5 requirement.[2] > The "Commons Math MT" would depend on "Commons Math" where we > would > continue developing single-thread (and thread-safe) "tasks", > i.e. > independent units of processing that could be used in > algorithms > located in "Commons Math MT". > > In summary: > - Commons Math (as usual): > * single-thread (sequential) algorithms, > * (pure) Java 5, > * no dependencies. > - Commons Math MT: > * multi-thread (parallel) algorithms, > * Java 7 and beyond, > * JNI allowed, > * dependencies allowed (jCuda). > > What do you think? There are several other possibilities to consider: 0) Implement multithreading using JDK 1.5 primitives 1) Set things up within [math] to support parallel execution in JDK 1.7, Hadoop or other frameworks 2) Instead of a new project, start a 4.x branch targeting JDK 1.7 I think we should maintain a version that has no dependencies and no JNI in any case. Starting a branch and getting concrete about how to parallelize some algorithms would be a good way to start. One thing I have not really investigated and would be interested in details on is what you actually get in efficiency gain (or loss?) using fork / join vs just using 1.5+ concurrency for the kinds of problems we would end up using this stuff for. Thinking about specific parallelization problem instances would also help decide whether 1) makes sense (i.e., whether it makes sense as
Re: [VOTE] Release Apache Commons Daemon 1.0.13
Le 07/02/2013 06:37, Mladen Turk a écrit : > > Apache Commons Daemon 1.0.13 based on RC1 is ready. > It contains a fix for regression found in previous release(s). > > Binaries and sources for testing are at [1], dist layout is at [2], > generated site can be found at [3]. Tag is [4] which will be renamed to > COMMONS_DAEMON_1_0_13 if voted. > > Please vote (vote will remain open for at least 72 hours). > > Apache Commons Daemon 1.0.13 is > [X] +1 Release Luc > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > > [1] > https://repository.apache.org/content/repositories/orgapachecommons-214/ > [2] http://people.apache.org/~mturk/daemon-1.0.13/ > [3] http://people.apache.org/~mturk/daemon-1.0.13-site/ > [4] > https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_13_RC1/ > > > > Regards - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
