date:20110123

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

2011-01-23 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 42 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

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

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 18 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-

---
 T E S T S
---
Running org.apache.commons.scxml.invoke.InvokeTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.423 sec
Running org.apache.commons.scxml.test.TestingTestSuite
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.305 sec
Running org.apache.commons.scxml.SCXMLTestSuite
Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.875 sec <<< 
FAILURE!
Running org.apache.commons.scxml.issues.IssuesTestSuite
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.357 sec
Running org.apache.commons.scxml.model.ModelTestSuite
Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.446 sec <<< 
FAILURE!
Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.scxml.semantics.SemanticsTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.063 sec
Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec
Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.scxml.io.IOTestSuite
Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.611 sec

Results :

Failed tests: 
  
testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest)
  testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest)

Tests run: 228, Failures: 2, Errors: 0, Skipped: 0

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

Please refer to 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 17 seconds
[INFO] Finished at: Sun Jan 23 09:37:32 UTC 2011
[INFO] Final Memory: 41M/99M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 07000623012011, vmgump.apache.org:vmgump:07000623012011
Gump E-mail Identifier (unique wit

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Luc Maisonobe

Le 23/01/2011 01:58, s...@apache.org a écrit :
> Author: sebb
> Date: Sun Jan 23 00:58:07 2011
> New Revision: 1062304
> 
> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
> Log:
> MATH-496 Create FastMath copySign methods

I was also creating these methods.
I have created all the missing ones and implemented hypot directly, so
don't bother doing it too.

Luc

> 
> Modified:
> 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
> 
> Modified: 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1062304&r1=1062303&r2=1062304&view=diff
> ==
> --- 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>  (original)
> +++ 
> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>  Sun Jan 23 00:58:07 2011
> @@ -247,18 +247,6 @@ public class FastMath {
>  // Generic helper methods
>  
>  /**
> - * Get the sign information (works even for 0).
> - * 
> - * @param d the value to check
> - * 
> - * @return +1.0 or -1.0, never 0.0
> - */
> -private static double getSign(double d){ // TODO perhaps move to 
> MathUtils?
> -long l = Double.doubleToLongBits(d);
> -return l < 0 ? -1.0 : 1.0;
> -}
> -
> -/**
>   * Get the high order bits from the mantissa.
>   * Equivalent to adding and subtracting HEX_4 but also works for 
> very large numbers
>   * 
> @@ -2798,7 +2786,7 @@ public class FastMath {
>  int idx;
>  
>  if (xa == 0.0) { // Matches +/- 0.0; return correct sign
> -return leftPlane ? getSign(xa) * Math.PI : xa;
> +return leftPlane ? copySign(Math.PI, xa) : xa;
>  }
>  
>  if (xa < 0) {
> @@ -2957,7 +2945,7 @@ public class FastMath {
>  if (x > 0) {
>  return y; // return +/- 0.0
>  } else {
> -return getSign(y) * Math.PI;
> +return copySign(Math.PI, y);
>  }
>  }
>  
> @@ -3737,4 +3725,37 @@ public class FastMath {
>  return StrictMath.IEEEremainder(dividend, divisor); // TODO provide 
> our own implementation
>  }
>  
> +/**
> + * Returns the first argument with the sign of the second argument.
> + * A NaN {@code sign} argument is treated as positive.
> + * 
> + * @param magnitude the value to return
> + * @param sign the sign for the returned value
> + * @return the magnitude with the same sign as the {@code sign} argument
> + */
> +public static double copySign(double magnitude, double sign){
> +long m = Double.doubleToLongBits(magnitude);
> +long s = Double.doubleToLongBits(sign);
> +if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently OK
> +return magnitude;
> +}
> +return -magnitude; // flip sign
> +}
> +
> +/**
> + * Returns the first argument with the sign of the second argument.
> + * A NaN {@code sign} argument is treated as positive.
> + * 
> + * @param magnitude the value to return
> + * @param sign the sign for the returned value
> + * @return the magnitude with the same sign as the {@code sign} argument
> + */
> +public static float copySign(float magnitude, float sign){
> +int m = Float.floatToIntBits(magnitude);
> +int s = Float.floatToIntBits(sign);
> +if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently OK
> +return magnitude;
> +}
> +return -magnitude; // flip sign
> +}
>  }
> 
> 
> 


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

[GUMP@vmgump]: Project commons-jelly-tags-quartz (in module commons-jelly) failed

2011-01-23 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-jelly-tags-quartz has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 30 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-quartz :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-jelly-tags-quartz-23012011.jar] identifier 
set to project name
 -DEBUG- Dependency on logging-log4j-12 exists, no need to add for property 
maven.jar.log4j.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property 
maven.jar.commons-jexl.
 -DEBUG- (Apache Gump generated) Apache Maven Properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.xml
 -DEBUG- Maven project properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.properties
 -INFO- Project Reports in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports]
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/gump_work/build_commons-jelly_commons-jelly-tags-quartz.html
Work Name: build_commons-jelly_commons-jelly-tags-quartz (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 secs
Command Line: maven --offline jar 
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz]
-
java:compile:
[echo] Compiling to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes
[javac] Compiling 7 source files to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:198:
 org.quartz.CronTrigger is abstract; cannot be instantiated
