Jeroen Demeyer wrote:
The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
properly due to a GCC bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
Since this problem doesn't seem to occur with GCC-4.7.2, I would propose
to upgrade Sage's GCC to version 4.7.2. There already
Le 30/03/2013 06:00, Jeroen Demeyer a écrit :
Sage 5.1x will also be the last release under my release management. The
switch to GIT is an excellent time for a new release manager, since the
release workflow will change substantially anyway. Robert Bradshaw has
agreed to be release manager for
On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
Jeroen Demeyer wrote:
The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
properly due to a GCC bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
Since this problem doesn't seem to occur with
On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
Jeroen Demeyer wrote:
The Cygwin folks have an issue that GCC-4.6.3 doesn't compile ECL
properly due to a GCC bug
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52061).
Since this problem doesn't seem to occur with
I am working on a patch to implement Zariski-Van Kampen method, and it
makes use of parallelization. For some reason, the use of plain
@parallel decorator (which uses fork) gives some problems, but it
works of if i use the multiprocessing option.
But IIRC, multiprocessing library requires open
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun as
and ld) on Solaris SPARC (32-bit) when compiling GAP and libGAP with
-O3; -O2 works in both cases. (I didn't get them with the
mmarco wrote:
I am working on a patch to implement Zariski-Van Kampen method, and it
makes use of parallelization. For some reason, the use of plain
@parallel decorator (which uses fork) gives some problems, but it
works of if i use the multiprocessing option.
Solve the problem with @parallel
Hello,
I've noticed this strange behavior (bug ?) on the following elementary
computation:
sage: a = matrix([[sqrt(x),0,0,0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0,
1]])
sage: det(a)
...
TypeError: no conversion of this rational to integer
If the matrix is smaller, it is fine:
sage: a =
Solve the problem with @parallel in the first place? ;-)
That is where the problem apperaed (see #14154). It doesn't appear
using @parallel('multiprocessing'), which is what i am asking here if
it is ok. I think that if you don't specify the number of threads, it
uses the number of cpus
On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with Sun
as
and ld) on Solaris SPARC (32-bit) when compiling GAP and
On Saturday, March 30, 2013 6:25:37 PM UTC+1, Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
Just for the record, I get ICEs with the GCC 4.7.2.p0 spkg (with
Its not linear algebra but comes from the symbolic ring stuff:
sage: var('x,y')
(x, y)
sage: (y - sqrt(x)).polynomial(None, ring=SR[y])
---
TypeError Traceback
On Mar 30, 10:14 am, Eric Gourgoulhon egourgoul...@gmail.com wrote:
Hello,
I've noticed this strange behavior (bug ?) on the following elementary
computation:
sage: a = matrix([[sqrt(x),0,0,0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0,
1]])
sage: det(a)
...
TypeError: no conversion of this
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 6:25:37 PM UTC+1, Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 7:15:10 AM UTC+1, leif wrote:
Just for the record, I
I think it's okay: the new doctesting code uses multiprocessing.
David
On Sat, Mar 30, 2013 at 10:22 AM, mmarco mma...@unizar.es wrote:
Solve the problem with @parallel in the first place? ;-)
That is where the problem apperaed (see #14154). It doesn't appear
using
On Saturday, March 30, 2013 7:42:38 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 6:25:37 PM UTC+1, Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March
On Saturday, March 30, 2013 7:42:38 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 6:25:37 PM UTC+1, Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March
On Saturday, March 30, 2013 9:35:40 PM UTC+1, Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 7:42:38 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 6:25:37 PM UTC+1, Jean-Pierre Flori wrote:
On Saturday, March 30, 2013 2:46:56 PM UTC+1, leif
On 2013-03-30, Julien Puydt julien.pu...@laposte.net wrote:
Le 30/03/2013 06:00, Jeroen Demeyer a écrit :
Sage 5.1x will also be the last release under my release management. The
switch to GIT is an excellent time for a new release manager, since the
release workflow will change substantially
On 03/31/2013 11:30 AM, Dima Pasechnik wrote:
On 2013-03-30, Julien Puydtjulien.pu...@laposte.net wrote:
Le 30/03/2013 06:00, Jeroen Demeyer a écrit :
Sage 5.1x will also be the last release under my release management. The
switch to GIT is an excellent time for a new release manager, since
Jeroen Demeyer jdeme...@cage.ugent.be writes:
Dear Sage lovers,
I'm here at the Sage-GIT workshop and it's very clear that the switch
to GIT is happening.
The current idea is to have Sage 5.9 and Sage 5.10 with the current
Mercurial-based workflow. Hopefully before Sage 5.10, there will
21 matches
Mail list logo
