Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
Hi Dennis, 2012/1/12 Dennis Hendriks : > > The online report at the top links to a page with details. > right under my nose... Sorry for bothering you with futilities. > > The tests use a method only available in Java 6... > Right. But why neither eclipse (configured to build with Java 1.5), nor mvn complains? Sébastien > Dennis > > > Sébastien Brisard wrote: >> >> 2012/1/12 Continuum@vmbuild : >>> >>> Online report : >>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=17130&projectId=97 >>> >>> Build statistics: >>> State: Failed >>> Previous State: Ok >>> Started at: Thu 12 Jan 2012 07:21:05 + >>> Finished at: Thu 12 Jan 2012 07:22:12 + >>> Total time: 1m 7s >>> Build Trigger: Schedule >>> Build Number: 634 >>> Exit code: 1 >>> Building machine hostname: vmbuild >>> Operating system : Linux(unknown) >>> Java Home version : >>> java version "1.6.0_30" >>> Java(TM) SE Runtime Environment (build 1.6.0_30-b12) >>> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) >>> >>> Builder version : >>> Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) >>> Java version: 1.6.0_30 >>> Java home: /usr/lib/jvm/jdk1.6.0_30/jre >>> Default locale: en_US, platform encoding: UTF-8 >>> OS name: "linux" version: "2.6.32-31-server" arch: "amd64" >>> Family: "unix" >>> >>> >>> >>> SCM Changes: >>> >>> >>> Changed: celestin @ Thu 12 Jan 2012 07:01:43 + >>> Comment: Implementation of continuous triangular distributions >>> (MATH-731). Patch contributed by Dennis Hendriks. >>> Files changed: >>> >>> /commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java >>> ( 1230419 ) >>> >>> /commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java >>> ( 1230419 ) >>> >>> >>> >>> Dependencies Changes: >>> >>> >>> No dependencies changed >>> >>> >>> >>> >>> Build Definition: >>> >>> >>> POM filename: pom.xml >>> Goals: clean deploy >>> Arguments: --batch-mode -Pjava-1.5 >>> Build Fresh: false >>> Always Build: false >>> Default Build Definition: true >>> Schedule: COMMONS_SCHEDULE >>> Profile Name: Maven 2.2.1 >>> Description: Default Maven 2 Build Definition (Java 1.5) >>> >>> >>> >>> Test Summary: >>> >>> >>> Tests: 0 >>> Failures: 0 >>> Errors: 0 >>> Total time: 0.0 >>> >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> Hi, >> where can I find a detailed report on this build failure? It seems >> Commons-Math builds successfully locally. >> Thanks! >> Sébastien >> >> >> - >> 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] Compatibility of licenses?
2012/1/11 Sébastien Brisard :
> Le 11 janvier 2012 07:42, Sébastien Brisard
> a écrit :
>> Hi,
>> Dennis recently contributed a patch for triangular distributions (see
>> MATH-731). One of the methods implemented is based on a third party
>> Python code, the license of which is reproduced below. My question is:
>> can I commit this patch? Should we try and get in touch with the
>> original author (1998!), to have him sign an ICLA?
>> Thanks for your advice.
>> Sébastien
>>
>> + * Implementation of the {@link #sample} method partly based on
>> triangular
>> + * distribution implementation of the rv Python module (Release 1.1
>> 27-Nov-98),
>> + * by Ivan Frohne, which is distributed under the following license:
>> + *
>> + * Copyright 1998 by Ivan Frohne; Wasilla, Alaska, U.S.A.
>> + * All Rights Reserved
>> + *
>> + * Permission to use, copy, modify and distribute this software and its
>> + * documentation for any purpose, free of charge, is granted subject to the
>> + * following conditions:
>> + * The above copyright notice and this permission notice shall be
>> included in
>> + * all copies or substantial portions of the software.
>> + *
>> + * THE SOFTWARE AND DOCUMENTATION IS PROVIDED WITHOUT WARRANTY OF ANY
>> KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY,
>> FITNESS
>> + * FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>> + * AUTHOR OR COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM OR DAMAGES IN A
>> + * CONTRACT ACTION, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
>> CONNECTION
>> + * WITH THE SOFTWARE OR ITS DOCUMENTATION.
>> + *
>> + *
>
> This is the answer I got on legal-disc...@apache.org
> {quote}
> t might also be an option for the commons PMC to personally reach out
> to him, notify him and send him a personal 'thank you'. Maybe he is
> even interested to help out in other areas as committer in the future
> ;)
> {quote}
>
> Any PMC willing to contact this guy (Ivan Frohne) personally?
> Otherwise, I can take care of that.
> Sébastien
"Hi, about this Python code you wrote 14 years ago" :)
Highly unlikely he's jumping at the bit to code in Commons Math.
Still, sending a thanks is polite and I'd recommend you doing it as it
always sounds best coming from the person closest to the commit.
Hen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support
Tell me why 1.6 is a problem again? This is DB-helper code, so much less worried about use cases like Android. Hen On Fri, Jan 6, 2012 at 3:05 AM, sebb wrote: > I did some experimenting with BeanProcessor to see what would be > involved in providing Java 1.5 support. > > As part of this, I tried commenting out the new code that requires Java 1.6. > > All tests still worked. > > I then commented out most of the rest of the else if clauses in the > processColumn method, and the unit tests still worked. > > I think it might be fairly easy to recode the SQLXML section so it > still works in Java 1.5, but without a proper unit test, this is > difficult to prove. > > In any case, more unit tests are definitely needed. > > - > 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: r1230419 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/distribution/TriangularDistribution.java test/java/org/apache/commons/math/distribution/TriangularDistri
Hi Sébastien,
- Mail original -
> Author: celestin
> Date: Thu Jan 12 07:01:43 2012
> New Revision: 1230419
>
> URL: http://svn.apache.org/viewvc?rev=1230419&view=rev
> Log:
> Implementation of continuous triangular distributions (MATH-731).
> Patch contributed by Dennis Hendriks.
>
> Added:
>
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java
> (with props)
>
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java
> (with props)
You should probably also change the NOTICE file to include the licence text
from the original code.
Luc
>
> Added:
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java?rev=1230419&view=auto
> ==
> ---
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java
> (added)
> +++
> commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java
> Thu Jan 12 07:01:43 2012
> @@ -0,0 +1,260 @@
> +/*
> + * 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.
> + */
> +
> +package org.apache.commons.math.distribution;
> +
> +import org.apache.commons.math.exception.NumberIsTooLargeException;
> +import org.apache.commons.math.exception.NumberIsTooSmallException;
> +import org.apache.commons.math.exception.OutOfRangeException;
> +import org.apache.commons.math.exception.util.LocalizedFormats;
> +import org.apache.commons.math.util.FastMath;
> +
> +/**
> + * Implementation of the triangular real distribution.
> + *
> + * @see href="http://en.wikipedia.org/wiki/Triangular_distribution";>
> + * Triangular distribution (Wikipedia)
> + *
> + * @version $Id$
> + * @since 3.0
> + */
> +public class TriangularDistribution extends AbstractRealDistribution
> {
> +/** Serializable version identifier. */
> +private static final long serialVersionUID = 20120112L;
> +
> +/** Lower limit of this distribution (inclusive). */
> +private final double a;
> +
> +/** Upper limit of this distribution (inclusive). */
> +private final double b;
> +
> +/** Mode of this distribution. */
> +private final double c;
> +
> +/** Inverse cumulative probability accuracy. */
> +private final double solverAbsoluteAccuracy;
> +
> +/**
> + * Create a triangular real distribution using the given lower
> limit,
> + * upper limit, and mode.
> + *
> + * @param a Lower limit of this distribution (inclusive).
> + * @param b Upper limit of this distribution (inclusive).
> + * @param c Mode of this distribution.
> + * @throws NumberIsTooLargeException if {@code a >= b} or if
> {@code c > b}
> + * @throws NumberIsTooSmallException if {@code c < a}
> + */
> +public TriangularDistribution(double a, double c, double b)
> +throws NumberIsTooLargeException, NumberIsTooSmallException
> {
> +if (a >= b) {
> +throw new NumberIsTooLargeException(
> +
>LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
> +a, b, false);
> +}
> +if (c < a) {
> +throw new NumberIsTooSmallException(
> +LocalizedFormats.NUMBER_TOO_SMALL, c, a, true);
> +}
> +if (c > b) {
> +throw new NumberIsTooLargeException(
> +LocalizedFormats.NUMBER_TOO_LARGE, c, b, true);
> +}
> +
> +this.a = a;
> +this.c = c;
> +this.b = b;
> +solverAbsoluteAccuracy = FastMath.ulp(c);
> +}
> +
> +/**
> + * Returns the mode {@code c} of this distribution.
> + *
> + * @return the mode {@code c} of this distribution
> + */
> +public double getMode() {
> +return c;
> +}
> +
> +/** {@inheritDoc} */
> +@Override
> +protected double getSolverAbsoluteAccuracy() {
> +r
Re: [math] Compatibility of licenses?
Hi Henri > > "Hi, about this Python code you wrote 14 years ago" :) > :)) > > Highly unlikely he's jumping at the bit to code in Commons Math. > Still, sending a thanks is polite and I'd recommend you doing it as it > always sounds best coming from the person closest to the commit. > That's how I felt about it, but I certainly do not want to act "above my rank". Thanks for this advice, I'll remember about it next time I come across this issue. Sébastien > Hen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
On Tue, Jan 10, 2012 at 10:19 AM, sebb wrote: > On 10 January 2012 16:45, Siegfried Goeschl wrote: >> Hi folks, >> >> the main reason for the failed vote of commons-email-1.3 is that the release >> is only source but not binary compatible >> >> +) if you compile your application with the new version everything is fine >> +) if you replace simply the JAR the invocation fails >> >> Is it mandatory that a minor release is binary compatible with the previous >> one or do I have to create a new major version? There is a lot of ugly stuff >> (mainly protected member variables) which should be done but is currently >> not in the scope of this release. > > If the jar is not a drop-in replacement for the previous version, then > yes, IMO that requires a major release. [1] > The only possible exception might be if the incompatibilities are in > internal parts of the API, i.e. classes/methods etc. that are not used > externally. Thinking back on previous discussions, the primary exception has been the API itself is the bug and needs changing. A contrived (and over-simple) example would be: public void toUppercase(String s); It'd be better to fix the return type than live with bad API. Rare, but worth mentioning I thought. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Supported Buildsystems of each component
Couldn't we generate this? It feels like a very simple svn script to see if a component has a build.xml, pom.xml or project.xml. Hen On Sun, Jan 8, 2012 at 4:50 AM, Christian Grobmeier wrote: > Hello, > > we have a nice wikipage mentioning what buildsystem is supported for > which component: > http://wiki.apache.org/commons/BuildSystems > > Can everybody update the lines for the components he is caring about? > For components which do not support maven3 just add a "no" in the > column - this way we know which lines have been updated. > > Cheers, > Christian > > - > 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] Compatibility of licenses?
2012/1/12 Sébastien Brisard : > Hi Henri >> >> "Hi, about this Python code you wrote 14 years ago" :) >> > :)) > >> >> Highly unlikely he's jumping at the bit to code in Commons Math. >> Still, sending a thanks is polite and I'd recommend you doing it as it >> always sounds best coming from the person closest to the commit. >> > That's how I felt about it, but I certainly do not want to act "above > my rank". Thanks for this advice, I'll remember about it next time I > come across this issue. With the exception of the PMC Chair, where pulling rank is a last-ditch option and should be avoided, and the PMC for the binding vote, where ignoring a -1 from non-PMC would be a very bad sign, every committer has the same 'rank'. Some of us have lots of outdated anecdotes that may educate, inspire or more likely simply bore, but that's it. :) Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230419 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/distribution/TriangularDistribution.java test/java/org/apache/commons/math/distribution/TriangularDistri
Hi Luc > > You should probably also change the NOTICE file to include the licence text > from the original code. > > Luc > In fact, this piece of code turned out to be very standard (and corresponded exactly to the default implementation of the base class, see my comments on MATH-731). So no need to refer to the guy who initially inspired Dennis. So this time, I won't use the advice I've received from legal-discuss, but I shall try to remember it!!! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230435 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java
Hello. On Thu, Jan 12, 2012 at 08:08:29AM -, celes...@apache.org wrote: > Author: celestin > Date: Thu Jan 12 08:08:29 2012 > New Revision: 1230435 > > URL: http://svn.apache.org/viewvc?rev=1230435&view=rev > Log: > Removed invocations of some Java 1.6 methods (MATH-731). > > Modified: > > commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java > > Modified: > commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java > URL: > http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java?rev=1230435&r1=1230434&r2=1230435&view=diff > == > --- > commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java > (original) > +++ > commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java > Thu Jan 12 08:08:29 2012 > @@ -100,7 +100,10 @@ public class TriangularDistributionTest > // probability of zero and one, meaning the inverse returns the > // limits and not the points outside the limits. > double[] points = makeCumulativeTestValues(); > -return Arrays.copyOfRange(points, 1, points.length - 1); > +double[] points2 = new double[points.length-2]; > +System.arraycopy(points, 1, points2, 0, points2.length); > +return points2; > +//return Arrays.copyOfRange(points, 1, points.length - 1); > } You might want to create a "copyOfRange" method in class "o.a.c.m.util.MathArrays". [This will remind that some code could be upgraded when the target version allows it.] Regards, Gilles > /** > @@ -113,7 +116,10 @@ public class TriangularDistributionTest > // probability of zero and one, meaning the inverse returns the > // limits and not the points outside the limits. > double[] points = makeCumulativeTestPoints(); > -return Arrays.copyOfRange(points, 1, points.length - 1); > +double[] points2 = new double[points.length-2]; > +System.arraycopy(points, 1, points2, 0, points2.length); > +return points2; > +//return Arrays.copyOfRange(points, 1, points.length - 1); > } > > /** Creates the default probability density test expected values. */ > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
2012/1/12 Sébastien Brisard : > Hi Dennis, > > 2012/1/12 Dennis Hendriks : >> >> The online report at the top links to a page with details. >> > right under my nose... Sorry for bothering you with futilities. > >> >> The tests use a method only available in Java 6... >> > Right. But why neither eclipse (configured to build with Java 1.5), Did you also configure the JVM library? > nor mvn complains? Maven uses the current version of Java unless you use one of the java-1.x profiles set up for the purpose. The compiler source and target settings only affect the syntax and generate byte-code. They do not affect the library jars. > Sébastien > >> Dennis >> >> >> Sébastien Brisard wrote: >>> >>> 2012/1/12 Continuum@vmbuild : Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=17130&projectId=97 Build statistics: State: Failed Previous State: Ok Started at: Thu 12 Jan 2012 07:21:05 + Finished at: Thu 12 Jan 2012 07:22:12 + Total time: 1m 7s Build Trigger: Schedule Build Number: 634 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_30" Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: celestin @ Thu 12 Jan 2012 07:01:43 + Comment: Implementation of continuous triangular distributions (MATH-731). Patch contributed by Dennis Hendriks. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java ( 1230419 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java ( 1230419 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> Hi, >>> where can I find a detailed report on this build failure? It seems >>> Commons-Math builds successfully locally. >>> Thanks! >>> Sébastien >>> >>> >>> - >>> 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: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
2012/1/12 sebb : > 2012/1/12 Sébastien Brisard : >> Hi Dennis, >> >> 2012/1/12 Dennis Hendriks : >>> >>> The online report at the top links to a page with details. >>> >> right under my nose... Sorry for bothering you with futilities. >> >>> >>> The tests use a method only available in Java 6... >>> >> Right. But why neither eclipse (configured to build with Java 1.5), > > Did you also configure the JVM library? > No, I probably didn't. >> nor mvn complains? > > Maven uses the current version of Java unless you use one of the > java-1.x profiles set up for the purpose. > > The compiler source and target settings only affect the syntax and > generate byte-code. > They do not affect the library jars. > I understand: that's why @Override on an interface method are rejected, which gave me a false sense of security. Thanks for that, I'll look into how to configure the libraries as well! Sébastien >> Sébastien >> >>> Dennis - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
On 12 January 2012 08:27, Henri Yandell wrote: > On Tue, Jan 10, 2012 at 10:19 AM, sebb wrote: >> On 10 January 2012 16:45, Siegfried Goeschl wrote: >>> Hi folks, >>> >>> the main reason for the failed vote of commons-email-1.3 is that the release >>> is only source but not binary compatible >>> >>> +) if you compile your application with the new version everything is fine >>> +) if you replace simply the JAR the invocation fails >>> >>> Is it mandatory that a minor release is binary compatible with the previous >>> one or do I have to create a new major version? There is a lot of ugly stuff >>> (mainly protected member variables) which should be done but is currently >>> not in the scope of this release. >> >> If the jar is not a drop-in replacement for the previous version, then >> yes, IMO that requires a major release. [1] >> The only possible exception might be if the incompatibilities are in >> internal parts of the API, i.e. classes/methods etc. that are not used >> externally. > > Thinking back on previous discussions, the primary exception has been > the API itself is the bug and needs changing. > > A contrived (and over-simple) example would be: > > public void toUppercase(String s); > > It'd be better to fix the return type than live with bad API. > > Rare, but worth mentioning I thought. But that can still cause jar hell. If there are multiple jars in the same classloader that use the broken API, they will all have to be updated at the same time. May be tricky or impossible even if they are not from different providers. That's why binary compatibility is so important. > Hen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support
On 12 January 2012 08:20, Henri Yandell wrote: > Tell me why 1.6 is a problem again? Because there are likely to be many companies still using Java 1.5 out there. I was hoping to fix the code so they are not prevented from using the new version. > This is DB-helper code, so much less worried about use cases like Android. > > Hen > > On Fri, Jan 6, 2012 at 3:05 AM, sebb wrote: >> I did some experimenting with BeanProcessor to see what would be >> involved in providing Java 1.5 support. >> >> As part of this, I tried commenting out the new code that requires Java 1.6. >> >> All tests still worked. >> >> I then commented out most of the rest of the else if clauses in the >> processColumn method, and the unit tests still worked. >> >> I think it might be fairly easy to recode the SQLXML section so it >> still works in Java 1.5, but without a proper unit test, this is >> difficult to prove. >> >> In any case, more unit tests are definitely needed. >> >> - >> 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: [ALL] Supported Buildsystems of each component
On 12 January 2012 08:28, Henri Yandell wrote: > Couldn't we generate this? > > It feels like a very simple svn script to see if a component has a > build.xml, pom.xml or project.xml. But that won't detect if the scripts actually still work. > Hen > > On Sun, Jan 8, 2012 at 4:50 AM, Christian Grobmeier > wrote: >> Hello, >> >> we have a nice wikipage mentioning what buildsystem is supported for >> which component: >> http://wiki.apache.org/commons/BuildSystems >> >> Can everybody update the lines for the components he is caring about? >> For components which do not support maven3 just add a "no" in the >> column - this way we know which lines have been updated. >> >> Cheers, >> Christian >> >> - >> 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] Transposable linear operators
On 01/11/2012 08:21 PM, Sébastien Brisard wrote: > Hi, Hi Sébastien, > My problem is: how to do that? > 1. Extend RealLinearOperator? That would allow for compile time > checks. The problem is I've already defined > InvertibleRealLinearOperator. So how about operators which are both > invertible and transposable? > 2. Create an interface, say Transposable? But then, no compile time > check can be performed in > LSQR.RealVector solve(RealLinearOperator a, RealVector b) > (defined in AbstractIterativeLinearSolver). The only thing I can do is > test whether the specified operator implements the interface > Transposable. > 3. Add the method operateTranspose to RealLinearOperator, and allow > for UnsupportedOperationException. I could then add a method > boolean isTransposable() to RealLinearOperator. Again, no compile-time > check is possible. > > Do you have any thoughts? looking at the rationale behind RealLinearOperator I understand this class is used to calculate either: y = A x y = A^T x The specialized class InvertibleRealLinearOperator further allows for the calculation of: y = A^-1 x @Alt1: you ask about operators which are both invertible and transposable, but the two properties do not collide imho, at least as long as you do not want to calculate something like y = A^T^-1 x And in that case, wouldn't it be better to create a RealLinearOperator object with A^T as parameter? @Alt2: if the solve method relies on an operator to provide operateTranspose than it should be checked on compile time imho. Assuming that any matrix A should be transposable, I would opt for alternative 3 and provide the operateTranspose method. Do you have a case where an operator would not be transposable? Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Hi all, the generic implementation of weights is finally completed, at least for currently implemented algorithms requiring weights. Check out the latest version of [graph] for details, and the related issue for description of changes: https://issues.apache.org/jira/browse/SANDBOX-356 Maybe one last effort can be made to come up with more understandable names (e.g. for a user that does not know what a Semigroup or Monoid is). Suggestions are welcome. Thank you, Claudio On 08/01/2012 18:43, Simone Tripodi wrote: Hola Claudio, I just saw the issue - flawless report! - just give me the time to process it and I'll let you know! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Jan 8, 2012 at 6:38 PM, Claudio Squarcella wrote: Hi, On 26/12/2011 22:09, Simone Tripodi wrote: Hi Claudio! just make your proposal and attach it to a jira Issue :) it took a while (you know, Xmas and stuff) but here it is, with description: https://issues.apache.org/jira/browse/SANDBOX-356 I hope it looks good -- quite a big patch, so of course all comments are welcome. Ciao, Claudio Hope to hear from you soon, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - 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 -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
Hi Thomas, and thanks for digging into that! > > looking at the rationale behind RealLinearOperator I understand this > class is used to calculate either: > > y = A x > y = A^T x > Not exactly. For the time being, RealLinearOperator only provides the method RealVector operate(RealVector), which performs y = A.x. I agree with you that any linear operator is "transposable" (don't even know whether this word makes sense in english). However, RealLinearOperator have been implemented for operators which are *not* known in closed-form. In other words, I do not know how to access efficiently the (i, j) coefficient, but I *do* know how to compute efficiently A.x. There might be some cases where computing A'.x would still be difficult. I do not have an example here, but that's the reason why initially RealVector operateTranspose(RealVector) was not put in the RealLinearOperator abstract class. > > The specialized class InvertibleRealLinearOperator further allows for the > calculation of: > > y = A^-1 x > right. > > @Alt1: you ask about operators which are both invertible and > transposable, but the two properties do not collide imho, at least as > long as you do not want to calculate something like y = A^T^-1 x > That's true. So are you suggesting I should write three specialized classes InvertibleRealLinearOperator, TransposableRealLinearOperator, InvertibleAndTransposableRealLinearOperator? > > And in that case, wouldn't it be better to create a RealLinearOperator > object with A^T as parameter? > Not sure I really follow, but I already thought of passing *two* RealLinearOperators to the LSQR solver, which requires A and A^T. However, LSQR would be out of the IterativeLinearSolver hierarchy in that case, since the typical signature in this hierarchy is RealVector solve(RealLinearOperator, RealVector), and LSQR would require RealVector solve(RealLinearOperator, RealLinearOperator, RealVector) > > @Alt2: if the solve method relies on an operator to provide > operateTranspose than it should be checked on compile time imho. > Agreed. I do not like the "tagging interface option". > > Assuming that any matrix A should be transposable, I would opt for > alternative 3 and provide the operateTranspose method. Do you have a > case where an operator would not be transposable? > > Thomas > I've actually started playing around with this option. Added RealVector operateTranspose(RealVector) to the RealLinearOperator abstract class. This method would be defined as "optional" in the Javadoc, with the option to throw an UnsupportedOperationException. I also thought about boolean isTransposable() to check at execution time that operateTranspose() has indeed been implemented. Not sure this method is absolutely necessary, though. Would be glad to read your thoughts! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
One such example is a text retrieval engine. A x is easy since that is what the engine does. A' y is very expensive. 2012/1/12 Sébastien Brisard > In other words, I do not know how to access > efficiently the (i, j) coefficient, but I *do* know how to compute > efficiently A.x. There might be some cases where computing A'.x would > still be difficult. I do not have an example here, but that's the > reason why initially > RealVector operateTranspose(RealVector) > was not put in the RealLinearOperator abstract class. >
Re: [math] Transposable linear operators
2012/1/12 Ted Dunning : > One such example is a text retrieval engine. A x is easy since that is > what the engine does. A' y is very expensive. > > 2012/1/12 Sébastien Brisard > >> In other words, I do not know how to access >> efficiently the (i, j) coefficient, but I *do* know how to compute >> efficiently A.x. There might be some cases where computing A'.x would >> still be difficult. I do not have an example here, but that's the >> reason why initially >> RealVector operateTranspose(RealVector) >> was not put in the RealLinearOperator abstract class. >> Thanks for this example! So you *do* agree that implementing operateTranspose() should be optional, don't you? Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230600 - /commons/sandbox/graph/trunk/
welcome in the grapher brotherhood! :) http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 12, 2012 at 4:42 PM, wrote: > Author: ggregory > Date: Thu Jan 12 15:42:11 2012 > New Revision: 1230600 > > URL: http://svn.apache.org/viewvc?rev=1230600&view=rev > Log: > Add Eclipse files to svn:ignore. > > Modified: > commons/sandbox/graph/trunk/ (props changed) > > Propchange: commons/sandbox/graph/trunk/ > -- > --- svn:ignore (original) > +++ svn:ignore Thu Jan 12 15:42:11 2012 > @@ -5,5 +5,7 @@ velocity.log* > .classpath > .project > maven.log > - > InvertedEdgeAdapter.patch > +maven-eclipse.xml > +.externalToolBuilders > +.settings > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230600 - /commons/sandbox/graph/trunk/
:) Gary On Jan 12, 2012, at 11:50, Simone Tripodi wrote: > welcome in the grapher brotherhood! :) > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Thu, Jan 12, 2012 at 4:42 PM, wrote: >> Author: ggregory >> Date: Thu Jan 12 15:42:11 2012 >> New Revision: 1230600 >> >> URL: http://svn.apache.org/viewvc?rev=1230600&view=rev >> Log: >> Add Eclipse files to svn:ignore. >> >> Modified: >>commons/sandbox/graph/trunk/ (props changed) >> >> Propchange: commons/sandbox/graph/trunk/ >> -- >> --- svn:ignore (original) >> +++ svn:ignore Thu Jan 12 15:42:11 2012 >> @@ -5,5 +5,7 @@ velocity.log* >> .classpath >> .project >> maven.log >> - >> InvertedEdgeAdapter.patch >> +maven-eclipse.xml >> +.externalToolBuilders >> +.settings >> >> > > - > 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] Transposable linear operators
On 01/12/2012 12:28 PM, Sébastien Brisard wrote: > Hi Thomas, [snip] > I agree with you that any linear operator is "transposable" (don't > even know whether this word makes sense in english). However, > RealLinearOperator have been implemented for operators which are *not* > known in closed-form. In other words, I do not know how to access > efficiently the (i, j) coefficient, but I *do* know how to compute > efficiently A.x. There might be some cases where computing A'.x would > still be difficult. I do not have an example here, but that's the > reason why initially > RealVector operateTranspose(RealVector) > was not put in the RealLinearOperator abstract class. ok, now I understand the purpose of the operator much better. >> @Alt1: you ask about operators which are both invertible and >> transposable, but the two properties do not collide imho, at least as >> long as you do not want to calculate something like y = A^T^-1 x >> > That's true. So are you suggesting I should write three specialized classes > InvertibleRealLinearOperator, > TransposableRealLinearOperator, > InvertibleAndTransposableRealLinearOperator? not really, I think such a structuring would create more confusion and problems in the long run than make up for the subtle differences that it may model right now. >> And in that case, wouldn't it be better to create a RealLinearOperator >> object with A^T as parameter? >> > Not sure I really follow, but I already thought of passing *two* > RealLinearOperators to the LSQR solver, which requires A and A^T. that's pretty much what I was thinking about ;-) > I've actually started playing around with this option. Added > RealVector operateTranspose(RealVector) > to the RealLinearOperator abstract class. This method would be defined > as "optional" in the Javadoc, with the option to throw an > UnsupportedOperationException. I also thought about > boolean isTransposable() > to check at execution time that operateTranspose() has indeed been > implemented. Not sure this method is absolutely necessary, though. Together with the comment from Ted, I think this is the best way to go. The isTransposable method may not be needed after all, I would be happy with a checked exception in case someone uses operateTranspose and it is not supported by the operator. Thomas - 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 18 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: 19 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 - /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[28,26] package com.sun.mirror.util does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[37,15] cannot find symbol symbol: class AnnotationProcessor implements AnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[40,18] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[42,33] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[28,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[29,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[30,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[31,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[32,33] package com.sun.mirror.declaration does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[41,15] cannot find symbol symbol: class AnnotationProcessorFactory implements AnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[47,52] cannot find symbol symbol : class AnnotationTypeDeclaration location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[48,48] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/comm
[GUMP@vmgump]: Project commons-exec-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-exec-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 23 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.027 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.032 ms Process completed in 2005 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2004 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8018 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.867 sec <<< FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Fri Jan 13 02:17:19 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1213012012, vmgump.apache.org:vmgump:1213012012 Gump E-mail Identifier (unique within run) #19. -- 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] Transposable linear operators
Yeah... but I am a fan of the UnsupportedOperationException so I think it should be OK to have something like that in the interface and just throw up if it is called. 2012/1/12 Sébastien Brisard > 2012/1/12 Ted Dunning : > > One such example is a text retrieval engine. A x is easy since that is > > what the engine does. A' y is very expensive. > > Thanks for this example! So you *do* agree that implementing > operateTranspose() should be optional, don't you? >
Re: [math] Transposable linear operators
Hi, > >> That's true. So are you suggesting I should write three specialized classes >> InvertibleRealLinearOperator, >> TransposableRealLinearOperator, >> InvertibleAndTransposableRealLinearOperator? > > not really, I think such a structuring would create more confusion and > problems in the long run than make up for the subtle differences that it > may model right now. > I agree. In fact, I'm now toying with the idea of removing InvertibleRealLinearOperator. I initially introduced this abstract class to handle preconditioners. In fact, if m is the preconditioner, instead of passing m to the solver (and calling m.solve(y)), I could just as well pass mInv = m^(-1) (and call mInv.operate(y)). > > Together with the comment from Ted, I think this is the best way to go. > The isTransposable method may not be needed after all, I would be happy > with a checked exception in case someone uses operateTranspose and it is > not supported by the operator. > Like Ted, I like UnsupportedOperationException, and do not really like catching unchecked exceptions. I hope you do not dislike the isTransposable() option too much? Last question (***to native english speakers***): I'm not sure isTransposable() really means what I would like it to mean. What do you think of boolean isTranspositionSupported()? Likewise, is this name OK RealVector operateTranspose(RealVector) considering that application of the real linear operator a is called RealVector operate(RealVector). Thanks for your help, Sébastien > > Thomas > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
The shorter name is fine. Operate is a bit funky. A more traditional verb would be be apply() 2012/1/12 Sébastien Brisard > Last question (***to native english speakers***): I'm not sure > isTransposable() really means what I would like it to mean. What do > you think of > boolean isTranspositionSupported()? > > Likewise, is this name OK > RealVector operateTranspose(RealVector) > considering that application of the real linear operator a is called > RealVector operate(RealVector). >
Re: [math] Transposable linear operators
> > The shorter name is fine. > isTransposable() it is, then! > > Operate is a bit funky. A more traditional verb would be be apply() > Agreed. But this verb has been around for quite a time in the matrix context, so I just kept it for RealLinearOperator. Thanks for your interest in this issue, Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
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 337 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.002 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.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 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.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.188 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 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.01 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: Fri Jan 13 05:28:42 UTC 2012 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.or
Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support
Oracle declared 1.5 EOL a good while back; ie) no security fixes; why should we encourage users to be on outdated versions? Especially as I think there are pretty big security issues unfixed in 1.5 (the magic floating number crash for example). If you're still on 1.5, you have worse problems than pieces of Commons throwing a ClassNotFound. I'm tempted to go as far as to say it's irresponsible of us to support 1.5 :) Hen On Thu, Jan 12, 2012 at 2:55 AM, sebb wrote: > On 12 January 2012 08:20, Henri Yandell wrote: >> Tell me why 1.6 is a problem again? > > Because there are likely to be many companies still using Java 1.5 out there. > > I was hoping to fix the code so they are not prevented from using the > new version. > >> This is DB-helper code, so much less worried about use cases like Android. >> >> Hen >> >> On Fri, Jan 6, 2012 at 3:05 AM, sebb wrote: >>> I did some experimenting with BeanProcessor to see what would be >>> involved in providing Java 1.5 support. >>> >>> As part of this, I tried commenting out the new code that requires Java 1.6. >>> >>> All tests still worked. >>> >>> I then commented out most of the rest of the else if clauses in the >>> processColumn method, and the unit tests still worked. >>> >>> I think it might be fairly easy to recode the SQLXML section so it >>> still works in Java 1.5, but without a proper unit test, this is >>> difficult to prove. >>> >>> In any case, more unit tests are definitely needed. >>> >>> - >>> 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: [ALL] Supported Buildsystems of each component
On Thu, Jan 12, 2012 at 2:56 AM, sebb wrote: > On 12 January 2012 08:28, Henri Yandell wrote: >> Couldn't we generate this? >> >> It feels like a very simple svn script to see if a component has a >> build.xml, pom.xml or project.xml. > > But that won't detect if the scripts actually still work. Agreed, but neither will the wiki. Unlike the wiki, it will detect when the build is removed. Not that I know how to integrate it into the website, but 'seems easy' :) Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
On Thu, Jan 12, 2012 at 2:52 AM, sebb wrote: > On 12 January 2012 08:27, Henri Yandell wrote: >> On Tue, Jan 10, 2012 at 10:19 AM, sebb wrote: >>> On 10 January 2012 16:45, Siegfried Goeschl wrote: Hi folks, the main reason for the failed vote of commons-email-1.3 is that the release is only source but not binary compatible +) if you compile your application with the new version everything is fine +) if you replace simply the JAR the invocation fails Is it mandatory that a minor release is binary compatible with the previous one or do I have to create a new major version? There is a lot of ugly stuff (mainly protected member variables) which should be done but is currently not in the scope of this release. >>> >>> If the jar is not a drop-in replacement for the previous version, then >>> yes, IMO that requires a major release. [1] >>> The only possible exception might be if the incompatibilities are in >>> internal parts of the API, i.e. classes/methods etc. that are not used >>> externally. >> >> Thinking back on previous discussions, the primary exception has been >> the API itself is the bug and needs changing. >> >> A contrived (and over-simple) example would be: >> >> public void toUppercase(String s); >> >> It'd be better to fix the return type than live with bad API. >> >> Rare, but worth mentioning I thought. > > But that can still cause jar hell. > > If there are multiple jars in the same classloader that use the broken > API, they will all have to be updated at the same time. > May be tricky or impossible even if they are not from different providers. > > That's why binary compatibility is so important. Bad packaging practices causes jar hell. There's only so far we can go worrying about how our code is used. Part of the reason I felt it worth mentioning is that binary compatibility is not a magic trump card that aces everything else. It's very strongly desirable but not a mandatory absolute. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