[javac] CronTrigger trigger = new CronTrigger( getName(),
[javac]   ^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:201:
 cannot find symbol
[javac] symbol  : method setCronExpression(java.lang.String)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setCronExpression( getSpec() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:206:
 cannot find symbol
[javac] symbol  : method setJobName(java.lang.String)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setJobName( getJobName() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:207:
 cannot find symbol
[javac] symbol  : method setJobGroup(java.lang.String)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setJobGroup( getJobGroup() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:208:
 cannot find symbol
[javac] symbol  : method setStartTime(java.util.Date)
[javac] location: interface org.quartz.CronTrigger
[javac] trigger.setStartTime( new Date() );
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:118:
 org.quartz.JobDetail is abstract; cannot be instantiated
[javac] JobDetail detail = new JobDetail( getName(),
[javac]^
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:122:
 cannot find symbol
[javac] symbol  : method setDurability(boolean)
[javac] location: interface org.quartz.JobDetail
[javac] detail.setDurability( true );
[javac]   ^
[javac] 
/srv

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

2011-01-23 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 42 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

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

That said, some information snippets are provided here.

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



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

Results :

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

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Sun Jan 23 10:13:48 UTC 2011
[INFO] Final Memory: 39M/94M
[INFO] 
-

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread sebb

On 23 January 2011 09:58, Luc Maisonobe  wrote:
> Le 23/01/2011 01:58, s...@apache.org a écrit :
>> Author: sebb
>> Date: Sun Jan 23 00:58:07 2011
>> New Revision: 1062304
>>
>> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
>> Log:
>> MATH-496 Create FastMath copySign methods
>
> I was also creating these methods.
> I have created all the missing ones and implemented hypot directly, so
> don't bother doing it too.

OK.

I've mainly been working in Math trunk, and porting back to 2.2, so
I'll add your new methods back to trunk.
I'll also merge my fixes to nextAfter.

FastMath and FastMathTest should be the same in both.

Apart from the @since marker in FastMath - perhaps we can use @since
2.2, 3.0 for that?
Or if that is confusing, we just need to fix one before release.

> Luc
>
>>
>> Modified:
>>     
>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>
>> Modified: 
>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1062304&r1=1062303&r2=1062304&view=diff
>> ==
>> --- 
>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>  (original)
>> +++ 
>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>  Sun Jan 23 00:58:07 2011
>> @@ -247,18 +247,6 @@ public class FastMath {
>>      // Generic helper methods
>>
>>      /**
>> -     * Get the sign information (works even for 0).
>> -     *
>> -     * @param d the value to check
>> -     *
>> -     * @return +1.0 or -1.0, never 0.0
>> -     */
>> -    private static double getSign(double d){ // TODO perhaps move to 
>> MathUtils?
>> -        long l = Double.doubleToLongBits(d);
>> -        return l < 0 ? -1.0 : 1.0;
>> -    }
>> -
>> -    /**
>>       * Get the high order bits from the mantissa.
>>       * Equivalent to adding and subtracting HEX_4 but also works for 
>> very large numbers
>>       *
>> @@ -2798,7 +2786,7 @@ public class FastMath {
>>          int idx;
>>
>>          if (xa == 0.0) { // Matches +/- 0.0; return correct sign
>> -            return leftPlane ? getSign(xa) * Math.PI : xa;
>> +            return leftPlane ? copySign(Math.PI, xa) : xa;
>>          }
>>
>>          if (xa < 0) {
>> @@ -2957,7 +2945,7 @@ public class FastMath {
>>                  if (x > 0) {
>>                      return y; // return +/- 0.0
>>                  } else {
>> -                    return getSign(y) * Math.PI;
>> +                    return copySign(Math.PI, y);
>>                  }
>>              }
>>
>> @@ -3737,4 +3725,37 @@ public class FastMath {
>>          return StrictMath.IEEEremainder(dividend, divisor); // TODO provide 
>> our own implementation
>>      }
>>
>> +    /**
>> +     * Returns the first argument with the sign of the second argument.
>> +     * A NaN {@code sign} argument is treated as positive.
>> +     *
>> +     * @param magnitude the value to return
>> +     * @param sign the sign for the returned value
>> +     * @return the magnitude with the same sign as the {@code sign} argument
>> +     */
>> +    public static double copySign(double magnitude, double sign){
>> +        long m = Double.doubleToLongBits(magnitude);
>> +        long s = Double.doubleToLongBits(sign);
>> +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently 
>> OK
>> +            return magnitude;
>> +        }
>> +        return -magnitude; // flip sign
>> +    }
>> +
>> +    /**
>> +     * Returns the first argument with the sign of the second argument.
>> +     * A NaN {@code sign} argument is treated as positive.
>> +     *
>> +     * @param magnitude the value to return
>> +     * @param sign the sign for the returned value
>> +     * @return the magnitude with the same sign as the {@code sign} argument
>> +     */
>> +    public static float copySign(float magnitude, float sign){
>> +        int m = Float.floatToIntBits(magnitude);
>> +        int s = Float.floatToIntBits(sign);
>> +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently 
>> OK
>> +            return magnitude;
>> +        }
>> +        return -magnitude; // flip sign
>> +    }
>>  }
>>
>>
>>
>
>
> -
> 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: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread sebb

On 23 January 2011 11:57, sebb  wrote:
> On 23 January 2011 09:58, Luc Maisonobe  wrote:
>> Le 23/01/2011 01:58, s...@apache.org a écrit :
>>> Author: sebb
>>> Date: Sun Jan 23 00:58:07 2011
>>> New Revision: 1062304
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
>>> Log:
>>> MATH-496 Create FastMath copySign methods
>>
>> I was also creating these methods.
>> I have created all the missing ones and implemented hypot directly, so
>> don't bother doing it too.
>
> OK.
>
> I've mainly been working in Math trunk, and porting back to 2.2, so
> I'll add your new methods back to trunk.
> I'll also merge my fixes to nextAfter.

Too late - I see you have already done this.

But I also made some other (Javadoc) changes which I've not yet committed.

And I'm working on changing FastMathTest to check all StrictMath
methods (even mixed parameter ones).
The reflection test anyway needs to be fixed so it only allows ULP=1
differences in methods that are not exact.

> FastMath and FastMathTest should be the same in both.
>
> Apart from the @since marker in FastMath - perhaps we can use @since
> 2.2, 3.0 for that?
> Or if that is confusing, we just need to fix one before release.
>
>> Luc
>>
>>>
>>> Modified:
>>>     
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>>
>>> Modified: 
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1062304&r1=1062303&r2=1062304&view=diff
>>> ==
>>> --- 
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>>  (original)
>>> +++ 
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>>  Sun Jan 23 00:58:07 2011
>>> @@ -247,18 +247,6 @@ public class FastMath {
>>>      // Generic helper methods
>>>
>>>      /**
>>> -     * Get the sign information (works even for 0).
>>> -     *
>>> -     * @param d the value to check
>>> -     *
>>> -     * @return +1.0 or -1.0, never 0.0
>>> -     */
>>> -    private static double getSign(double d){ // TODO perhaps move to 
>>> MathUtils?
>>> -        long l = Double.doubleToLongBits(d);
>>> -        return l < 0 ? -1.0 : 1.0;
>>> -    }
>>> -
>>> -    /**
>>>       * Get the high order bits from the mantissa.
>>>       * Equivalent to adding and subtracting HEX_4 but also works for 
>>> very large numbers
>>>       *
>>> @@ -2798,7 +2786,7 @@ public class FastMath {
>>>          int idx;
>>>
>>>          if (xa == 0.0) { // Matches +/- 0.0; return correct sign
>>> -            return leftPlane ? getSign(xa) * Math.PI : xa;
>>> +            return leftPlane ? copySign(Math.PI, xa) : xa;
>>>          }
>>>
>>>          if (xa < 0) {
>>> @@ -2957,7 +2945,7 @@ public class FastMath {
>>>                  if (x > 0) {
>>>                      return y; // return +/- 0.0
>>>                  } else {
>>> -                    return getSign(y) * Math.PI;
>>> +                    return copySign(Math.PI, y);
>>>                  }
>>>              }
>>>
>>> @@ -3737,4 +3725,37 @@ public class FastMath {
>>>          return StrictMath.IEEEremainder(dividend, divisor); // TODO 
>>> provide our own implementation
>>>      }
>>>
>>> +    /**
>>> +     * Returns the first argument with the sign of the second argument.
>>> +     * A NaN {@code sign} argument is treated as positive.
>>> +     *
>>> +     * @param magnitude the value to return
>>> +     * @param sign the sign for the returned value
>>> +     * @return the magnitude with the same sign as the {@code sign} 
>>> argument
>>> +     */
>>> +    public static double copySign(double magnitude, double sign){
>>> +        long m = Double.doubleToLongBits(magnitude);
>>> +        long s = Double.doubleToLongBits(sign);
>>> +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently 
>>> OK
>>> +            return magnitude;
>>> +        }
>>> +        return -magnitude; // flip sign
>>> +    }
>>> +
>>> +    /**
>>> +     * Returns the first argument with the sign of the second argument.
>>> +     * A NaN {@code sign} argument is treated as positive.
>>> +     *
>>> +     * @param magnitude the value to return
>>> +     * @param sign the sign for the returned value
>>> +     * @return the magnitude with the same sign as the {@code sign} 
>>> argument
>>> +     */
>>> +    public static float copySign(float magnitude, float sign){
>>> +        int m = Float.floatToIntBits(magnitude);
>>> +        int s = Float.floatToIntBits(sign);
>>> +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently 
>>> OK
>>> +            return magnitude;
>>> +        }
>>> +        return -magnitude; // flip sign
>>> +    }
>>>  }
>>>
>>>
>>>
>>
>>
>> --

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Luc Maisonobe

Hi Sebastian,


Le 23/01/2011 13:07, sebb a écrit :
> On 23 January 2011 11:57, sebb  wrote:
>> On 23 January 2011 09:58, Luc Maisonobe  wrote:
>>> Le 23/01/2011 01:58, s...@apache.org a écrit :
 Author: sebb
 Date: Sun Jan 23 00:58:07 2011
 New Revision: 1062304

 URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
 Log:
 MATH-496 Create FastMath copySign methods
>>>
>>> I was also creating these methods.
>>> I have created all the missing ones and implemented hypot directly, so
>>> don't bother doing it too.
>>
>> OK.
>>
>> I've mainly been working in Math trunk, and porting back to 2.2, so
>> I'll add your new methods back to trunk.
>> I'll also merge my fixes to nextAfter.
> 
> Too late - I see you have already done this.
> 
> But I also made some other (Javadoc) changes which I've not yet committed.
> 
> And I'm working on changing FastMathTest to check all StrictMath
> methods (even mixed parameter ones).

Fine. I used an hacked version of your test framework to deal with
getExponent (which returns an int) and scalb (which uses an int as
second argument). However, my hack is really ugly so I won't commit it.
I will not attempt to fix my hack and will use your updated version. In
my tests, I used a loop for the input integers in scalb, I needed to use
values from -2048 to +2048 to really push the system to limits (for
example going from POSITIVE_INFINITY to +0 by scaling down).

For now, I am trying to get scalb work on all type of inputs. It is
rather tricky for subnormals as a subnormal can become a normal number
if scale factor is large and the reverse is also possible if the scale
factor is sufficiently negative.

I first tried to simply build a number of the form 2^n, but it is not
sufficient. For example it should be possible to scale Double.MIN_VALUE
up to max exponent, but in this case 2 cannot be represented as a
number, it is too large. So I have to rely on bits magics ...

I hope I will have a reliable version of scalb in the next few hours.

Once scalb is ready, I will also commit hypot. It is already coded and
teste, but it relies on scalb to avoid overflow/underflow (and in fact
it helps me testing scalb).

best regards,
Luc


> The reflection test anyway needs to be fixed so it only allows ULP=1
> differences in methods that are not exact.
> 
>> FastMath and FastMathTest should be the same in both.
>>
>> Apart from the @since marker in FastMath - perhaps we can use @since
>> 2.2, 3.0 for that?
>> Or if that is confusing, we just need to fix one before release.
>>
>>> Luc
>>>

 Modified:
 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

 Modified: 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1062304&r1=1062303&r2=1062304&view=diff
 ==
 --- 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
  (original)
 +++ 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
  Sun Jan 23 00:58:07 2011
 @@ -247,18 +247,6 @@ public class FastMath {
  // Generic helper methods

  /**
 - * Get the sign information (works even for 0).
 - *
 - * @param d the value to check
 - *
 - * @return +1.0 or -1.0, never 0.0
 - */
 -private static double getSign(double d){ // TODO perhaps move to 
 MathUtils?
 -long l = Double.doubleToLongBits(d);
 -return l < 0 ? -1.0 : 1.0;
 -}
 -
 -/**
   * Get the high order bits from the mantissa.
   * Equivalent to adding and subtracting HEX_4 but also works for 
 very large numbers
   *
 @@ -2798,7 +2786,7 @@ public class FastMath {
  int idx;

  if (xa == 0.0) { // Matches +/- 0.0; return correct sign
 -return leftPlane ? getSign(xa) * Math.PI : xa;
 +return leftPlane ? copySign(Math.PI, xa) : xa;
  }

  if (xa < 0) {
 @@ -2957,7 +2945,7 @@ public class FastMath {
  if (x > 0) {
  return y; // return +/- 0.0
  } else {
 -return getSign(y) * Math.PI;
 +return copySign(Math.PI, y);
  }
  }

 @@ -3737,4 +3725,37 @@ public class FastMath {
  return StrictMath.IEEEremainder(dividend, divisor); // TODO 
 provide our own implementation
  }

 +/**
 + * Returns the first argument with the sign of the second argument.
 + * A NaN {@code sign}

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread sebb

On 23 January 2011 12:35, Luc Maisonobe  wrote:
> Hi Sebastian,
>
>
> Le 23/01/2011 13:07, sebb a écrit :
>> On 23 January 2011 11:57, sebb  wrote:
>>> On 23 January 2011 09:58, Luc Maisonobe  wrote:
 Le 23/01/2011 01:58, s...@apache.org a écrit :
> Author: sebb
> Date: Sun Jan 23 00:58:07 2011
> New Revision: 1062304
>
> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
> Log:
> MATH-496 Create FastMath copySign methods

 I was also creating these methods.
 I have created all the missing ones and implemented hypot directly, so
 don't bother doing it too.
>>>
>>> OK.
>>>
>>> I've mainly been working in Math trunk, and porting back to 2.2, so
>>> I'll add your new methods back to trunk.
>>> I'll also merge my fixes to nextAfter.
>>
>> Too late - I see you have already done this.
>>
>> But I also made some other (Javadoc) changes which I've not yet committed.
>>
>> And I'm working on changing FastMathTest to check all StrictMath
>> methods (even mixed parameter ones).
>
> Fine. I used an hacked version of your test framework to deal with
> getExponent (which returns an int) and scalb (which uses an int as
> second argument). However, my hack is really ugly so I won't commit it.
> I will not attempt to fix my hack and will use your updated version.

OK.

I'm not promising my version will be beautiful, but I'm hoping it
won't be too messy!

> In my tests, I used a loop for the input integers in scalb, I needed to use
> values from -2048 to +2048 to really push the system to limits (for
> example going from POSITIVE_INFINITY to +0 by scaling down).
>
> For now, I am trying to get scalb work on all type of inputs. It is
> rather tricky for subnormals as a subnormal can become a normal number
> if scale factor is large and the reverse is also possible if the scale
> factor is sufficiently negative.

Yes, I took a look at scalb, and decided not to tackle it ...
just as well the exponent is integral, or that would be even more fun!

> I first tried to simply build a number of the form 2^n, but it is not
> sufficient. For example it should be possible to scale Double.MIN_VALUE
> up to max exponent, but in this case 2 cannot be represented as a
> number, it is too large. So I have to rely on bits magics ...
>
> I hope I will have a reliable version of scalb in the next few hours.
>
> Once scalb is ready, I will also commit hypot. It is already coded and
> teste, but it relies on scalb to avoid overflow/underflow (and in fact
> it helps me testing scalb).

Have fun!

> best regards,
> Luc
>
>
>> The reflection test anyway needs to be fixed so it only allows ULP=1
>> differences in methods that are not exact.
>>
>>> FastMath and FastMathTest should be the same in both.
>>>
>>> Apart from the @since marker in FastMath - perhaps we can use @since
>>> 2.2, 3.0 for that?
>>> Or if that is confusing, we just need to fix one before release.

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

Re: svn commit: r1062330 - in /commons/proper/codec/trunk/src: java/org/apache/commons/codec/binary/Base64.java test/org/apache/commons/codec/binary/Base64Test.java

2011-01-23 Thread sebb

On 23 January 2011 05:52,   wrote:
> Author: julius
> Date: Sun Jan 23 05:52:42 2011
> New Revision: 1062330
>
> URL: http://svn.apache.org/viewvc?rev=1062330&view=rev
> Log:
> CODEC-99 - Base64.encodeBase64String() should not chunk
>
> Modified:
>    
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/binary/Base64.java
>    
> commons/proper/codec/trunk/src/test/org/apache/commons/codec/binary/Base64Test.java
>
> Modified: 
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/binary/Base64.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/java/org/apache/commons/codec/binary/Base64.java?rev=1062330&r1=1062329&r2=1062330&view=diff
> ==
> --- 
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/binary/Base64.java
>  (original)
> +++ 
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/binary/Base64.java
>  Sun Jan 23 05:52:42 2011
> @@ -667,7 +667,7 @@ public class Base64 implements BinaryEnc
>      * @since 1.4
>      */
>     public static String encodeBase64String(byte[] binaryData) {
> -        return StringUtils.newStringUtf8(encodeBase64(binaryData, true));
> +        return StringUtils.newStringUtf8(encodeBase64(binaryData, false));

The Javadoc needs to be updated to make this clear.

>     }
>
>     /**
>
> Modified: 
> commons/proper/codec/trunk/src/test/org/apache/commons/codec/binary/Base64Test.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/test/org/apache/commons/codec/binary/Base64Test.java?rev=1062330&r1=1062329&r2=1062330&view=diff
> ==
> --- 
> commons/proper/codec/trunk/src/test/org/apache/commons/codec/binary/Base64Test.java
>  (original)
> +++ 
> commons/proper/codec/trunk/src/test/org/apache/commons/codec/binary/Base64Test.java
>  Sun Jan 23 05:52:42 2011
> @@ -583,12 +583,12 @@ public class Base64Test extends TestCase
>      */
>     public void testRfc4648Section10Encode() {
>         assertEquals("", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("")));
> -        //assertEquals("Zg==", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("f")));
> -        //assertEquals("Zm8=", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("fo")));
> -        //assertEquals("Zm9v", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("foo")));
> -        //assertEquals("Zm9vYg==", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("foob")));
> -        //assertEquals("Zm9vYmE=", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("fooba")));
> -        //assertEquals("Zm9vYmFy", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("foobar")));
> +        assertEquals("Zg==", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("f")));
> +        assertEquals("Zm8=", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("fo")));
> +        assertEquals("Zm9v", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("foo")));
> +        assertEquals("Zm9vYg==", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("foob")));
> +        assertEquals("Zm9vYmE=", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("fooba")));
> +        assertEquals("Zm9vYmFy", 
> Base64.encodeBase64String(StringUtils.getBytesUtf8("foobar")));
>     }
>
>     /**
> @@ -1126,13 +1126,13 @@ public class Base64Test extends TestCase
>         byte[] b4 = 
> Hex.decodeHex("2bf7cc2701fe4397b49ebeed5acc7090".toCharArray());  // for 
> url-safe tests
>
>         assertEquals("byteToString Hello World", "SGVsbG8gV29ybGQ=", 
> base64.encodeToString(b1));
> -        assertEquals("byteToString static Hello World", 
> "SGVsbG8gV29ybGQ=\r\n", Base64.encodeBase64String(b1));
> +        assertEquals("byteToString static Hello World", "SGVsbG8gV29ybGQ=", 
> Base64.encodeBase64String(b1));
>         assertEquals("byteToString \"\"", "", base64.encodeToString(b2));
>         assertEquals("byteToString static \"\"", "", 
> Base64.encodeBase64String(b2));
>         assertEquals("byteToString null", null, base64.encodeToString(b3));
>         assertEquals("byteToString static null", null, 
> Base64.encodeBase64String(b3));
>         assertEquals("byteToString UUID", "K/fMJwH+Q5e0nr7tWsxwkA==", 
> base64.encodeToString(b4));
> -        assertEquals("byteToString static UUID", 
> "K/fMJwH+Q5e0nr7tWsxwkA==\r\n", Base64.encodeBase64String(b4));
> +        assertEquals("byteToString static UUID", "K/fMJwH+Q5e0nr7tWsxwkA==", 
> Base64.encodeBase64String(b4));
>         assertEquals("byteToString static-url-safe UUID", 
> "K_fMJwH-Q5e0nr7tWsxwkA", Base64.encodeBase64URLSafeString(b4));
>     }
>
>
>
>

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Gilles Sadowski

Hello.

> [...]
> 
> I hope I will have a reliable version of scalb in the next few hours.
> 
> Once scalb is ready, I will also commit hypot. It is already coded and
> teste, but it relies on scalb to avoid overflow/underflow (and in fact
> it helps me testing scalb).

Do you keep an eye on the timing tests while comparing Math and FastMath?

Pardon the naive question but it would be a pity to conclude that fixing
FastMath for the extreme values will not make it fast any longer...


Best,
Gilles

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

[MATH] FastMathTest - split into 2 or 3 classes?

2011-01-23 Thread sebb

I think it would be useful to split the FastMathTest class into 2 or 3 classes.

FastMathTest - individual method tests
FastMathPerformanceTest - the performance test
FastMathGenericTest - tests to compare against all StrictMath methods
(the current reflection-based tests)

I think it would definitely be an improvement to put the performance
tests in a separate class.
At present the tests can only be run by editting the source (to remove
the @Ignore annotation).
This could be removed, and the test ignored in the Surefire
configuration instead.
One could still run the test independently using -Dtest=FastMathPerformanceTest.

I'm not so sure about splitting off the reflection tests.
However the current class is getting quite big, and I want to use a
suite to create individual tests for each method.
So it would probably be simpler to have a separate class.

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Luc Maisonobe

Le 23/01/2011 15:24, Gilles Sadowski a écrit :
> Hello.

Hi Gilles,

> 
>> [...]
>>
>> I hope I will have a reliable version of scalb in the next few hours.
>>
>> Once scalb is ready, I will also commit hypot. It is already coded and
>> teste, but it relies on scalb to avoid overflow/underflow (and in fact
>> it helps me testing scalb).
> 
> Do you keep an eye on the timing tests while comparing Math and FastMath?

Not yet. You can give it a try by simply temporarily removing the
@Ignore notation in the performance test in FastMathTest to see if we
have done a good job or not.

> 
> Pardon the naive question but it would be a pity to conclude that fixing
> FastMath for the extreme values will not make it fast any longer...

For widely used functions like cos, sin and the like, yes it would be a
problem. For functions which appear only very seldom in general
algorithms like scalb or nextAfter, it could be accepted. In fact, these
versions are more useful as a way to backport some features from Java 6
to Java 5.

best regards,
Luc

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


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

Re: [MATH] FastMathTest - split into 2 or 3 classes?

2011-01-23 Thread Luc Maisonobe

Hi Sebb,

Le 23/01/2011 15:51, sebb a écrit :
> I think it would be useful to split the FastMathTest class into 2 or 3 
> classes.
> 
> FastMathTest - individual method tests
> FastMathPerformanceTest - the performance test
> FastMathGenericTest - tests to compare against all StrictMath methods
> (the current reflection-based tests)
> 
> I think it would definitely be an improvement to put the performance
> tests in a separate class.
> At present the tests can only be run by editting the source (to remove
> the @Ignore annotation).
> This could be removed, and the test ignored in the Surefire
> configuration instead.
> One could still run the test independently using 
> -Dtest=FastMathPerformanceTest.
> 
> I'm not so sure about splitting off the reflection tests.
> However the current class is getting quite big, and I want to use a
> suite to create individual tests for each method.
> So it would probably be simpler to have a separate class.

This is a very good idea.

Luc

> 
> -
> 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: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread sebb

On 23 January 2011 14:57, Luc Maisonobe  wrote:
> Le 23/01/2011 15:24, Gilles Sadowski a écrit :
>> Hello.
>
> Hi Gilles,
>
>>
>>> [...]
>>>
>>> I hope I will have a reliable version of scalb in the next few hours.
>>>
>>> Once scalb is ready, I will also commit hypot. It is already coded and
>>> teste, but it relies on scalb to avoid overflow/underflow (and in fact
>>> it helps me testing scalb).
>>
>> Do you keep an eye on the timing tests while comparing Math and FastMath?
>
> Not yet. You can give it a try by simply temporarily removing the
> @Ignore notation in the performance test in FastMathTest to see if we
> have done a good job or not.

Now in separate class:

mvn test -Dtest=FastMathTestPerformance

>>
>> Pardon the naive question but it would be a pity to conclude that fixing
>> FastMath for the extreme values will not make it fast any longer...
>
> For widely used functions like cos, sin and the like, yes it would be a
> problem. For functions which appear only very seldom in general
> algorithms like scalb or nextAfter, it could be accepted. In fact, these
> versions are more useful as a way to backport some features from Java 6
> to Java 5.
>
> best regards,
> Luc
>
>>
>>
>> Best,
>> Gilles
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

[pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Simone Tripodi

Hi all guys,
I'm here to ask your help to finalize the 2.0 version of pool
component, IMHO the following important steps are fondamental before
publishing at least the first alpha:

 * POOL-172: I added the MBean required interfaces, but due to the
lack of JMX tests the issue shouldn't be considered closed;
 * POOL-176;
 * POOL-173, POOL-177, POOL-178: these can be take in consideration as
part of the same refactoring group.
 * make pools fields volatile, where possible.

Is there anyone that does have spare time to help me?
Many thanks in advance, have  anice weekend!!!
Simo

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

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

[vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Simone Tripodi

Hi all guys,
I would like to propose a new sandbox to experiment a fresh,
different, new set of Digester APIs that strongly uses a DSL for rules
configuration.
As described in the original proposal[1], the idea comes from a James
Carman's comment on an old Digester issue, so his
help/guidance/mentoring would be more than appreciated.
Please cast your vote, if there are no objections I would like to
start this work in the sandbox and try to promote as TLP with your
help/mentoring/involvement.
I really hope this could be point of your interest that makes you
curious enough to participate!
Have a nice day, all the best,
Simo

[1] http://markmail.org/message/5ry2lmfkpxkrqwh6

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

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

Re: [Math] Exception handling (again)

2011-01-23 Thread Phil Steitz

Thanks for restarting the discussion of this topic, Gilles.

Here is a first attempt at some principles for exceptions management
in [math], followed by an illustration using the ConvergenceException
case discussed in MATH-487.  The principles are no doubt incomplete
and some may be wrong and/or not acceptable to the community.  Lets
try to find consensus on a simple set of principles that we can agree
on and use as a guide in the 3.0 refactoring and new development.  I
will update the Developers Guide with what we eventually agree to.

0) Exceptions generated by [math] are all unchecked.

1) All public methods advertise all exceptions that they can generate.

2) All exceptions inherit from the base class, MathRuntimeException

3) Whenever possible, methods fully specify parameter preconditions
required for successful activation.  When preconditions are violated,
a MathIllegalArgumentException should be thrown.  Subclasses of
MathIllegalArgumentException may be used to represent common parameter
contract violations (for example, NoBracketingException).  Exception
messages must contain sufficient information on parameter values to
determine the exact precondition failure.

4) Exceptions generated by [math] make sense without knowing
implementation details other than those stated in the public API.  For
example, a NoBracketingException makes sense thrown by a solver that
has an API precondition requiring that initial points bracket a root.
 This exception does not make sense, however, thrown by an inverse
cumulative probability estimator.

Together, 3) and 4) imply

5) MathIllegalArgumentException should only be thrown in situations
satisfying 3) - i.e., unless the preconditions can be exhaustively
provided so that what arguments are "illegal" can be specified fully
to the caller, different exceptions should be thrown on the event of
failure.  For example, the exact domain of successful activation of a
solver or quadrature method may be impossible to specify because of
numerical properties of the method.  If a solver fails to find a root
or a quadrature method fails to converge for a given set of
parameters, *unless those parameters violate the advertised
preconditions* it is not appropriate to throw
MathIllegalArgumentException.  Domain-specific exceptions need to be
defined for these cases.  For example, SingularMatrixException should
not inherit from MathIllegalArgumentException unless it is only thrown
in situations satisfying 3) .  All current uses of
SingularMatrixException do satisfy 3), though the javadoc in some
cases needs a little cleanup to make it clear how singularity violates
the contract.  My HO is that it would be better for
SingularMatrixException to not extend MathIllegalArgumentException,
substituting instead either just MathRuntimeException or a linear
domain-specific parent (shared by the other matrix exceptions).

Now on to the ConvergenceException example.  Many of our algorithms
amount to generating a sequence of values, hoping that the sequence
converges (really "gets Cauchy enough") and returning an estimate of
the limit of the sequence.   Thus far, convergence is always in an
incomplete metric space and we usually have the extra-mathematical
issue to deal with that one form of divergence is becoming NaN.
Convergence failure happens when arguments are outside the
effectiveness range of the algorithm.  It is often impossible to state
precisely in preconditions exactly what the conditions are on the
parameters that will lead to failed convergence.  This is especially
true when the implementation code contains bugs :)

Failed convergence manifests in three ways: a) maximum iterations
exceeded without meeting the convergence criteria b) iterates diverge
to an infinity an infinite result is not correct c) iterates "diverge
to NaN" and NaN is not correct.  I suggest therefore, that we define:

ConvergenceException extending MathIllegalStateException or even just
MathRuntimeException;

MaxIterationsExceededException extends ConvergenceException, including
the max iterations as part of its state and message;

IterationRangeException extends ConvergenceException, including the
out of range value encountered and what element of the sequence
attained the bad value (this allows values other than NaN or
infinities to count as "divergence").

We could also add InfiniteIterateException and NaNIterateException
extending IterationRangeException for these cases.

I have often wanted to know how far out in the sequence one of the
values becomes infinite.  Capturing this information in the exception
and including it in the message would be an improvement, IMO.  The
fact that you *can* do this in the setup above is an illustration of
why I like domain-specific exceptions.

Phil

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

Re: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
 wrote:
> Hi all guys,
> I'm here to ask your help to finalize the 2.0 version of pool
> component, IMHO the following important steps are fondamental before
> publishing at least the first alpha:
>
>  * POOL-172: I added the MBean required interfaces, but due to the
> lack of JMX tests the issue shouldn't be considered closed;
>  * POOL-176;
>  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
> part of the same refactoring group.
>  * make pools fields volatile, where possible.
>
> Is there anyone that does have spare time to help me?
> Many thanks in advance, have  anice weekend!!!

I apologize for being very slow on [pool] recently.  Too many things
going on.  I have been working, however, on getting a 1.5.6 bugfix
release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
need to get them resolved in any case.

I think we also agreed that we were going to rewrite the core
implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
would still like to do that.  We should all take a careful look at the
Tomcat code and also the concurrency stuff in [lang] and talk about
how we are going to do this.

I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
the bugs that are impacting users as we work to finalize the API and
rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
bugs would also be appreciated :)

For me personally, priorities are
 0) [math] 2.2 release (almost done)
 1) [pool] 1.5.6
 2) [dbcp] 1.3.1/1.4.1
 3) [pool] 2.0
 4) [dbcp] 2.0

I would very much like to be involved in the pool rewrite, so any help
I can get with 1) and 2) would be greatly appreciated.

Phil

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

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

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
 wrote:
> Hi all guys,
> I would like to propose a new sandbox to experiment a fresh,
> different, new set of Digester APIs that strongly uses a DSL for rules
> configuration.
> As described in the original proposal[1], the idea comes from a James
> Carman's comment on an old Digester issue, so his
> help/guidance/mentoring would be more than appreciated.
> Please cast your vote, if there are no objections I would like to
> start this work in the sandbox and try to promote as TLP with your
> help/mentoring/involvement.
> I really hope this could be point of your interest that makes you
> curious enough to participate!
> Have a nice day, all the best,
> Simo
>
> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>

Go for it!

I think you mean s/TLP/Commons Proper Component, right?

Phil

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

Re: [MATH] FastMathTest - split into 2 or 3 classes?

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 9:59 AM, Luc Maisonobe  wrote:
> Hi Sebb,
>
> Le 23/01/2011 15:51, sebb a écrit :
>> I think it would be useful to split the FastMathTest class into 2 or 3 
>> classes.
>>
>> FastMathTest - individual method tests
>> FastMathPerformanceTest - the performance test
>> FastMathGenericTest - tests to compare against all StrictMath methods
>> (the current reflection-based tests)
>>
>> I think it would definitely be an improvement to put the performance
>> tests in a separate class.
>> At present the tests can only be run by editting the source (to remove
>> the @Ignore annotation).
>> This could be removed, and the test ignored in the Surefire
>> configuration instead.
>> One could still run the test independently using 
>> -Dtest=FastMathPerformanceTest.
>>
>> I'm not so sure about splitting off the reflection tests.
>> However the current class is getting quite big, and I want to use a
>> suite to create individual tests for each method.
>> So it would probably be simpler to have a separate class.
>
> This is a very good idea.

+1

Phil
>
> Luc
>
>>
>> -
>> 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: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Simone Tripodi

Hi Phil!!!
don't worry, no apologizes are needed, that's open source and we all
participate simply because we love it :)
The roadmap is more than clear, thanks for sharing it, I'll start
studying both Tomcat JDBC and Lang concurrency stuff so I can
contribute as well :)
Thanks a lot, have a nice day!!!
Simo

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



On Sun, Jan 23, 2011 at 7:48 PM, Phil Steitz  wrote:
> On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
>  wrote:
>> Hi all guys,
>> I'm here to ask your help to finalize the 2.0 version of pool
>> component, IMHO the following important steps are fondamental before
>> publishing at least the first alpha:
>>
>>  * POOL-172: I added the MBean required interfaces, but due to the
>> lack of JMX tests the issue shouldn't be considered closed;
>>  * POOL-176;
>>  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
>> part of the same refactoring group.
>>  * make pools fields volatile, where possible.
>>
>> Is there anyone that does have spare time to help me?
>> Many thanks in advance, have  anice weekend!!!
>
> I apologize for being very slow on [pool] recently.  Too many things
> going on.  I have been working, however, on getting a 1.5.6 bugfix
> release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
> need to get them resolved in any case.
>
> I think we also agreed that we were going to rewrite the core
> implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
> borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
> would still like to do that.  We should all take a careful look at the
> Tomcat code and also the concurrency stuff in [lang] and talk about
> how we are going to do this.
>
> I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
> the bugs that are impacting users as we work to finalize the API and
> rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
> be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
> bugs would also be appreciated :)
>
> For me personally, priorities are
>  0) [math] 2.2 release (almost done)
>  1) [pool] 1.5.6
>  2) [dbcp] 1.3.1/1.4.1
>  3) [pool] 2.0
>  4) [dbcp] 2.0
>
> I would very much like to be involved in the pool rewrite, so any help
> I can get with 1) and 2) would be greatly appreciated.
>
> Phil
>
>
>
>
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Simone Tripodi

Hi Phil,
thanks for the feedbacks!!! Yes, sorry for the miswriting, I meant
s/TLP/Commons Proper Component :P
Thanks again, have a nice day,
Simo

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



On Sun, Jan 23, 2011 at 7:52 PM, Phil Steitz  wrote:
> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
>  wrote:
>> Hi all guys,
>> I would like to propose a new sandbox to experiment a fresh,
>> different, new set of Digester APIs that strongly uses a DSL for rules
>> configuration.
>> As described in the original proposal[1], the idea comes from a James
>> Carman's comment on an old Digester issue, so his
>> help/guidance/mentoring would be more than appreciated.
>> Please cast your vote, if there are no objections I would like to
>> start this work in the sandbox and try to promote as TLP with your
>> help/mentoring/involvement.
>> I really hope this could be point of your interest that makes you
>> curious enough to participate!
>> Have a nice day, all the best,
>> Simo
>>
>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>
> Go for it!
>
> I think you mean s/TLP/Commons Proper Component, right?
>
> Phil
>
> -
> 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: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Adrian Crum


Two books I found valuable for working on Java concurrency:

1. Java Concurrency In Practice, by Brian Goetz
2. Concurrent Programming In Java, by Doug Lea

-Adrian

On 1/23/2011 11:02 AM, Simone Tripodi wrote:

Hi Phil!!!
don't worry, no apologizes are needed, that's open source and we all
participate simply because we love it :)
The roadmap is more than clear, thanks for sharing it, I'll start
studying both Tomcat JDBC and Lang concurrency stuff so I can
contribute as well :)
Thanks a lot, have a nice day!!!
Simo

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



On Sun, Jan 23, 2011 at 7:48 PM, Phil Steitz  wrote:

On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
  wrote:

Hi all guys,
I'm here to ask your help to finalize the 2.0 version of pool
component, IMHO the following important steps are fondamental before
publishing at least the first alpha:

  * POOL-172: I added the MBean required interfaces, but due to the
lack of JMX tests the issue shouldn't be considered closed;
  * POOL-176;
  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
part of the same refactoring group.
  * make pools fields volatile, where possible.

Is there anyone that does have spare time to help me?
Many thanks in advance, have  anice weekend!!!

I apologize for being very slow on [pool] recently.  Too many things
going on.  I have been working, however, on getting a 1.5.6 bugfix
release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
need to get them resolved in any case.

I think we also agreed that we were going to rewrite the core
implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
would still like to do that.  We should all take a careful look at the
Tomcat code and also the concurrency stuff in [lang] and talk about
how we are going to do this.

I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
the bugs that are impacting users as we work to finalize the API and
rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
bugs would also be appreciated :)

For me personally, priorities are
  0) [math] 2.2 release (almost done)
  1) [pool] 1.5.6
  2) [dbcp] 1.3.1/1.4.1
  3) [pool] 2.0
  4) [dbcp] 2.0

I would very much like to be involved in the pool rewrite, so any help
I can get with 1) and 2) would be greatly appreciated.

Phil





Simo

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

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



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



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



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

Re: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Simone Tripodi

Hi Adrian,
thanks for the suggestions, I think I'll buy the Doug Lea's one :P
Thanks again, have a nice day,
Simo

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



On Sun, Jan 23, 2011 at 8:07 PM, Adrian Crum
 wrote:
> Two books I found valuable for working on Java concurrency:
>
> 1. Java Concurrency In Practice, by Brian Goetz
> 2. Concurrent Programming In Java, by Doug Lea
>
> -Adrian
>
> On 1/23/2011 11:02 AM, Simone Tripodi wrote:
>>
>> Hi Phil!!!
>> don't worry, no apologizes are needed, that's open source and we all
>> participate simply because we love it :)
>> The roadmap is more than clear, thanks for sharing it, I'll start
>> studying both Tomcat JDBC and Lang concurrency stuff so I can
>> contribute as well :)
>> Thanks a lot, have a nice day!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Jan 23, 2011 at 7:48 PM, Phil Steitz
>>  wrote:
>>>
>>> On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
>>>   wrote:

 Hi all guys,
 I'm here to ask your help to finalize the 2.0 version of pool
 component, IMHO the following important steps are fondamental before
 publishing at least the first alpha:

  * POOL-172: I added the MBean required interfaces, but due to the
 lack of JMX tests the issue shouldn't be considered closed;
  * POOL-176;
  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
 part of the same refactoring group.
  * make pools fields volatile, where possible.

 Is there anyone that does have spare time to help me?
 Many thanks in advance, have  anice weekend!!!
>>>
>>> I apologize for being very slow on [pool] recently.  Too many things
>>> going on.  I have been working, however, on getting a 1.5.6 bugfix
>>> release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
>>> need to get them resolved in any case.
>>>
>>> I think we also agreed that we were going to rewrite the core
>>> implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
>>> borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
>>> would still like to do that.  We should all take a careful look at the
>>> Tomcat code and also the concurrency stuff in [lang] and talk about
>>> how we are going to do this.
>>>
>>> I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
>>> the bugs that are impacting users as we work to finalize the API and
>>> rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
>>> be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
>>> bugs would also be appreciated :)
>>>
>>> For me personally, priorities are
>>>  0) [math] 2.2 release (almost done)
>>>  1) [pool] 1.5.6
>>>  2) [dbcp] 1.3.1/1.4.1
>>>  3) [pool] 2.0
>>>  4) [dbcp] 2.0
>>>
>>> I would very much like to be involved in the pool rewrite, so any help
>>> I can get with 1) and 2) would be greatly appreciated.
>>>
>>> Phil
>>>
>>>
>>>
>>>
 Simo

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

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


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

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

RE: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Gary Gregory

Personally, I would prefer to see an earlier release of [pool] 2.0 to be able 
to use Generics ASAP.

Gary 

> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Sunday, January 23, 2011 13:48
> To: Commons Developers List
> Subject: Re: [pool] help needed for pool2.0 - proposal for a release plan
> 
> On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
>  wrote:
> > Hi all guys,
> > I'm here to ask your help to finalize the 2.0 version of pool
> > component, IMHO the following important steps are fondamental before
> > publishing at least the first alpha:
> >
> >  * POOL-172: I added the MBean required interfaces, but due to the
> > lack of JMX tests the issue shouldn't be considered closed;
> >  * POOL-176;
> >  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
> > part of the same refactoring group.
> >  * make pools fields volatile, where possible.
> >
> > Is there anyone that does have spare time to help me?
> > Many thanks in advance, have  anice weekend!!!
> 
> I apologize for being very slow on [pool] recently.  Too many things
> going on.  I have been working, however, on getting a 1.5.6 bugfix
> release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
> need to get them resolved in any case.
> 
> I think we also agreed that we were going to rewrite the core
> implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
> borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
> would still like to do that.  We should all take a careful look at the
> Tomcat code and also the concurrency stuff in [lang] and talk about
> how we are going to do this.
> 
> I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
> the bugs that are impacting users as we work to finalize the API and
> rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
> be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
> bugs would also be appreciated :)
> 
> For me personally, priorities are
>  0) [math] 2.2 release (almost done)
>  1) [pool] 1.5.6
>  2) [dbcp] 1.3.1/1.4.1
>  3) [pool] 2.0
>  4) [dbcp] 2.0
> 
> I would very much like to be involved in the pool rewrite, so any help
> I can get with 1) and 2) would be greatly appreciated.
> 
> Phil
> 
> 
> 
> 
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

RE: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Gary Gregory

> -Original Message-
> From: Gary Gregory
> Sent: Sunday, January 23, 2011 14:37
> To: Commons Developers List
> Subject: RE: [pool] help needed for pool2.0 - proposal for a release plan
> 
> Personally, I would prefer to see an earlier release of [pool] 2.0 to be
> able to use Generics ASAP.

I meant "earlier" not in Phil's schedule but earlier as before re-implementing 
pool guts.

Gary

> 
> Gary
> 
> > -Original Message-
> > From: Phil Steitz [mailto:phil.ste...@gmail.com]
> > Sent: Sunday, January 23, 2011 13:48
> > To: Commons Developers List
> > Subject: Re: [pool] help needed for pool2.0 - proposal for a release plan
> >
> > On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
> >  wrote:
> > > Hi all guys,
> > > I'm here to ask your help to finalize the 2.0 version of pool
> > > component, IMHO the following important steps are fondamental before
> > > publishing at least the first alpha:
> > >
> > >  * POOL-172: I added the MBean required interfaces, but due to the
> > > lack of JMX tests the issue shouldn't be considered closed;
> > >  * POOL-176;
> > >  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
> > > part of the same refactoring group.
> > >  * make pools fields volatile, where possible.
> > >
> > > Is there anyone that does have spare time to help me?
> > > Many thanks in advance, have  anice weekend!!!
> >
> > I apologize for being very slow on [pool] recently.  Too many things
> > going on.  I have been working, however, on getting a 1.5.6 bugfix
> > release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
> > need to get them resolved in any case.
> >
> > I think we also agreed that we were going to rewrite the core
> > implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
> > borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
> > would still like to do that.  We should all take a careful look at the
> > Tomcat code and also the concurrency stuff in [lang] and talk about
> > how we are going to do this.
> >
> > I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
> > the bugs that are impacting users as we work to finalize the API and
> > rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
> > be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
> > bugs would also be appreciated :)
> >
> > For me personally, priorities are
> >  0) [math] 2.2 release (almost done)
> >  1) [pool] 1.5.6
> >  2) [dbcp] 1.3.1/1.4.1
> >  3) [pool] 2.0
> >  4) [dbcp] 2.0
> >
> > I would very much like to be involved in the pool rewrite, so any help
> > I can get with 1) and 2) would be greatly appreciated.
> >
> > Phil
> >
> >
> >
> >
> > > Simo
> > >
> > > http://people.apache.org/~simonetripodi/
> > > http://www.99soft.org/
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [Math] Exception handling (again)

2011-01-23 Thread Luc Maisonobe

Hi Phil,

Le 23/01/2011 19:27, Phil Steitz a écrit :
> Thanks for restarting the discussion of this topic, Gilles.
> 
> Here is a first attempt at some principles for exceptions management
> in [math], followed by an illustration using the ConvergenceException
> case discussed in MATH-487.  The principles are no doubt incomplete
> and some may be wrong and/or not acceptable to the community.  Lets
> try to find consensus on a simple set of principles that we can agree
> on and use as a guide in the 3.0 refactoring and new development.  I
> will update the Developers Guide with what we eventually agree to.
> 
> 0) Exceptions generated by [math] are all unchecked.
> 
> 1) All public methods advertise all exceptions that they can generate.
> 
> 2) All exceptions inherit from the base class, MathRuntimeException
> 
> 3) Whenever possible, methods fully specify parameter preconditions
> required for successful activation.  When preconditions are violated,
> a MathIllegalArgumentException should be thrown.  Subclasses of
> MathIllegalArgumentException may be used to represent common parameter
> contract violations (for example, NoBracketingException).  Exception
> messages must contain sufficient information on parameter values to
> determine the exact precondition failure.
> 
> 4) Exceptions generated by [math] make sense without knowing
> implementation details other than those stated in the public API.  For
> example, a NoBracketingException makes sense thrown by a solver that
> has an API precondition requiring that initial points bracket a root.
>  This exception does not make sense, however, thrown by an inverse
> cumulative probability estimator.
> 
> Together, 3) and 4) imply
> 
> 5) MathIllegalArgumentException should only be thrown in situations
> satisfying 3) - i.e., unless the preconditions can be exhaustively
> provided so that what arguments are "illegal" can be specified fully
> to the caller, different exceptions should be thrown on the event of
> failure.  For example, the exact domain of successful activation of a
> solver or quadrature method may be impossible to specify because of
> numerical properties of the method.  If a solver fails to find a root
> or a quadrature method fails to converge for a given set of
> parameters, *unless those parameters violate the advertised
> preconditions* it is not appropriate to throw
> MathIllegalArgumentException.  Domain-specific exceptions need to be
> defined for these cases.  For example, SingularMatrixException should
> not inherit from MathIllegalArgumentException unless it is only thrown
> in situations satisfying 3) .  All current uses of
> SingularMatrixException do satisfy 3), though the javadoc in some
> cases needs a little cleanup to make it clear how singularity violates
> the contract.  My HO is that it would be better for
> SingularMatrixException to not extend MathIllegalArgumentException,
> substituting instead either just MathRuntimeException or a linear
> domain-specific parent (shared by the other matrix exceptions).
> 
> Now on to the ConvergenceException example.  Many of our algorithms
> amount to generating a sequence of values, hoping that the sequence
> converges (really "gets Cauchy enough") and returning an estimate of
> the limit of the sequence.   Thus far, convergence is always in an
> incomplete metric space and we usually have the extra-mathematical
> issue to deal with that one form of divergence is becoming NaN.
> Convergence failure happens when arguments are outside the
> effectiveness range of the algorithm.  It is often impossible to state
> precisely in preconditions exactly what the conditions are on the
> parameters that will lead to failed convergence.  This is especially
> true when the implementation code contains bugs :)
> 
> Failed convergence manifests in three ways: a) maximum iterations
> exceeded without meeting the convergence criteria b) iterates diverge
> to an infinity an infinite result is not correct c) iterates "diverge
> to NaN" and NaN is not correct.  I suggest therefore, that we define:
> 
> ConvergenceException extending MathIllegalStateException or even just
> MathRuntimeException;
> 
> MaxIterationsExceededException extends ConvergenceException, including
> the max iterations as part of its state and message;
> 
> IterationRangeException extends ConvergenceException, including the
> out of range value encountered and what element of the sequence
> attained the bad value (this allows values other than NaN or
> infinities to count as "divergence").
> 
> We could also add InfiniteIterateException and NaNIterateException
> extending IterationRangeException for these cases.
> 
> I have often wanted to know how far out in the sequence one of the
> values becomes infinite.  Capturing this information in the exception
> and including it in the message would be an improvement, IMO.  The
> fact that you *can* do this in the setup above is an illustration of
> why I like domain-specific exceptions.

Re: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Simone Tripodi

Hi Gary,
I suggest we can push a beta release first, WDYT? I'd like to see the
Generics in action too :P
Simo

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



On Sun, Jan 23, 2011 at 8:38 PM, Gary Gregory
 wrote:
>> -Original Message-
>> From: Gary Gregory
>> Sent: Sunday, January 23, 2011 14:37
>> To: Commons Developers List
>> Subject: RE: [pool] help needed for pool2.0 - proposal for a release plan
>>
>> Personally, I would prefer to see an earlier release of [pool] 2.0 to be
>> able to use Generics ASAP.
>
> I meant "earlier" not in Phil's schedule but earlier as before 
> re-implementing pool guts.
>
> Gary
>
>>
>> Gary
>>
>> > -Original Message-
>> > From: Phil Steitz [mailto:phil.ste...@gmail.com]
>> > Sent: Sunday, January 23, 2011 13:48
>> > To: Commons Developers List
>> > Subject: Re: [pool] help needed for pool2.0 - proposal for a release plan
>> >
>> > On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
>> >  wrote:
>> > > Hi all guys,
>> > > I'm here to ask your help to finalize the 2.0 version of pool
>> > > component, IMHO the following important steps are fondamental before
>> > > publishing at least the first alpha:
>> > >
>> > >  * POOL-172: I added the MBean required interfaces, but due to the
>> > > lack of JMX tests the issue shouldn't be considered closed;
>> > >  * POOL-176;
>> > >  * POOL-173, POOL-177, POOL-178: these can be take in consideration as
>> > > part of the same refactoring group.
>> > >  * make pools fields volatile, where possible.
>> > >
>> > > Is there anyone that does have spare time to help me?
>> > > Many thanks in advance, have  anice weekend!!!
>> >
>> > I apologize for being very slow on [pool] recently.  Too many things
>> > going on.  I have been working, however, on getting a 1.5.6 bugfix
>> > release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
>> > need to get them resolved in any case.
>> >
>> > I think we also agreed that we were going to rewrite the core
>> > implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
>> > borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
>> > would still like to do that.  We should all take a careful look at the
>> > Tomcat code and also the concurrency stuff in [lang] and talk about
>> > how we are going to do this.
>> >
>> > I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
>> > the bugs that are impacting users as we work to finalize the API and
>> > rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
>> > be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
>> > bugs would also be appreciated :)
>> >
>> > For me personally, priorities are
>> >  0) [math] 2.2 release (almost done)
>> >  1) [pool] 1.5.6
>> >  2) [dbcp] 1.3.1/1.4.1
>> >  3) [pool] 2.0
>> >  4) [dbcp] 2.0
>> >
>> > I would very much like to be involved in the pool rewrite, so any help
>> > I can get with 1) and 2) would be greatly appreciated.
>> >
>> > Phil
>> >
>> >
>> >
>> >
>> > > Simo
>> > >
>> > > http://people.apache.org/~simonetripodi/
>> > > http://www.99soft.org/
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > >
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

RE: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Gary Gregory

It feels like a lot of changes have gone in recently and I am not sure if the 
project is in a consistent state. It feels like a lot is in flux.

Gary

> -Original Message-
> From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf
> Of Simone Tripodi
> Sent: Sunday, January 23, 2011 14:48
> To: Commons Developers List
> Subject: Re: [pool] help needed for pool2.0 - proposal for a release plan
> 
> Hi Gary,
> I suggest we can push a beta release first, WDYT? I'd like to see the
> Generics in action too :P
> Simo
> 
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
> 
> 
> 
> On Sun, Jan 23, 2011 at 8:38 PM, Gary Gregory
>  wrote:
> >> -Original Message-
> >> From: Gary Gregory
> >> Sent: Sunday, January 23, 2011 14:37
> >> To: Commons Developers List
> >> Subject: RE: [pool] help needed for pool2.0 - proposal for a release
> plan
> >>
> >> Personally, I would prefer to see an earlier release of [pool] 2.0 to be
> >> able to use Generics ASAP.
> >
> > I meant "earlier" not in Phil's schedule but earlier as before re-
> implementing pool guts.
> >
> > Gary
> >
> >>
> >> Gary
> >>
> >> > -Original Message-
> >> > From: Phil Steitz [mailto:phil.ste...@gmail.com]
> >> > Sent: Sunday, January 23, 2011 13:48
> >> > To: Commons Developers List
> >> > Subject: Re: [pool] help needed for pool2.0 - proposal for a release
> plan
> >> >
> >> > On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
> >> >  wrote:
> >> > > Hi all guys,
> >> > > I'm here to ask your help to finalize the 2.0 version of pool
> >> > > component, IMHO the following important steps are fondamental before
> >> > > publishing at least the first alpha:
> >> > >
> >> > >  * POOL-172: I added the MBean required interfaces, but due to the
> >> > > lack of JMX tests the issue shouldn't be considered closed;
> >> > >  * POOL-176;
> >> > >  * POOL-173, POOL-177, POOL-178: these can be take in consideration
> as
> >> > > part of the same refactoring group.
> >> > >  * make pools fields volatile, where possible.
> >> > >
> >> > > Is there anyone that does have spare time to help me?
> >> > > Many thanks in advance, have  anice weekend!!!
> >> >
> >> > I apologize for being very slow on [pool] recently.  Too many things
> >> > going on.  I have been working, however, on getting a 1.5.6 bugfix
> >> > release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
> >> > need to get them resolved in any case.
> >> >
> >> > I think we also agreed that we were going to rewrite the core
> >> > implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
> >> > borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
> >> > would still like to do that.  We should all take a careful look at the
> >> > Tomcat code and also the concurrency stuff in [lang] and talk about
> >> > how we are going to do this.
> >> >
> >> > I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
> >> > the bugs that are impacting users as we work to finalize the API and
> >> > rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
> >> > be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
> >> > bugs would also be appreciated :)
> >> >
> >> > For me personally, priorities are
> >> >  0) [math] 2.2 release (almost done)
> >> >  1) [pool] 1.5.6
> >> >  2) [dbcp] 1.3.1/1.4.1
> >> >  3) [pool] 2.0
> >> >  4) [dbcp] 2.0
> >> >
> >> > I would very much like to be involved in the pool rewrite, so any help
> >> > I can get with 1) and 2) would be greatly appreciated.
> >> >
> >> > Phil
> >> >
> >> >
> >> >
> >> >
> >> > > Simo
> >> > >
> >> > > http://people.apache.org/~simonetripodi/
> >> > > http://www.99soft.org/
> >> > >
> >> > > 
> -
> >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > > For additional commands, e-mail: dev-h...@commons.apache.org
> >> > >
> >> > >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org

Re: [pool] help needed for pool2.0 - proposal for a release plan

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 3:06 PM, Gary Gregory
 wrote:
> It feels like a lot of changes have gone in recently and I am not sure if the 
> project is in a consistent state. It feels like a lot is in flux.
>

If we are going to release a 2.0 without rewriting the
implementations, we at least need to fix the bugs reported against
1.5.5 first.  I think it is a much better idea to do the
reimplementation first so we - and users - have just one stabilization
period for 2.0 to deal with and we don't have to backport all of the
1.5.x fixes.  I was actually going to recommend that we delete the
org.apache.commons.pool tree in trunk and just start rewriting the
impl in pool2.

Phil

> Gary
>
>> -Original Message-
>> From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf
>> Of Simone Tripodi
>> Sent: Sunday, January 23, 2011 14:48
>> To: Commons Developers List
>> Subject: Re: [pool] help needed for pool2.0 - proposal for a release plan
>>
>> Hi Gary,
>> I suggest we can push a beta release first, WDYT? I'd like to see the
>> Generics in action too :P
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Jan 23, 2011 at 8:38 PM, Gary Gregory
>>  wrote:
>> >> -Original Message-
>> >> From: Gary Gregory
>> >> Sent: Sunday, January 23, 2011 14:37
>> >> To: Commons Developers List
>> >> Subject: RE: [pool] help needed for pool2.0 - proposal for a release
>> plan
>> >>
>> >> Personally, I would prefer to see an earlier release of [pool] 2.0 to be
>> >> able to use Generics ASAP.
>> >
>> > I meant "earlier" not in Phil's schedule but earlier as before re-
>> implementing pool guts.
>> >
>> > Gary
>> >
>> >>
>> >> Gary
>> >>
>> >> > -Original Message-
>> >> > From: Phil Steitz [mailto:phil.ste...@gmail.com]
>> >> > Sent: Sunday, January 23, 2011 13:48
>> >> > To: Commons Developers List
>> >> > Subject: Re: [pool] help needed for pool2.0 - proposal for a release
>> plan
>> >> >
>> >> > On Sun, Jan 23, 2011 at 1:09 PM, Simone Tripodi
>> >> >  wrote:
>> >> > > Hi all guys,
>> >> > > I'm here to ask your help to finalize the 2.0 version of pool
>> >> > > component, IMHO the following important steps are fondamental before
>> >> > > publishing at least the first alpha:
>> >> > >
>> >> > >  * POOL-172: I added the MBean required interfaces, but due to the
>> >> > > lack of JMX tests the issue shouldn't be considered closed;
>> >> > >  * POOL-176;
>> >> > >  * POOL-173, POOL-177, POOL-178: these can be take in consideration
>> as
>> >> > > part of the same refactoring group.
>> >> > >  * make pools fields volatile, where possible.
>> >> > >
>> >> > > Is there anyone that does have spare time to help me?
>> >> > > Many thanks in advance, have  anice weekend!!!
>> >> >
>> >> > I apologize for being very slow on [pool] recently.  Too many things
>> >> > going on.  I have been working, however, on getting a 1.5.6 bugfix
>> >> > release out.  All of the bugs marked 1.5.6 impact the 2.0 code, so we
>> >> > need to get them resolved in any case.
>> >> >
>> >> > I think we also agreed that we were going to rewrite the core
>> >> > implementation of GOP, GKOP for 2.0 using JDK 1.5+ concurrency,
>> >> > borrowing ideas (and maybe code) from Tomcat's jdbc-pool module.  I
>> >> > would still like to do that.  We should all take a careful look at the
>> >> > Tomcat code and also the concurrency stuff in [lang] and talk about
>> >> > how we are going to do this.
>> >> >
>> >> > I would like to get a pool 1.5.6 and DBCP 1.3.1/1.4.1 out ASAP to fix
>> >> > the bugs that are impacting users as we work to finalize the API and
>> >> > rework the implementation in pool 2.0.  Help on the 1.5.6 bugs would
>> >> > be greatly appreciated.  Hijacking as this may be, help on the [dbcp]
>> >> > bugs would also be appreciated :)
>> >> >
>> >> > For me personally, priorities are
>> >> >  0) [math] 2.2 release (almost done)
>> >> >  1) [pool] 1.5.6
>> >> >  2) [dbcp] 1.3.1/1.4.1
>> >> >  3) [pool] 2.0
>> >> >  4) [dbcp] 2.0
>> >> >
>> >> > I would very much like to be involved in the pool rewrite, so any help
>> >> > I can get with 1) and 2) would be greatly appreciated.
>> >> >
>> >> > Phil
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > > Simo
>> >> > >
>> >> > > http://people.apache.org/~simonetripodi/
>> >> > > http://www.99soft.org/
>> >> > >
>> >> > > 
>> -
>> >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> >> > >
>> >> > >
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands

Re: [Math] Exception handling (again)

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 2:45 PM, Luc Maisonobe  wrote:
> Hi Phil,
>
> Le 23/01/2011 19:27, Phil Steitz a écrit :
>> Thanks for restarting the discussion of this topic, Gilles.
>>
>> Here is a first attempt at some principles for exceptions management
>> in [math], followed by an illustration using the ConvergenceException
>> case discussed in MATH-487.  The principles are no doubt incomplete
>> and some may be wrong and/or not acceptable to the community.  Lets
>> try to find consensus on a simple set of principles that we can agree
>> on and use as a guide in the 3.0 refactoring and new development.  I
>> will update the Developers Guide with what we eventually agree to.
>>
>> 0) Exceptions generated by [math] are all unchecked.
>>
>> 1) All public methods advertise all exceptions that they can generate.
>>
>> 2) All exceptions inherit from the base class, MathRuntimeException
>>
>> 3) Whenever possible, methods fully specify parameter preconditions
>> required for successful activation.  When preconditions are violated,
>> a MathIllegalArgumentException should be thrown.  Subclasses of
>> MathIllegalArgumentException may be used to represent common parameter
>> contract violations (for example, NoBracketingException).  Exception
>> messages must contain sufficient information on parameter values to
>> determine the exact precondition failure.
>>
>> 4) Exceptions generated by [math] make sense without knowing
>> implementation details other than those stated in the public API.  For
>> example, a NoBracketingException makes sense thrown by a solver that
>> has an API precondition requiring that initial points bracket a root.
>>  This exception does not make sense, however, thrown by an inverse
>> cumulative probability estimator.
>>
>> Together, 3) and 4) imply
>>
>> 5) MathIllegalArgumentException should only be thrown in situations
>> satisfying 3) - i.e., unless the preconditions can be exhaustively
>> provided so that what arguments are "illegal" can be specified fully
>> to the caller, different exceptions should be thrown on the event of
>> failure.  For example, the exact domain of successful activation of a
>> solver or quadrature method may be impossible to specify because of
>> numerical properties of the method.  If a solver fails to find a root
>> or a quadrature method fails to converge for a given set of
>> parameters, *unless those parameters violate the advertised
>> preconditions* it is not appropriate to throw
>> MathIllegalArgumentException.  Domain-specific exceptions need to be
>> defined for these cases.  For example, SingularMatrixException should
>> not inherit from MathIllegalArgumentException unless it is only thrown
>> in situations satisfying 3) .  All current uses of
>> SingularMatrixException do satisfy 3), though the javadoc in some
>> cases needs a little cleanup to make it clear how singularity violates
>> the contract.  My HO is that it would be better for
>> SingularMatrixException to not extend MathIllegalArgumentException,
>> substituting instead either just MathRuntimeException or a linear
>> domain-specific parent (shared by the other matrix exceptions).
>>
>> Now on to the ConvergenceException example.  Many of our algorithms
>> amount to generating a sequence of values, hoping that the sequence
>> converges (really "gets Cauchy enough") and returning an estimate of
>> the limit of the sequence.   Thus far, convergence is always in an
>> incomplete metric space and we usually have the extra-mathematical
>> issue to deal with that one form of divergence is becoming NaN.
>> Convergence failure happens when arguments are outside the
>> effectiveness range of the algorithm.  It is often impossible to state
>> precisely in preconditions exactly what the conditions are on the
>> parameters that will lead to failed convergence.  This is especially
>> true when the implementation code contains bugs :)
>>
>> Failed convergence manifests in three ways: a) maximum iterations
>> exceeded without meeting the convergence criteria b) iterates diverge
>> to an infinity an infinite result is not correct c) iterates "diverge
>> to NaN" and NaN is not correct.  I suggest therefore, that we define:
>>
>> ConvergenceException extending MathIllegalStateException or even just
>> MathRuntimeException;
>>
>> MaxIterationsExceededException extends ConvergenceException, including
>> the max iterations as part of its state and message;
>>
>> IterationRangeException extends ConvergenceException, including the
>> out of range value encountered and what element of the sequence
>> attained the bad value (this allows values other than NaN or
>> infinities to count as "divergence").
>>
>> We could also add InfiniteIterateException and NaNIterateException
>> extending IterationRangeException for these cases.
>>
>> I have often wanted to know how far out in the sequence one of the
>> values becomes infinite.  Capturing this information in the exception
>> and including it in the message would be an imp

Re: [Math] Exception handling (again)

2011-01-23 Thread Gilles Sadowski

Hello.

> > Thanks for restarting the discussion of this topic, Gilles.
> > 
> > Here is a first attempt at some principles for exceptions management
> > in [math], followed by an illustration using the ConvergenceException
> > case discussed in MATH-487.  The principles are no doubt incomplete
> > and some may be wrong and/or not acceptable to the community.  Lets
> > try to find consensus on a simple set of principles that we can agree
> > on and use as a guide in the 3.0 refactoring and new development.  I
> > will update the Developers Guide with what we eventually agree to.
> > 
> > 0) Exceptions generated by [math] are all unchecked.
> > 
> > 1) All public methods advertise all exceptions that they can generate.
> > 
> > 2) All exceptions inherit from the base class, MathRuntimeException
> > 
> > 3) Whenever possible, methods fully specify parameter preconditions
> > required for successful activation.  When preconditions are violated,
> > a MathIllegalArgumentException should be thrown.  Subclasses of
> > MathIllegalArgumentException may be used to represent common parameter
> > contract violations (for example, NoBracketingException).  Exception
> > messages must contain sufficient information on parameter values to
> > determine the exact precondition failure.
> > 
> > 4) Exceptions generated by [math] make sense without knowing
> > implementation details other than those stated in the public API.  For
> > example, a NoBracketingException makes sense thrown by a solver that
> > has an API precondition requiring that initial points bracket a root.
> >  This exception does not make sense, however, thrown by an inverse
> > cumulative probability estimator.
> > 
> > Together, 3) and 4) imply
> > 
> > 5) MathIllegalArgumentException should only be thrown in situations
> > satisfying 3) - i.e., unless the preconditions can be exhaustively
> > provided so that what arguments are "illegal" can be specified fully
> > to the caller, different exceptions should be thrown on the event of
> > failure.  For example, the exact domain of successful activation of a
> > solver or quadrature method may be impossible to specify because of
> > numerical properties of the method.  If a solver fails to find a root
> > or a quadrature method fails to converge for a given set of
> > parameters, *unless those parameters violate the advertised
> > preconditions* it is not appropriate to throw
> > MathIllegalArgumentException.  Domain-specific exceptions need to be
> > defined for these cases.  For example, SingularMatrixException should
> > not inherit from MathIllegalArgumentException unless it is only thrown
> > in situations satisfying 3) .  All current uses of
> > SingularMatrixException do satisfy 3), though the javadoc in some
> > cases needs a little cleanup to make it clear how singularity violates
> > the contract.  My HO is that it would be better for
> > SingularMatrixException to not extend MathIllegalArgumentException,
> > substituting instead either just MathRuntimeException or a linear
> > domain-specific parent (shared by the other matrix exceptions).
> > 
> > Now on to the ConvergenceException example.  Many of our algorithms
> > amount to generating a sequence of values, hoping that the sequence
> > converges (really "gets Cauchy enough") and returning an estimate of
> > the limit of the sequence.   Thus far, convergence is always in an
> > incomplete metric space and we usually have the extra-mathematical
> > issue to deal with that one form of divergence is becoming NaN.
> > Convergence failure happens when arguments are outside the
> > effectiveness range of the algorithm.  It is often impossible to state
> > precisely in preconditions exactly what the conditions are on the
> > parameters that will lead to failed convergence.  This is especially
> > true when the implementation code contains bugs :)
> > 
> > Failed convergence manifests in three ways: a) maximum iterations
> > exceeded without meeting the convergence criteria b) iterates diverge
> > to an infinity an infinite result is not correct c) iterates "diverge
> > to NaN" and NaN is not correct.  I suggest therefore, that we define:
> > 
> > ConvergenceException extending MathIllegalStateException or even just
> > MathRuntimeException;
> > 
> > MaxIterationsExceededException extends ConvergenceException, including
> > the max iterations as part of its state and message;
> > 
> > IterationRangeException extends ConvergenceException, including the
> > out of range value encountered and what element of the sequence
> > attained the bad value (this allows values other than NaN or
> > infinities to count as "divergence").
> > 
> > We could also add InfiniteIterateException and NaNIterateException
> > extending IterationRangeException for these cases.
> > 
> > I have often wanted to know how far out in the sequence one of the
> > values becomes infinite.  Capturing this information in the exception
> > and including it in the message would be an impro

Re: [Math] Exception handling (again)

2011-01-23 Thread Luc Maisonobe

Le 23/01/2011 22:10, Phil Steitz a écrit :
> On Sun, Jan 23, 2011 at 2:45 PM, Luc Maisonobe  wrote:
>> Hi Phil,
>>
>> Le 23/01/2011 19:27, Phil Steitz a écrit :
>>> Thanks for restarting the discussion of this topic, Gilles.
>>>
>>> Here is a first attempt at some principles for exceptions management
>>> in [math], followed by an illustration using the ConvergenceException
>>> case discussed in MATH-487.  The principles are no doubt incomplete
>>> and some may be wrong and/or not acceptable to the community.  Lets
>>> try to find consensus on a simple set of principles that we can agree
>>> on and use as a guide in the 3.0 refactoring and new development.  I
>>> will update the Developers Guide with what we eventually agree to.
>>>
>>> 0) Exceptions generated by [math] are all unchecked.
>>>
>>> 1) All public methods advertise all exceptions that they can generate.
>>>
>>> 2) All exceptions inherit from the base class, MathRuntimeException
>>>
>>> 3) Whenever possible, methods fully specify parameter preconditions
>>> required for successful activation.  When preconditions are violated,
>>> a MathIllegalArgumentException should be thrown.  Subclasses of
>>> MathIllegalArgumentException may be used to represent common parameter
>>> contract violations (for example, NoBracketingException).  Exception
>>> messages must contain sufficient information on parameter values to
>>> determine the exact precondition failure.
>>>
>>> 4) Exceptions generated by [math] make sense without knowing
>>> implementation details other than those stated in the public API.  For
>>> example, a NoBracketingException makes sense thrown by a solver that
>>> has an API precondition requiring that initial points bracket a root.
>>>  This exception does not make sense, however, thrown by an inverse
>>> cumulative probability estimator.
>>>
>>> Together, 3) and 4) imply
>>>
>>> 5) MathIllegalArgumentException should only be thrown in situations
>>> satisfying 3) - i.e., unless the preconditions can be exhaustively
>>> provided so that what arguments are "illegal" can be specified fully
>>> to the caller, different exceptions should be thrown on the event of
>>> failure.  For example, the exact domain of successful activation of a
>>> solver or quadrature method may be impossible to specify because of
>>> numerical properties of the method.  If a solver fails to find a root
>>> or a quadrature method fails to converge for a given set of
>>> parameters, *unless those parameters violate the advertised
>>> preconditions* it is not appropriate to throw
>>> MathIllegalArgumentException.  Domain-specific exceptions need to be
>>> defined for these cases.  For example, SingularMatrixException should
>>> not inherit from MathIllegalArgumentException unless it is only thrown
>>> in situations satisfying 3) .  All current uses of
>>> SingularMatrixException do satisfy 3), though the javadoc in some
>>> cases needs a little cleanup to make it clear how singularity violates
>>> the contract.  My HO is that it would be better for
>>> SingularMatrixException to not extend MathIllegalArgumentException,
>>> substituting instead either just MathRuntimeException or a linear
>>> domain-specific parent (shared by the other matrix exceptions).
>>>
>>> Now on to the ConvergenceException example.  Many of our algorithms
>>> amount to generating a sequence of values, hoping that the sequence
>>> converges (really "gets Cauchy enough") and returning an estimate of
>>> the limit of the sequence.   Thus far, convergence is always in an
>>> incomplete metric space and we usually have the extra-mathematical
>>> issue to deal with that one form of divergence is becoming NaN.
>>> Convergence failure happens when arguments are outside the
>>> effectiveness range of the algorithm.  It is often impossible to state
>>> precisely in preconditions exactly what the conditions are on the
>>> parameters that will lead to failed convergence.  This is especially
>>> true when the implementation code contains bugs :)
>>>
>>> Failed convergence manifests in three ways: a) maximum iterations
>>> exceeded without meeting the convergence criteria b) iterates diverge
>>> to an infinity an infinite result is not correct c) iterates "diverge
>>> to NaN" and NaN is not correct.  I suggest therefore, that we define:
>>>
>>> ConvergenceException extending MathIllegalStateException or even just
>>> MathRuntimeException;
>>>
>>> MaxIterationsExceededException extends ConvergenceException, including
>>> the max iterations as part of its state and message;
>>>
>>> IterationRangeException extends ConvergenceException, including the
>>> out of range value encountered and what element of the sequence
>>> attained the bad value (this allows values other than NaN or
>>> infinities to count as "divergence").
>>>
>>> We could also add InfiniteIterateException and NaNIterateException
>>> extending IterationRangeException for these cases.
>>>
>>> I have often wanted to know how far out in the sequence

Re: [Math] Exception handling (again)

2011-01-23 Thread Luc Maisonobe

Le 23/01/2011 22:12, Gilles Sadowski a écrit :
> Hello.
> 
>>> Thanks for restarting the discussion of this topic, Gilles.
>>>
>>> Here is a first attempt at some principles for exceptions management
>>> in [math], followed by an illustration using the ConvergenceException
>>> case discussed in MATH-487.  The principles are no doubt incomplete
>>> and some may be wrong and/or not acceptable to the community.  Lets
>>> try to find consensus on a simple set of principles that we can agree
>>> on and use as a guide in the 3.0 refactoring and new development.  I
>>> will update the Developers Guide with what we eventually agree to.
>>>
>>> 0) Exceptions generated by [math] are all unchecked.
>>>
>>> 1) All public methods advertise all exceptions that they can generate.
>>>
>>> 2) All exceptions inherit from the base class, MathRuntimeException
>>>
>>> 3) Whenever possible, methods fully specify parameter preconditions
>>> required for successful activation.  When preconditions are violated,
>>> a MathIllegalArgumentException should be thrown.  Subclasses of
>>> MathIllegalArgumentException may be used to represent common parameter
>>> contract violations (for example, NoBracketingException).  Exception
>>> messages must contain sufficient information on parameter values to
>>> determine the exact precondition failure.
>>>
>>> 4) Exceptions generated by [math] make sense without knowing
>>> implementation details other than those stated in the public API.  For
>>> example, a NoBracketingException makes sense thrown by a solver that
>>> has an API precondition requiring that initial points bracket a root.
>>>  This exception does not make sense, however, thrown by an inverse
>>> cumulative probability estimator.
>>>
>>> Together, 3) and 4) imply
>>>
>>> 5) MathIllegalArgumentException should only be thrown in situations
>>> satisfying 3) - i.e., unless the preconditions can be exhaustively
>>> provided so that what arguments are "illegal" can be specified fully
>>> to the caller, different exceptions should be thrown on the event of
>>> failure.  For example, the exact domain of successful activation of a
>>> solver or quadrature method may be impossible to specify because of
>>> numerical properties of the method.  If a solver fails to find a root
>>> or a quadrature method fails to converge for a given set of
>>> parameters, *unless those parameters violate the advertised
>>> preconditions* it is not appropriate to throw
>>> MathIllegalArgumentException.  Domain-specific exceptions need to be
>>> defined for these cases.  For example, SingularMatrixException should
>>> not inherit from MathIllegalArgumentException unless it is only thrown
>>> in situations satisfying 3) .  All current uses of
>>> SingularMatrixException do satisfy 3), though the javadoc in some
>>> cases needs a little cleanup to make it clear how singularity violates
>>> the contract.  My HO is that it would be better for
>>> SingularMatrixException to not extend MathIllegalArgumentException,
>>> substituting instead either just MathRuntimeException or a linear
>>> domain-specific parent (shared by the other matrix exceptions).
>>>
>>> Now on to the ConvergenceException example.  Many of our algorithms
>>> amount to generating a sequence of values, hoping that the sequence
>>> converges (really "gets Cauchy enough") and returning an estimate of
>>> the limit of the sequence.   Thus far, convergence is always in an
>>> incomplete metric space and we usually have the extra-mathematical
>>> issue to deal with that one form of divergence is becoming NaN.
>>> Convergence failure happens when arguments are outside the
>>> effectiveness range of the algorithm.  It is often impossible to state
>>> precisely in preconditions exactly what the conditions are on the
>>> parameters that will lead to failed convergence.  This is especially
>>> true when the implementation code contains bugs :)
>>>
>>> Failed convergence manifests in three ways: a) maximum iterations
>>> exceeded without meeting the convergence criteria b) iterates diverge
>>> to an infinity an infinite result is not correct c) iterates "diverge
>>> to NaN" and NaN is not correct.  I suggest therefore, that we define:
>>>
>>> ConvergenceException extending MathIllegalStateException or even just
>>> MathRuntimeException;
>>>
>>> MaxIterationsExceededException extends ConvergenceException, including
>>> the max iterations as part of its state and message;
>>>
>>> IterationRangeException extends ConvergenceException, including the
>>> out of range value encountered and what element of the sequence
>>> attained the bad value (this allows values other than NaN or
>>> infinities to count as "divergence").
>>>
>>> We could also add InfiniteIterateException and NaNIterateException
>>> extending IterationRangeException for these cases.
>>>
>>> I have often wanted to know how far out in the sequence one of the
>>> values becomes infinite.  Capturing this information in the exception
>>> and including

Re: [Math] Exception handling (again)

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 4:12 PM, Gilles Sadowski
 wrote:
> Hello.
>
>> > Thanks for restarting the discussion of this topic, Gilles.
>> >
>> > Here is a first attempt at some principles for exceptions management
>> > in [math], followed by an illustration using the ConvergenceException
>> > case discussed in MATH-487.  The principles are no doubt incomplete
>> > and some may be wrong and/or not acceptable to the community.  Lets
>> > try to find consensus on a simple set of principles that we can agree
>> > on and use as a guide in the 3.0 refactoring and new development.  I
>> > will update the Developers Guide with what we eventually agree to.
>> >
>> > 0) Exceptions generated by [math] are all unchecked.
>> >
>> > 1) All public methods advertise all exceptions that they can generate.
>> >
>> > 2) All exceptions inherit from the base class, MathRuntimeException
>> >
>> > 3) Whenever possible, methods fully specify parameter preconditions
>> > required for successful activation.  When preconditions are violated,
>> > a MathIllegalArgumentException should be thrown.  Subclasses of
>> > MathIllegalArgumentException may be used to represent common parameter
>> > contract violations (for example, NoBracketingException).  Exception
>> > messages must contain sufficient information on parameter values to
>> > determine the exact precondition failure.
>> >
>> > 4) Exceptions generated by [math] make sense without knowing
>> > implementation details other than those stated in the public API.  For
>> > example, a NoBracketingException makes sense thrown by a solver that
>> > has an API precondition requiring that initial points bracket a root.
>> >  This exception does not make sense, however, thrown by an inverse
>> > cumulative probability estimator.
>> >
>> > Together, 3) and 4) imply
>> >
>> > 5) MathIllegalArgumentException should only be thrown in situations
>> > satisfying 3) - i.e., unless the preconditions can be exhaustively
>> > provided so that what arguments are "illegal" can be specified fully
>> > to the caller, different exceptions should be thrown on the event of
>> > failure.  For example, the exact domain of successful activation of a
>> > solver or quadrature method may be impossible to specify because of
>> > numerical properties of the method.  If a solver fails to find a root
>> > or a quadrature method fails to converge for a given set of
>> > parameters, *unless those parameters violate the advertised
>> > preconditions* it is not appropriate to throw
>> > MathIllegalArgumentException.  Domain-specific exceptions need to be
>> > defined for these cases.  For example, SingularMatrixException should
>> > not inherit from MathIllegalArgumentException unless it is only thrown
>> > in situations satisfying 3) .  All current uses of
>> > SingularMatrixException do satisfy 3), though the javadoc in some
>> > cases needs a little cleanup to make it clear how singularity violates
>> > the contract.  My HO is that it would be better for
>> > SingularMatrixException to not extend MathIllegalArgumentException,
>> > substituting instead either just MathRuntimeException or a linear
>> > domain-specific parent (shared by the other matrix exceptions).
>> >
>> > Now on to the ConvergenceException example.  Many of our algorithms
>> > amount to generating a sequence of values, hoping that the sequence
>> > converges (really "gets Cauchy enough") and returning an estimate of
>> > the limit of the sequence.   Thus far, convergence is always in an
>> > incomplete metric space and we usually have the extra-mathematical
>> > issue to deal with that one form of divergence is becoming NaN.
>> > Convergence failure happens when arguments are outside the
>> > effectiveness range of the algorithm.  It is often impossible to state
>> > precisely in preconditions exactly what the conditions are on the
>> > parameters that will lead to failed convergence.  This is especially
>> > true when the implementation code contains bugs :)
>> >
>> > Failed convergence manifests in three ways: a) maximum iterations
>> > exceeded without meeting the convergence criteria b) iterates diverge
>> > to an infinity an infinite result is not correct c) iterates "diverge
>> > to NaN" and NaN is not correct.  I suggest therefore, that we define:
>> >
>> > ConvergenceException extending MathIllegalStateException or even just
>> > MathRuntimeException;
>> >
>> > MaxIterationsExceededException extends ConvergenceException, including
>> > the max iterations as part of its state and message;
>> >
>> > IterationRangeException extends ConvergenceException, including the
>> > out of range value encountered and what element of the sequence
>> > attained the bad value (this allows values other than NaN or
>> > infinities to count as "divergence").
>> >
>> > We could also add InfiniteIterateException and NaNIterateException
>> > extending IterationRangeException for these cases.
>> >
>> > I have often wanted to know how far out in the sequence one of

Re: [Math] Exception handling (again)

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 4:10 PM, Phil Steitz  wrote:
> On Sun, Jan 23, 2011 at 2:45 PM, Luc Maisonobe  wrote:
>> Hi Phil,
>>
>> Le 23/01/2011 19:27, Phil Steitz a écrit :
>>> Thanks for restarting the discussion of this topic, Gilles.
>>>
>>> Here is a first attempt at some principles for exceptions management
>>> in [math], followed by an illustration using the ConvergenceException
>>> case discussed in MATH-487.  The principles are no doubt incomplete
>>> and some may be wrong and/or not acceptable to the community.  Lets
>>> try to find consensus on a simple set of principles that we can agree
>>> on and use as a guide in the 3.0 refactoring and new development.  I
>>> will update the Developers Guide with what we eventually agree to.
>>>
>>> 0) Exceptions generated by [math] are all unchecked.
>>>
>>> 1) All public methods advertise all exceptions that they can generate.
>>>
>>> 2) All exceptions inherit from the base class, MathRuntimeException
>>>
>>> 3) Whenever possible, methods fully specify parameter preconditions
>>> required for successful activation.  When preconditions are violated,
>>> a MathIllegalArgumentException should be thrown.  Subclasses of
>>> MathIllegalArgumentException may be used to represent common parameter
>>> contract violations (for example, NoBracketingException).  Exception
>>> messages must contain sufficient information on parameter values to
>>> determine the exact precondition failure.
>>>
>>> 4) Exceptions generated by [math] make sense without knowing
>>> implementation details other than those stated in the public API.  For
>>> example, a NoBracketingException makes sense thrown by a solver that
>>> has an API precondition requiring that initial points bracket a root.
>>>  This exception does not make sense, however, thrown by an inverse
>>> cumulative probability estimator.
>>>
>>> Together, 3) and 4) imply
>>>
>>> 5) MathIllegalArgumentException should only be thrown in situations
>>> satisfying 3) - i.e., unless the preconditions can be exhaustively
>>> provided so that what arguments are "illegal" can be specified fully
>>> to the caller, different exceptions should be thrown on the event of
>>> failure.  For example, the exact domain of successful activation of a
>>> solver or quadrature method may be impossible to specify because of
>>> numerical properties of the method.  If a solver fails to find a root
>>> or a quadrature method fails to converge for a given set of
>>> parameters, *unless those parameters violate the advertised
>>> preconditions* it is not appropriate to throw
>>> MathIllegalArgumentException.  Domain-specific exceptions need to be
>>> defined for these cases.  For example, SingularMatrixException should
>>> not inherit from MathIllegalArgumentException unless it is only thrown
>>> in situations satisfying 3) .  All current uses of
>>> SingularMatrixException do satisfy 3), though the javadoc in some
>>> cases needs a little cleanup to make it clear how singularity violates
>>> the contract.  My HO is that it would be better for
>>> SingularMatrixException to not extend MathIllegalArgumentException,
>>> substituting instead either just MathRuntimeException or a linear
>>> domain-specific parent (shared by the other matrix exceptions).
>>>
>>> Now on to the ConvergenceException example.  Many of our algorithms
>>> amount to generating a sequence of values, hoping that the sequence
>>> converges (really "gets Cauchy enough") and returning an estimate of
>>> the limit of the sequence.   Thus far, convergence is always in an
>>> incomplete metric space and we usually have the extra-mathematical
>>> issue to deal with that one form of divergence is becoming NaN.
>>> Convergence failure happens when arguments are outside the
>>> effectiveness range of the algorithm.  It is often impossible to state
>>> precisely in preconditions exactly what the conditions are on the
>>> parameters that will lead to failed convergence.  This is especially
>>> true when the implementation code contains bugs :)
>>>
>>> Failed convergence manifests in three ways: a) maximum iterations
>>> exceeded without meeting the convergence criteria b) iterates diverge
>>> to an infinity an infinite result is not correct c) iterates "diverge
>>> to NaN" and NaN is not correct.  I suggest therefore, that we define:
>>>
>>> ConvergenceException extending MathIllegalStateException or even just
>>> MathRuntimeException;
>>>
>>> MaxIterationsExceededException extends ConvergenceException, including
>>> the max iterations as part of its state and message;
>>>
>>> IterationRangeException extends ConvergenceException, including the
>>> out of range value encountered and what element of the sequence
>>> attained the bad value (this allows values other than NaN or
>>> infinities to count as "divergence").
>>>
>>> We could also add InfiniteIterateException and NaNIterateException
>>> extending IterationRangeException for these cases.
>>>
>>> I have often wanted to know how far out in the

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Rahul Akolkar

On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
 wrote:
> Hi all guys,
> I would like to propose a new sandbox to experiment a fresh,
> different, new set of Digester APIs that strongly uses a DSL for rules
> configuration.
> As described in the original proposal[1], the idea comes from a James
> Carman's comment on an old Digester issue, so his
> help/guidance/mentoring would be more than appreciated.
> Please cast your vote, if there are no objections I would like to
> start this work in the sandbox and try to promote as TLP with your
> help/mentoring/involvement.


This would be in addition to the existing digester APIs? I think we
want to be compatible so don't know if it makes sense to remove/change
existing APIs.

The sandbox is always open for experimentation, no objections there.

-Rahul


> I really hope this could be point of your interest that makes you
> curious enough to participate!
> Have a nice day, all the best,
> Simo
>
> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 6:57 AM, sebb  wrote:
> On 23 January 2011 09:58, Luc Maisonobe  wrote:
>> Le 23/01/2011 01:58, s...@apache.org a écrit :
>>> Author: sebb
>>> Date: Sun Jan 23 00:58:07 2011
>>> New Revision: 1062304
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
>>> Log:
>>> MATH-496 Create FastMath copySign methods
>>
>> I was also creating these methods.
>> I have created all the missing ones and implemented hypot directly, so
>> don't bother doing it too.
>
> OK.
>
> I've mainly been working in Math trunk, and porting back to 2.2, so
> I'll add your new methods back to trunk.
> I'll also merge my fixes to nextAfter.
>
> FastMath and FastMathTest should be the same in both.
>
> Apart from the @since marker in FastMath - perhaps we can use @since
> 2.2, 3.0 for that?

Should be @since 2.2

Lets try to get all the fixes into 2.2.

Phil

> Or if that is confusing, we just need to fix one before release.
>
>> Luc
>>
>>>
>>> Modified:
>>>     
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>>
>>> Modified: 
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>> URL: 
>>> http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1062304&r1=1062303&r2=1062304&view=diff
>>> ==
>>> --- 
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>>  (original)
>>> +++ 
>>> commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
>>>  Sun Jan 23 00:58:07 2011
>>> @@ -247,18 +247,6 @@ public class FastMath {
>>>      // Generic helper methods
>>>
>>>      /**
>>> -     * Get the sign information (works even for 0).
>>> -     *
>>> -     * @param d the value to check
>>> -     *
>>> -     * @return +1.0 or -1.0, never 0.0
>>> -     */
>>> -    private static double getSign(double d){ // TODO perhaps move to 
>>> MathUtils?
>>> -        long l = Double.doubleToLongBits(d);
>>> -        return l < 0 ? -1.0 : 1.0;
>>> -    }
>>> -
>>> -    /**
>>>       * Get the high order bits from the mantissa.
>>>       * Equivalent to adding and subtracting HEX_4 but also works for 
>>> very large numbers
>>>       *
>>> @@ -2798,7 +2786,7 @@ public class FastMath {
>>>          int idx;
>>>
>>>          if (xa == 0.0) { // Matches +/- 0.0; return correct sign
>>> -            return leftPlane ? getSign(xa) * Math.PI : xa;
>>> +            return leftPlane ? copySign(Math.PI, xa) : xa;
>>>          }
>>>
>>>          if (xa < 0) {
>>> @@ -2957,7 +2945,7 @@ public class FastMath {
>>>                  if (x > 0) {
>>>                      return y; // return +/- 0.0
>>>                  } else {
>>> -                    return getSign(y) * Math.PI;
>>> +                    return copySign(Math.PI, y);
>>>                  }
>>>              }
>>>
>>> @@ -3737,4 +3725,37 @@ public class FastMath {
>>>          return StrictMath.IEEEremainder(dividend, divisor); // TODO 
>>> provide our own implementation
>>>      }
>>>
>>> +    /**
>>> +     * Returns the first argument with the sign of the second argument.
>>> +     * A NaN {@code sign} argument is treated as positive.
>>> +     *
>>> +     * @param magnitude the value to return
>>> +     * @param sign the sign for the returned value
>>> +     * @return the magnitude with the same sign as the {@code sign} 
>>> argument
>>> +     */
>>> +    public static double copySign(double magnitude, double sign){
>>> +        long m = Double.doubleToLongBits(magnitude);
>>> +        long s = Double.doubleToLongBits(sign);
>>> +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently 
>>> OK
>>> +            return magnitude;
>>> +        }
>>> +        return -magnitude; // flip sign
>>> +    }
>>> +
>>> +    /**
>>> +     * Returns the first argument with the sign of the second argument.
>>> +     * A NaN {@code sign} argument is treated as positive.
>>> +     *
>>> +     * @param magnitude the value to return
>>> +     * @param sign the sign for the returned value
>>> +     * @return the magnitude with the same sign as the {@code sign} 
>>> argument
>>> +     */
>>> +    public static float copySign(float magnitude, float sign){
>>> +        int m = Float.floatToIntBits(magnitude);
>>> +        int s = Float.floatToIntBits(sign);
>>> +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is currently 
>>> OK
>>> +            return magnitude;
>>> +        }
>>> +        return -magnitude; // flip sign
>>> +    }
>>>  }
>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsu

