On Sun, 16 Oct 2016 17:19:36 -0400 Camm Maguire <c...@maguirefamily.org> wrote:
> Greetings!
> 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 
written in.

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.


GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE

Reply via email to