Also, I think that further cleanup is possible (cf. wantu and wantv
checks that don't seem very useful).
This is residual from the JAMA code and is not required with our current
interface.
I wonder if we could implement something around this. I can conceive of
cases where users may only want
Le 14/08/2011 17:29, sebb a écrit :
FastMath.java:1008 says:
* for extra precision (i.e. exp(x) = result[0] ° result[1]
The operator symbol is mangled (probably due to conversion between encodings).
I'm not sure what the operator should be - dot product perhaps?
Hi Sebb,
It should
Hi,
while working on the Zip64 stuff I deliberately created some invalid
archives to test I get the expected exceptions. While doing so I
realized I couldn't close the underlying stream because
ZipArchiveOutputStream's close would throw an exception as finish()
failed before ever closing the
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-vfs2 has an issue affecting its community integration.
This issue
Hi.
Also, I think that further cleanup is possible (cf. wantu and wantv
checks that don't seem very useful).
This is residual from the JAMA code and is not required with our current
interface.
I removed them in r1157281.
I wonder if we could implement something around this. I can
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
Hello.
I'm in favor of moving some methods to the SparseXXX interface, but
got voted down at the time. For application developers (like me),
that can expect in advance if the Vector/Matrix is sparse or not it
isn't a big deal. But I can see how it may cause problems for other
libraries that
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11271projectId=64
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon 15 Aug 2011 11:20:24 +
Finished at: Mon 15 Aug 2011 11:20:47 +
Total time: 23s
Build Trigger: Schedule
Build
On 15 August 2011 09:50, Luc Maisonobe luc.maison...@free.fr wrote:
Le 14/08/2011 17:29, sebb a écrit :
FastMath.java:1008 says:
* for extra precision (i.e. exp(x) = result[0] ° result[1]
The operator symbol is mangled (probably due to conversion between
encodings).
I'm not sure
/home/continuum/continuum-base/data/working-directory/64/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveException.java:[38,8]
cannot find symbol
symbol : constructor IOException(java.lang.Throwable)
That's Java 1.6+
On 15 August 2011 12:20, Continuum@vmbuild
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=11273projectId=64
Build statistics:
State: Failed
Previous State: Failed
Started at: Mon 15 Aug 2011 12:20:55 +
Finished at: Mon 15 Aug 2011 12:21:20 +
Total time: 25s
Build Trigger: Schedule
On 15 August 2011 09:56, Stefan Bodewig bode...@apache.org wrote:
Hi,
while working on the Zip64 stuff I deliberately created some invalid
archives to test I get the expected exceptions. While doing so I
realized I couldn't close the underlying stream because
ZipArchiveOutputStream's close
On 2011-08-15, sebb wrote:
/home/continuum/continuum-base/data/working-directory/64/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveException.java:[38,8]
cannot find symbol
symbol : constructor IOException(java.lang.Throwable)
That's Java 1.6+
Yes, will fix it in one of
Hi, Elijah--
I am neither a develop nor even a user of chain, so my comments will
be high-level. Firstly, by all means upgrade to whatever JUnit 4
release version you like, e.g. 4.8.2. Next, I personally am a big fan
of Mockito, so no complaints here on that account. I can't guarantee
noone
On Mon, Aug 15, 2011 at 8:22 AM, Matt Benson gudnabr...@gmail.com wrote:
Hi, Elijah--
I am neither a develop nor even a user of chain, so my comments will
[SNIP]
Nay, nor even a develop[er]. :|
Matt
-
To unsubscribe,
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a release.
As the Commons project is already very experienced with releasing
components, there is no need for
On 14 August 2011 22:38, Gary Gregory garydgreg...@gmail.com wrote:
Hi,
On Aug 14, 2011, at 10:19, sebb seb...@gmail.com wrote:
On 14 August 2011 03:02, sebb seb...@gmail.com wrote:
On 12 August 2011 20:56, Gary Gregory garydgreg...@gmail.com wrote:
Hello All:
For a first cut at generics
On Mon, Aug 15, 2011 at 4:04 AM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
Hello.
I'm in favor of moving some methods to the SparseXXX interface, but
got voted down at the time. For application developers (like me),
that can expect in advance if the Vector/Matrix is sparse or
+1 (Commons PMC).
On Mon, Aug 15, 2011 at 6:51 AM, Christian Grobmeier
grobme...@gmail.com wrote:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a release.
+1
On Mon, Aug 15, 2011 at 10:19 AM, Henri Yandell flame...@gmail.com wrote:
+1 (Commons PMC).
On Mon, Aug 15, 2011 at 6:51 AM, Christian Grobmeier
grobme...@gmail.com wrote:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons
On 15 August 2011 14:51, Christian Grobmeier grobme...@gmail.com wrote:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a release.
As the Commons project is
+1
OGNL committer
Maurizio Cucchiara
On 15 August 2011 15:51, Christian Grobmeier grobme...@gmail.com wrote:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having
Hi Matt,
Thanks for the advice. I've created a JIRA issue for the patch
(https://issues.apache.org/jira/browse/CHAIN-53) and signed and
submitted the CLA.
As for JSF, I believe I made a mistake in changing the API to use the
office jsf API instead of the myfaces API that was previously being
Just in case anyone wants to use Maven to download the Java part of
Commons Daemon (this has been requested in the past), I thought it
would be useful to create and upload the Maven artifacts to the Nexus
staging repo.
The uploads contain source, so although the main release votes have
already
Am 14.08.2011 23:28, schrieb Emmanuel Bourg:
Le 13/08/2011 20:53, Oliver Heger a écrit :
Hi,
as you may have noticed, I have started some work in order to prepare a
release (version 1.7) of [configuration]. I assume this will be the last
release compatible with Java 1.4.
So the release after
+1 (Commons PMC)
Oliver
Am 15.08.2011 15:51, schrieb Christian Grobmeier:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a release.
As the Commons project
+1 (Commons PMC)
Gary
On Mon, Aug 15, 2011 at 9:51 AM, Christian Grobmeier
grobme...@gmail.com wrote:
OGNL [1] has checked off all status items in the incubator.
Most of the OGNL developers are already commons developers and the
risk of failure is pretty small, even without having made a
I don't know. I think it really needs a refactoring. We always said that all
configurations should be based on HierarchicalConfiguration but that still
hasn't happened. Attribute splitting and delimiter parsing have been a pain.
I think it would be great to start with clean interfaces and
I'm in favor of moving some methods to the SparseXXX interface, but
got voted down at the time. For application developers (like me),
that can expect in advance if the Vector/Matrix is sparse or not it
isn't a big deal. But I can see how it may cause problems for other
libraries
Well, no they wouldn't.
They would often need to write something like
dense.times(unknown)
They know that their own object is dense, but they don't know what kind of
input they were given. They should still run fast if the input is sparse.
On Mon, Aug 15, 2011 at 3:06 PM, Gilles Sadowski
On Mon, Aug 15, 2011 at 10:12 AM, sebb seb...@gmail.com wrote:
On 14 August 2011 22:38, Gary Gregory garydgreg...@gmail.com wrote:
Hi,
On Aug 14, 2011, at 10:19, sebb seb...@gmail.com wrote:
On 14 August 2011 03:02, sebb seb...@gmail.com wrote:
On 12 August 2011 20:56, Gary Gregory
Well, no they wouldn't.
They would often need to write something like
dense.times(unknown)
An actual code excerpt would help me understand what you think is or isn't
or should be possible with CM.
If dense and unknown are vectors, then in ArrayRealVector, dotProduct
uses a
No.
You can't. This is because the type is lost as you enter the generic
library.
On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
They know that their own object is dense, but they don't know what kind
of
input they were given. They should still run
I am using Maven 3 to do my release of Commons VFS and have noticed that I am
getting way more junk than I expected in Nexus. The first thing I'm
investigating are the site.xml files being deployed. Do we have a requirement
that these should be deployed? Why does commons parent have the site
Forgive me for pushing my nose under the tent... I couldn't resist.
I think Gilles is saying that each specialization of the matrix/vector
objects would need to support pre (and post) multiplication with a dense. So
the type issue would not be problematic.
On Mon, Aug 15, 2011 at 6:34 PM, Ted
On 15 August 2011 23:53, Gary Gregory garydgreg...@gmail.com wrote:
On Mon, Aug 15, 2011 at 10:12 AM, sebb seb...@gmail.com wrote:
On 14 August 2011 22:38, Gary Gregory garydgreg...@gmail.com wrote:
Hi,
On Aug 14, 2011, at 10:19, sebb seb...@gmail.com wrote:
On 14 August 2011 03:02,
On 16 August 2011 00:48, Ralph Goers ralph.go...@dslextreme.com wrote:
I am using Maven 3 to do my release of Commons VFS and have noticed that I am
getting way more junk than I expected in Nexus. The first thing I'm
investigating are the site.xml files being deployed. Do we have a
I understood what he was suggesting. I still disagree. Dynamic dispatch
and non-lattice typing structure is still required to make this all work.
Java doesn't really do that. Pretending that what Java does is sufficient
is hammer-looking-for-a-nail, not solving the problems at hand.
On Mon,
Am 15.08.2011 23:02, schrieb Ralph Goers:
I don't know. I think it really needs a refactoring. We always said that all
configurations should be based on HierarchicalConfiguration but that still
hasn't happened. Attribute splitting and delimiter parsing have been a pain.
I think it would be
39 matches
Mail list logo
