On Sun, 16 Oct 2016 17:19:36 -0400 Camm Maguire <c...@maguirefamily.org> wrote:
> Why don't you send me a description of what you've done with current
> maxima and sage so far and what errors you see, so I can take a look.
> Take care,
Thanks for the reply Camm,
Another point is the cost of the patching exercise. Packaging Sage is already
huge effort and I don't believe that any of us on this team have the necessary
expertise to keep a ECL->GPL Sage patch updated for the lifetime of this
OTOH, patching Maxima to output an ECL form of the library is relatively
simple, and it's only a few files. Furthermore, Sage upstream themselves are
directly maintaining this, so we don't have to.
The FASL library is quite important, you can think of Sage as a programming
environment much like Python, so "users" are expected to dynamically load FASL
libraries and manipulate Lisp objects directly via Sage (which already includes
an interface to ECL). As opposed to say, loading a shared-library "plugin" into
a program that then extends its functionality with a fixed and very limited
UI/CLI unrelated to the underlying programming language that the plugin is
I'll also note that /usr/bin/maxima has a --list-avail option so clearly
upstream expects some users to want the same version of maxima installed built
with multiple Lisp compilers. This is not typically the case for e.g. C
libraries; none of them offer run-time options that let you switch between
different versions built by different C compilers. I guess that this might be
because Lisp is much less standardised than C, but I don't really know the
ecosystem for sure.
Anyway, I'll leave you two to explore Sage-with-Maxima-GCL a bit more, but I
think it's important to also consider this as a long-term-cost-reduction
exercise and not merely a "is it possible" exercise.