spkg-configure.m4 for maxima #32867
Comments
|
Author: Michael Orlitzky |
|
Commit: |
|
Branch: u/mjo/ticket/32867 |
|
comment:2
I opened #32898 so that removing |
|
comment:3
This works for me on void linux. Note that debian, arch, and I think also gentoo all include |
|
comment:4
Maxima is packaged for Cygwin as "maxima", Or that can be a separate ticket. |
|
Changed keywords from none to maxima |
|
comment:5
We don't have the patch in Gentoo... |
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
|
comment:7
Would it be hard to support system maxima compiled with sbcl if available? It seems to be ~ 5-6 times faster than maxima on ecl (at least the time it takes to run the testsuite) and it is also more available in general. For the command line interface, it seems to me setting MAXIMA to "maxima" instead of "maxima -l ecl" would work (btw: why eliminate the config option MAXIMA and hardcode "maxima -l ecl" everywhere instead of just changing MAXIMA in a single place?) For the library interface I don't know if it is possible to compile |
|
comment:8
Replying to @tornaria:
Sadly it's not possible. Sage interfaces with maxima at a very low level through ECL; see
Given that we need ECL maxima for Sage, there aren't any other good values for that variable. The With that in mind, removing the variable eliminates a "configurable" option that isn't actually configurable in practice, and also gets rid of a tiny bit of coupling between modules.
No, until very recently even the ability to create an ECL library required a custom patch. That patch has finally been accepted upstream, but I don't think anything similar is possible with the other lisp implementations. (Sage is married to ECL for the moment either way.) |
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
|
comment:11
I've disabled (for now) the one remaining test that needs |
|
comment:12
Replying to @tornaria:
Adding to mjo's answer: for the expect-based interface, it may be doable to use SBCL. There are peculiarities in the way the stdin/stdout character streams are driven in different LISPs that may interfere with a simple drop-in replacement. The main use in sage now, however, is through maxima_lib which is really using that the E in ECL means "embeddable": we link in the ecl, start it through its binary interface, and then instruct it to load maxima.fas. Our interfacing is using an ABI, not I/O streams, and we directly access the memory objects that ECL constructs to translate them to python (or leave them wrapped). I'm pretty sure this is all fundamentally impossible with SBCL. We are getting huge latency and efficiency gains through the ABI interface compared to I/O, so in many cases I suspect we can afford slower execution in ECL, and I think we don't want to go back to expect-based interfaces. That's why we're tied to ECL. |
|
comment:13
Replying to @nbruin:
I tried it (using sbcl maxima for the binary but maxima-ecl for maxima_lib) and I think it worked ok (as in: doctests passed).
In theory it may be possible (see http://www.sbcl.org/manual/#Calling-Lisp-From-C) although it might be a lot of work. The speed gains could be considerable for that part of sage, I don't know if it's overall worth the trouble. |
|
comment:14
Isn't a version check for maxima necessary? On the oldest supported platform, system maxima is 5.32.1. https://repology.org/project/maxima/versions |
|
comment:15
Replying to @mkoeppe:
In spirit yes, but in practice... maybe. The |
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
… directory. This just fixes a test. The problem was noticed on Arch where, due to some other circumstances, maxima was executed from within /usr/sbin. But all we know for sure is that maxima will live in PATH. So we modify the test to look only for "maxima", and not its parent directory.
The ECL library is now contained in a separate maxima-fas package that will pull in maxima itself.
This should work automatically, and the previous behavior is incorrect if we intend to use the system copy of maxima.
This new spkg-configure.m4 checks for both a "maxima" executable, and the usability of a "maxima" package by ECL. (The latter requires a patched maxima until a new release with commit a0d7a43e523 is made.) Notably absent for the moment is a version check, but that should be okay: at the moment, the only system copies of maxima that support being used as an ECL library are those that are patched, and the only reason to patch them is if you intend to use them with SageMath. So in short, if a distro patches their maxima to use it with sage, we expect it to work with sage. This commit also moves the SAGE_MAXIMA_FAS variable handling from ECL's spkg-configure.m4 to maxima's (where it would have belonged in the first place, if maxima had an spkg-configure.m4 at the time.)
This patch won't be present in a system copy of maxima (at least for now), so we disable these tests to avoid spurious failures once we start accepting maxima from the system.
We have some old code and an old test for a memory limit that was present in ECL 12 years ago, worked around in ticket 6772. The memory limit is no longer in place, and would not have applied to a non-ECL maxima from the system anyway. Since the test itself is purposely wasteful (to ensure that we can use lots of RAM), we take this opportunity to remove it and speed up the test suite a bit.
… directory. This just fixes a test. The problem was noticed on Arch where, due to some other circumstances, maxima was executed from within /usr/sbin. But all we know for sure is that maxima will live in PATH. So we modify the test to look only for "maxima", and not its parent directory.
The ECL library is now contained in a separate maxima-fas package that will pull in maxima itself.
This should work automatically, and the previous behavior is incorrect if we intend to use the system copy of maxima.
This new spkg-configure.m4 checks for both a "maxima" executable, and the usability of a "maxima" package by ECL. (The latter requires a patched maxima until a new release with commit a0d7a43e523 is made.) Notably absent for the moment is a version check, but that should be okay: at the moment, the only system copies of maxima that support being used as an ECL library are those that are patched, and the only reason to patch them is if you intend to use them with SageMath. So in short, if a distro patches their maxima to use it with sage, we expect it to work with sage. This commit also moves the SAGE_MAXIMA_FAS variable handling from ECL's spkg-configure.m4 to maxima's (where it would have belonged in the first place, if maxima had an spkg-configure.m4 at the time.)
This patch won't be present in a system copy of maxima (at least for now), so we disable these tests to avoid spurious failures once we start accepting maxima from the system.
We have some old code and an old test for a memory limit that was present in ECL 12 years ago, worked around in ticket 6772. The memory limit is no longer in place, and would not have applied to a non-ECL maxima from the system anyway. Since the test itself is purposely wasteful (to ensure that we can use lots of RAM), we take this opportunity to remove it and speed up the test suite a bit.
… directory. This just fixes a test. The problem was noticed on Arch where, due to some other circumstances, maxima was executed from within /usr/sbin. But all we know for sure is that maxima will live in PATH. So we modify the test to look only for "maxima", and not its parent directory.
The ECL library is now contained in a separate maxima-fas package that will pull in maxima itself.
This should work automatically, and the previous behavior is incorrect if we intend to use the system copy of maxima.
This new spkg-configure.m4 checks for both a "maxima" executable, and the usability of a "maxima" package by ECL. (The latter requires a patched maxima until a new release with commit a0d7a43e523 is made.) Notably absent for the moment is a version check, but that should be okay: at the moment, the only system copies of maxima that support being used as an ECL library are those that are patched, and the only reason to patch them is if you intend to use them with SageMath. So in short, if a distro patches their maxima to use it with sage, we expect it to work with sage. This commit also moves the SAGE_MAXIMA_FAS variable handling from ECL's spkg-configure.m4 to maxima's (where it would have belonged in the first place, if maxima had an spkg-configure.m4 at the time.)
This patch won't be present in a system copy of maxima (at least for now), so we disable these tests to avoid spurious failures once we start accepting maxima from the system.
We have some old code and an old test for a memory limit that was present in ECL 12 years ago, worked around in ticket 6772. The memory limit is no longer in place, and would not have applied to a non-ECL maxima from the system anyway. Since the test itself is purposely wasteful (to ensure that we can use lots of RAM), we take this opportunity to remove it and speed up the test suite a bit.
… directory. This just fixes a test. The problem was noticed on Arch where, due to some other circumstances, maxima was executed from within /usr/sbin. But all we know for sure is that maxima will live in PATH. So we modify the test to look only for "maxima", and not its parent directory.
The ECL library is now contained in a separate maxima-fas package that will pull in maxima itself.
|
done in #35615 |
We handled ECL by itself in #29617, so now maxima needs its own ticket.
This would actually be "easy" at this point if not for our custom
matrixexp.patch(https://sourceforge.net/p/maxima/bugs/2596/).Depends on #33718
CC: @slel @antonio-rojas
Component: build: configure
Keywords: maxima
Author: Michael Orlitzky
Branch/Commit: u/mjo/ticket/32867 @
544b601Reviewer: https://github.com/sagemath/sage/actions/runs/1992568379
Issue created by migration from https://trac.sagemath.org/ticket/32867
The text was updated successfully, but these errors were encountered: