[sage-devel] Re: Upgrading to GCC 4.7.2
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 exists an optional
package for this, so basically we just need to make that optional
package standard. Several of the buildbots are already using GCC-4.7.x
or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
don't expect problems. If nobody complains, I will do this upgrade to
GCC-4.7.2.
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 system-wide
GCC 4.7.0 on {mark,mark2}.)
[Probably more to come; haven't yet investigated further either.]
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] GIT + release management
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 Sage 6.0. He doesn't want to do further releases, so we need volunteers for release management for Sage 6.1 and later. Let me use that occasion to thank you publicly and loudly about your work managing releases! Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 GCC-4.7.2, I would propose
to upgrade Sage's GCC to version 4.7.2. There already exists an optional
package for this, so basically we just need to make that optional
package standard. Several of the buildbots are already using GCC-4.7.x
or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
don't expect problems. If nobody complains, I will do this upgrade to
GCC-4.7.2.
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 system-wide
GCC 4.7.0 on {mark,mark2}.)
[Probably more to come; haven't yet investigated further either.]
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
I'm currently rebuilding Sage using only Sun ld and as (my previous
attempt used the GNU ones and presented some problems).
The first failure I encountered was Singular, but that's the restrict
keyword crap I already mentioned, and is not GCC 4.7.2 related.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 GCC-4.7.2, I would propose
to upgrade Sage's GCC to version 4.7.2. There already exists an optional
package for this, so basically we just need to make that optional
package standard. Several of the buildbots are already using GCC-4.7.x
or even GCC-4.8-trunk, so GCC-4.7.x should be well-tested by now and I
don't expect problems. If nobody complains, I will do this upgrade to
GCC-4.7.2.
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 system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to (same as the one
with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any
difference), I can build the GAP and libgap spkgs both with CFLAGS unset
and with CFLAGS=-O3.
[Probably more to come; haven't yet investigated further either.]
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Is it ok to include multiprocessing functions in a patch?
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 semaphores support in the kernel. I really don't know if it is enabled by default in most distros or not, but anyways i would like to ask if it is ok to include some function that requires a specific kernel configuration (and that hence, could not work on some systems). So, is it ok? And if it is not, is there a way to circumvent this issue? (besides disabling parallelism, which is not really a good idea since the method can take a long time, and is trivially parallelizable). -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to (same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any
difference), I can build the GAP and libgap spkgs both with CFLAGS unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
-leif
[Probably more to come; haven't yet investigated further either.]
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is it ok to include multiprocessing functions in a patch?
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 in the first place? ;-) But IIRC, multiprocessing library requires open semaphores support in the kernel. I really don't know if it is enabled by default in most distros or not, but anyways i would like to ask if it is ok to include some function that requires a specific kernel configuration (and that hence, could not work on some systems). try: from multiprocessing.synchronize import ... ... # probably need to catch further exceptions upon construction ... except ImportError: # use a single-threaded fall-back implementation or give # an appropriate error message AFAIK, /building/ the Sage library also requires semaphores to work (even if SAGE_NUM_THREADS=1, which is odd, and we still don't even check this in advance), so at least /trying/ to use it should be ok... :-) So, is it ok? And if it is not, is there a way to circumvent this issue? (besides disabling parallelism, which is not really a good idea since the method can take a long time, and is trivially parallelizable). In any case, the maximum number of threads used should IMHO by default be limited to SAGE_NUM_THREADS. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Error in the determinant of a simple 4x4 matrix
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 = matrix([[sqrt(x),0,0], [0, 1, 0], [0, 0, 1]]) sage: det(a) sqrt(x) If sqrt(x) is replaced by another function, e.g. exp(x), it is fine as well: sage: a = matrix([[exp(x),0,0,0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0, 1]]) sage: det(a) e^x The problem seems to be connected with the non-integer power of x: sage: a = matrix([[x^(1/2),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 I've reproduced it in Sage 5.8, 5.7 and 5.4. Is this a known issue ? Eric. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Is it ok to include multiprocessing functions in a patch?
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 available in the computer.
Maybe it would be possible even to do it in a way that is suitable for
supercomputers (that is, with parallelism between different machines),
but that would be a completely different discussion.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 libGAP with
-O3; -O2 works in both cases. (I didn't get them with the
system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to (same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make any
difference), I can build the GAP and libgap spkgs both with CFLAGS unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
I rebuilt GCC with CFLAGS=-O3 -mcpu=niagara2 -mtune=niagara2.
And ... tada! It breaks when building GAP:
{{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in
simplify_immed_subreg, at simplify-rtx.c:5262
}}}
three times.
-leif
[Probably more to come; haven't yet investigated further either.]
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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
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
system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to (same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should not make
any
difference), I can build the GAP and libgap spkgs both with CFLAGS
unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
I rebuilt GCC with CFLAGS=-O3 -mcpu=niagara2 -mtune=niagara2.
And ... tada! It breaks when building GAP:
{{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in
simplify_immed_subreg, at simplify-rtx.c:5262
}}}
three times.
No problems with the same GCC built with CFLAGS=-O3 -mcpu=niagara2
-mtune=niagara2 if I build GAP with CFLAGS=-O2.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Error in the determinant of a simple 4x4 matrix
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 (most recent call last)
ipython-input-75-0227d66cfcfd in module()
1 (y - sqrt(x)).polynomial(None, ring=SR[y])
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression.polynomial
(sage/symbolic/expression.cpp:23610)()
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in polynomial(ex, base_ring, ring)
1054
1055 converter = PolynomialConverter(ex, base_ring=base_ring,
ring=ring)
- 1056 res = converter()
1057 return converter.ring(res)
1058
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in __call__(self, ex)
212 div = self.get_fake_div(ex)
213 return self.arithmetic(div, div.operator())
-- 214 return self.arithmetic(ex, operator)
215 elif operator in relation_operators:
216 return self.relation(ex, operator)
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in arithmetic(self, ex, operator)
1008 return self(base)**Integer(exp)
1009 else:
- 1010 ops = [self(a) for a in ex.operands()]
1011 return reduce(operator, ops)
1012
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in __call__(self, ex)
212 div = self.get_fake_div(ex)
213 return self.arithmetic(div, div.operator())
-- 214 return self.arithmetic(ex, operator)
215 elif operator in relation_operators:
216 return self.relation(ex, operator)
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in arithmetic(self, ex, operator)
1008 return self(base)**Integer(exp)
1009 else:
- 1010 ops = [self(a) for a in ex.operands()]
1011 return reduce(operator, ops)
1012
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in __call__(self, ex)
212 div = self.get_fake_div(ex)
213 return self.arithmetic(div, div.operator())
-- 214 return self.arithmetic(ex, operator)
215 elif operator in relation_operators:
216 return self.relation(ex, operator)
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression_conversions.pyc
in arithmetic(self, ex, operator)
1006 from sage.rings.all import Integer
1007 base, exp = ex.operands()
- 1008 return self(base)**Integer(exp)
1009 else:
1010 ops = [self(a) for a in ex.operands()]
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__init__ (sage/rings/integer.c:7335)()
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression._integer_
(sage/symbolic/expression.cpp:5340)()
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/rings/integer.so
in sage.rings.integer.Integer.__init__ (sage/rings/integer.c:7335)()
/home/vbraun/opt/sage-5.9.beta2/local/lib/python2.7/site-packages/sage/rings/rational.so
in sage.rings.rational.Rational._integer_ (sage/rings/rational.c:20598)()
TypeError: no conversion of this rational to integer
On Saturday, March 30, 2013 5:14:35 PM UTC, Eric Gourgoulhon 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 rational to integer
If the matrix is smaller, it is fine:
sage: a = matrix([[sqrt(x),0,0], [0, 1, 0], [0, 0, 1]])
sage: det(a)
sqrt(x)
If sqrt(x) is replaced by another function, e.g. exp(x), it is fine as
well:
sage: a = matrix([[exp(x),0,0,0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0,
1]])
sage: det(a)
e^x
The problem seems to be connected with the non-integer power of x:
sage: a = matrix([[x^(1/2),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
I've reproduced it in Sage 5.8, 5.7 and 5.4.
Is this a known issue ?
Eric.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group
[sage-devel] Re: Error in the determinant of a simple 4x4 matrix
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 rational to integer
Good catch!
The problem seems to be that `det` punts to `charpoly` for 4x4
matrices and larger, and that has some issues:
sage: a=matrix([[x,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]])
sage: charpoly(a)
0
this is due to the use of x as a variable:
sage: var('y')
y
sage: a=matrix([[y,0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]])
sage: charpoly(a)
x^4 + (-y - 3)*x^3 + (3*y + 3)*x^2 + (-3*y - 1)*x + y
which is correct.
That is not the (only) issue you are running into, however. Unwrapping
the code for a.charpoly:
sage: a=matrix([[y^(1/2),0,0,0],[0,1,0,0],[0,0,1,0],[0,0,0,1]])
sage: self=a
sage: var='x'
sage: cp = self._maxima_(maxima).charpoly(var)._sage_()
Up to here everything is fine:
sage: cp
(x - 1)^3*(x - sqrt(y))
sage: cp.expand()
x^4 - x^3*sqrt(y) - 3*x^3 + 3*x^2*sqrt(y) + 3*x^2 - 3*x*sqrt(y) - x +
sqrt(y)
It's in the following step that things go wrong:
sage: cp.expand().polynomial(None, ring=SR[var])
TypeError
so the problem is sage.symbolic.expression_conversions.polynomial
It's silly that such a generic, dodgy routine is used here. You know
which variable you want to isolate (and we should NOT make that 'x'
but some 'custom_variable_you_never_use_somewhere_else') and you also
know the degree. So the conversion should be something like
V=SR('crazy_varname')
cp=self._maxima_(maxima).charpoly('crazy_varname')._sage_().expand()
SR[var](list(cp.coefficient(V,i) for i in range(self.nrows()+1)))
Of course, even in this you're at the mercy of maxima's expand doing
what you'd hope it does, but given that the result really should just
be a polynomial in 'crazy_varname', so we can have good hopes 'expand'
does the proper (expensive) thing here.
(You really don't want to let 'crazy_varname' leak out of charpoly,
otherwise you'll have trouble if someone decides to make a matrix of
characteristic polynomials and determine the charpoly of that. You
also don't want to generate a fresh variable every time, since the
management of variables in maxima/our interface would create a memory
leak)
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 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 system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to
(same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should
not make any
difference), I can build the GAP and libgap spkgs both with
CFLAGS unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
I rebuilt GCC with CFLAGS=-O3 -mcpu=niagara2 -mtune=niagara2.
And ... tada! It breaks when building GAP:
{{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in
simplify_immed_subreg, at simplify-rtx.c:5262
}}}
Exactly.
three times.
No problems with the same GCC built with CFLAGS=-O3 -mcpu=niagara2
-mtune=niagara2 if I build GAP with CFLAGS=-O2.
Yep. Although I didn't get them with GCC 4.7.0 and '-mcpu=...
-mtune=... -O3', so this might be a regression in 4.7.1 or 4.7.2.
Did you search GCC bugzilla? (I haven't yet.)
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Is it ok to include multiprocessing functions in a patch?
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 @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 available in the computer.
Maybe it would be possible even to do it in a way that is suitable for
supercomputers (that is, with parallelism between different machines),
but that would be a completely different discussion.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 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 system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to
(same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should
not make any
difference), I can build the GAP and libgap spkgs both with
CFLAGS unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
I rebuilt GCC with CFLAGS=-O3 -mcpu=niagara2 -mtune=niagara2.
And ... tada! It breaks when building GAP:
{{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in
simplify_immed_subreg, at simplify-rtx.c:5262
}}}
Exactly.
three times.
No problems with the same GCC built with CFLAGS=-O3 -mcpu=niagara2
-mtune=niagara2 if I build GAP with CFLAGS=-O2.
Yep. Although I didn't get them with GCC 4.7.0 and '-mcpu=...
-mtune=... -O3', so this might be a regression in 4.7.1 or 4.7.2.
Did you search GCC bugzilla? (I haven't yet.)
Nope, I rather tried to finish building Sage.
Here is the result of make ptestlong:
{{{
sage -t --long devel/sage/sage/crypto/mq/sr.py # 1 doctest failed
sage -t --long devel/sage/sage/interfaces/expect.py # 2 doctests failed
sage -t --long devel/sage/sage/matrix/matrix_modn_dense.pyx # 5 doctests
failed
sage -t --long devel/sage/sage/matrix/matrix_modn_dense_template.pxi # 5
doctes
ts failed
sage -t --long devel/sage/sage/combinat/backtrack.py # Time out
sage -t --long
devel/sage/sage/combinat/cluster_algebra_quiver/cluster_seed.py
# Time out
sage -t --long
devel/sage/sage/combinat/cluster_algebra_quiver/mutation_type.py
# Time out
sage -t --long devel/sage/sage/combinat/cluster_algebra_quiver/quiver.py #
Time
out
sage -t --long devel/sage/sage/rings/polynomial/polynomial_element.pyx # 1
doct
est failed
sage -t --long devel/sage/sage/interfaces/ecm.py # Time out
sage -t --long
devel/sage/sage/quadratic_forms/quadratic_form__automorphisms.py
# Time out
sage -t --long
devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py #
Time out
}}}
The non-timeout errors are worrying:
* sage.crypto.mq.sr.test_consistency
{{{
File multi_polynomial_ideal_libsingular.pyx, line 250, in
sage.rings.polynomial.multi_polynomial_ideal_libsingular.slimgb_libsingular
(sage/rings/polynomial/multi_polynomial_ideal_libsingular.cpp:3568)
RuntimeError: Bus error
}}}
* sage.interface.expect: Singular crashes
* sage.matrix.matrix_modn_dense.Matrix_modn_dense._unpickle: unpickle
failures
{{{
File matrix_modn_dense_template.pxi, line 640, in
sage.matrix.matrix_modn_dense_double.Matrix_modn_dense_template._pickle
(sage/matrix/matrix_modn_dense_double.cpp:6719)
RuntimeError: Bus error
}}}
* matrix.matrix_modn_dense_template.Matrix_modn_dense_template._unpickle:
unpickle failures.
except for
* sage.rings.polynomial.polynomial_element.Polynomial.inverse_mod: likely
numerical noise
Of course all these failures might be GCC 4.7.2 non-related.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 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 system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to
(same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should
not make any
difference), I can build the GAP and libgap spkgs both with
CFLAGS unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
I rebuilt GCC with CFLAGS=-O3 -mcpu=niagara2 -mtune=niagara2.
And ... tada! It breaks when building GAP:
{{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in
simplify_immed_subreg, at simplify-rtx.c:5262
}}}
Exactly.
three times.
No problems with the same GCC built with CFLAGS=-O3 -mcpu=niagara2
-mtune=niagara2 if I build GAP with CFLAGS=-O2.
Yep. Although I didn't get them with GCC 4.7.0 and '-mcpu=...
-mtune=... -O3', so this might be a regression in 4.7.1 or 4.7.2.
It does not errors out if I only use -O3 and not -mtune and -mcpu.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Upgrading to GCC 4.7.2
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 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
libGAP with
-O3; -O2 works in both cases. (I didn't get them with
the system-wide
GCC 4.7.0 on {mark,mark2}.)
I cannot reproduce these on the Solaris I have access to
(same as the
one with singular/restrict problem).
With Sage 5.7 and the GCC 4.7.2.p1 spkg (not that it should
not make any
difference), I can build the GAP and libgap spkgs both with
CFLAGS unset
and with CFLAGS=-O3.
I also built GCC itself with -O3 (and -mcpu=ultrasparc3
-mtune=ultrasparc3); not yet sure whether that matters.
I rebuilt GCC with CFLAGS=-O3 -mcpu=niagara2 -mtune=niagara2.
And ... tada! It breaks when building GAP:
{{{
../../src/blister.c: In function 'InitKernel':
../../src/blister.c:2743:1: internal compiler error: in
simplify_immed_subreg, at simplify-rtx.c:5262
}}}
Exactly.
three times.
No problems with the same GCC built with CFLAGS=-O3 -mcpu=niagara2
-mtune=niagara2 if I build GAP with CFLAGS=-O2.
Yep. Although I didn't get them with GCC 4.7.0 and '-mcpu=...
-mtune=... -O3', so this might be a regression in 4.7.1 or 4.7.2.
It does not errors out if I only use -O3 and not -mtune and -mcpu.
And does with -O3 -mcpu=niagara2
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GIT + release management
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 anyway. Robert Bradshaw has agreed to be release manager for Sage 6.0. He doesn't want to do further releases, so we need volunteers for release management for Sage 6.1 and later. Let me use that occasion to thank you publicly and loudly about your work managing releases! +1000 Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GIT + release management
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 the release workflow will change substantially anyway. Robert Bradshaw has agreed to be release manager for Sage 6.0. He doesn't want to do further releases, so we need volunteers for release management for Sage 6.1 and later. Let me use that occasion to thank you publicly and loudly about your work managing releases! +1000 **10 to dima's number. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GIT + release management
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 already be a usable GIT-based release in parallel with the Mercurial release. This won't have all features yet, but it should be possible to use for development (for those who know it). If needed, there will be further Sage 5.1x releases until the GIT development scripts are ready. Sage 6.0 will then be a release which is only about switching to GIT (no other non-GIT-related tickets). 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 Sage 6.0. He doesn't want to do further releases, so we need volunteers for release management for Sage 6.1 and later. Thank you for your tireless work over the last few years :) And thanks for helping us so much with the Git transition too! -Keshav -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
