#6781: Library access to ecl
-------------------------+--------------------------------------------------
Reporter: nbruin | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-feature
Component: symbolics | Keywords:
Reviewer: | Author:
Merged: |
-------------------------+--------------------------------------------------
Description changed by nbruin:
Old description:
> ecl can be run "embedded" and has a fairly clean C interface, which
> should be tightly wrappable in cython.
> There are good macros provided for accessing ecl objects, and many of the
> atomic values should be fairly easily mappable to/from sage or python
> native datatypes. Hence, data communication on binary level with the ecl
> library should be doable, and would be a stepping stone towards a binary
> interface with maxima.
>
> ISSUES:
>
> 1. I quote from Section 5.2 of the ECL reference manual:
>
> The collector will not scan the data sectors. If you embed ECL in another
> program, or link libraries with ECL, you will have to notify ECL which
> variables point to lisp objects.
>
> So, cython wrapper objects that keep track of an object under ECL memory
> management will have to do something, but the manual doesn't say what.
>
> 2. Maxima currently gets built as a stand-alone executable. Somewhere in
> the build process, there must exist a lisp-environment that has Maxima
> built but not running. In order to communicate with maxima as a library
> (via ECL's API), one would have to get such an image. It does look like
> Maxima just store its state in LISP's global state, so just calling
> maxima routines from LISP should work.
New description:
ecl can be run "embedded" and has a fairly clean C interface, which should
be tightly wrappable in cython.
There are good macros provided for accessing ecl objects, and many of the
atomic values should be fairly easily mappable to/from sage or python
native datatypes. Hence, data communication on binary level with the ecl
library should be doable, and would be a stepping stone towards a binary
interface with maxima.
ISSUES:
1. I quote from Section 5.2 of the ECL reference manual:
The collector will not scan the data sectors. If you embed ECL in another
program, or link libraries with ECL, you will have to notify ECL which
variables point to lisp objects.
SOLUTION: Boehm does look on the stack for pointers, so the only objects
in danger are on the heap, outside of Boehm's control. The easiest
solution is to place pointers somewhere in a list or a vector inside
lisp's control (in some global variable).
2. Maxima currently gets built as a stand-alone executable. We need Maxima
loaded, but not running.
SOLUTION: It is possible to extract the right kind of image.
a) remove the last line from init-cl.lisp, since this starts
maxima's read-eval-print loop
b) start ecl and run:
(require 'asdf)
(load "maxima-build.lisp")
(asdf:make-build :maxima :type :fasl)
c) this produces a file "maxima.fasb" that can be loaded into ecl
after (require 'asdf)
3. ecl installs a signal and error handler that wreaks havoc with
the sage environment. It should be possible to turn the error handler /
debugger off via common lisp. The signal handler needs to be handled
separately
4. after ecl has run in sage, exit triggers a segfault.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6781#comment:1>
Sage <http://sagemath.org/>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
