[sage-devel] Re: Cython and Python signal
On May 12, 6:50 pm, leif wrote: > With Sage 5.10.beta1, (the custom SIGALRM handler gets called as > expected and) I get a traceback, but only after much more than 10 > seconds -- I'd say exactly *after* maxima_eval() returned [normally], > which is (almost) the same behaviour as with factor() using the PARI > library. Confirmed. Never mind. -- 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: Cython and Python signal
Nils Bruin wrote: Incidentally, note: sage: alarm(10); integrate(cos(x*sin(x)^10),x) KeyboardInterrupt: computation timed out because alarm was set for 10 seconds so somehow the SIGALRM gets reacted on properly by ECL (which has its own signal handler) and somehow the condition arrives in its proper state in Python as well, so that Python gets a turn at running the registered signal handlers. -- | Sage Version 5.8, Release Date: 2013-03-15 | | Type "notebook()" for the browser-based notebook interface.| | Type "help()" for help.| -- sage: alarm(10); integrate(cos(x*sin(x)^10),x) /usr/local/bin/sage: line 140: 30247 Segmentation fault "$SAGE_ROOT/spkg/bin/sage" "$@" :-) With Sage 5.10.beta1, (the custom SIGALRM handler gets called as expected and) I get a traceback, but only after much more than 10 seconds -- I'd say exactly *after* maxima_eval() returned [normally], which is (almost) the same behaviour as with factor() using the PARI library. -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: Cython and Python signal
On May 12, 4:17 pm, leif wrote: > It doesn't seem Python would execute *any* code of the custom (Python) > handler (as opposed to just deferring the raise KeyboardInterrupt or > what follows it) before the Cython function returns by other means. Looking at the Python code base (and using common sense), I don't think Python ever executes any python interpreter code *in the signal handler*. Rather, the "signal occurred" information gets stored and next time the interpreter gets around to it, all routines registered with the relevant signal get executed, by then in the normal execution context. This still happens now as well: When the alarm arrives, the right data gets set. If, in addition, a SIGINT arrives inside a sigon/sigoff, the cython routine exits under exception conditions. However, as you see from the message that gets processed, the signal condition is checked by python before the exception condition and the signal handler code gets executed and raises a KeyboardInterrupt with a custom message, and that's the one that arrives. So, one mode of operation would be: Inside a sigon/sigoff, set the usual Python "signal occurred" information. Furthermore, raise (as usual) an exception at the outermost "sigon" active. That exception only serves the purpose as a short path to the closes Python interpreter, which will process the "signal occurred" information. This would work slightly differently from the current sigon/sigoff processing for SIGINT, which raises an exception but does not call PyErr_SetInterrupt(), so presently, the signal gets processed as an exception, not via Python's signal handling. Incidentally, note: sage: alarm(10); integrate(cos(x*sin(x)^10),x) KeyboardInterrupt: computation timed out because alarm was set for 10 seconds so somehow the SIGALRM gets reacted on properly by ECL (which has its own signal handler) and somehow the condition arrives in its proper state in Python as well, so that Python gets a turn at running the registered signal handlers. Cheers, Nils -- 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: Cython and Python signal
Nils Bruin wrote: Probably more importantly, the signal handler that misc.alarm installs is: def __mysig(a,b): raise KeyboardInterrupt, "computation timed out because alarm was set for %s seconds"%__alarm_time Given that installing this handler delays the handling of the SIGALRM, I guess what happens is the normal thing in python exception handlers: Some flags get set to remember that a signal has occurred and the next time the interpreter sees fit to check, the signal gets handled (by the routine that Of course, when this happens during a long computation in the PARI library, one can wait a LONG time before the flag gets checked. It doesn't seem Python would execute *any* code of the custom (Python) handler (as opposed to just deferring the raise KeyboardInterrupt or what follows it) before the Cython function returns by other means. The sig_on/sig_off aware signal handlers that get installed on SIGINT etc. (but not on SIGALRM!) handle things differently. If we want SIGALRM to be handled similarly to SIGINT when activated, we should probably make the code in interrupt.c aware of a flag of some sort that enables trapping/acting on SIGALRM. Well, there are certainly also other use cases of signal.alarm() (or more generally, SIGALRM) than aborting some computation, so while we might (easily, I think) implement some abort_next_computation_if_it_doesnt_finish_within(), also working with Cython functions (or foreign functions they call), this could badly (and presumably rather unexpectedly) interfere with user code (or, perhaps less problematic, other libraries used). So at the very least, we should not /unconditionally/ treat SIGALRM as if it was SIGINT. In the meantime, the documentation of sage.misc.misc.alarm() should probably get clarified, perhaps hinting at @fork as well. -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] Binaries for Solaris and Cygwin
On Sunday, May 12, 2013 9:41:06 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Sunday, May 12, 2013 8:33:44 PM UTC+1, Jeroen Demeyer wrote: >> >> On 05/12/2013 03:27 PM, Jean-Pierre Flori wrote: >> > Dear all, >> > >> > I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: >> > * http://boxen.math.washington.edu/home/jpflori/dist/ >> >> Any chance for a Cygwin buildbot? That would be very cool. >> > Not on my side unfortunately (this one was built inside a VM running on my > personal laptop...) > Maybe William would agree to install such VMs on the sage cluster? -- 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: recompilation with "sage -clone"
leif wrote:
leif wrote:
Eric Gourgoulhon wrote:
I confirm this behavior on a fresh install of version 5.9 from the
sources: sage -clone triggers the recompilation of the Cython sources.
In version 5.8, it did not. Don't know the reason for this...
For the impatient, the following at least avoids rebuilding of (most of
the) Cython-generated files:
diff --git a/sage-clone b/sage-clone
--- a/sage-clone
+++ b/sage-clone
@@ -53,6 +53,10 @@
cpdir(os.path.abspath('sage/sage'), os.path.abspath(branch + '/sage'))
+if os.path.isfile('sage/.cython_version'):
+print "Copying over hidden Cython version file..."
+os.link('sage/.cython_version', branch+'/.cython_version')
+
def copy_dtree(src_dir, dest_dir):
src_root = os.path.abspath(src_dir)
dest_root = os.path.abspath(dest_dir)
It seems the interpreters for "fast_callable" get regenerated (and hence
also re-"cythonized") because sage-clone does not (or no longer)
properly copy devel/sage/sage/ext/interpreters/timestamp either:
Building interpreters for fast_callable
Updating Cython code
Building sage/plot/plot3d/parametric_surface.pyx because it depends on
sage/ext/interpreters/wrapper_rdf.pxd.
Building modified file sage/ext/interpreters/wrapper_rdf.pyx.
Building modified file sage/ext/interpreters/wrapper_cdf.pyx.
Building modified file sage/ext/interpreters/wrapper_rr.pyx.
Building modified file sage/ext/interpreters/wrapper_py.pyx.
Building modified file sage/ext/interpreters/wrapper_el.pyx.
...
(This is what I meant by "avoids rebuilding of /most of/ the
Cython-generated code".)
-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] Binaries for Solaris and Cygwin
On Sunday, May 12, 2013 8:33:44 PM UTC+1, Jeroen Demeyer wrote: > > On 05/12/2013 03:27 PM, Jean-Pierre Flori wrote: > > Dear all, > > > > I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: > > * http://boxen.math.washington.edu/home/jpflori/dist/ > > Any chance for a Cygwin buildbot? That would be very cool. > Not on my side unfortunately (this one was built inside a VM running on my personal laptop...) -- 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: Optional package requiring recent gcc
Hi Leif,
On 2013-05-12, leif wrote:
>> And it is the programs of David Green which don't work with old gcc and
>> high optimization. So, before processing the Cython code, I could simply
>> call David's programs; if they work without error, then apparently the
>> gcc version was fine.
>>
>> Would this be a valid approach?
>
> If that doesn't add an overhead of days to the overall build time... Sure.
Building these programs is less than a minute (and has to be done anyway),
testing it should be less than a second. The overall build time is more
like 5 to 10 minutes, but most of the time would come *after* the test.
> [And it shouldn't leave crap / a partial install in the Sage
> installation, i.e., $SAGE_ROOT/{local,data}/*, in case the check fails.]
Indeed, the programs would create data on disk, and it relies on the
contents of some other file on disk. However, a test case would be
really small and would probably add less than 200 Byte to the spkg.
And the itt could all happen in the build directory. This would usually be
deleted after an installation attempt, isn't it? So, it would vanish,
regardless whether the check fails or not.
It sounds like I should try it.
Best regards,
Simon
--
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: Optional package requiring recent gcc
leif wrote:
Simon King wrote:
I'm just thinking: Perhaps one could check the result rather than the
gcc version?
My spkg first builds a patched version of C-MeatAxe (for linear algebra
over finite fields) and then some programs of David Green (which use
C-MeatAxe, and I wouldn't like to rewrite them to use Linbox...); this
works pretty fast. After that, my Cython code gets processed, and this
takes some time.
And it is the programs of David Green which don't work with old gcc and
high optimization. So, before processing the Cython code, I could simply
call David's programs; if they work without error, then apparently the
gcc version was fine.
You could probably even add such a check to the Makefile for his
programs; haven't yet looked at your spkg at all...
-leif
Would this be a valid approach?
If that doesn't add an overhead of days to the overall build time... Sure.
[And it shouldn't leave crap / a partial install in the Sage
installation, i.e., $SAGE_ROOT/{local,data}/*, in case the check fails.]
-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: Optional package requiring recent gcc
Simon King wrote:
I'm just thinking: Perhaps one could check the result rather than the
gcc version?
My spkg first builds a patched version of C-MeatAxe (for linear algebra
over finite fields) and then some programs of David Green (which use
C-MeatAxe, and I wouldn't like to rewrite them to use Linbox...); this
works pretty fast. After that, my Cython code gets processed, and this
takes some time.
And it is the programs of David Green which don't work with old gcc and
high optimization. So, before processing the Cython code, I could simply
call David's programs; if they work without error, then apparently the
gcc version was fine.
Would this be a valid approach?
If that doesn't add an overhead of days to the overall build time... Sure.
[And it shouldn't leave crap / a partial install in the Sage
installation, i.e., $SAGE_ROOT/{local,data}/*, in case the check fails.]
-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: Optional package requiring recent gcc
Hi Leif, On 2013-05-12, leif wrote: > In shell scripts (including spkg-install files), we usually just use > something like > > case `$CC -dumpversion 2>/dev/null` in > 4.[01].*) > # Usually spoiled apples > ;; I'm just thinking: Perhaps one could check the result rather than the gcc version? My spkg first builds a patched version of C-MeatAxe (for linear algebra over finite fields) and then some programs of David Green (which use C-MeatAxe, and I wouldn't like to rewrite them to use Linbox...); this works pretty fast. After that, my Cython code gets processed, and this takes some time. And it is the programs of David Green which don't work with old gcc and high optimization. So, before processing the Cython code, I could simply call David's programs; if they work without error, then apparently the gcc version was fine. Would this be a valid approach? Best regards, Simon -- 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] Binaries for Solaris and Cygwin
On 05/12/2013 03:27 PM, Jean-Pierre Flori wrote: Dear all, I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: * http://boxen.math.washington.edu/home/jpflori/dist/ Any chance for a Cygwin buildbot? That would be very cool. -- 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: Optional package requiring recent gcc
Simon King wrote: I guess there is some script in Sage that tests the available version of GCC (called when you type "make" in SAGE_ROOT). There's only a (partially broken) script for testing whether $CC /is/ GCC (or SunCC etc.), and another one for testing whether $CC supports / accepts specific options. In shell scripts (including spkg-install files), we usually just use something like case `$CC -dumpversion 2>/dev/null` in 4.[01].*) # Usually spoiled apples ;; 4.4.5*) # Probably from Debian Squeeze's default GCC4 package ;; 4.2.0|4.5.0|4.6.0) # Pretty broken... ;; 4.7*|4.8.0) # Good. ;; *) # Something else esac [The version numbers don't mean much here, there're just to give an example.] -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: Optional package requiring recent gcc
Simon King wrote: In a few months, Debian's GCC 4.4.5 will hopefully have vanished... ;-) I love when problems disappear into thin air :-) You mean space [1]? XD [Unfortunately, some race condition happened in concurrent posting...] -leif [1] http://www.golem.de/news/internationale-raumstation-astronauten-surfen-mit-debian-squeeze-1305-99176.html -- () 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: Optional package requiring recent gcc
Simon King wrote: On 2013-05-12, leif wrote: I wouldn't be too concerned with /optional/ spkgs and a few broken (in this case no longer maintained, 4.4.6 was the last bugfix release IIRC) compiler versions -- unless this may silently lead to wrong results perhaps. Does the /build/ fail with Debian's GCC 4.4.5, or some test suite of your spkg? In this optimization level and with a too old gcc, one sub-program that is computing basic data for the cohomology computations simply won't run. So, it does not give wrong results, it gives no result whatsoever. I probably should have added I was a bit worried because http://www.golem.de/news/internationale-raumstation-astronauten-surfen-mit-debian-squeeze-1305-99176.html -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: Optional package requiring recent gcc
Hi Leif, On 2013-05-12, leif wrote: > Good. (Does it terminate [with an error]?) Yes, but not very informative (it says that the Gap command MakeThisSmallGroup does not work, and since this Gap command is only defined by the spkg, the user won't know what it means). > I'd say no (it isn't required), but would issuing a quick (and dirty) > pN+1 be such of an effort? Probably not. I guess there is some script in Sage that tests the available version of GCC (called when you type "make" in SAGE_ROOT). > In a few months, Debian's GCC 4.4.5 will hopefully have vanished... ;-) I love when problems disappear into thin air :-) Cheers, Simon -- 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: Binaries for Solaris and Cygwin
On Sunday, May 12, 2013 5:34:52 PM UTC+1, leif wrote: > > Jean-Pierre Flori wrote: > > Dear all, > > > > I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: > > * http://boxen.math.washington.edu/home/jpflori/dist/ > > > > They were generated as follows: > > * export SAGE_FAT_BINARIES=yes > > Although AFAIK this only really matters (or works) on x86/x86_64, it > should be SAGE_FAT_BINARY=yes, but the typo is probably just in your > post... ;-) > Yes indeed. > > > * make > > Depending on the default target of the compiler(s) used, you may have > set C/CPP/CXX/F/FCFLAGS to use some "generic" -march/-mcpu etc. in > addition. > > I thought about that and then thought it might not work for every spkg so just exported nothing :) > > * ./sage -bdist 5.9 > > --bdist !!! > I'd say -bdist, although --bdist (which is better in my opinion) works as well! This cam to my mind when i was writin this post so I typed ./sage --advanced (or was it -advanced?) and wrote what it suggested: -bdist... > > > Not sure this is sufficient to get something running on a wide variety > > of hardware. > > Unless they're mostly broken on a wide variety of machines (and we get > lots of complaints), presumably better than having nothing, especially > on Cygwin I guess. > > > > Feel free to test or even use them, I can not guarantee anything is > > actualy working right (but at least sage computes 1+1 and returns 2). > > Hopefully not in GF(2). > > Although that wouldn't be that wrong I guess. > > -leif > > > Note that for Cygwin you will still need to install Cygwin itself and > > the system-wide lapack packages; it might also need a rebase depending > > on what your Cygwin install already includes. > > > > Best, > > JP > > -- > () 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: Optional package requiring recent gcc
Simon King wrote: Is the new package version already put into the repository of optional packages? AFAICS the version on sagemath.org is still p_group_cohomology-2.1.3. (You can 'wget -q --no-cache -O - sagemath.org/packages/optional/list | grep p_group', alternatively 'sage --optional | grep p_group_cohomology'.) -leif P.S.: The new spkg is here: http://sage.math.washington.edu/home/SimonKing/Cohomology/p_group_cohomology-2.1.4.spkg Ticket: http://trac.sagemath.org/sage_trac/ticket/14492 -- () 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: Optional package requiring recent gcc
Simon King wrote: On 2013-05-12, leif wrote: I wouldn't be too concerned with /optional/ spkgs and a few broken (in this case no longer maintained, 4.4.6 was the last bugfix release IIRC) compiler versions -- unless this may silently lead to wrong results perhaps. Does the /build/ fail with Debian's GCC 4.4.5, or some test suite of your spkg? In this optimization level and with a too old gcc, one sub-program that is computing basic data for the cohomology computations simply won't run. So, it does not give wrong results, it gives no result whatsoever. Good. (Does it terminate [with an error]?) If it's not too complicated, you could lower the optimization level depending on the GCC version, or some build option, though. That's the plan. The question is: Can this wait a few months (of course being documented on the project web page), or is it required for an optional pack that this issue is addressed immediately? I'd say no (it isn't required), but would issuing a quick (and dirty) pN+1 be such of an effort? In a few months, Debian's GCC 4.4.5 will hopefully have vanished... ;-) -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: Optional package requiring recent gcc
Hi Leif, On 2013-05-12, leif wrote: > I wouldn't be too concerned with /optional/ spkgs and a few broken (in > this case no longer maintained, 4.4.6 was the last bugfix release IIRC) > compiler versions -- unless this may silently lead to wrong results perhaps. > > Does the /build/ fail with Debian's GCC 4.4.5, or some test suite of > your spkg? In this optimization level and with a too old gcc, one sub-program that is computing basic data for the cohomology computations simply won't run. So, it does not give wrong results, it gives no result whatsoever. > If it's not too complicated, you could lower the optimization level > depending on the GCC version, or some build option, though. That's the plan. The question is: Can this wait a few months (of course being documented on the project web page), or is it required for an optional pack that this issue is addressed immediately? Best regards, Simon -- 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: Binaries for Solaris and Cygwin
Jean-Pierre Flori wrote: Dear all, I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: * http://boxen.math.washington.edu/home/jpflori/dist/ They were generated as follows: * export SAGE_FAT_BINARIES=yes Although AFAIK this only really matters (or works) on x86/x86_64, it should be SAGE_FAT_BINARY=yes, but the typo is probably just in your post... ;-) * make Depending on the default target of the compiler(s) used, you may have set C/CPP/CXX/F/FCFLAGS to use some "generic" -march/-mcpu etc. in addition. * ./sage -bdist 5.9 --bdist !!! Not sure this is sufficient to get something running on a wide variety of hardware. Unless they're mostly broken on a wide variety of machines (and we get lots of complaints), presumably better than having nothing, especially on Cygwin I guess. Feel free to test or even use them, I can not guarantee anything is actualy working right (but at least sage computes 1+1 and returns 2). Hopefully not in GF(2). -leif Note that for Cygwin you will still need to install Cygwin itself and the system-wide lapack packages; it might also need a rebase depending on what your Cygwin install already includes. Best, JP -- () 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: Optional package requiring recent gcc
Simon King wrote: Version 2.1.4 of my optional p_group_cohomology spkg got a positive review a few days ago. Now, I found that it will not correctly build with gcc 4.4.5 (which my university's sysadmins have put on the computer in my office), while it *does* work with Sage's gcc spkg (4.7.2) on the same machine, and also with gcc 4.6.2 on my laptop. Cause of the problem could be an increased optimization level for some part of the C-code. I wouldn't be too concerned with /optional/ spkgs and a few broken (in this case no longer maintained, 4.4.6 was the last bugfix release IIRC) compiler versions -- unless this may silently lead to wrong results perhaps. Does the /build/ fail with Debian's GCC 4.4.5, or some test suite of your spkg? If it's not too complicated, you could lower the optimization level depending on the GCC version, or some build option, though. In any case, documenting the situation shouldn't hurt... ;-) -leif What is to do in such situation? Is it enough to add a warning on the project web page and add a test for the gcc version to spkg-install when the next version of the spkg is ready (in a couple of months)? Or do you think the test should be added right now? Is the new package version already put into the repository of optional packages? Best regards, Simon -- () 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] Functions returning
One possibility would be to wrap the call to .n() in a try-except block. David On Sun, May 12, 2013 at 7:03 AM, wrote: > I think there is a conceptual problem with function returning s. > > Consider the following: > > def find_roots( func,l,r ): > tol = 1e-10 > try: > result = find_root( func,l,r ) ) > except RuntimeError: > return [] > return find_roots( func,l,result-tol )+[ result ]+find_roots( > func,result+tol,r ) > > Ignoring, for the moment, that find_root returns a , too (and > therefore is a problem by itsself). > > If "func" is a function which does not automatically evaluate to a > number (where only evalf_func evaluates), we need to write > > [...] find_root( lambda x: func.n( x ),l,r ) > > instead, because otherwise find_root crashes. But then, this doesn't > work if func returns a , because float has no .n( ). > > So what's the solution to this dilemma? I think this is only permanently > solved by making sure functions generally return a Sage-type > > -- > 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: All variables vanish
On May 12, 5:29 am, man...@gmx.net wrote: > This happens reproducibly. plot( ) evaluates to nothing (no output, etc) > and afterwards, the workspace seems to be emptied of everything that was > defined. That means that the sage worker process servicing your plot crashed and died. The notebook unfortunately doesn't report that that happens; it simply restarts the worker process (losing all definitions in the process, of course). Run your example on the command line if you want to see and debug what exactly crashes. -- 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: Binaries for Solaris and Cygwin
On Sunday, May 12, 2013 2:27:16 PM UTC+1, Jean-Pierre Flori wrote: > > Dear all, > > I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: > * http://boxen.math.washington.edu/home/jpflori/dist/ > > They were generated as follows: > * export SAGE_FAT_BINARIES=yes > * make > * ./sage -bdist 5.9 > Not sure this is sufficient to get something running on a wide variety of > hardware. > > Feel free to test or even use them, I can not guarantee anything is > actualy working right (but at least sage computes 1+1 and returns 2). > Note that for Cygwin you will still need to install Cygwin itself and the > system-wide lapack packages; it might also need a rebase depending on what > your Cygwin install already includes. > > Best, > JP > I should surely have posted that to sage-release but it's just too late. -- 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] Binaries for Solaris and Cygwin
Dear all, I've put binaries of Sage 5.9 for Solaris (10)/sparc and Cygwin at: * http://boxen.math.washington.edu/home/jpflori/dist/ They were generated as follows: * export SAGE_FAT_BINARIES=yes * make * ./sage -bdist 5.9 Not sure this is sufficient to get something running on a wide variety of hardware. Feel free to test or even use them, I can not guarantee anything is actualy working right (but at least sage computes 1+1 and returns 2). Note that for Cygwin you will still need to install Cygwin itself and the system-wide lapack packages; it might also need a rebase depending on what your Cygwin install already includes. Best, JP -- 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] Functions returning
I think there is a conceptual problem with function returning s. Consider the following: def find_roots( func,l,r ): tol = 1e-10 try: result = find_root( func,l,r ) ) except RuntimeError: return [] return find_roots( func,l,result-tol )+[ result ]+find_roots( func,result+tol,r ) Ignoring, for the moment, that find_root returns a , too (and therefore is a problem by itsself). If "func" is a function which does not automatically evaluate to a number (where only evalf_func evaluates), we need to write [...] find_root( lambda x: func.n( x ),l,r ) instead, because otherwise find_root crashes. But then, this doesn't work if func returns a , because float has no .n( ). So what's the solution to this dilemma? I think this is only permanently solved by making sure functions generally return a Sage-type -- 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] All variables vanish
Please have a look at this, is there any reasonable explanation for the output of the few last cells? http://alpha.sagenb.org/home/pub/700/ This happens reproducibly. plot( ) evaluates to nothing (no output, etc) and afterwards, the workspace seems to be emptied of everything that was defined. -- 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] Cython and Python signal
Short answer: SIGALRM doesn't use the standard csage interrupt handling, therefore it doesn't work in Cython code: http://trac.sagemath.org/sage_trac/ticket/13311 -- 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: Cython and Python signal
On May 11, 9:44 pm, William Stein wrote:
> By the way, the alarm function in Sage uses Python's "signal.alarm",
> whose source code is this:
>
> static PyObject *
> signal_alarm(PyObject *self, PyObject *args)
> {
> int t;
> if (!PyArg_ParseTuple(args, "i:alarm", &t))
> return NULL;
> /* alarm() returns the number of seconds remaining */
> return PyInt_FromLong((long)alarm(t));
Probably more importantly, the signal handler that misc.alarm installs
is:
def __mysig(a,b):
raise KeyboardInterrupt, "computation timed out because alarm was
set for %s seconds"%__alarm_time
Given that installing this handler delays the handling of the SIGALRM,
I guess what happens is the normal thing in python exception handlers:
Some flags get set to remember that a signal has occurred and the next
time the interpreter sees fit to check, the signal gets handled (by
the routine that Of course, when this happens during a long
computation in the PARI library, one can wait a LONG time before the
flag gets checked.
The sig_on/sig_off aware signal handlers that get installed on SIGINT
etc. (but not on SIGALRM!) handle things differently. If we want
SIGALRM to be handled similarly to SIGINT when activated, we should
probably make the code in interrupt.c aware of a flag of some sort
that enables trapping/acting on SIGALRM.
--
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.