Re: [Math] Exception handling (again)

2011-01-23 Thread Gilles Sadowski

Hi.

> > [...]
> > 
> >> Concerning point 1), there are two ways to advertise the exception.
> >> Javadoc only, or Javadoc plus throws clause. I personnaly would prefer
> >> Javadoc plus throws clause as it is simpler to make sure we didn't
> >> forget anything (using the trick of temporarily changing the base class
> >> for MathRuntimeException and look at compiler errors).
> > 
> > I'm against declaring runtime exception in "throws" clauses because it's
> > only useful for the trick you mention. If the documentation is consistent,
> > it is just redundant with it.
> 
> The goal is to be sure documentation is consistent and to have tools to
> check it.

I understand. But, as I have already said, this has drawbacks for the unwary
user, and because of this, it is advised against (also in Sun's guidelines,
I think).

> > Nothing prevents you from using your trick, but don't force the others to
> > follow non-standard coding guidelines ;-)
> 
> The problem with missing throws statements is that if someone tries to
> use this trick but someone else
 ^^^
That's me. Doing that was also a lot of work, aimed at (from my standpoint)
cleaning up the code...

> removes the throws statements each time,
> this is a LOT of work to redo each time because there will be a lot of
> missing throws.

It shouldn't be done each time: Someone writes some code, he knows what
exceptions his code throws, and he documents them.
Of course, he can forget something, but you have to balance that with the
drawbacks of having misleading "throws" clauses.

> So if you don't want to add the throws statements yourself, you are free
> to ignore them, but please don't remove the ones others put as it
> simplifies their work.

OK. I won't delete them anymore (even if I still don't like them). But their
purpose should be mentioned somewhere (e.g. in these CM-specific guidelines
which everyone thought they were not necessary because we follow the
"standard" coding guidelines; which, obviously, is not true is this case).

Also, to reduce the amount of tedious work of commenting the trivial
cases, I propose that it is not mandatory to document occurrences of
"NullArgumentException" and "NoDataException": I think that it's sufficient
clue for the user to have their names appear in "throws" clause (even if the
argument is no explicitely mentioned).


Gilles

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread sebb

On 23 January 2011 22:18, Phil Steitz  wrote:
> On Sun, Jan 23, 2011 at 6:57 AM, sebb  wrote:
>> On 23 January 2011 09:58, Luc Maisonobe  wrote:
>>> Le 23/01/2011 01:58, s...@apache.org a écrit :
 Author: sebb
 Date: Sun Jan 23 00:58:07 2011
 New Revision: 1062304

 URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
 Log:
 MATH-496 Create FastMath copySign methods
>>>
>>> I was also creating these methods.
>>> I have created all the missing ones and implemented hypot directly, so
>>> don't bother doing it too.
>>
>> OK.
>>
>> I've mainly been working in Math trunk, and porting back to 2.2, so
>> I'll add your new methods back to trunk.
>> I'll also merge my fixes to nextAfter.
>>
>> FastMath and FastMathTest should be the same in both.
>>
>> Apart from the @since marker in FastMath - perhaps we can use @since
>> 2.2, 3.0 for that?
>
> Should be @since 2.2
>
> Lets try to get all the fixes into 2.2.

