On Sat, Aug 22, 2009 at 2:13 PM, Juanjo < juanjose.garciarip...@googlemail.com> wrote:
> > On Aug 22, 9:12 pm, Nils Bruin <nbr...@sfu.ca> wrote: > > On Aug 22, 2:23 am, Juanjo <juanjose.garciarip...@googlemail.com> > > wrote: > > > > > A C function can be used to deactivate trapping of signals > > > > Thanks! that is probably a more elegant way. > > There is only one thing that worries me, though. ECL installs its own > signal handlers so that we can quickly disable / enable them without > calling sigaction every time -- a single flag variable and a mmap() is > used as a simple way to delay the signal ---. Sage's own signal > handlers might interfere badly with code that right now is protected > that way in ECL. One possibility would be to teach ECL to further call > previously registered handlers... > > > running cl_shutdown manually doesn't seem to be correlated. I tried > > removing the one atexit() call that appears in the ecl source, but the > > segfault still occurs. The segfault only occurs after sage has printed > > its goodbye message, so it's definitely something in the cleanup > > process and it doesn't really functionally affect anything. A C-level > > debug wizzard would probably find the offence in no-time. > > Hmm, sounds perhaps like cleaning up in the garbage collector. Is it > easy to reproduce your system? I am quite used to debug large pieces > of C code. Nils -- why don't you build everything in your (presumed) account on sage.math.washington.edu? Then you can easily given Juanjo access to that, since he also has an account on sage.math.washington.edu. William > > > > I think browsing your replies to other people's questions solved that > > one (good candidate to include in embedding examples!): > > > > si_safe_eval(3,obj,NIL,NULL) > > > > evaluates obj and returns NULL upon error. It seems that NULL is a > > completely illegal cl_object, so that is sufficient to properly detect > > an error condition. (of course, by now we have completely lost any > > idea of *what* the error was. Or does the "last raised error message" > > get cached somewhere?) > > This is the least sophisticated way to safely evaluate forms. If you > want to keep the errors, then you can cook up a simple evaluation > function in Common Lisp. My example here > > > http://sourceforge.net/mailarchive/message.php?msg_name=c159f9ab0809140803h1cfc3473p17a7b7afb82a4e71%40mail.gmail.com > > can be improved, but it basically intercepts an exception (error or > "condition" in Common Lisp), returning two values in that case. The > second one, ecl_process_env()->values[1] or VALUES(1) would be the > error object, which can be printed, inspected, etc. If that is too > hard to translate for the C-python, it is possible to cook up other > recipies. > > Juanjo > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
