Re: [math] apachecon
I'll be there, I am giving a talk about some works we've done in commons (and other ASF components) glad to meet other commons people! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Sep 18, 2012 at 9:29 PM, Thomas Neidhart wrote: > Hi, > > does anybody plan to go to ApacheCon 2012? > Would be nice to meet each other there. > > Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] About "NullArgumentException"
Hi,
2012/9/18 Phil Steitz :
> On 9/18/12 12:02 PM, Sébastien Brisard wrote:
>> Hello,
>>
>> 2012/9/17 Gilles Sadowski :
>>> On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
OK, I give up. Lets do option 2. Just warn users in the User Guide
somewhere that our APIs are in general not null-safe and unless the
javadoc explicitly allows nulls, they can expect NPE when passing nulls.
>>> Thanks, Phil; we are making progress, and I hope that you'll be convinced of
>>> that at some point.
>>>
>>> Another decision still needs to be made.
>>>
>>> I think that everybody now agrees that wherever an argument will be directly
>>> used (i.e. "dereferenced") inside the body of the method[1], it is safe to
>>> not check for null (since the JVM will throw an NPE).
>>>
>>> But, whenever an argument is passed for _later_ use (e.g. stored by a
>>> constructor or passed to another method), we also all expressed that it is
>>> better to fail early if the object is supposed to be non-null. In those
>>> cases, checks are not mandatory (since the JVM will throw NPE at some
>>> point), but we must agree on how optional checks are to be implemented.
>>> 1. The current state of affairs was to throw "NullArgumentException"; in 4.0
>>>this exception will become a subclass of NPE and we can continue to use
>>>it in the same way as now (i.e. possibly providing additional localizable
>>>error messages).
>>> 2. The alternative is to directly throw a standard NPE, but without any
>>>message, since it wouldn't be localizable with the support of CM's
>>>"context".
>>>
>>> So, which of those alternatives do people want to settle on?
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] As opposed to being passed on to another method.
>>>
>> I have another question: are we going to little by little remove all
>> null checks that we feel are not absolutely necessary? I would not
>> mind going through this cleaning phase while working on MATH-854.
>
> I think we should wait to remove the existing null checks until
> 4.0. This is a significant behavior change, especially for the ones
> that have been in place and documented since 1.x. Removing the
> checks and allowing NPEs to propagate will break apps that catch IAE.
>
> Phil
>
OK. I would like to say that I think this is going the right way: it
is better to have no null checks than incomplete null checks which
provide a false sense of security. For example, have a look to
Array2DRowRealMatrix
/**
* Create a new RealMatrix using the input array as the underlying
* data array.
* If an array is built specially in order to be embedded in a
* RealMatrix and not used directly, the {@code copyArray} may be
* set to {@code false}. This will prevent the copying and improve
* performance as no new array will be built and no data will be copied.
*
* @param d Data for new matrix.
* @param copyArray if {@code true}, the input array will be copied,
* otherwise it will be referenced.
* @throws DimensionMismatchException if {@code d} is not rectangular
* (not all rows have the same length) or empty.
* @throws NullArgumentException if {@code d} is {@code null}.
* @throws NoDataException if there are not at least one row and one column.
* @see #Array2DRowRealMatrix(double[][])
*/
public Array2DRowRealMatrix(final double[][] d, final boolean copyArray) {
if (copyArray) {
copyIn(d);
} else {
if (d == null) {
throw new NullArgumentException();
}
final int nRows = d.length;
if (nRows == 0) {
throw new NoDataException(LocalizedFormats.AT_LEAST_ONE_ROW);
}
final int nCols = d[0].length;
if (nCols == 0) {
throw new NoDataException(LocalizedFormats.AT_LEAST_ONE_COLUMN);
}
for (int r = 1; r < nRows; r++) {
if (d[r].length != nCols) {
throw new DimensionMismatchException(d[r].length, nCols);
}
}
data = d;
}
}
I think if you want to be really helpful, a null check should also be
carried out on each d[i]. I think I will leave it as is for now, but
in 4.0, we should certainly remove this null check.
Do you agree?
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
Olá Bruno,
excellent work, congrats!! I will have a look tonight (my local TZ)
I'll try to let you know ASAP!
thanks, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Sep 19, 2012 at 4:12 AM, Bruno P. Kinoshita
wrote:
> Hi all,
>
> me again bringing a new implementation idea for the Generators API
>
> in [functor], and looking forward to some thoughts on this :-)
>
> There is a separate branch for this issue [1], and here's what has been done.
>
> - Split Generator interface into Generator interface and LoopGenerator
> (abstract class). IMO, this will help in modularization (see this discussion
> [2])
> in the Generators API, as the stop() method and the wrapped generators,
> for instance, had been added because of the generators created for handling
> execution flow control (e.g.: GenerateWhile, UntilGenerate, etc).
>
> - Moved LoopGenerator and its implementations under the newly created
> org.apache.commons.functor.generator.loop package.
>
> - Moved IntegerRange and LongRange from
> org.apache.commons.functor.generator.util to
> the newly created org.apache.commons.functor.generator.range package.
>
> - Created a Range API, with a Range interface, a Ranges helper interface and
> some implementations (including existing IntegerRange and LongRange, and new
> ones like DoubleRange, FloatRange and CharacterRange).
>
> - Added steps different than 1 to Ranges (not the generator interface, as this
> is related only to ranges).
>
> - The Ranges implemented are all Generators too, what is very convenient, as
> you
> can use Ranges to both define intervals and/or execute a procedure for each
> of its
> elements.
>
> I've wrote a sample code using the existing Generators API [3] and wrote the
> same code for the new Generators API [4]. The API is compatible, but as some
> packages changed, you have to update existing code (but as [functor] hasn't
> been
> released yet, it shouldn't be a problem I believe :-). Both codes produce the
> same output too (0 1 2 3 4 5 6 7 8 9 ).
>
> And here's an example [5] of creating Ranges and using them as Generators.
> More
> examples can be found in the tests for the Generator and the Range API's.
>
> I've updated the examples page and added tests. I've also updated the parent
> pom to 26, but as this is not related to the FUNCTOR-14 issue, we can drop
> this
>
> part when merging the code.
>
> I'll merge the changes to trunk if everybody thinks this new implementation is
> better than the current one.
>
> A side note: PHP recently got generators too [6], and an interesting thing
> that I noticed in
> their Wiki was the discussion about callback functions. After reading the
> discussion, for me it looks like [functor] generators API is more similar to
> callback handler. Differently than the Python and PHP implementations with the
> yield statement.
>
> Thank you in advance!
>
> [1]
> https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14
> [2] http://markmail.org/message/nymsk7l64aj4csxi
> [3] https://gist.github.com/3747204
> [4] https://gist.github.com/3747207
> [5] https://gist.github.com/3747224
> [5] https://wiki.php.net/rfc/generators
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>>
>> From: Matt Benson
>>To: Bruno P. Kinoshita
>>Cc: Commons Developers List
>>Sent: Wednesday, 6 June 2012 9:56 AM
>>Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
>>
>>On Tue, Jun 5, 2012 at 11:48 PM, Bruno P. Kinoshita
>> wrote:
>>> Hi Matt,
>>>
>>>
Would there be a type of Range that could not be turned into a
Generator given a compatible Step parameter? If not, we could define:
interface Range {
...
Generator toGenerator(S step);
}
This way, Range itself does not contain a step, but still maintains
control over how a step is used to create a generator.
>>>
>>> I can't think of any type that could not be turned into a generator given
>>> the step parameter. But if a range has no step, I think we would have to
>>> remove the isEmpty(), contains(), containsAll() methods from range
>>> implementations, as using steps higher than 1, we need to use the step value
>>> to check if a range is empty or contains a certain element (e.g.: integer
>>> range (1, 2], step 3, check if contains(2) or isEmpty()).
>>>
>>
>>My thought was that by decoupling a Range from a step, you use only
>>the bound types/values to determine inclusion of a given value. If a
>>Generator is created from (1, 2] with step 3, then that Generator will
>>only return 1, but that doesn't reflect on the Range, IMO.
>>
>>Matt
>>
>>>
Either way, I like the notion that a Range is its own type that just
*happens* to either provide access to, or an implementation of,
Generator.
>>>
>>> +1, let it provide access or be an impl
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
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 88 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: 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info
--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
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from =
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.244 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from =
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element in namespace
"http://my.foo.example/"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element in namespace
"http://www.w3.org/2005/07/scxml"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element in namespace
"http://my.foo.example/"; at
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null):
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from =
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec
Results :
Failed tests:
testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)
Tests run: 229, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO]
[GUMP@vmgump]: Project commons-jelly-tags-sql (in module commons-jelly) failed
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-sql has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 16 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-sql : Commons Jelly
Full details are available at:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/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-sql-19092012.jar] identifier set
to project name
-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/sql/build.properties
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.xml
-DEBUG- Maven project properties in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.properties
-INFO- Project Reports in:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports
-WARNING- No directory
[/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/gump_work/build_commons-jelly_commons-jelly-tags-sql.html
Work Name: build_commons-jelly_commons-jelly-tags-sql (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: maven --offline jar
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/sql]
-
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
You are working offline so the build will continue, but
commons-jelly-1.1-SNAPSHOT.jar may be out of date!
build:start:
java:prepare-filesystem:
[mkdir] Created dir:
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
java:compile:
[echo] Compiling to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] Compiling 18 source files to
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 1.5
[javac]
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/src/java/org/apache/commons/jelly/tags/sql/DataSourceWrapper.java:38:
error: DataSourceWrapper is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class DataSourceWrapper implements DataSource {
[javac]^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning
BUILD FAILED
File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly
Element... ant:javac
Line.. 63
Column 48
Compile failed; see the compiler error output for details.
Total time: 6 seconds
Finished at: Wed Sep 19 07:34:16 UTC 2012
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/atom.xml
== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1319092012, vmgump.apache.org:vmgump:1319092012
Gump E-mail Identifier (unique within run) #60.
--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] apachecon
Hi Thomas, it would have been nice to meet up face to face. Unfortunately, I won't be able to make it. I would have loved to, though. I hope you have fun, there. Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] apachecon
Hi, I am there too! (referring to ApacheCon EU) Cheers On Tue, Sep 18, 2012 at 9:29 PM, Thomas Neidhart wrote: > Hi, > > does anybody plan to go to ApacheCon 2012? > Would be nice to meet each other there. > > Thomas > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] Adding some methods in Precision class (oacm.util)
Hello,
This message is about some methods in Precision class, and follows a discussion
about MATH-863 (https://issues.apache.org/jira/browse/MATH-863).
Recently, we slightly modified our Precision class, by adding a specific
epsilon value to compute a relative deviation and also some methods.
---
/** Epsilon used for doubles relative comparison */
public static final double DOUBLE_COMPARISON_EPSILON = 1.0e-14;
---
This value is quite useful to compare two values. It's approximatively 100
times larger than the previous EPSILON value (1e-16, the difference between 1.
and the next closest value).
We also added static methods, to compute a relative difference : if x1 and x2
are not equal (according to the equals(x1,x2, "1 ulp") function), then we
compute a relative deviation ("abs(x1-x2)/max(abs(x1),abs(x2))" and see if it's
lower than an epsilon value.
---
public static boolean equalsWithRelativeTolerance(final double x, final
double y) -> uses the DOUBLE_COMPARISON_EPSILON
public static boolean equalsWithRelativeTolerance(final double x, final
double y, final double eps)
---
These kind of methods are used in some of our tools (space dynamic libraries)
to assert equality between values, when we don't know the order of magnitude.
Do you think it's useful for Commons Math users ?
Shall I open a ticket on JIRA and contribute the corresponding code source ?
Best regards,
Yannick TANGUY
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Adding some methods in Precision class (oacm.util)
Le 19/09/2012 15:02, Tanguy Yannick a écrit :
> Hello,
Hi Yannick,
>
> This message is about some methods in Precision class, and follows a
> discussion about MATH-863
> (https://issues.apache.org/jira/browse/MATH-863).
>
> Recently, we slightly modified our Precision class, by adding a
> specific epsilon value to compute a relative deviation and also some
> methods. --- /** Epsilon used for doubles relative comparison */
> public static final double DOUBLE_COMPARISON_EPSILON = 1.0e-14; ---
>
> This value is quite useful to compare two values. It's
> approximatively 100 times larger than the previous EPSILON value
> (1e-16, the difference between 1. and the next closest value).
>
> We also added static methods, to compute a relative difference : if
> x1 and x2 are not equal (according to the equals(x1,x2, "1 ulp")
> function), then we compute a relative deviation
> ("abs(x1-x2)/max(abs(x1),abs(x2))" and see if it's lower than an
> epsilon value.
The comparison should probably rather be:
abs(x1-x2) <= eps * max(abs(x1),abs(x2)
The reason for that is that with your implementation when both x1 and x2
are 0 (either +0 or -0), then the result would be false, despite the
numbers are equal. The division 0/0 leads to a NaN and all comparisons
involving NaN return false.
>
> --- public static boolean equalsWithRelativeTolerance(final double x,
> final double y) -> uses the DOUBLE_COMPARISON_EPSILON public static
> boolean equalsWithRelativeTolerance(final double x, final double y,
> final double eps) ---
>
> These kind of methods are used in some of our tools (space dynamic
> libraries) to assert equality between values, when we don't know the
> order of magnitude.
>
> Do you think it's useful for Commons Math users ? Shall I open a
> ticket on JIRA and contribute the corresponding code source ?
Yes, along with test cases, including special cases (+/-0, +/-infinity,
NaNs, +/-Double.MAX_VALUE, +/-Double.MIN_VALUE ...)
best regards,
Luc
>
> Best regards,
>
> Yannick TANGUY
>
> -
>
>
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] About "NullArgumentException"
On 9/19/12 12:12 AM, Sébastien Brisard wrote:
> Hi,
>
> 2012/9/18 Phil Steitz :
>> On 9/18/12 12:02 PM, Sébastien Brisard wrote:
>>> Hello,
>>>
>>> 2012/9/17 Gilles Sadowski :
On Fri, Sep 14, 2012 at 11:29:41AM -0700, Phil Steitz wrote:
> OK, I give up. Lets do option 2. Just warn users in the User Guide
> somewhere that our APIs are in general not null-safe and unless the
> javadoc explicitly allows nulls, they can expect NPE when passing nulls.
Thanks, Phil; we are making progress, and I hope that you'll be convinced
of
that at some point.
Another decision still needs to be made.
I think that everybody now agrees that wherever an argument will be
directly
used (i.e. "dereferenced") inside the body of the method[1], it is safe to
not check for null (since the JVM will throw an NPE).
But, whenever an argument is passed for _later_ use (e.g. stored by a
constructor or passed to another method), we also all expressed that it is
better to fail early if the object is supposed to be non-null. In those
cases, checks are not mandatory (since the JVM will throw NPE at some
point), but we must agree on how optional checks are to be implemented.
1. The current state of affairs was to throw "NullArgumentException"; in
4.0
this exception will become a subclass of NPE and we can continue to use
it in the same way as now (i.e. possibly providing additional
localizable
error messages).
2. The alternative is to directly throw a standard NPE, but without any
message, since it wouldn't be localizable with the support of CM's
"context".
So, which of those alternatives do people want to settle on?
Regards,
Gilles
[1] As opposed to being passed on to another method.
>>> I have another question: are we going to little by little remove all
>>> null checks that we feel are not absolutely necessary? I would not
>>> mind going through this cleaning phase while working on MATH-854.
>> I think we should wait to remove the existing null checks until
>> 4.0. This is a significant behavior change, especially for the ones
>> that have been in place and documented since 1.x. Removing the
>> checks and allowing NPEs to propagate will break apps that catch IAE.
>>
>> Phil
>>
> OK. I would like to say that I think this is going the right way: it
> is better to have no null checks than incomplete null checks which
> provide a false sense of security. For example, have a look to
> Array2DRowRealMatrix
>
>
> /**
> * Create a new RealMatrix using the input array as the underlying
> * data array.
> * If an array is built specially in order to be embedded in a
> * RealMatrix and not used directly, the {@code copyArray} may be
> * set to {@code false}. This will prevent the copying and improve
> * performance as no new array will be built and no data will be copied.
> *
> * @param d Data for new matrix.
> * @param copyArray if {@code true}, the input array will be copied,
> * otherwise it will be referenced.
> * @throws DimensionMismatchException if {@code d} is not rectangular
> * (not all rows have the same length) or empty.
> * @throws NullArgumentException if {@code d} is {@code null}.
> * @throws NoDataException if there are not at least one row and one
> column.
> * @see #Array2DRowRealMatrix(double[][])
> */
> public Array2DRowRealMatrix(final double[][] d, final boolean copyArray) {
> if (copyArray) {
> copyIn(d);
> } else {
> if (d == null) {
> throw new NullArgumentException();
> }
> final int nRows = d.length;
> if (nRows == 0) {
> throw new NoDataException(LocalizedFormats.AT_LEAST_ONE_ROW);
> }
> final int nCols = d[0].length;
> if (nCols == 0) {
> throw new
> NoDataException(LocalizedFormats.AT_LEAST_ONE_COLUMN);
> }
> for (int r = 1; r < nRows; r++) {
> if (d[r].length != nCols) {
> throw new DimensionMismatchException(d[r].length, nCols);
> }
> }
> data = d;
> }
> }
>
> I think if you want to be really helpful, a null check should also be
> carried out on each d[i]. I think I will leave it as is for now, but
> in 4.0, we should certainly remove this null check.
> Do you agree?
Yes, the API should be nullsafe or not. The half-way solution above
is no good and it makes the javadoc misleading. I would be OK
actually adding the check at the row level now (or catching the NPE
and throwing DME in its place) so what the javadoc says is true (d
null means NAE and d non-rectangular or empty means DME). On the
other hand, this is unlikely to ever happen in practice, so I would
Re: [math] Adding some methods in Precision class (oacm.util)
Hi.
>
> >
> > This message is about some methods in Precision class, and follows a
> > discussion about MATH-863
> > (https://issues.apache.org/jira/browse/MATH-863).
> >
> > Recently, we slightly modified our Precision class, by adding a
> > specific epsilon value to compute a relative deviation and also some
> > methods. --- /** Epsilon used for doubles relative comparison */
> > public static final double DOUBLE_COMPARISON_EPSILON = 1.0e-14; ---
> >
> > This value is quite useful to compare two values. It's
> > approximatively 100 times larger than the previous EPSILON value
> > (1e-16, the difference between 1. and the next closest value).
> >
> > We also added static methods, to compute a relative difference : if
> > x1 and x2 are not equal (according to the equals(x1,x2, "1 ulp")
> > function), then we compute a relative deviation
> > ("abs(x1-x2)/max(abs(x1),abs(x2))" and see if it's lower than an
> > epsilon value.
>
> The comparison should probably rather be:
> abs(x1-x2) <= eps * max(abs(x1),abs(x2)
>
> The reason for that is that with your implementation when both x1 and x2
> are 0 (either +0 or -0), then the result would be false, despite the
> numbers are equal. The division 0/0 leads to a NaN and all comparisons
> involving NaN return false.
Unfotunately, that version makes the comparison fail when one of the
argument is infinite; in that case we get for the proposed code
inf / inf < eps --> false thanks to NaN
while the above leads to
inf <= inf --> true
Also, the proposed implementation first checks for strict equality: when the
arguments are equal, the division is not performed.
[I wanted to replace the proposed implementation with a call to the existing
"absolute" comparison method, but because of that problem, it doesn't seem
possible without adding conditionals.]
> >
> > --- public static boolean equalsWithRelativeTolerance(final double x,
> > final double y) -> uses the DOUBLE_COMPARISON_EPSILON public static
> > boolean equalsWithRelativeTolerance(final double x, final double y,
> > final double eps) ---
> >
> > These kind of methods are used in some of our tools (space dynamic
> > libraries) to assert equality between values, when we don't know the
> > order of magnitude.
> >
> > Do you think it's useful for Commons Math users ? Shall I open a
> > ticket on JIRA and contribute the corresponding code source ?
>
> Yes, along with test cases, including special cases (+/-0, +/-infinity,
> NaNs, +/-Double.MAX_VALUE, +/-Double.MIN_VALUE ...)
I think that we should focus on the second version (with an explicit
tolerance).
The tolerance is very much case-dependent, so that the default value is not
widely useful: Why 1e-14 rather than 1e-15 or 1e-13 or even 1e-7 ?
Best regards,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [math] Adding some methods in Precision class (oacm.util)
Thanks for your answers.
As I said, our solution first uses equals() method, to distinguish wether
number are "strictly" equals (thanks to existing methods) before dividing the
difference by the max value of (x,y).
So I tested the use case proposed by Luc with our implementation and with Luc's
one (see here after).
About the default value (1e-14), I know the tolerance is case-dependant, but
some times, we don't precisely know the order of magnitude (ex : jacobians
matrices) and it's quite practical to have a default value.
In our tools, we use this value in the test classes, but also for specific
algorithm convergence threshold.
If you agree, I'll open a ticket and attach our patch.
Best regards,
Yannick
--
Here are the results obtained with various methods : CommonsMath equals (one
ulp), our method with a relative 1e-14 threshold, and another method
(abs(x1-x2) <= eps * max(abs(x1),abs(x2) )
---
X: 0.0 vs Y: -0.0
Equals (CM) true
EqualsWithRelativeTol true
EqualsOtherSolution false
---
X: 0.1 vs Y: 0.10001
Equals (CM) false
EqualsWithRelativeTol false
EqualsOtherSolution false
---
X: 1.7976931348623157E308 vs Y: 1.7976931348623157E308
Equals (CM) true
EqualsWithRelativeTol true
EqualsOtherSolution true
---
X: 4.9E-324 vs Y: 4.9E-324
Equals (CM) true
EqualsWithRelativeTol true
EqualsOtherSolution false
---
X: Infinity vs Y: Infinity
Equals (CM) true
EqualsWithRelativeTol true
EqualsOtherSolution false
---
X: NaN vs Y: NaN
Equals (CM) false
EqualsWithRelativeTol false
EqualsOtherSolution false
---
X: 0.0 vs Y: 0.0
Equals (CM) true
EqualsWithRelativeTol true
EqualsOtherSolution false
---
X: -Infinity vs Y: -Infinity
Equals (CM) true
EqualsWithRelativeTol true
EqualsOtherSolution false
---
X: 0.101 vs Y: 0.1
Equals (CM) false
EqualsWithRelativeTol true
EqualsOtherSolution true
---
X: 0.1011 vs Y: 0.1
Equals (CM) false
EqualsWithRelativeTol false
EqualsOtherSolution false
-Message d'origine-
De : Gilles Sadowski [mailto:gil...@harfang.homelinux.org]
Envoyé : mercredi 19 septembre 2012 16:38
À : dev@commons.apache.org
Objet : Re: [math] Adding some methods in Precision class (oacm.util)
Hi.
>
> >
> > This message is about some methods in Precision class, and follows a
> > discussion about MATH-863
> > (https://issues.apache.org/jira/browse/MATH-863).
> >
> > Recently, we slightly modified our Precision class, by adding a
> > specific epsilon value to compute a relative deviation and also some
> > methods. --- /** Epsilon used for doubles relative comparison */
> > public static final double DOUBLE_COMPARISON_EPSILON = 1.0e-14; ---
> >
> > This value is quite useful to compare two values. It's
> > approximatively 100 times larger than the previous EPSILON value
> > (1e-16, the difference between 1. and the next closest value).
> >
> > We also added static methods, to compute a relative difference : if
> > x1 and x2 are not equal (according to the equals(x1,x2, "1 ulp")
> > function), then we compute a relative deviation
> > ("abs(x1-x2)/max(abs(x1),abs(x2))" and see if it's lower than an
> > epsilon value.
>
> The comparison should probably rather be:
> abs(x1-x2) <= eps * max(abs(x1),abs(x2)
>
> The reason for that is that with your implementation when both x1 and x2
> are 0 (either +0 or -0), then the result would be false, despite the
> numbers are equal. The division 0/0 leads to a NaN and all comparisons
> involving NaN return false.
Unfotunately, that version makes the comparison fail when one of the
argument is infinite; in that case we get for the proposed code
inf / inf < eps --> false thanks to NaN
while the above leads to
inf <= inf --> true
Also, the proposed implementation first checks for strict equality: when the
arguments are equal, the division is not performed.
[I wanted to replace the proposed implementation with a call to the existing
"absolute" comparison method, but because of that problem, it doesn't seem
possible without adding conditionals.]
> >
> > --- public static boolean equalsWithRelativeTolerance(final double x,
> > final double y) -> uses the DOUBLE_COMPARISON_EPSILON public static
> > boolean equalsWithRelativeTolerance(final double x, final double y,
> > final double eps) ---
> >
> > These kind of methods are used in some of our tools (space dynamic
> > libraries) to assert equality between values, when we don't know the
> > order of magnitude.
> >
> > Do you think it's useful for Commons Math users ? Shall I open a
> > ticket on JIRA and contribute the corresponding code source ?
>
> Yes, along with test cases, including special cases (+/-0,
Re: [math] Adding some methods in Precision class (oacm.util)
Hi Yannick, > > About the default value (1e-14), I know the tolerance is case-dependant, but > some times, we don't precisely know the order of magnitude (ex : jacobians > matrices) and it's quite practical to have a default value. > In our tools, we use this value in the test classes, but also for specific > algorithm convergence threshold. > I'm uncomfortable with CM having a default tolerance implemented somewhere. As you said, tolerances are case-dependant, and therefore DEFAULT_TOL (or whatever you want to call it) should stand in your particular application, not in a utility Commons-Math class. This is pretty much the approach adopted in our testing suites. You will frequently find a constant field with a default tolerance which applies for the specific unit test only. I would be very reluctant to try and be more general, while we all know that such a constant would not mean anything. Don't mistake me. I'm not saying that chosing a (somewhat arbitrary) default tolerance is bad practice. As you said, sometimes there is no other option. I would like to know what others think, Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Adding some methods in Precision class (oacm.util)
Hello.
> Thanks for your answers.
> As I said, our solution first uses equals() method, to distinguish wether
> number are "strictly" equals (thanks to existing methods) before dividing the
> difference by the max value of (x,y).
>
> So I tested the use case proposed by Luc with our implementation and with
> Luc's one (see here after).
>
> About the default value (1e-14), I know the tolerance is case-dependant, but
> some times, we don't precisely know the order of magnitude (ex : jacobians
> matrices) and it's quite practical to have a default value.
> In our tools, we use this value in the test classes, but also for specific
> algorithm convergence threshold.
Yes but the value is a simply a choice, and one that is not driven by
anything related to the implementation. Hence I think that it is more
dangerous than useful to include that "magic" number in CM.
It's safer that users are forced to figure out what would be a good value
for their case.
>
> If you agree, I'll open a ticket and attach our patch.
Filing a report on JIRA is useful to keep a history but a new patch is not
necessary, as I've already included the code in my working copy (with some
minor changes).
[I'll wait for the report so that the commit can be linked to the issue
number.]
Thanks,
Gilles
>
> Best regards,
>
> Yannick
>
> --
> Here are the results obtained with various methods : CommonsMath equals (one
> ulp), our method with a relative 1e-14 threshold, and another method
> (abs(x1-x2) <= eps * max(abs(x1),abs(x2) )
>
>
> ---
> X: 0.0 vs Y: -0.0
> Equals (CM) true
> EqualsWithRelativeTol true
> EqualsOtherSolutionfalse
> ---
> X: 0.1 vs Y: 0.10001
> Equals (CM) false
> EqualsWithRelativeTol false
> EqualsOtherSolutionfalse
> ---
> X: 1.7976931348623157E308 vs Y: 1.7976931348623157E308
> Equals (CM) true
> EqualsWithRelativeTol true
> EqualsOtherSolutiontrue
> ---
> X: 4.9E-324 vs Y: 4.9E-324
> Equals (CM) true
> EqualsWithRelativeTol true
> EqualsOtherSolutionfalse
> ---
> X: Infinity vs Y: Infinity
> Equals (CM) true
> EqualsWithRelativeTol true
> EqualsOtherSolutionfalse
> ---
> X: NaN vs Y: NaN
> Equals (CM) false
> EqualsWithRelativeTol false
> EqualsOtherSolutionfalse
> ---
> X: 0.0 vs Y: 0.0
> Equals (CM) true
> EqualsWithRelativeTol true
> EqualsOtherSolutionfalse
> ---
> X: -Infinity vs Y: -Infinity
> Equals (CM) true
> EqualsWithRelativeTol true
> EqualsOtherSolutionfalse
> ---
> X: 0.101 vs Y: 0.1
> Equals (CM) false
> EqualsWithRelativeTol true
> EqualsOtherSolutiontrue
> ---
> X: 0.1011 vs Y: 0.1
> Equals (CM) false
> EqualsWithRelativeTol false
> EqualsOtherSolutionfalse
>
>
>
> -Message d'origine-
> De : Gilles Sadowski [mailto:gil...@harfang.homelinux.org]
> Envoyé : mercredi 19 septembre 2012 16:38
> À : dev@commons.apache.org
> Objet : Re: [math] Adding some methods in Precision class (oacm.util)
>
> Hi.
>
> >
> > >
> > > This message is about some methods in Precision class, and follows a
> > > discussion about MATH-863
> > > (https://issues.apache.org/jira/browse/MATH-863).
> > >
> > > Recently, we slightly modified our Precision class, by adding a
> > > specific epsilon value to compute a relative deviation and also some
> > > methods. --- /** Epsilon used for doubles relative comparison */
> > > public static final double DOUBLE_COMPARISON_EPSILON = 1.0e-14; ---
> > >
> > > This value is quite useful to compare two values. It's
> > > approximatively 100 times larger than the previous EPSILON value
> > > (1e-16, the difference between 1. and the next closest value).
> > >
> > > We also added static methods, to compute a relative difference : if
> > > x1 and x2 are not equal (according to the equals(x1,x2, "1 ulp")
> > > function), then we compute a relative deviation
> > > ("abs(x1-x2)/max(abs(x1),abs(x2))" and see if it's lower than an
> > > epsilon value.
> >
> > The comparison should probably rather be:
> > abs(x1-x2) <= eps * max(abs(x1),abs(x2)
> >
> > The reason for that is that with your implementation when both x1 and x2
> > are 0 (either +0 or -0), then the result would be false, despite the
> > numbers are equal. The division 0/0 leads to a NaN and all comparisons
> > involving NaN return false.
>
> Unfotunately, that version makes the comparison fail when one of the
> argument is infinite; in that case we get for the proposed code
> inf / inf < eps --> false thanks to NaN
> while the above leads to
> inf <= inf --> true
>
> Also, the proposed implementation first checks for strict equality: when the
> arguments are equal, the division is
Re: [configuration] Thoughts about multi-threading
Hi Phil, Am 18.09.2012 20:09, schrieb Phil Steitz: On 9/17/12 12:39 PM, Oliver Heger wrote: Hi Jörg, many thanks for your input! Am 17.09.2012 10:01, schrieb Jörg Schaible: Hi Oliver, Oliver Heger wrote: Hi, one limitation of the 1.x versions of [configuration] is the incomplete support for concurrent access to Configuration objects. In version 2.0 we should try to improve this. I have some ideas about this topic - not fully thought out - and would like to start a discussion. Here they are (in no specific order): - Thread-safety is not always required. Therefore, I would like to take an approach similar to the JDK Collections framework: having basic, unsynchronized configurations which can be turned into thread-safe ones. Fair approach. - Many Configuration implementations are based on a hash map. Access to their content could be made thread-safe by replacing the map by a ConcurrentHashMap. You could use a protected method to instantiate the underlaying HashMap. Then you're free in overloaded Configurations.synchronizedConfiguration methods to use a derived class or a wrapper. It has also implications on subset(). Or pass the map in at construction time. Using a protected method to create the map would either mean that the constructor has to invoke this method (problematic for subclasses which are not yet fully initialized at this time) or the field cannot be made final. Alternatively, there could be an abstract method getMap() returning the reference to the map. - For hierarchical configurations situation is more complex. Here we will probably need something like a ReadWriteLock to protect their content. (There could be different lock implementations including a dummy one used by unsynchronized configurations). - Reloading is a major problem; at least in the way it is implemented now, it is very hard to get synchronization correct and efficient. Therefore, I would like to use a different strategy here. One option could be to not handle reloading in Configuration objects, but on an additional layer which creates such objects. - Other properties of configuration objects (e.g. the throwExceptionOnMissing flag or the file name) must be taken into account, too. In a typical use case those should not be accessed frequently, so it is probably not an issue to always synchronize them or make them volatile. Looking forward to your input Another option would be immutability (well, apart probably from reloading). Personally I have often the use case that I do not want to offer my clients/consumers to write into the configuration. One approach can also be the JDK approach creating Collections.unmodifiableConfiguration. However, what also bugs me in the meantime is the current hard relation between the configuration object and its format. Why should I care at all in what format the configuration had been saved when I access its values? For some time I am thinking now of something in the line of: - interface Configuration: Core interfaces, only getters - interface ReloadableConfiguration extends Configuration, Reloadable - class BaseConfiguration: In memory, implements all the stuff for interpolation and the setters - interface ConfigurationSource: Core interface to load (and probably save a configuration) - class PropertiesConfigurationSource: Concrete implementation that loads a properties file and creates a BaseConfiguration This approach offers immutability for the Configuration itself and also allows Serializability. Format is separated completely from the configuration functionality. I know, this looks more like Configuration 3.0 ... ;-) I really like this approach. I was also thinking about separating loading and saving from core Configuration classes. However, I fear such an approach will make it difficult to preserve the format of a configuration. E.g. XMLConfiguration currently stores the XML document it was loaded from. So when saved to disk, result looks much like the original document. Read-only configurations is also an interesting topic. This obviously makes the concurrency problem easier :) Apart from this case, it would be good to agree on exactly what it means for [configuration] to be threadsafe. Is it basically the semantics of ConcurrentHashmap? Or are there sequencing / event serialization constraints? For example, suppose the sequence below happens Thread A start add property Thread B start clear Thread A notify property change Thread B notify clear Thread B clear map Thread A update map Is it OK for this sequence to happen? Is it OK for A's add to trump B's clear even though B's activation started later and B's notification was later? This is a very good point, I did not think about this. It would be very confusing for an event listener to receive a clear event and then find out that the configuration is not empty. So I guess it is too naive to simply replace the plain map by a concurrent map to gain thread-safety. We will then probably have to
[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed
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-dbcp has an issue affecting its community integration. This issue affects 18 projects, and has been outstanding for 85 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-dbcp : Object Pooling - db-ddlutils : Easy-to-use component for working with Database Definition (... - jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation - jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation - jakarta-tomcat-dbcp : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-tomcat-jk : Connectors to various web servers - javax.el : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - javax.servlet : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - javax.servlet.jsp : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - solr : Java Based Search Engine - solr-test : Java Based Search Engine - tomcat-tc6 : Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for ... - tomcat-tc7.0.x : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-dbcp : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-tc7.0.x-test : Tomcat 7.x, a web server implementing Java Servlet 3.0, ... - tomcat-trunk : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-dbcp : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/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-dbcp.jar] identifier set to project name -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: /usr/lib/jvm/java-7-oracle/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 dist [Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x] CLASSPATH: /usr/lib/jvm/java-7-oracle/lib/tools.jar:/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/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-20092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-20092012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar - [javac]^ [javac] where T is a type-variable: [javac] T extends Object declared in method getObject(String,Class) [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65: error: DelegatingConnection is not abstract and does not override abstract method getNetworkTimeout() in Connection [javac] public class DelegatingConnection extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38: error: DelegatingDatabaseMetaData is not abstract and does not override abstract method generatedKeyAlwaysReturned() in DatabaseMetaData [javac] public class DelegatingDatabaseMetaData extends AbandonedTrace [javac]^ [javac] /srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61: error: DelegatingResultSet is not abstract and does not override abstract method getObject(String,Class) in ResultSet [javac] public class DelegatingResultSet extends Aban
[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed
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-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 85 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 : Database Connection Pool
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/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-dbcp2-*[0-9T].jar] identifier set to project
name
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/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
dist
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH:
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/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/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-20092012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-20092012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir:
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
error: BasicDataSource is not abstract and does not override abstract method
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
error: DelegatingConnection is not abstract and does not override abstract
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
error: DelegatingStatement is not abstract and does not override abstract
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements
Statement {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
error: DelegatingPreparedStatement is not abstract and does not override
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
error: DelegatingCallableStatement is not abstract and does not override
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends
DelegatingPreparedStatement
[javac]^
[javac] where T is a type-variable:
[javac] T extends Object declared in method
getObject(String,Class)
[javac]
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
error: DelegatingDatabaseMetaData is not abstract and does not override
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class
[VFS] HDFS provider
I did not see a provider for HDFS on the list of supported file systems. I created a read-only HDFS provider while working on an Accumulo ticket. I was wondering if one of the devs had time to review to see if I made any glaring mistakes. I am in the process of becoming an Accumulo committer, so I'm assuming that this file system provider could be included in the VFS project if it makes sense. Thanks, Dave Marion
[functor] Rename CollectionTransformer and update javadocs
Hi all, There is one item pending from the last poll to release [functor], regarding a TODO in CollectionTransformer. Excerpt below: * TODO revisit this class... it could stand a more-descriptive name. Also, it's a little * hard to say whether, for an instance constructed without a specific target collection, * #evaluate() should return a new ArrayList for each call, or continue adding to * a single ArrayList instance (the current behavior). * Perhaps this is more a documentation issue than anything. And the comments on the TODO items. > it could stand a more-descriptive name. I'm +0 to rename. The only name that I could think of was GeneratorToCollectionTransformer, but found some on the Internet after looking for 'convert generator to iterator' and 'convert generator to list': Listify, Eagerlize and Lazy List Builder. I liked Lazy List Builder, as this class creates a list from a given generator, but only when you call the evaluate(Generator) method (lazily initializing the list). Anyone has other thoughts on this? > Also, it's a little hard to say whether, for an instance constructed without > a specific target collection, > #evaluate() should return a new ArrayList for each call, or continue adding to > a single ArrayList instance (the current behavior). The constructor doesn't return a new ArrayList for each call anymore. Now it validates whether the list is null or not null, throwing an exception if the former is true. After an instance of CollectionTransformer is created, for every call of evaluate(Generator) it adds the generator elements to the given list. It means that if you call the evaluate method 10 times, it will return the same list with more elements. I'm +1 for changing this behaviour too and returning a new list for each call of evaluate(Generator). This way we don't have to worry about multiple threads accessing the same list object. If nobody is against this I will file an issue to work on this. Finally, the javadocs are out of date, so I would like to update it with our consensus on these items :-) Many thanks in advance! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 90 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 : XML to Java Object Configuration
- commons-digester3-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/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-digester3-*[0-9T].jar] identifier set to
project name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/apache-commons/digester/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1348113183275
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn
--non-interactive info
[INFO] Working directory:
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
error: Impossible to generate class
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule:
Attempt to recreate a file for type
org.apache.commons.digester3.annota
[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed
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-chain2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 107 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-chain2 : GoF "Chain of Responsibility" pattern Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/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-chain2-*[0-9T].jar] identifier set to project name -DEBUG- Sole pom output [pom.xml] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html Work Name: build_apache-commons_commons-chain2 (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 2 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/chain] M2_HOME: /opt/maven2 - [INFO] Building war: /srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war [INFO] [INFO] Building Apache Commons Chain :: Distribution Packages [INFO]task-segment: [package] [INFO] [INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT 2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2), gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute [INFO] Finished at: Thu Sep 20 05:04:59 UTC 2012 [INFO] Final Memory: 115M/241M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
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 90 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: 18 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.007 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 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.027 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.423 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.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.1 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: 16 seconds [INFO] Finished at: Thu Sep 20 05:39:00 UTC 2012 [INFO] Final Memory: 25M/60M [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.org/
[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed
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-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
and has been outstanding for 85 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils : Commons DbUtils
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/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-dbutils-*[0-9T].jar] identifier set to
project name
-INFO- Optional dependency mockito failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
-WARNING- No directory
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.pom
1K downloaded (mockito-core-1.9.0.pom)
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded (hamcrest-all-1.1.pom)
Downloading:
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading:
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded (hamcrest-all-1.1.jar)
1381K downloaded (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
main:
[copy] Copying 2 files to
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1348119921789
[INFO] Executing: /bin/sh -c cd
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 28 source files to
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
error: DriverProxy is not abstract and does not override abstract method
getParentLogger() in Driver
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[math] APT format for the users guide
Hello,
as I previously said, I'd like to extend the user's guide for the
special functions package. I am not a big fan of the xdoc format
currently in use, at is not easily readable. So I thought I would give
APT a go. Please find below the code corresponding to the current
"Special Functions" page.
The learning curve is not steep at all (about 5 minutes!). I think
it's much better (even for tables, which might require a large screen
;)).
The generated pages are identical (I've even reproduced the typo in
5.4...), but for the fact that you cannot have anchors with a name
different from the text they refer to. So anchor {Beta} would be named
"Beta", and not "beta" as is currently the case. I don't think this is
much of an issue, as there is no reference to these anchors (I'll
check the other pages of the user's guide, and update them if
necessary).
So, what do you think? Should I pursue, or would you like me to stay
with the xdoc format?
I would like to emphasize I'm not advocating for a complete switch
from one format to another. But since I'm going to concentrate on this
section of the users guide, I thought I might as well choose the
format which I am most comfortable with. If you do not like the idea
of having two different formats for the same site, please let me know.
Best regards,
Sébastien
Here is the text (best viewed after copying/pasting in a real text editor).
~~
~~ Licensed to the Apache Software Foundation (ASF) under one or more
~~ contributor license agreements. See the NOTICE file distributed with
~~ this work for additional information regarding copyright ownership.
~~ The ASF licenses this file to You under the Apache License, Version 2.0
~~ (the "License"); you may not use this file except in compliance with
~~ the License. You may obtain a copy of the License at
~~
~~ http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing, software
~~ distributed under the License is distributed on an "AS IS" BASIS,
~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~~ See the License for the specific language governing permissions and
~~ limitations under the License.
~~
---
The Commons Math User Guide - Special Functions
---
5 Special Functions
* 5.1 Overview
The special functions portion of Commons-Math contains several useful
functions not provided by <<>>. These functions mostly serve
as building blocks for other portions of Commons-Math but, as others may find
them useful as stand-alone methods, these special functions were included as
part of the Commons-Math public API.
* 5.2 Erf functions
{{{../apidocs/org/apache/commons/math3/special/Erf.html}Erf}} contains
several useful functions involving the Error Function, Erf.
*+-+---+
|| Function || Method || Reference
|
*+-+---+
| Error Function |erf | See
{{{http://mathworld.wolfram.com/Erf.html}Erf}} from MathWorld |
*+-+---+
* 5.3 Gamma functions
{{{../apidocs/org/apache/commons/math3/special/Gamma.html}Gamma}} contains
several useful functions involving the Gamma Function.
*---+---+---+
|| Function || Method || Reference
|
*---+---+---+
| Log Gamma | logGamma | See
{{{http://mathworld.wolfram.com/GammaFunction.html}Gamma Function}}
from MathWorld|
*---+---+---+
| Regularized Gamma | regularizedGammaP | See
{{{http://mathworld.wolfram.com/RegularizedGammaFunction.html}Regularized
Gamma Function}} from MathWorld |
*---+---+---+
* 5.4 Beta funtions
{{{../apidocs/org/apache/commons/math3/special/Beta.html}Beta}} contains
several useful functions involving the Beta Function.
*--+-+-+
|| Function|| Method || Reference
|
*--+-+-+
| L
Re: [configuration] Thoughts about multi-threading
Oliver Heger wrote: > Hi Jörg, > > many thanks for your input! > > Am 17.09.2012 10:01, schrieb Jörg Schaible: [snip] >> However, what also bugs me in the meantime is the current hard relation >> between the configuration object and its format. Why should I care at all >> in what format the configuration had been saved when I access its values? >> >> For some time I am thinking now of something in the line of: >> >> - interface Configuration: Core interfaces, only getters >> - interface ReloadableConfiguration extends Configuration, Reloadable >> - class BaseConfiguration: In memory, implements all the stuff for >> interpolation and the setters >> >> - interface ConfigurationSource: Core interface to load (and probably >> save a configuration) >> - class PropertiesConfigurationSource: Concrete implementation that loads >> a properties file and creates a BaseConfiguration >> >> This approach offers immutability for the Configuration itself and also >> allows Serializability. Format is separated completely from the >> configuration functionality. >> >> I know, this looks more like Configuration 3.0 ... ;-) >> > I really like this approach. I was also thinking about separating > loading and saving from core Configuration classes. However, I fear such > an approach will make it difficult to preserve the format of a > configuration. E.g. XMLConfiguration currently stores the XML document > it was loaded from. So when saved to disk, result looks much like the > original document. A ConfigurationSource may still collect the necessary data and keep it internally or attach it somehow to the generated Configuration instance for later use. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