Yes, indeed. I think we are quite close now.

==

What I meant was - the class is new for 2.2 and also new for 3.0.
The class and its test class(es) are currently the same for both
versions of Math.

We obviously need to put @since 2.2 in the class for the 2.2 release.
Is that sufficient also for the 3.0 release?
Or do we need to put @since 3.0 in it for that?

Strictly speaking it is new to 3.0 too.

So maybe we can put:

@since 2.0
@since 3.0

or

@since 2.0,3.0

in the (one) copy of the file.

This would be easier than having to fix the @since marker in one of the files.

> Phil
>
>> Or if that is confusing, we just need to fix one before release.
>>
>>> Luc
>>>

 Modified:
     
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

 Modified: 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
 URL: 
 http://svn.apache.org/viewvc/commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1062304&r1=1062303&r2=1062304&view=diff
 ==
 --- 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
  (original)
 +++ 
 commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java
  Sun Jan 23 00:58:07 2011
 @@ -247,18 +247,6 @@ public class FastMath {
      // Generic helper methods

      /**
 -     * Get the sign information (works even for 0).
 -     *
 -     * @param d the value to check
 -     *
 -     * @return +1.0 or -1.0, never 0.0
 -     */
 -    private static double getSign(double d){ // TODO perhaps move to 
 MathUtils?
 -        long l = Double.doubleToLongBits(d);
 -        return l < 0 ? -1.0 : 1.0;
 -    }
 -
 -    /**
       * Get the high order bits from the mantissa.
       * Equivalent to adding and subtracting HEX_4 but also works for 
 very large numbers
       *
 @@ -2798,7 +2786,7 @@ public class FastMath {
          int idx;

          if (xa == 0.0) { // Matches +/- 0.0; return correct sign
 -            return leftPlane ? getSign(xa) * Math.PI : xa;
 +            return leftPlane ? copySign(Math.PI, xa) : xa;
          }

          if (xa < 0) {
 @@ -2957,7 +2945,7 @@ public class FastMath {
                  if (x > 0) {
                      return y; // return +/- 0.0
                  } else {
 -                    return getSign(y) * Math.PI;
 +                    return copySign(Math.PI, y);
                  }
              }

 @@ -3737,4 +3725,37 @@ public class FastMath {
          return StrictMath.IEEEremainder(dividend, divisor); // TODO 
 provide our own implementation
      }

 +    /**
 +     * Returns the first argument with the sign of the second argument.
 +     * A NaN {@code sign} argument is treated as positive.
 +     *
 +     * @param magnitude the value to return
 +     * @param sign the sign for the returned value
 +     * @return the magnitude with the same sign as the {@code sign} 
 argument
 +     */
 +    public static double copySign(double magnitude, double sign){
 +        long m = Double.doubleToLongBits(magnitude);
 +        long s = Double.doubleToLongBits(sign);
 +        if ((m >= 0 && s >= 0) || (m < 0 && s < 0)) { // Sign is 
 currently OK
 +            return magnitude;
 +        }
 +        return -magnitude; // flip sign
 +    }
 +
 +    /**
 +     * Returns the first argument with the sign of the second argument.
 +     * A NaN {@code sign} argument is treated as positive.
 +     *
 +     * @param magnitude the value to return
 +     * @param sign the sign for the returned value
 +     * @return the m

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 6:54 PM, sebb  wrote:
> On 23 January 2011 22:18, Phil Steitz  wrote:
>> On Sun, Jan 23, 2011 at 6:57 AM, sebb  wrote:
>>> On 23 January 2011 09:58, Luc Maisonobe  wrote:
 Le 23/01/2011 01:58, s...@apache.org a écrit :
> Author: sebb
> Date: Sun Jan 23 00:58:07 2011
> New Revision: 1062304
>
> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
> Log:
> MATH-496 Create FastMath copySign methods

 I was also creating these methods.
 I have created all the missing ones and implemented hypot directly, so
 don't bother doing it too.
>>>
>>> OK.
>>>
>>> I've mainly been working in Math trunk, and porting back to 2.2, so
>>> I'll add your new methods back to trunk.
>>> I'll also merge my fixes to nextAfter.
>>>
>>> FastMath and FastMathTest should be the same in both.
>>>
>>> Apart from the @since marker in FastMath - perhaps we can use @since
>>> 2.2, 3.0 for that?
>>
>> Should be @since 2.2
>>
>> Lets try to get all the fixes into 2.2.
>
> Yes, indeed. I think we are quite close now.
>
> ==
>
> What I meant was - the class is new for 2.2 and also new for 3.0.
> The class and its test class(es) are currently the same for both
> versions of Math.
>
> We obviously need to put @since 2.2 in the class for the 2.2 release.
> Is that sufficient also for the 3.0 release?

I think so.  As long as we release 2.2 before 3.0.

> Or do we need to put @since 3.0 in it for that?
>
> Strictly speaking it is new to 3.0 too.

I don't understand what you mean by this.  All classes added since 2.1
are in this sense new for 3.0 as well.

>
> So maybe we can put:
>
> @since 2.0
> @since 3.0
>
> or
>
> @since 2.0,3.0
>
> in the (one) copy of the file.
>
> This would be easier than having to fix the @since marker in one of the files.

I am not following you here.  I must be missing something.  To me this
is no different from classes added in 2.0, 2.1, 2.2.  What matters is
when the class is actually released.  There is no harm in the 2.0 and
3.0 versions diverging even in incompatible ways.  The @since tag
tells the version number of first release.  Unless you are thinking
that 3.0 might be released before 2.0?  Or we need to do something
different during the time that neither has been released?  What am I
missing?

Phil

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

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Simone Tripodi

Hi Rahul!!! :)
thanks for your feedbacks!!! this time I would like to experiment in
the sandbox an almost complete rewrite of Digester, simplifying the
actual design centralizing the configuration - and loosing
retro-compatibility. Moreover I would like doing a strong code
polishing, removing deprecated APIs at first stage.

The idea can, of course, be ported also on the current Digester
implementation, so once the sandbox will be completed we could apply
the new feature also on 2.X and at the same time think about a
possible 3.X.
WDYT?
Have a nice day, all the best,
Simo

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



On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar  wrote:
> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
>  wrote:
>> Hi all guys,
>> I would like to propose a new sandbox to experiment a fresh,
>> different, new set of Digester APIs that strongly uses a DSL for rules
>> configuration.
>> As described in the original proposal[1], the idea comes from a James
>> Carman's comment on an old Digester issue, so his
>> help/guidance/mentoring would be more than appreciated.
>> Please cast your vote, if there are no objections I would like to
>> start this work in the sandbox and try to promote as TLP with your
>> help/mentoring/involvement.
> 
>
> This would be in addition to the existing digester APIs? I think we
> want to be compatible so don't know if it makes sense to remove/change
> existing APIs.
>
> The sandbox is always open for experimentation, no objections there.
>
> -Rahul
>
>
>> I really hope this could be point of your interest that makes you
>> curious enough to participate!
>> Have a nice day, all the best,
>> Simo
>>
>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

Re: Publish commons-parent 18

2011-01-23 Thread sebb

We normally hold a formal vote on commons parent releases first.

On 24 January 2011 01:13, Gary Gregory  wrote:
> Can someone do the honors and push commons-parent 18 to the repository?
> Gary Gregory
> Senior Software Engineer
> Rocket Software
> 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA
> Tel: +1.404.760.1560
> Email: ggreg...@seagullsoftware.com
> Web: seagull.rocketsoftware.com
>
>
>

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread sebb

On 24 January 2011 00:16, Phil Steitz  wrote:
> On Sun, Jan 23, 2011 at 6:54 PM, sebb  wrote:
>> On 23 January 2011 22:18, Phil Steitz  wrote:
>>> On Sun, Jan 23, 2011 at 6:57 AM, sebb  wrote:
 On 23 January 2011 09:58, Luc Maisonobe  wrote:
> Le 23/01/2011 01:58, s...@apache.org a écrit :
>> Author: sebb
>> Date: Sun Jan 23 00:58:07 2011
>> New Revision: 1062304
>>
>> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
>> Log:
>> MATH-496 Create FastMath copySign methods
>
> I was also creating these methods.
> I have created all the missing ones and implemented hypot directly, so
> don't bother doing it too.

 OK.

 I've mainly been working in Math trunk, and porting back to 2.2, so
 I'll add your new methods back to trunk.
 I'll also merge my fixes to nextAfter.

 FastMath and FastMathTest should be the same in both.

 Apart from the @since marker in FastMath - perhaps we can use @since
 2.2, 3.0 for that?
>>>
>>> Should be @since 2.2
>>>
>>> Lets try to get all the fixes into 2.2.
>>
>> Yes, indeed. I think we are quite close now.
>>
>> ==
>>
>> What I meant was - the class is new for 2.2 and also new for 3.0.
>> The class and its test class(es) are currently the same for both
>> versions of Math.
>>
>> We obviously need to put @since 2.2 in the class for the 2.2 release.
>> Is that sufficient also for the 3.0 release?
>
> I think so.  As long as we release 2.2 before 3.0.
>
>> Or do we need to put @since 3.0 in it for that?
>>
>> Strictly speaking it is new to 3.0 too.
>
> I don't understand what you mean by this.  All classes added since 2.1
> are in this sense new for 3.0 as well.
>
>>
>> So maybe we can put:
>>
>> @since 2.0
>> @since 3.0
>>
>> or
>>
>> @since 2.0,3.0
>>
>> in the (one) copy of the file.
>>
>> This would be easier than having to fix the @since marker in one of the 
>> files.
>
> I am not following you here.  I must be missing something.  To me this
> is no different from classes added in 2.0, 2.1, 2.2.  What matters is
> when the class is actually released.  There is no harm in the 2.0 and
> 3.0 versions diverging even in incompatible ways.  The @since tag
> tells the version number of first release.  Unless you are thinking
> that 3.0 might be released before 2.0?  Or we need to do something
> different during the time that neither has been released?  What am I
> missing?

Perhaps it does not matter here.

But suppose we release 2.2 and then 3.0, with FastMath @since 2.2.
That works fine, since 3.0 is later than 2.2.

We then release 2.3 with a new class, which is also later added to 3.1.

Do we leave the @since as 2.3?
In that case, users might think it was already in 3.0, which is not the case.

Or do we change it to @since 3.1?

Perhaps 3.0 is special in this regard, as it is the first of the 3.x releases.

> Phil
>
> -
> 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: Publish commons-parent 18

2011-01-23 Thread Gary Gregory

Sebb: Thank you for the procedural pointer.

Gary

> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Sunday, January 23, 2011 21:18
> To: Commons Developers List
> Subject: Re: Publish commons-parent 18
> 
> We normally hold a formal vote on commons parent releases first.
> 
> On 24 January 2011 01:13, Gary Gregory 
> wrote:
> > Can someone do the honors and push commons-parent 18 to the repository?
> > Gary Gregory
> > Senior Software Engineer
> > Rocket Software
> > 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326 * USA
> > Tel: +1.404.760.1560
> > Email: ggreg...@seagullsoftware.com
> > Web: seagull.rocketsoftware.com
> >
> >
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org


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

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Rahul Akolkar

On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi
 wrote:
> Hi Rahul!!! :)
> thanks for your feedbacks!!! this time I would like to experiment in
> the sandbox an almost complete rewrite of Digester, simplifying the
> actual design centralizing the configuration - and loosing
> retro-compatibility. Moreover I would like doing a strong code
> polishing, removing deprecated APIs at first stage.
>


If we're losing compatibility in the core component APIs due to a
major rewrite, it may be better as a new component rather than the
next major release.

-Rahul


> The idea can, of course, be ported also on the current Digester
> implementation, so once the sandbox will be completed we could apply
> the new feature also on 2.X and at the same time think about a
> possible 3.X.
> WDYT?
> Have a nice day, all the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar  
> wrote:
>> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
>>  wrote:
>>> Hi all guys,
>>> I would like to propose a new sandbox to experiment a fresh,
>>> different, new set of Digester APIs that strongly uses a DSL for rules
>>> configuration.
>>> As described in the original proposal[1], the idea comes from a James
>>> Carman's comment on an old Digester issue, so his
>>> help/guidance/mentoring would be more than appreciated.
>>> Please cast your vote, if there are no objections I would like to
>>> start this work in the sandbox and try to promote as TLP with your
>>> help/mentoring/involvement.
>> 
>>
>> This would be in addition to the existing digester APIs? I think we
>> want to be compatible so don't know if it makes sense to remove/change
>> existing APIs.
>>
>> The sandbox is always open for experimentation, no objections there.
>>
>> -Rahul
>>
>>
>>> I really hope this could be point of your interest that makes you
>>> curious enough to participate!
>>> Have a nice day, all the best,
>>> Simo
>>>
>>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>

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

Re: svn commit: r1062572 - /commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java

2011-01-23 Thread sebb

On 23 January 2011 23:17,   wrote:
> Author: ggregory
> Date: Sun Jan 23 23:17:18 2011
> New Revision: 1062572
>
> URL: http://svn.apache.org/viewvc?rev=1062572&view=rev
> Log:
> @version 1.5
>
> Modified:
>    
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java
>
> Modified: 
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java?rev=1062572&r1=1062571&r2=1062572&view=diff
> ==
> --- 
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java
>  (original)
> +++ 
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java
>  Sun Jan 23 23:17:18 2011
> @@ -189,7 +189,7 @@ import org.apache.commons.codec.StringEn
>  *          class 
>  *
>  * @author Apache Software Foundation
> - * @version beta 2010/9/13
> + * @version 1.5
>  */

Shouldn't that be @since 1.5?

If we do use @version, it's normally set to $Revision$ or some such.
(Don't use $Date, because it is Locale-dependent)

>
>  public class ColognePhonetic implements StringEncoder {
>
>
>

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

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Simone Tripodi

Hi Rahul! :)
good point, I think that this is yet another good reason to work on
sandbox before, I'll try to stay close as much as possible to the
current Digester concept, my idea/purpose/intensions are providing a
new Digester and not replacing it.
Of course, suggestions/participation/feedbacks/guidelines are always
accepted, many thanks in advance!!!
Simo

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



On Mon, Jan 24, 2011 at 3:25 AM, Rahul Akolkar  wrote:
> On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi
>  wrote:
>> Hi Rahul!!! :)
>> thanks for your feedbacks!!! this time I would like to experiment in
>> the sandbox an almost complete rewrite of Digester, simplifying the
>> actual design centralizing the configuration - and loosing
>> retro-compatibility. Moreover I would like doing a strong code
>> polishing, removing deprecated APIs at first stage.
>>
> 
>
> If we're losing compatibility in the core component APIs due to a
> major rewrite, it may be better as a new component rather than the
> next major release.
>
> -Rahul
>
>
>> The idea can, of course, be ported also on the current Digester
>> implementation, so once the sandbox will be completed we could apply
>> the new feature also on 2.X and at the same time think about a
>> possible 3.X.
>> WDYT?
>> Have a nice day, all the best,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar  
>> wrote:
>>> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
>>>  wrote:
 Hi all guys,
 I would like to propose a new sandbox to experiment a fresh,
 different, new set of Digester APIs that strongly uses a DSL for rules
 configuration.
 As described in the original proposal[1], the idea comes from a James
 Carman's comment on an old Digester issue, so his
 help/guidance/mentoring would be more than appreciated.
 Please cast your vote, if there are no objections I would like to
 start this work in the sandbox and try to promote as TLP with your
 help/mentoring/involvement.
>>> 
>>>
>>> This would be in addition to the existing digester APIs? I think we
>>> want to be compatible so don't know if it makes sense to remove/change
>>> existing APIs.
>>>
>>> The sandbox is always open for experimentation, no objections there.
>>>
>>> -Rahul
>>>
>>>
 I really hope this could be point of your interest that makes you
 curious enough to participate!
 Have a nice day, all the best,
 Simo

 [1] http://markmail.org/message/5ry2lmfkpxkrqwh6

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

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

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

Re: svn commit: r1062304 - /commons/proper/math/branches/MATH_2_X/src/main/java/org/apache/commons/math/util/FastMath.java

2011-01-23 Thread Phil Steitz

On Sun, Jan 23, 2011 at 9:15 PM, sebb  wrote:
> On 24 January 2011 00:16, Phil Steitz  wrote:
>> On Sun, Jan 23, 2011 at 6:54 PM, sebb  wrote:
>>> On 23 January 2011 22:18, Phil Steitz  wrote:
 On Sun, Jan 23, 2011 at 6:57 AM, sebb  wrote:
> On 23 January 2011 09:58, Luc Maisonobe  wrote:
>> Le 23/01/2011 01:58, s...@apache.org a écrit :
>>> Author: sebb
>>> Date: Sun Jan 23 00:58:07 2011
>>> New Revision: 1062304
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1062304&view=rev
>>> Log:
>>> MATH-496 Create FastMath copySign methods
>>
>> I was also creating these methods.
>> I have created all the missing ones and implemented hypot directly, so
>> don't bother doing it too.
>
> OK.
>
> I've mainly been working in Math trunk, and porting back to 2.2, so
> I'll add your new methods back to trunk.
> I'll also merge my fixes to nextAfter.
>
> FastMath and FastMathTest should be the same in both.
>
> Apart from the @since marker in FastMath - perhaps we can use @since
> 2.2, 3.0 for that?

 Should be @since 2.2

 Lets try to get all the fixes into 2.2.
>>>
>>> Yes, indeed. I think we are quite close now.
>>>
>>> ==
>>>
>>> What I meant was - the class is new for 2.2 and also new for 3.0.
>>> The class and its test class(es) are currently the same for both
>>> versions of Math.
>>>
>>> We obviously need to put @since 2.2 in the class for the 2.2 release.
>>> Is that sufficient also for the 3.0 release?
>>
>> I think so.  As long as we release 2.2 before 3.0.
>>
>>> Or do we need to put @since 3.0 in it for that?
>>>
>>> Strictly speaking it is new to 3.0 too.
>>
>> I don't understand what you mean by this.  All classes added since 2.1
>> are in this sense new for 3.0 as well.
>>
>>>
>>> So maybe we can put:
>>>
>>> @since 2.0
>>> @since 3.0
>>>
>>> or
>>>
>>> @since 2.0,3.0
>>>
>>> in the (one) copy of the file.
>>>
>>> This would be easier than having to fix the @since marker in one of the 
>>> files.
>>
>> I am not following you here.  I must be missing something.  To me this
>> is no different from classes added in 2.0, 2.1, 2.2.  What matters is
>> when the class is actually released.  There is no harm in the 2.0 and
>> 3.0 versions diverging even in incompatible ways.  The @since tag
>> tells the version number of first release.  Unless you are thinking
>> that 3.0 might be released before 2.0?  Or we need to do something
>> different during the time that neither has been released?  What am I
>> missing?
>
> Perhaps it does not matter here.
>
> But suppose we release 2.2 and then 3.0, with FastMath @since 2.2.
> That works fine, since 3.0 is later than 2.2.
>
> We then release 2.3 with a new class, which is also later added to 3.1.
>
> Do we leave the @since as 2.3?
> In that case, users might think it was already in 3.0, which is not the case.
>
> Or do we change it to @since 3.1?
>
> Perhaps 3.0 is special in this regard, as it is the first of the 3.x releases.
>
I think we have agreed to keep the 2.x releases after 2.2 as pure
bugfix.  I guess in theory we could end up in the scenario you
describe above, but I don't expect it to happen.  In case it does, we
can use the @since with two versions method you suggest.

Phil

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

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

Re: [vote][sandbox] Proposal for Digester3 sandbox

2011-01-23 Thread Rahul Akolkar

On Sun, Jan 23, 2011 at 9:47 PM, Simone Tripodi
 wrote:
> Hi Rahul! :)
> good point, I think that this is yet another good reason to work on
> sandbox before, I'll try to stay close as much as possible to the
> current Digester concept, my idea/purpose/intensions are providing a
> new Digester and not replacing it.


