-
-
Notifications
You must be signed in to change notification settings - Fork 604
Support for --disable-giac #38668
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I wonder if it's really worth replying such an attack. If sagemath chooses to make giac optional, it might be a problem for some sage users, not for me. There are plenty of users of giac worldwide, either from ports I maintain myself or embedded in other applications. |
Phase one of sagemath#38668 AFAICS it's not doing anything anyway. URL: sagemath#38669 Reported by: Michael Orlitzky Reviewer(s):
Hi Parisse, |
Geogebra has indeed it's own build system, but the source files and header files of giac are the same as in the giac tarball (except for the FLTK Xcas UI). The giac tarball is a unique source for the giac library and Xcas UI, that's the reason why it contains files relative to Xcas, like ARM32 firmwares port of Xcas for the Numworks calculators (Xcas can handle these calculators). |
sagemathgh-38669: Remove giac integration from GiNaC Phase one of sagemath#38668 AFAICS it's not doing anything anyway. URL: sagemath#38669 Reported by: Michael Orlitzky Reviewer(s):
just changing the package type to |
sagemathgh-38690: Tweak a few tests to pass when giac is not installed This is one of the prerequisites to make it possible to install sage without giac (sagemath#38668). These few tests can be made to work easily without a `# needs giac`, so let's do that. URL: sagemath#38690 Reported by: Michael Orlitzky Reviewer(s): David Coudert
sagemathgh-38690: Tweak a few tests to pass when giac is not installed This is one of the prerequisites to make it possible to install sage without giac (sagemath#38668). These few tests can be made to work easily without a `# needs giac`, so let's do that. URL: sagemath#38690 Reported by: Michael Orlitzky Reviewer(s): David Coudert
For the last step (disabling sage.libs.giac), meson will help in the short term, but for sage-the-distro I think we should move the entire folder into a separate sagemath-giac package. We can have it depend on sagemath-standard rather than -categories and -objects unless someone wants to adopt Matthias's PR. |
Frankly, I'd rather see the distributions spaghetti in a freezer or another suitable container. The objections to #38712 seem to stem from the old way(s) of building sagelib, and sagelib only. If you build sage-distro in the usual way, then #38712 pretty much does what's advertised. With meson build, it should not be a problem, no need to do a deep dive into spaghetti, to produce more of it ? |
I think if you
Yes meson will be a big help because it will skip compilation of
|
sagemathgh-38770: Add "needs" tags for giac and libgiac Part of sagemath#38668. If it's going to be possible to disable giac, we need to guard all of the tests that use it with either `# needs giac` or `# needs sage.libs.giac`. I think I've gotten them all. A crude way to test: 1. `git rm -r src/sage/libs/giac` and rebuild to disable sage.libs.giac 2. build sage, and then delete the giac executable to disable the pexpect interface If you do these one at a time, it should ensure that the correct tags are used. (Typically, if giac is missing, neither sage.libs.giac nor the giac executable will be present, making it very easy to mix up the tags.) For bonus points you can undelete `src/sage/libs/giac` after building but before testing to make sure the "needs" tags in those files are accurate. ### Dependencies: * sagemath#38756 * sagemath#38686 (not strictly required, but it adds a few "needs sage.libs.giac" tags of its own) URL: sagemath#38770 Reported by: Michael Orlitzky Reviewer(s): Tobias Diez
sagemathgh-38770: Add "needs" tags for giac and libgiac Part of sagemath#38668. If it's going to be possible to disable giac, we need to guard all of the tests that use it with either `# needs giac` or `# needs sage.libs.giac`. I think I've gotten them all. A crude way to test: 1. `git rm -r src/sage/libs/giac` and rebuild to disable sage.libs.giac 2. build sage, and then delete the giac executable to disable the pexpect interface If you do these one at a time, it should ensure that the correct tags are used. (Typically, if giac is missing, neither sage.libs.giac nor the giac executable will be present, making it very easy to mix up the tags.) For bonus points you can undelete `src/sage/libs/giac` after building but before testing to make sure the "needs" tags in those files are accurate. ### Dependencies: * sagemath#38756 * sagemath#38686 (not strictly required, but it adds a few "needs sage.libs.giac" tags of its own) URL: sagemath#38770 Reported by: Michael Orlitzky Reviewer(s): Tobias Diez
For the record, +1 for having a way to disable giac |
Please post your fix proposal here as well as the command that raised the segfault (probably a gbasis). |
I don't want to take over this issue, so I opened #38864 (for lack of an upstream bug tracker) |
sagemathgh-38686: Use the faster libgiac interface for "giac" integration While working on sagemath#38668, I noticed that all of our examples that use giac for integration do so with `algorithm='giac'`. This uses the pexpect interface that is much slower (and simply sloppier) than the library interface that would be used with `algorithm='libgiac'`. To fix this, I could just change those examples to `algorithm='libgiac'`, but since the libgiac interface is better in every way, that seems kind of rude to me. Most users aren't going to know what lib-anything is, and if they just want to use giac, they're going to try `algorithm='giac'`. So instead this PR makes `algorithm='giac'` do the right thing, and use the better interface. I've left the `algorithm='libgiac'` alone for now to avoid breaking any code. Afterwards I have removed the pexpect giac integrator entirely, because there's no reason to use it, and no other code in sagelib uses it. URL: sagemath#38686 Reported by: Michael Orlitzky Reviewer(s): Dima Pasechnik, Tobias Diez
sagemathgh-38686: Use the faster libgiac interface for "giac" integration While working on sagemath#38668, I noticed that all of our examples that use giac for integration do so with `algorithm='giac'`. This uses the pexpect interface that is much slower (and simply sloppier) than the library interface that would be used with `algorithm='libgiac'`. To fix this, I could just change those examples to `algorithm='libgiac'`, but since the libgiac interface is better in every way, that seems kind of rude to me. Most users aren't going to know what lib-anything is, and if they just want to use giac, they're going to try `algorithm='giac'`. So instead this PR makes `algorithm='giac'` do the right thing, and use the better interface. I've left the `algorithm='libgiac'` alone for now to avoid breaking any code. Afterwards I have removed the pexpect giac integrator entirely, because there's no reason to use it, and no other code in sagelib uses it. URL: sagemath#38686 Reported by: Michael Orlitzky Reviewer(s): Dima Pasechnik, Tobias Diez
sagemathgh-38686: Use the faster libgiac interface for "giac" integration While working on sagemath#38668, I noticed that all of our examples that use giac for integration do so with `algorithm='giac'`. This uses the pexpect interface that is much slower (and simply sloppier) than the library interface that would be used with `algorithm='libgiac'`. To fix this, I could just change those examples to `algorithm='libgiac'`, but since the libgiac interface is better in every way, that seems kind of rude to me. Most users aren't going to know what lib-anything is, and if they just want to use giac, they're going to try `algorithm='giac'`. So instead this PR makes `algorithm='giac'` do the right thing, and use the better interface. I've left the `algorithm='libgiac'` alone for now to avoid breaking any code. Afterwards I have removed the pexpect giac integrator entirely, because there's no reason to use it, and no other code in sagelib uses it. URL: sagemath#38686 Reported by: Michael Orlitzky Reviewer(s): Dima Pasechnik, Tobias Diez
sagemathgh-39376: Replace sage.libs.giac with new optional package sagemath-giac As the last step in sagemath#38668, we move `sage/libs/giac` into a separate package, * https://github.com/sagemath/sagemath-giac and make it optional. This module is already mostly independent of sage -- there is nothing in sagelib that depends on it unconditionally. Its main use is as an integration backend, where it is technically optional because we try whatever backends are available in succession and expect some to fail. In fact, the modules themselves are already optional if you are using meson. The `sage/libs/giac` directory is simply skipped when meson cannot find giac. It is not possible to do the same thing using the build system for sage-the-distro, however, which motivates the separate package. Many reasons are given in sagemath#38668 for why you might want to avoid giac, but the main reason for me right now is because it's not portable: it doesn't build and/or run on systems where the rest of sage works fine, including the one I am using most of the time. The new package uses the namespace `sagemath_giac` to work around missing namespace support in cython, but `sage.libs.giac` re-exports everything under the old name for backwards compatibility. URL: sagemath#39376 Reported by: Michael Orlitzky Reviewer(s): François Bissey, Michael Orlitzky, Tobias Diez
Giac is a PITA to have as a dependency:
Fortunately it looks like it won't be too hard to make giac optional in Sage:
We lose a few integration examples in the doctests when the giac algorithm is skipped in favor of sympy, but that's about it.
The text was updated successfully, but these errors were encountered: