On Sun, Aug 23, 2009 at 1:54 PM, Nils Bruin wrote:
>
>
> On Aug 23, 3:43 am, Juanjo
> wrote:
>> > Concerning signals:
>> ECL does not need to be notified of signals. The important thing is
>> that Sage's code does not interrupt ECL's code at arbitrary places and
>> then transfers control out of t
On Aug 23, 3:43 am, Juanjo
wrote:
> > Concerning signals:
> ECL does not need to be notified of signals. The important thing is
> that Sage's code does not interrupt ECL's code at arbitrary places and
> then transfers control out of them.
>
> For instance, interrupts during memory allocation are
On Aug 23, 9:14 am, Nils Bruin wrote:
> So it's no surprise at all that integer_free_integer_pool seems to
> call ecl_dealloc, because it does (via some gmp macro for deallocating
> a gmp integer), and since that integer was allocated by another memory
> manager, a segfault is entirely expected.
On Aug 22, 2:16 pm, William Stein wrote:
> 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.
Done. The following is now available on sage.
On Sat, Aug 22, 2009 at 4:32 PM, Nick Alexander wrote:
>
> William, I don't mean to pick on you; this is a generic "please quote
> appropriately" message.
Well, in the interest of netiquette, I think you should post these directly
to the person you're complaining to or on sage-flame, instead of
William, I don't mean to pick on you; this is a generic "please quote
appropriately" message.
I am going to start replying to messages that don't quote with good
netiquette. This is a two line reply. Please just leave a few lines
of direct context, then reply:
[ pages of text deleted, be
On Aug 22, 2009, at 12:12 PM, Nils Bruin wrote:
>
> On Aug 22, 2:23 am, Juanjo
> wrote:
>
>> A C function can be used to deactivate trapping of signals
>
> Thanks! that is probably a more elegant way. I found the POSIX
> "sigaction" which allows signal handlers to be read and set. Bracing
> cl_b
On Sat, Aug 22, 2009 at 2:13 PM, Juanjo <
juanjose.garciarip...@googlemail.com> wrote:
>
> On Aug 22, 9:12 pm, Nils Bruin wrote:
> > On Aug 22, 2:23 am, Juanjo
> > wrote:
> >
> > > A C function can be used to deactivate trapping of signals
> >
> > Thanks! that is probably a more elegant way.
>
>
On Aug 22, 9:12 pm, Nils Bruin wrote:
> On Aug 22, 2:23 am, Juanjo
> 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 quic
On Aug 22, 2:23 am, Juanjo
wrote:
> A C function can be used to deactivate trapping of signals
Thanks! that is probably a more elegant way. I found the POSIX
"sigaction" which allows signal handlers to be read and set. Bracing
cl_boot between an appropriate amount of those seems to do the trick
On Aug 22, 2:23 am, Nils Bruin wrote:
> 1. Signal handler collision between sage and ecl
A C function can be used to deactivate trapping of signals
http://ecls.sourceforge.net/new-manual/re37.html#table.boot_options
> 2. sage segfaults upon exit if ecl has run
Run cl_shutdown() manually bef
On Fri, 21 Aug 2009, Nils Bruin wrote:
>
> Maxima can indeed be coerced into behaving like a library in ECL. The
> changes required are relatively small and it would be easy to
> incorporate them into the current spkg. I haven't bothered, since
> other people are already working on a new maxima.
Maxima can indeed be coerced into behaving like a library in ECL. The
changes required are relatively small and it would be easy to
incorporate them into the current spkg. I haven't bothered, since
other people are already working on a new maxima. Details posted on:
http://trac.sagemath.org/sage_
On Aug 21, 2:27 am, Juanjo
wrote:
> [...] ecl_register_root is only scarcely
> used, and only for static variables. If you keep references to objects
> in the C stack, this will not be needed (as far as the garbage
> collector knows your thread)
Thank you very much. Keeping an array of pointers
On Fri, Aug 21, 2009 at 2:27 AM, Juanjo <
juanjose.garciarip...@googlemail.com> wrote:
>
> On Aug 21, 2:08 am, Nils Bruin wrote:
> > Thank you! Should I call that on any cl_object that lives outside ecl?
> > or only (as the name suggests) on the root of a cl_object tree?
>
> If you have a single
On Aug 21, 2:08 am, Nils Bruin wrote:
> Thank you! Should I call that on any cl_object that lives outside ecl?
> or only (as the name suggests) on the root of a cl_object tree?
If you have a single lisp object that links to all live data outside
of ECL, then you need only register that object. A
On Aug 20, 2:09 pm, Juanjo
wrote:
> > - If one keeps pointers to ECL objects outside of ECL's management
> > (i.e., a cl_object pointer in a cython object), one needs to tell
> > ECL's garbage collector about it. I don't know how.
>
> extern ECL_API void ecl_register_root(cl_object *p);
>
> But
On Aug 20, 10:18 pm, Nils Bruin wrote:
> - If one keeps pointers to ECL objects outside of ECL's management
> (i.e., a cl_object pointer in a cython object), one needs to tell
> ECL's garbage collector about it. I don't know how.
extern ECL_API void ecl_register_root(cl_object *p);
But a more
18 matches
Mail list logo