Great, lets put ourselves in the shoes of existing digester users
(indeed, I am one).

If that doesn't sound like fun, the rewrite can always be proposed as
a new component :-)

-Rahul


> Of course, suggestions/participation/feedbacks/guidelines are always
> accepted, many thanks in advance!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Jan 24, 2011 at 3:25 AM, Rahul Akolkar  
> wrote:
>> On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi
>>  wrote:
>>> Hi Rahul!!! :)
>>> thanks for your feedbacks!!! this time I would like to experiment in
>>> the sandbox an almost complete rewrite of Digester, simplifying the
>>> actual design centralizing the configuration - and loosing
>>> retro-compatibility. Moreover I would like doing a strong code
>>> polishing, removing deprecated APIs at first stage.
>>>
>> 
>>
>> If we're losing compatibility in the core component APIs due to a
>> major rewrite, it may be better as a new component rather than the
>> next major release.
>>
>> -Rahul
>>
>>
>>> The idea can, of course, be ported also on the current Digester
>>> implementation, so once the sandbox will be completed we could apply
>>> the new feature also on 2.X and at the same time think about a
>>> possible 3.X.
>>> WDYT?
>>> Have a nice day, all the best,
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar  
>>> wrote:
 On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi
  wrote:
> Hi all guys,
> I would like to propose a new sandbox to experiment a fresh,
> different, new set of Digester APIs that strongly uses a DSL for rules
> configuration.
> As described in the original proposal[1], the idea comes from a James
> Carman's comment on an old Digester issue, so his
> help/guidance/mentoring would be more than appreciated.
> Please cast your vote, if there are no objections I would like to
> start this work in the sandbox and try to promote as TLP with your
> help/mentoring/involvement.
 

 This would be in addition to the existing digester APIs? I think we
 want to be compatible so don't know if it makes sense to remove/change
 existing APIs.

 The sandbox is always open for experimentation, no objections there.

 -Rahul


