On Aug 20, 2:09 pm, Juanjo <juanjose.garciarip...@googlemail.com> 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 useful procedure is to store the data in lisp variables. 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? Can the garbage collector move allocated pieces around? (so, can pointed become invalid for reasons other than deallocation?) Am I right in assuming that if a cl_ routine gives me back a cl_object pointer, I can trust that this pointer will remain valid until the next time that I call a cl_ routine? Would threads invalidate that assumption? Should I call ecl_register_root immediately after being supplied with the pointer to ensure the object doesn't inadvertently get deallocated? Is there a corresponding ecl_deregister_root to be called when I no longer need the object? Are you suggesting that I'd be better off allocating a vector or an a- list in ecl and store any reference to an ecl structure in that and address it using an index or a handle? That could definitely be arranged. > I wonder whether you have found some of the embedding examples in the > mailing list and wiki (http://sourceforge.net/apps/mediawiki/ecls/ > index.php?title=Simple_embedded_usage) More sophisticated recipies can > be posted, if needed. Yes I have and in fact, the track ticket contains a straight translation of that example into cython. The initial usage scenario I am thinking about is to first create a cython class cl_object, which wraps an essentially opaque pointer cl_object. c_string_to_object can easily be wrapped to produce such objects, and via write-to-string they are easily turned into strings as well. Translating the ecl API is completely straightforward in that model. Once that works, one could gradually de-opaque-ify cl_object and provide access to the different fields, depending on the type. This would allow more efficient conversion between ecl and python native data types. If you know of examples that may contain relevant code for this, I'm very interested in pointers. > ECL can build maxima using a list of object files. The last step is > now a build-program (see maxima/src/maxima.system). If instead of that > you use build-fasl, you will get a big binary file maxima.fasl, that > you can load using ECL's library function (cl_load). Great. That's exactly what I hoped. Incidentally, I managed to attach gdb to sage to get a little insight in the segfault that happens when sage with ecl shuts down: Program received signal SIGSEGV, Segmentation fault. GC_free (p=0x1c584fc0) at malloc.c:412 backtrace: #0 GC_free (p=0x1c584fc0) at malloc.c:412 #1 0x00002b5798868966 in ecl_dealloc (ptr=0x184) at /usr/local/sage/4.1.1/spkg/build/ecl-9.4.1/src/src/c/alloc_2.d: 265 #2 0x00002b57790572e2 in __pyx_pf_4sage_5rings_7integer_free_integer_pool ( __pyx_self=<value optimized out>, unused=0x8) at sage/rings/ integer.c:29479 #3 0x00000000004933b5 in PyEval_EvalFrameEx (f=0x1c92d8d0, throwflag=<value optimized out>) at Python/ceval.c:3690 [...] It seems a bit strange to me that the sage integers would have any business calling ecl_dealloc, but this may ring bells with people who have looked at either the sage or the ecl memory management. In order to reproduce, apply patch on ticket 6781 and run something like this in sage: sage: from sage.libs.ecl import * sage: hello() sage: quit --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
