You could just use call from the Python subprocess module, which is
documented in the Python docs. It depends on exactly what functionality
you need from Sage.
David
On Fri, Mar 29, 2013 at 12:58 AM, tom d <sdent...@gmail.com> wrote:
> Ok, the patch maybe works. Sage starts normally after patching, but I'm
> getting a segfault from the django process when I try to load a webpage, so
> not sure what that's about....
>
> Is there documentation or good examples somewhere on how to use Sage as a
> subprocess?
>
>
> On Friday, March 29, 2013 10:23:10 AM UTC+3, tom d wrote:
>>
>> Cool, I'll give the patch a shot. It looks like some other projects have
>> a variable or option for disabling interrupts for exactly this reason; if a
>> patch works, it might make sense to do signals optionally in Sage.
>>
>> I'm trying to import the sage libraries into some Django code. I'm
>> playing with getting a sage-enabled web-framework, which would allow me to
>> do lots and lots of Sage-things in a webpage using a local installation of
>> Sage directly, instead of passing through the cell server, for example.
>> Django has a server which builds up the webpages that you ask for. Then,
>> in the code that generates a webpage, I'm doing a 'from sage.all import *'
>> to give access to the Sage libraries. If a subprocess is a better way to
>> do that, I should look into it...
>>
>> Thanks for the quick response!
>>
>> On Friday, March 29, 2013 10:02:25 AM UTC+3, Jeroen Demeyer wrote:
>>>
>>> On 03/28/2013 11:44 PM, tom d wrote:
>>> > The problem seems to be at:
>>> > from sage.ext.c_lib import _init_csage, sig_on_count
>>> > _init_csage()
>>> > which is explicitly using the signal library and doing signal handling
>>> > stuff for Sage. Any idea how deep this goes? Some of the online
>>> > suggestions are about using some different libraries for signal
>>> > handling, which might be a bit more sensitive about whether Sage is
>>> the
>>> > main process or not.
>>> You could completely disable the Sage signal handler, I guess the
>>> following patch would do it (NOT TESTED!)
>>>
>>> diff --git a/c_lib/src/stdsage.c b/c_lib/src/stdsage.c
>>> --- a/c_lib/src/stdsage.c
>>> +++ b/c_lib/src/stdsage.c
>>> @@ -48,7 +48,6 @@
>>> void init_csage() {
>>> init_global_empty_tuple();
>>> init_memory_functions();
>>> - setup_sage_signal_handler();
>>> setup_NTL_error_callback(**global_NTL_error_callback, NULL);
>>> }
>>>
>>> diff --git a/sage/ext/c_lib.pyx b/sage/ext/c_lib.pyx
>>> --- a/sage/ext/c_lib.pyx
>>> +++ b/sage/ext/c_lib.pyx
>>> @@ -37,8 +37,6 @@
>>> # call its interrupt handler (which is the one we set now). This
>>> # handler issues a sig_check() which finally raises the
>>> # KeyboardInterrupt exception.
>>> - import signal
>>> - signal.signal(signal.SIGINT, sage_python_check_interrupt)
>>>
>>> init_csage()
>>>
>>>
>>>
>>> But seriously: why are you trying to run Django and Sage in the same
>>> process? That seems like asking for trouble. Couldn't you run a Sage
>>> subprocess?
>>>
>> --
> 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.