> I really hope this could be point of your interest that makes you
> curious enough to participate!
> Have a nice day, all the best,
> Simo
>
> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>


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

RE: svn commit: r1062572 - /commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/ColognePhonetic.java

2011-01-23 Thread Gary Gregory

> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Sunday, January 23, 2011 21:34
> To: dev@commons.apache.org
> Subject: Re: svn commit: r1062572 -
> /commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/Colo
> gnePhonetic.java
> 
> On 23 January 2011 23:17,   wrote:
> > Author: ggregory
> > Date: Sun Jan 23 23:17:18 2011
> > New Revision: 1062572
> >
> > URL: http://svn.apache.org/viewvc?rev=1062572&view=rev
> > Log:
> > @version 1.5
> >
> > Modified:
> >
>  commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/Colo
> gnePhonetic.java
> >
> > Modified:
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/Colog
> nePhonetic.java
> > URL:
> http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/java/org/apache
> /commons/codec/language/ColognePhonetic.java?rev=1062572&r1=1062571&r2=1062
> 572&view=diff
> >
> ===
> ===
> > ---
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/Colog
> nePhonetic.java (original)
> > +++
> commons/proper/codec/trunk/src/java/org/apache/commons/codec/language/Colog
> nePhonetic.java Sun Jan 23 23:17:18 2011
> > @@ -189,7 +189,7 @@ import org.apache.commons.codec.StringEn
> >  *          class 
> >  *
> >  * @author Apache Software Foundation
> > - * @version beta 2010/9/13
> > + * @version 1.5
> >  */
> 
> Shouldn't that be @since 1.5?

