#6391: libGAP! -- create a Cython library interface to gap
----------------------------------------------------------------------------+
Reporter: was |
Owner: was
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-5.5
Component: group theory |
Resolution:
Keywords: |
Work issues: assert usage
Report Upstream: N/A |
Reviewers: Dima Pasechnik, Ivan Andrus, Volker Braun, William Stein
Authors: Dima Pasechnik, Ivan Andrus, Volker Braun, William Stein |
Merged in:
Dependencies: #13415, #13123, #13211 |
Stopgaps:
----------------------------------------------------------------------------+
Comment (by dimpase):
Replying to [comment:125 burcin]:
> Replying to [comment:124 vbraun]:
>
> > a GAP interpreter that communicates over zeromq
>
> Also based on conversations in St. Andrews, some upstream developers are
interested in an autotools based build system. AFAICT, the main problem
with compiled GAP packages is that they rely on the object files
previously compiled for the GAP executable to find symbols they need from
the GAP kernel.
Do you mean GAP extension packages, things which are compiled using
{{{gac}}} ?
"Normal" GAP packages do not need any of this, AFAIK.
The extension packages are few and far apart. The only one I know is
[http://www.math.rwth-aachen.de/~Frank.Luebeck/EDIM/index.html EDIM].
The main use of {{{gac}}} seems to be
to create faster loading GAP executables.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6391#comment:127>
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.
