Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=303483&projectId=178
Build statistics:
State: Ok
Previous State: Error
Started at: Wed 17 Mar 2010 00:55:15 -0700
Finished at: Wed 17 Mar 2010 00:57:01 -0700
Total time: 1m 46s
Build Trigger: Schedule
Bui
Hi,
28: there is still one spurious non zero singular value
(3.547702387229884E-7 which I am going to try to kick out) instead of
two.
Dim.
I pushed it to 2.2 because what remained to resolve did not look to
me like a showstopper for 2.1. I may be missing something, though,
regarding severit
On 16/03/2010, Mladen Turk wrote:
> On 03/16/2010 05:22 PM, sebb wrote:
>
> >
> > The KEYS file is a bit old, but I assume it won't actually be used.
> >
> > Also, the source/ directory still has the 1.0.2 version in it, which
> > confused me a bit.
> >
> >
>
> This has nothing to do with a relea
On 03/17/2010 12:26 PM, sebb wrote:
-1. .zip is usable on platforms having broken tar like Solaris.
The files in windows/directory have CRLF
Seems to me that this is penalising Windows users for bugs on other OSes.
Having the wrong EOLs on Windows makes it difficult to read the text
files
Dimitri Pourbaix wrote:
> Hi,
>
>>> 28: there is still one spurious non zero singular value
>>> (3.547702387229884E-7 which I am going to try to kick out) instead of
>>> two.
>>>
>>> Dim.
>>
>> I pushed it to 2.2 because what remained to resolve did not look to
>> me like a showstopper for 2.1. I
On 17/03/2010, Mladen Turk wrote:
> On 03/16/2010 10:25 PM, s...@apache.org wrote:
>
> > Author: sebb
> >
>
> > +The Windows archive contains 2 different executables:
>
> It actually contains four of them.
> prunsvr.exe for x86, amd64 and ia64 and prunmgr for x86
> that manages all cpu specifi
Phil,
Right now, I see no option but avoiding the computation of A^tA. It is
fair to ask for 2.2.
OK, so you are OK with keeping the fix version for this one at 2.2?
Yes, I am. I will try to find a fix as soon as possible. If it turns out
to be before the release of 2.1, it will go there.
On 17/03/2010, Mladen Turk wrote:
> On 03/17/2010 12:26 PM, sebb wrote:
>
> >
> > >
> > > -1. .zip is usable on platforms having broken tar like Solaris.
> > > The files in windows/directory have CRLF
> > >
> >
> > Seems to me that this is penalising Windows users for bugs on other OSes.
> >
> >
To get an SVD isn't it more common to compute the eigen decomposition of
[ 0 A' ]
[ A 0 ]
Rather than A' A?
I have heard that this is supposed to avoid some problems with round-off
such as you are seeing. Moreover, many algorithms can be restated so that
this matrix never needs to be constr
Dimitri Pourbaix wrote:
> Phil,
>
>>> Right now, I see no option but avoiding the computation of A^tA. It is
>>> fair to ask for 2.2.
>>
>> OK, so you are OK with keeping the fix version for this one at 2.2?
>
> Yes, I am. I will try to find a fix as soon as possible. If it turns out
> to be b
On 03/17/2010 04:56 PM, sebb wrote:
On 17/03/2010, Mladen Turk wrote:
But that is exactly how it's done now.
Please double check the .zip file. Windows dir *has* DOS line endings.
But the N&L files don't have DOS EOLs.
Presumption that .zip file MUST be targeted
for windows and thus
On 17/03/2010, Mladen Turk wrote:
> On 03/17/2010 04:56 PM, sebb wrote:
>
> > On 17/03/2010, Mladen Turk wrote:
> >
> > >
> > > But that is exactly how it's done now.
> > > Please double check the .zip file. Windows dir *has* DOS line endings.
> > >
> >
> > But the N&L files don't have DOS EOLs
On 03/17/2010 06:40 PM, sebb wrote:
The purpose of multiple archives is to allow
users to choose their preferred unarchiver.
It therefore follows that the presumption that the files in zip
archives must have LF line endings is wrong.
Nope. It presumes that the sources will be buildable
Phil Steitz a écrit :
> Dimitri Pourbaix wrote:
>> Phil,
>>
Right now, I see no option but avoiding the computation of A^tA. It is
fair to ask for 2.2.
>>> OK, so you are OK with keeping the fix version for this one at 2.2?
>> Yes, I am. I will try to find a fix as soon as possible. If
On 17/03/2010, Bill Barker wrote:
>
>
> --
> From: "sebb"
> Sent: Tuesday, March 16, 2010 11:46 AM
> To: "Commons Developers List"
> Subject: [DAEMON] Site documentation
>
>
>
> > The binaries page:
> >
> >
> http://people.apache.org/~mturk/da
One of the POOL test cases is failing -
TestSoftRefOutOfMemory.testOutOfMemoryError()
I can't see any recent code changes that may have caused this and I
think the recent removal of the testAll code is what has exposed this.
On the basis that always catching Throwable is bad, but there are man
On 17/03/2010, Mark Thomas wrote:
> One of the POOL test cases is failing -
> TestSoftRefOutOfMemory.testOutOfMemoryError()
>
> I can't see any recent code changes that may have caused this and I think
> the recent removal of the testAll code is what has exposed this. On the
> basis that always c
This is a bit strange. The test that is now failing was added because
there was a bug report against [configuration] that was originally
caused by a problem in [lang] 2.4. In [lang] 2.5 (and also in the
current trunk) the problem was fixed, so after switching the dependency
to version 2.5 the t
On 17/03/2010 22:04, sebb wrote:
On 17/03/2010, Mark Thomas wrote:
One of the POOL test cases is failing -
TestSoftRefOutOfMemory.testOutOfMemoryError()
I can't see any recent code changes that may have caused this and I think
the recent removal of the testAll code is what has exposed this.
On 17/03/2010, Mark Thomas wrote:
> On 17/03/2010 22:04, sebb wrote:
>
> > On 17/03/2010, Mark Thomas wrote:
> >
> > > One of the POOL test cases is failing -
> > > TestSoftRefOutOfMemory.testOutOfMemoryError()
> > >
> > > I can't see any recent code changes that may have caused this and I
> thi
sebb wrote:
> On 17/03/2010, Mark Thomas wrote:
>> On 17/03/2010 22:04, sebb wrote:
>>
>>> On 17/03/2010, Mark Thomas wrote:
>>>
One of the POOL test cases is failing -
TestSoftRefOutOfMemory.testOutOfMemoryError()
I can't see any recent code changes that may have caused this
--
From: "sebb"
Sent: Wednesday, March 17, 2010 12:53 PM
To: "Commons Developers List"
Subject: Re: [DAEMON] Site documentation
On 17/03/2010, Bill Barker wrote:
--
From: "sebb"
Sent: Tues
UNLIST
Guido Schmutz
Technology Manager Integration,
Common and Open Source based Development
Partner / Principal Consultant
Application Development
Trivadis AG
Papiermühlestrasse 73
CH-3014 Bern
Phone +41-31-928 09 60
Fax +41-31-928 09 64
Mobile +41-79-412 05 39
guido.schm...@trivadis.com
www.
23 matches
Mail list logo