Yes, I'll fix that.

Thanks for the catch.

Gary

> 
> If we do use @version, it's normally set to $Revision$ or some such.
> (Don't use $Date, because it is Locale-dependent)
> 
> >
> >  public class ColognePhonetic implements StringEncoder {
> >
> >
> >
> 
> -
> 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

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

2011-01-23 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-math has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 149 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-math :  The Jakarta Mathematics Library


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-math/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-math-24012011.jar] identifier set to project 
name
 -DEBUG- Dependency on junit exists, no need to add for property junit.jar.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-math/gump_work/build_apache-commons_commons-math.html
Work Name: build_apache-commons_commons-math (Type: Build)
Work ended in a state of : Failed
Elapsed: 4 mins 55 secs
Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-24012011.jar 
-Dfinal.name=commons-math-24012011 jar 
[Working Directory: /srv/gump/public/workspace/apache-commons/math]
CLASSPATH: 
/usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/apache-commons/math/target/classes:/srv/gump/public/workspace/apache-commons/math/target/test-classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-24012011.jar:/srv/gump/public/workspace/junit/dist/junit-dep-24012011.jar
-
[junit] Testcase: testCopy took 0 sec
[junit] Testcase: testContainsKey took 0.005 sec
[junit] Testcase: testIterator took 0.01 sec
[junit] Testcase: testConcurrentModification took 0 sec
[junit] Testcase: testPutKeysWithCollisions took 0 sec
[junit] Testcase: testPutKeysWithCollision2 took 0 sec
[junit] Running org.apache.commons.math.util.PairTest
[junit] Testsuite: org.apache.commons.math.util.PairTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
[junit] 
[junit] Testcase: testAccessor took 0.004 sec
[junit] Testcase: testEquals took 0 sec
[junit] Running org.apache.commons.math.util.ResizableDoubleArrayTest
[junit] Testsuite: org.apache.commons.math.util.ResizableDoubleArrayTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 0.213 sec
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 0.213 sec
[junit] 
[junit] Testcase: testConstructors took 0.021 sec
[junit] Testcase: testSetElementArbitraryExpansion took 0.133 sec
[junit] Testcase: testAdd1000 took 0.001 sec
[junit] Testcase: testAddElements took 0.011 sec
[junit] Testcase: testAddElementRolling took 0.032 sec
[junit] Testcase: testSetNumberOfElements took 0 sec
[junit] Testcase: testWithInitialCapacity took 0.005 sec
[junit] Testcase: testWithInitialCapacityAndExpansionFactor took 0 sec
[junit] Testcase: testDiscard took 0 sec
[junit] Testcase: testSubstitute took 0 sec
[junit] Testcase: testMutators took 0 sec
[junit] Testcase: testEqualsAndHashCode took 0 sec
[junit] Testcase: testGetValues took 0 sec
[junit] Testcase: testMinMax took 0 sec
[junit] Running org.apache.commons.math.util.TransformerMapTest
[junit] Testsuite: org.apache.commons.math.util.TransformerMapTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.028 sec
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.028 sec
[junit] 
[junit] Testcase: testPutTransformer took 0.004 sec
[junit] Testcase: testContainsClass took 0 sec
[junit] Testcase: testContainsTransformer took 0

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

2011-01-23 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-collections4 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 56 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-collections4 :  Collections
- commons-collections4-testframework :  Apache Commons


Full details are available at:

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

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/collections/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/collections/pom.xml
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-collections4/gump_work/build_apache-commons_commons-collections4.html
Work Name: build_apache-commons_commons-collections4 (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/collections/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/collections]
M2_HOME: /opt/maven2
-
required: org.apache.commons.collections.Closure[]
found: org.apache.commons.collections.Closure[]

[INFO] 8 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[68,38]
 invalid inferred types for T; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Predicate[]
found: org.apache.commons.collections.Predicate[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[69,40]
 invalid inferred types for I; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Transformer[]
found: org.apache.commons.collections.Transformer[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/OnePredicate.java:[66,38]
 invalid inferred types for T; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Predicate[]
found: org.apache.commons.collections.Predicate[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchClosure.java:[66,38]
 invalid inferred types for T; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Predicate[]
found: org.apache.commons.collections.Predicate[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchClosure.java:[67,36]
 invalid inferred types for E; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Closure[]
found: org.apache.commons.collections.Closure[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/ChainedTransformer.java:[56,40]
 invalid inferred types for I; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Transformer[]
found: org.apache.commons.collections.Transformer[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/NonePredicate.java:[61,38]
 invalid inferred types for T; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Predicate[]
found: org.apache.commons.collections.Predicate[]

/srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/ChainedClosure.java:[53,36]
 invalid inferred types for E; actual arguments do not conforms to inferred 
formal arguments
required: org.apache.commons.collections.Closure[]
found: org.apache.commons.collections.Closure[]


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] -

53 matches

Mail list logo