Re: [sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
could you pleae confirm that the fix I've committed to the gf2x main branch fixes the issue you encounter ? This is a genuine bug which deserves to be fixed, so: - I care about whether my changes correct the issue. - I don't mind creating a bugfix tarball if deemed useful. On the other hand, if you consider the gf2x-1.1 spkg as distributed in sage-5.11 as something immutable you can't change, there's not much I can do. Frankly, you'd be better off replacing the spkg with a really fixed one... E. On Fri, Oct 4, 2013 at 5:55 PM, Robert Campbell rcamp...@umbc.edu wrote: The bug appears to be something in gf2x's configure.ac file, but as I know little about writing config scripts it's hard to give advice. In the meantime, here is a simple step-by-step for those who want SAGE-5.11 but have an old pre-SSE2 machine (schools cheapskates like me): 1) Confirm that your machine doesn't have SSE2 - look for the sse2 flag in the /proc/cpuinfo file. 2) Edit the gf2x spkg file: a) copy sage-5.11/spkg/standard/gf2x-1.1.spkg to a working location b) tar -jxvf gf2x-1.1.spkg c) Edit gf2x-1.1/spkg-install: Edit line 38 to read ./configure --enable-sse2=no --prefix=$SAGE_LOCAL d) tar -jcvf gf2x-1.1.spkg gf2x-1.1 e) move gf2x-1.1.spkg back to its original location in sage-5.11/spkg/standard/. 3) Compile SAGE as usual Most folks in this situation will not want to compile SAGE themselves (it took me 37 hours on my 1.3 GHz Athlon) and it would be nice to have a pre-compiled version available. An easy solution would be a binary from before the bug was introduced (gf2x-1.1 and hence SAGE-5.11), but I don't see that older binary versions are available from sagemath.org. Robert Campbell On Friday, September 20, 2013 9:01:13 AM UTC-4, Andrew Fiori wrote: This is likely a build error bug on all systems which do not support SSE2 but where building is done using the current version of gcc. It may also manifest as a runtime error on binary builds installed on systems which do not support SSE2 (but I have not tested that). I am submitting this here rather than to bug tracker for several reasons: - It is unlikely anyone cares enough to fix this properly upstream (which is where the bug really is). - The build error only effects building from source on systems that are out of date and will becoming even less common going forward. I am mentioning it at all, because it will help anyone who comes across this error in the future. The same type of error may cause somewhat confusing runtime errors in other packages (bug tracker searches suggest this type of issue has come up before in other packages). The bug: The bug is somewhere in the gf2x build scripts src/config/acinclude.m4 or src/configure somehow it decides whether or not the system supports sse2 (look around line 75 of acinclude.m4. It appears to do this by checking if gcc can compile something that uses sse2. It turns out that it can... even if the system you are on cannot. Consequently it tries to build everything with sse2. This causes a problem when it tries to tune itself src/src/tune-lowlevel.pl. Around line 70-78 it tries to run the compiled code. Most of these don't require sse2 really, and so work, some do (mul3t, mul3k, mul3k2) these fail, it then can't pick which one to use, and terminates building. If there are other places in sage where similar sse2 detection is used, but which are not executed at build time (most things are not), then sage will encounter unexpected runtime bugs when pieces of code that can benefit from sse2 are used. The solution: gf2x doesn't require sse2 to work. The easiest way to build it on a system where the above bug is encountered is to modify: spkg-install:38 to become: ./configure --enable-sse2=no --prefix=$SAGE_LOCAL You don't really want to do this in the main branch though, as this slows things down for the 99+% of people who don't have an archaic system they are trying to run sage on. A better solution is to add an if statement at this place and environment variable globally to disable sse2 when it doesn't exist. Alternatively one could invest the time and figure out then fix gf2x build system. - Andrew -- You received this message because you are subscribed to a topic in the Google Groups sage-devel group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/Cp1lDMzyCrU/unsubscribe. To unsubscribe from this group and all its topics, 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. 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
Re: [sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
It seems I only sent my reply to Emmanuel. So briefly: - Andrew: can you please confirm that the latest tarball provided by Emmanuel is fixed? - if that's the case, I'll open a trac ticket to update the gf2x spkg provided by Sage and it should make its way into Sage 5.12 or 5.13. Best, JP On Friday, October 4, 2013 6:41:19 PM UTC+2, Emmanuel Thomé wrote: could you pleae confirm that the fix I've committed to the gf2x main branch fixes the issue you encounter ? This is a genuine bug which deserves to be fixed, so: - I care about whether my changes correct the issue. - I don't mind creating a bugfix tarball if deemed useful. On the other hand, if you consider the gf2x-1.1 spkg as distributed in sage-5.11 as something immutable you can't change, there's not much I can do. Frankly, you'd be better off replacing the spkg with a really fixed one... E. On Fri, Oct 4, 2013 at 5:55 PM, Robert Campbell rcam...@umbc.edujavascript: wrote: The bug appears to be something in gf2x's configure.ac file, but as I know little about writing config scripts it's hard to give advice. In the meantime, here is a simple step-by-step for those who want SAGE-5.11 but have an old pre-SSE2 machine (schools cheapskates like me): 1) Confirm that your machine doesn't have SSE2 - look for the sse2 flag in the /proc/cpuinfo file. 2) Edit the gf2x spkg file: a) copy sage-5.11/spkg/standard/gf2x-1.1.spkg to a working location b) tar -jxvf gf2x-1.1.spkg c) Edit gf2x-1.1/spkg-install: Edit line 38 to read ./configure --enable-sse2=no --prefix=$SAGE_LOCAL d) tar -jcvf gf2x-1.1.spkg gf2x-1.1 e) move gf2x-1.1.spkg back to its original location in sage-5.11/spkg/standard/. 3) Compile SAGE as usual Most folks in this situation will not want to compile SAGE themselves (it took me 37 hours on my 1.3 GHz Athlon) and it would be nice to have a pre-compiled version available. An easy solution would be a binary from before the bug was introduced (gf2x-1.1 and hence SAGE-5.11), but I don't see that older binary versions are available from sagemath.org. Robert Campbell On Friday, September 20, 2013 9:01:13 AM UTC-4, Andrew Fiori wrote: This is likely a build error bug on all systems which do not support SSE2 but where building is done using the current version of gcc. It may also manifest as a runtime error on binary builds installed on systems which do not support SSE2 (but I have not tested that). I am submitting this here rather than to bug tracker for several reasons: - It is unlikely anyone cares enough to fix this properly upstream (which is where the bug really is). - The build error only effects building from source on systems that are out of date and will becoming even less common going forward. I am mentioning it at all, because it will help anyone who comes across this error in the future. The same type of error may cause somewhat confusing runtime errors in other packages (bug tracker searches suggest this type of issue has come up before in other packages). The bug: The bug is somewhere in the gf2x build scripts src/config/acinclude.m4 or src/configure somehow it decides whether or not the system supports sse2 (look around line 75 of acinclude.m4. It appears to do this by checking if gcc can compile something that uses sse2. It turns out that it can... even if the system you are on cannot. Consequently it tries to build everything with sse2. This causes a problem when it tries to tune itself src/src/tune-lowlevel.pl. Around line 70-78 it tries to run the compiled code. Most of these don't require sse2 really, and so work, some do (mul3t, mul3k, mul3k2) these fail, it then can't pick which one to use, and terminates building. If there are other places in sage where similar sse2 detection is used, but which are not executed at build time (most things are not), then sage will encounter unexpected runtime bugs when pieces of code that can benefit from sse2 are used. The solution: gf2x doesn't require sse2 to work. The easiest way to build it on a system where the above bug is encountered is to modify: spkg-install:38 to become: ./configure --enable-sse2=no --prefix=$SAGE_LOCAL You don't really want to do this in the main branch though, as this slows things down for the 99+% of people who don't have an archaic system they are trying to run sage on. A better solution is to add an if statement at this place and environment variable globally to disable sse2 when it doesn't exist. Alternatively one could invest the time and figure out then fix gf2x build system. - Andrew -- You received this message because you are subscribed to a topic in the Google Groups sage-devel group. To
Re: [sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
I never did figure out how to grab the latest snapshot off the gf2x dev site, I had been working with the tarballs linked in this thread, of which I never tested one that worked (though, I believe we determined which changes would fix the problem). Right now that machine is being tortured by running some long calculations which are making the machine fairly unusable. These should be done sometime tomorrow, I can try to build the latest snapshot then. - Andrew On Fri, Oct 4, 2013 at 1:18 PM, Jean-Pierre Flori jpfl...@gmail.com wrote: It seems I only sent my reply to Emmanuel. So briefly: - Andrew: can you please confirm that the latest tarball provided by Emmanuel is fixed? - if that's the case, I'll open a trac ticket to update the gf2x spkg provided by Sage and it should make its way into Sage 5.12 or 5.13. Best, JP On Friday, October 4, 2013 6:41:19 PM UTC+2, Emmanuel Thomé wrote: could you pleae confirm that the fix I've committed to the gf2x main branch fixes the issue you encounter ? This is a genuine bug which deserves to be fixed, so: - I care about whether my changes correct the issue. - I don't mind creating a bugfix tarball if deemed useful. On the other hand, if you consider the gf2x-1.1 spkg as distributed in sage-5.11 as something immutable you can't change, there's not much I can do. Frankly, you'd be better off replacing the spkg with a really fixed one... E. On Fri, Oct 4, 2013 at 5:55 PM, Robert Campbell rcam...@umbc.edu wrote: The bug appears to be something in gf2x's configure.ac file, but as I know little about writing config scripts it's hard to give advice. In the meantime, here is a simple step-by-step for those who want SAGE-5.11 but have an old pre-SSE2 machine (schools cheapskates like me): 1) Confirm that your machine doesn't have SSE2 - look for the sse2 flag in the /proc/cpuinfo file. 2) Edit the gf2x spkg file: a) copy sage-5.11/spkg/standard/gf2x-**1.1.spkg to a working location b) tar -jxvf gf2x-1.1.spkg c) Edit gf2x-1.1/spkg-install: Edit line 38 to read ./configure --enable-sse2=no --prefix=$SAGE_LOCAL d) tar -jcvf gf2x-1.1.spkg gf2x-1.1 e) move gf2x-1.1.spkg back to its original location in sage-5.11/spkg/standard/. 3) Compile SAGE as usual Most folks in this situation will not want to compile SAGE themselves (it took me 37 hours on my 1.3 GHz Athlon) and it would be nice to have a pre-compiled version available. An easy solution would be a binary from before the bug was introduced (gf2x-1.1 and hence SAGE-5.11), but I don't see that older binary versions are available from sagemath.org. Robert Campbell On Friday, September 20, 2013 9:01:13 AM UTC-4, Andrew Fiori wrote: This is likely a build error bug on all systems which do not support SSE2 but where building is done using the current version of gcc. It may also manifest as a runtime error on binary builds installed on systems which do not support SSE2 (but I have not tested that). I am submitting this here rather than to bug tracker for several reasons: - It is unlikely anyone cares enough to fix this properly upstream (which is where the bug really is). - The build error only effects building from source on systems that are out of date and will becoming even less common going forward. I am mentioning it at all, because it will help anyone who comes across this error in the future. The same type of error may cause somewhat confusing runtime errors in other packages (bug tracker searches suggest this type of issue has come up before in other packages). The bug: The bug is somewhere in the gf2x build scripts src/config/acinclude.m4 or src/configure somehow it decides whether or not the system supports sse2 (look around line 75 of acinclude.m4. It appears to do this by checking if gcc can compile something that uses sse2. It turns out that it can... even if the system you are on cannot. Consequently it tries to build everything with sse2. This causes a problem when it tries to tune itself src/src/tune-lowlevel.pl. Around line 70-78 it tries to run the compiled code. Most of these don't require sse2 really, and so work, some do (mul3t, mul3k, mul3k2) these fail, it then can't pick which one to use, and terminates building. If there are other places in sage where similar sse2 detection is used, but which are not executed at build time (most things are not), then sage will encounter unexpected runtime bugs when pieces of code that can benefit from sse2 are used. The solution: gf2x doesn't require sse2 to work. The easiest way to build it on a system where the above bug is encountered is to modify: spkg-install:38 to become: ./configure --enable-sse2=no --prefix=$SAGE_LOCAL You don't really want to do this in the main branch though, as this slows things down for the 99+% of people who
Re: [sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
my latest mail, after I checked in the changes which I believe is right, did not include a tar.gz file indeed. Will create one later. E. On Fri, Oct 4, 2013 at 7:50 PM, Andrew Fiori algi...@gmail.com wrote: I never did figure out how to grab the latest snapshot off the gf2x dev site, I had been working with the tarballs linked in this thread, of which I never tested one that worked (though, I believe we determined which changes would fix the problem). Right now that machine is being tortured by running some long calculations which are making the machine fairly unusable. These should be done sometime tomorrow, I can try to build the latest snapshot then. - Andrew On Fri, Oct 4, 2013 at 1:18 PM, Jean-Pierre Flori jpfl...@gmail.com wrote: It seems I only sent my reply to Emmanuel. So briefly: - Andrew: can you please confirm that the latest tarball provided by Emmanuel is fixed? - if that's the case, I'll open a trac ticket to update the gf2x spkg provided by Sage and it should make its way into Sage 5.12 or 5.13. Best, JP On Friday, October 4, 2013 6:41:19 PM UTC+2, Emmanuel Thomé wrote: could you pleae confirm that the fix I've committed to the gf2x main branch fixes the issue you encounter ? This is a genuine bug which deserves to be fixed, so: - I care about whether my changes correct the issue. - I don't mind creating a bugfix tarball if deemed useful. On the other hand, if you consider the gf2x-1.1 spkg as distributed in sage-5.11 as something immutable you can't change, there's not much I can do. Frankly, you'd be better off replacing the spkg with a really fixed one... E. On Fri, Oct 4, 2013 at 5:55 PM, Robert Campbell rcam...@umbc.edu wrote: The bug appears to be something in gf2x's configure.ac file, but as I know little about writing config scripts it's hard to give advice. In the meantime, here is a simple step-by-step for those who want SAGE-5.11 but have an old pre-SSE2 machine (schools cheapskates like me): 1) Confirm that your machine doesn't have SSE2 - look for the sse2 flag in the /proc/cpuinfo file. 2) Edit the gf2x spkg file: a) copy sage-5.11/spkg/standard/gf2x-1.1.spkg to a working location b) tar -jxvf gf2x-1.1.spkg c) Edit gf2x-1.1/spkg-install: Edit line 38 to read ./configure --enable-sse2=no --prefix=$SAGE_LOCAL d) tar -jcvf gf2x-1.1.spkg gf2x-1.1 e) move gf2x-1.1.spkg back to its original location in sage-5.11/spkg/standard/. 3) Compile SAGE as usual Most folks in this situation will not want to compile SAGE themselves (it took me 37 hours on my 1.3 GHz Athlon) and it would be nice to have a pre-compiled version available. An easy solution would be a binary from before the bug was introduced (gf2x-1.1 and hence SAGE-5.11), but I don't see that older binary versions are available from sagemath.org. Robert Campbell On Friday, September 20, 2013 9:01:13 AM UTC-4, Andrew Fiori wrote: This is likely a build error bug on all systems which do not support SSE2 but where building is done using the current version of gcc. It may also manifest as a runtime error on binary builds installed on systems which do not support SSE2 (but I have not tested that). I am submitting this here rather than to bug tracker for several reasons: - It is unlikely anyone cares enough to fix this properly upstream (which is where the bug really is). - The build error only effects building from source on systems that are out of date and will becoming even less common going forward. I am mentioning it at all, because it will help anyone who comes across this error in the future. The same type of error may cause somewhat confusing runtime errors in other packages (bug tracker searches suggest this type of issue has come up before in other packages). The bug: The bug is somewhere in the gf2x build scripts src/config/acinclude.m4 or src/configure somehow it decides whether or not the system supports sse2 (look around line 75 of acinclude.m4. It appears to do this by checking if gcc can compile something that uses sse2. It turns out that it can... even if the system you are on cannot. Consequently it tries to build everything with sse2. This causes a problem when it tries to tune itself src/src/tune-lowlevel.pl. Around line 70-78 it tries to run the compiled code. Most of these don't require sse2 really, and so work, some do (mul3t, mul3k, mul3k2) these fail, it then can't pick which one to use, and terminates building. If there are other places in sage where similar sse2 detection is used, but which are not executed at build time (most things are not), then sage will encounter unexpected runtime bugs when pieces of code that can benefit from sse2 are used. The solution: gf2x doesn't require sse2 to work. The easiest way to build it on a system where the above bug
Re: [sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
On closer inspection, the sse2 test code in:
http://www.loria.fr/~thome/vrac/gf2x-201309240733-4b5636d.tar.gz
the previously linked
http://www.loria.fr/~thome/vracgf2x-201309232352-49027b2.tar.gz
and the code above all compile (gcc -msse2 test.c), however when they are
run the output of:
./a.out || echo $?
is
Illegal instruction (core dumped)
132
However... If I add in the flags that I think you are using -std=gnu99 -g
-O4 -Wall -W, it now compiles and runs.
I am attaching the file that compiles and its object dump.
You may be able to come up with something better that breaks optimization.
For reference the following does, it may be simpler to just drop the
optimization flags for the purpose of the system testing (since there could
in principle be other tests going on that also silently pass when they
should fail).
#include stdlib.h
#include emmintrin.h
#include stdio.h
__v2di x; /* Our code currently uses these, but it should not */
int main() {
__m128i foo = _mm_setr_epi32(rand(), rand(), rand(), rand());
__m128i bar = _mm_setr_epi32(rand(), 0x26622626, 0xabbabbab,
0xfeed1664);
foo = _mm_mullo_epi16(foo, bar);
if( _mm_extract_epi16(foo, 0) )
{
printf(XX);
return 0;
}
else
{
printf(YY);
return _mm_extract_epi16(foo, 0);
}
}
- Andrew
On Tue, Sep 24, 2013 at 1:44 AM, Emmanuel Thomé emmanuel.th...@gmail.comwrote:
On Tuesday, September 24, 2013 2:41:58 AM UTC+2, Andrew Fiori wrote:
The linked tar.gz file doesn't appear to fix the problem (I am assuming
this is what you wanted me to test).
It still tries to compile with sse2 on the non-sse 2 machine
I am attaching the config.log as well as the output from both make and
make tune-lowlevel.
ok ; It seems that optimization got me.
Please try again with the repository tip, or
http://www.loria.fr/~thome/vrac/gf2x-201309240733-4b5636d.tar.gz
E.
--
You received this message because you are subscribed to a topic in the
Google Groups sage-devel group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sage-devel/Cp1lDMzyCrU/unsubscribe.
To unsubscribe from this group and all its topics, 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.
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.
For more options, visit https://groups.google.com/groups/opt_out.
./a.out: file format elf32-i386
Disassembly of section .init:
08048294 _init:
8048294: 53 push %ebx
8048295: 83 ec 08sub$0x8,%esp
8048298: e8 00 00 00 00 call 804829d _init+0x9
804829d: 5b pop%ebx
804829e: 81 c3 57 1d 00 00 add$0x1d57,%ebx
80482a4: 8b 83 fc ff ff ff mov-0x4(%ebx),%eax
80482aa: 85 c0 test %eax,%eax
80482ac: 74 05 je 80482b3 _init+0x1f
80482ae: e8 2d 00 00 00 call 80482e0 __gmon_start__@plt
80482b3: e8 e8 00 00 00 call 80483a0 frame_dummy
80482b8: e8 93 01 00 00 call 8048450 __do_global_ctors_aux
80482bd: 83 c4 08add$0x8,%esp
80482c0: 5b pop%ebx
80482c1: c3 ret
Disassembly of section .plt:
080482d0 __gmon_start__@plt-0x10:
80482d0: ff 35 f8 9f 04 08 pushl 0x8049ff8
80482d6: ff 25 fc 9f 04 08 jmp*0x8049ffc
80482dc: 00 00 add%al,(%eax)
...
080482e0 __gmon_start__@plt:
80482e0: ff 25 00 a0 04 08 jmp*0x804a000
80482e6: 68 00 00 00 00 push $0x0
80482eb: e9 e0 ff ff ff jmp80482d0 _init+0x3c
080482f0 __libc_start_main@plt:
80482f0: ff 25 04 a0 04 08 jmp*0x804a004
80482f6: 68 08 00 00 00 push $0x8
80482fb: e9 d0 ff ff ff jmp80482d0 _init+0x3c
Disassembly of section .text:
08048300 main:
8048300: 55 push %ebp
8048301: b8 00 b2 00 00 mov$0xb200,%eax
8048306: 89 e5 mov%esp,%ebp
8048308: 83 e4 f0and$0xfff0,%esp
804830b: c9 leave
804830c: c3 ret
804830d: 90 nop
804830e: 90 nop
804830f: 90 nop
08048310
Re: [sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
You're right about rand(). printf() does not matter here, as using the
computed value via the return code of main() suffices to use the value as
far as optimization is concerned.
Checked in a new test.
E.
On Tue, Sep 24, 2013 at 10:55 AM, Andrew Fiori algi...@gmail.com wrote:
On closer inspection, the sse2 test code in:
http://www.loria.fr/~thome/vrac/gf2x-201309240733-4b5636d.tar.gz
the previously linked
http://www.loria.fr/~thome/vracgf2x-201309232352-49027b2.tar.gz
and the code above all compile (gcc -msse2 test.c), however when they are
run the output of:
./a.out || echo $?
is
Illegal instruction (core dumped)
132
However... If I add in the flags that I think you are using -std=gnu99 -g
-O4 -Wall -W, it now compiles and runs.
I am attaching the file that compiles and its object dump.
You may be able to come up with something better that breaks optimization.
For reference the following does, it may be simpler to just drop the
optimization flags for the purpose of the system testing (since there could
in principle be other tests going on that also silently pass when they
should fail).
#include stdlib.h
#include emmintrin.h
#include stdio.h
__v2di x; /* Our code currently uses these, but it should not */
int main() {
__m128i foo = _mm_setr_epi32(rand(), rand(), rand(), rand());
__m128i bar = _mm_setr_epi32(rand(), 0x26622626, 0xabbabbab,
0xfeed1664);
foo = _mm_mullo_epi16(foo, bar);
if( _mm_extract_epi16(foo, 0) )
{
printf(XX);
return 0;
}
else
{
printf(YY);
return _mm_extract_epi16(foo, 0);
}
}
- Andrew
On Tue, Sep 24, 2013 at 1:44 AM, Emmanuel Thomé
emmanuel.th...@gmail.comwrote:
On Tuesday, September 24, 2013 2:41:58 AM UTC+2, Andrew Fiori wrote:
The linked tar.gz file doesn't appear to fix the problem (I am assuming
this is what you wanted me to test).
It still tries to compile with sse2 on the non-sse 2 machine
I am attaching the config.log as well as the output from both make and
make tune-lowlevel.
ok ; It seems that optimization got me.
Please try again with the repository tip, or
http://www.loria.fr/~thome/vrac/gf2x-201309240733-4b5636d.tar.gz
E.
--
You received this message because you are subscribed to a topic in the
Google Groups sage-devel group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sage-devel/Cp1lDMzyCrU/unsubscribe.
To unsubscribe from this group and all its topics, 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.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups sage-devel group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/sage-devel/Cp1lDMzyCrU/unsubscribe.
To unsubscribe from this group and all its topics, 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.
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.
For more options, visit https://groups.google.com/groups/opt_out.
