On Mon, May 4, 2009 at 7:36 AM, mabshoff wrote:
>
>
>
> On May 4, 7:30 am, Jaap Spies wrote:
>> mabshoff wrote:
>> > Hello folks,
>>
>> > the final release for 3.4.2 is done and sources, the upgrade bits and
>> > a sage.math binary are in the usual place at
>>
>> > http://sage.math.washington.e
mabshoff wrote:
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final
mabshoff wrote:
>
>
> On May 4, 7:30 am, Jaap Spies wrote:
>> mabshoff wrote:
>>> Hello folks,
>>> the final release for 3.4.2 is done and sources, the upgrade bits and
>>> a sage.math binary are in the usual place at
>>> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>>>
On Mon, May 4, 2009 at 7:52 AM, mabshoff wrote:
>
>
>
> On May 4, 7:40 am, William Stein wrote:
>> On Mon, May 4, 2009 at 7:36 AM, mabshoff wrote:
>>
>> > On May 4, 7:30 am, Jaap Spies wrote:
>> >> mabshoff wrote:
>> >> > Hello folks,
>>
>> >> > the final release for 3.4.2 is done and sources,
On May 4, 7:57 am, Jaap Spies wrote:
> mabshoff wrote:
> > Well, I knew FLINT still ran its test suite and given we updated MPIR
> > I do prefer for it to run. There was also no 3.4.2 ticket to turn it
> > off :p.
>
> This testing feels ok for alpha and rc releases, but not on a final
> sour
mabshoff wrote:
>
>
> On May 4, 7:57 am, Jaap Spies wrote:
>> mabshoff wrote:
>
>
>
>>> Well, I knew FLINT still ran its test suite and given we updated MPIR
>>> I do prefer for it to run. There was also no 3.4.2 ticket to turn it
>>> off :p.
>> This testing feels ok for alpha and rc release
On May 4, 7:40 am, William Stein wrote:
> On Mon, May 4, 2009 at 7:36 AM, mabshoff wrote:
>
> > On May 4, 7:30 am, Jaap Spies wrote:
> >> mabshoff wrote:
> >> > Hello folks,
>
> >> > the final release for 3.4.2 is done and sources, the upgrade bits and
> >> > a sage.math binary are in the usu
On May 4, 8:26 am, Jaap Spies wrote:
> > Nope, it was commonly handled that way. But since the 'real' releases
> > are build more widely that either alpha or rc releases I have been
> > changing this to even run some test suites even then. This has already
> > flushed out various bugs in MPI
On May 4, 7:30 am, Jaap Spies wrote:
> mabshoff wrote:
> > Hello folks,
>
> > the final release for 3.4.2 is done and sources, the upgrade bits and
> > a sage.math binary are in the usual place at
>
> > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> > I was cocky and l
mabshoff wrote:
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
>
> I was cocky and labeled the release 3.4.2 instead of 3.4.2.final
On May 4, 5:53 am, mabshoff wrote:
> Hello folks,
> #5957: Michael Abshoff: 3.4.2.rc0: Maxima related doctest failure in
> matrix/matrix_symbolic_dense.pyx [Reviewed by Michael Abshoff]
Oops, author credit here goes to William. I uploaded the patch, so
that caused the confusion. Sorry :(
C
On May 4, 9:07 am, Jaap Spies wrote:
> mabshoff wrote:
> > Hello folks,
> > Please build, test and report issues as usual.
>
> On Fedora 9, 32 bit upgraded from alpha0 -> rc0-> sage-3.4.2
> and on Fedora 10, 32 bit upgraded from rc0 I get tons
> of failures with prime_pi, e.g.:
>
> sage -t
On May 4, 9:33 am, mabshoff wrote:
> On May 4, 9:07 am, Jaap Spies wrote:
> Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
> Cython. I didn't use any long representation of 2^40 to avoid running
> into 32 vs. 64 bit issues. Oh well, please open a ticket, I guess
> ther
mabshoff wrote:
>
>
> On May 4, 9:33 am, mabshoff wrote:
>> On May 4, 9:07 am, Jaap Spies wrote:
>
>
>
>> Arrg, this is cause by Integer(2**40) on 32 bit systems being "0" in
>> Cython. I didn't use any long representation of 2^40 to avoid running
>> into 32 vs. 64 bit issues. Oh well, plea
On May 4, 10:03 am, Jaap Spies wrote:
> mabshoff wrote:
As mentioned on #5980 I checked if you had opened the ticket already
before I opened #5981, but you did open it parallel to my ticket - so
great minds think alike I guess ;)
> > This is now #5981 with a proto patch attached. With it pr
mabshoff wrote:
>
>
> On May 4, 10:03 am, Jaap Spies wrote:
>> mabshoff wrote:
>
>
>
> As mentioned on #5980 I checked if you had opened the ticket already
> before I opened #5981, but you did open it parallel to my ticket - so
> great minds think alike I guess ;)
>
:)
[...]
>
> Good. I
On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
sage -t "devel/sage/sage/interfaces/sage0.py"
which is random, i.e. rerunning it usually works fine. But not always.
Two other builds on slower / heavily loaded machines still building...
John
2009/5/4 Jaap Spie
On May 4, 11:30 am, John Cremona wrote:
Hi John,
> On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
> sage -t "devel/sage/sage/interfaces/sage0.py"
> which is random, i.e. rerunning it usually works fine. But not always.
>
> Two other builds on slower / heav
mabshoff wrote:
>
>
>
> Good. I tested on 32 and 64 bit and it works for me, too. The patch is
> formally up and the ticket is also open against 3.4.2, so feel free to
> review. I will wait for all my other build tests to finish doctesting
> before pushing out the new tarball (just in case som
2009/5/4 mabshoff :
>
>
>
> On May 4, 11:30 am, John Cremona wrote:
>
> Hi John,
>
>> On Bill Hart's machine (64-bit ubuntu) I build ok but get a failure here:
>> sage -t "devel/sage/sage/interfaces/sage0.py"
>> which is random, i.e. rerunning it usually works fine. But not always.
>>
>
On May 4, 2009, at 05:53 , mabshoff wrote:
>
> Hello folks,
>
> the final release for 3.4.2 is done and sources, the upgrade bits and
> a sage.math binary are in the usual place at
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.4.2/
Built on Mac OS X, 10.5.6 (Dual Quad Xeon
>>
>> On relative slow hardware it looks like a good idea to make
>> installation of ATLAS and e.g. FLINT less time consuming.
>
> Well, for ATLAS we don't even run the test suite, so what you see at
> the moment is as close to optimum as it gets. You can reuse a
> previously build ATLAS (assuming
22 matches
Mail list logo
