Ximin Luo: > 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. >
Hi Camm, I've taken another look at the package and I don't believe we will be able to get Maxima-GCL working with Sage, now or in the long run. Could you please consider applying our patches again? The updated versions are here: https://anonscm.debian.org/cgit/debian-science/packages/maxima-sage.git/commit/?id=eca9a4414a8b2b5678e24be03bda779fd8e65177 We'd be happy to co-maintain maxima to make sure our patches are kept up-to-date across version updates. -- To give some background, Sage has two interfaces to Maxima: a. https://doc.sagemath.org/html/en/reference/interfaces/sage/interfaces/maxima_lib.html via the ECL FASL library (newer, more preferred) b. https://doc.sagemath.org/html/en/reference/interfaces/sage/interfaces/maxima.html via the maxima CLI (older) Looking at src/maxima.system around line 62, this is an ECL-specific component and upstream do not support it for other compilers. I don't believe it's reasonable to expect Debian package maintainers to add this support ourselves. If upstream haven't done this, clearly it's not an easy thing to do - for the other components of maxima, they support other Lisp compilers including GCL just fine. Furthermore, Sage upstream do a lot of testing with Maxima-ECL. In upstream ticket #18920 in trying to upgrade to version 5.38.1, they have run into several problems related to ECL: https://trac.sagemath.org/ticket/18920 If we use GCL we will very likely have to duplicate this detailed Lisp debugging work, every time a new version of Maxima is released. We got a lot of test failures last time this was tried about a year ago, and we don't have time to try again. We in the Debian Sage team don't have enough expertise or time resources to be able to do this in the long run. OTOH, if we use Maxima-ECL, we can benefit from their work, and learn from their detailed reporting in their tickets instead of having to invent everything from scratch. Debian package maintainers are not supposed to deviate from upstream significantly, and using Maxima-GCL instead of Maxima-ECL would be a significant deviation. I'd like to also point out that other packages have "different flavours" in Debian without issues - for example see libcurl[34]-{gnutls,nss,openssl}-dev. This is closer to the situation with Maxima - there are significant differences in Lisp compilers, that upstream's build system has lots of conditional switches like "#+ gcl" for different compilers etc, and explicitly allow for multiple flavours at run-time. It is not at all like the C compiler situation, where most FOSS projects assume GCC. Thanks, Ximin -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
