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 package. 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. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
