#6781: [with patch, needs review] Library access to ecl
---------------------------+------------------------------------------------
Reporter: nbruin | Owner: nbruin
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-4.2.1
Component: packages | Keywords:
Work_issues: | Author:
Reviewer: | Merged:
---------------------------+------------------------------------------------
Changes (by nbruin):
* component: symbolics => packages
* milestone: sage-feature => sage-4.2.1
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.
>
> 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.
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.
-----------------
All issues have been resolved and ecllib.patch should apply cleanly
to add Ecl library support. The Ecl package has already been updated
due to other reasons (at least in 4.1.2) to a version that supports
the necessary options.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6781#comment:7>
Sage <http://www.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
-~----------~----~----~----~------~----~------~--~---
