[sage-devel] Build Error in gf2x package on AMD Athlon XP 2600+
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 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.
[sage-devel] broken prompts in Emacs shell-mode
In an Emacs shell, Sage seems to be ignoring the TERM setting (dumb) and sending ANSI escape sequences to the terminal around the sage: prompt. [pippin:~] wjanssen% printenv TERM dumb [pippin:~] wjanssen% /local/sage-5.11/sage ++ | Sage Version 5.11, Release Date: 2013-08-13| | Type notebook() for the browser-based notebook interface.| | Type help() for help.| ++ [0;34msage: [0m Is there a way to defeat this? Should I file a bug on this? Bill -- 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.
[sage-devel] Re: Build Error in gf2x package on AMD Athlon XP 2600+
Hey, I think you should report this to the gf2x dev as well... you never know. I've CC'ed Paul Zimmermann in case he cares. Best, JP On Friday, September 20, 2013 3:01:13 PM UTC+2, 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 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.
Re: [sage-devel] broken prompts in Emacs shell-mode
Hi, What happens if you run straight ipython? sage -ipython If the problem is the same, you could ask on the ipython list... (since sage's command line is ipython). William On Fri, Sep 20, 2013 at 10:54 AM, Bill Janssen bill.jans...@gmail.com wrote: In an Emacs shell, Sage seems to be ignoring the TERM setting (dumb) and sending ANSI escape sequences to the terminal around the sage: prompt. [pippin:~] wjanssen% printenv TERM dumb [pippin:~] wjanssen% /local/sage-5.11/sage ++ | Sage Version 5.11, Release Date: 2013-08-13| | Type notebook() for the browser-based notebook interface.| | Type help() for help.| ++ [0;34msage: [0m Is there a way to defeat this? Should I file a bug on this? Bill -- 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. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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.
Re: [sage-devel] Re: Deprecation of %load
The main thing that's bugging me, actually, is the discrepancy between notebook and command line. On the command line: %runfile /path/to/myfile.sage In the notebook: load /path/to/myfile.sage Note the absence of the %. And neither of these options will work in the other environment. -- 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.
Re: [sage-devel] broken prompts in Emacs shell-mode
On Friday, September 20, 2013 11:12:37 AM UTC-7, William wrote: If the problem is the same, you could ask on the ipython list... (since sage's command line is ipython). William It is. I don't think IPython's prompt configuration looks at the environment TERM at all. It's fully configurable, though, so you can make it do that. Perhaps start with %config PromptManager and take it from there. -- 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.
