"Paul A. Patience" skribis: > (Forwarding my message since I accidentally didn't include 54938@debbugs.gnu.org > in the "to" field.) > > On Thursday, April 14th, 2022 at 13:14, Paul A. Patience wrote: >> On Thursday, April 14th, 2022 at 10:36, Guillaume Le Vaillant glv@posteo.net wrote: >>> Is there a reason to update only to commit 2f2a008 from September 2019 >>> instead of a more recent one? >> >> The latest commit (from February 2021) has several issues originating from >> the backports from digikar99's py4cl2 package. >> For example, the py-cd function does not follow the naming scheme of py4cl, >> and also calls the inexistent pycall function (pycall is py4cl2's equivalent >> of py4cl's python-call). >> >> Further, a configuration file was introduced to configure several things, >> including the path to python and some configuration variables related to >> numpy array pickling. >> The problem is the configuration file has to be located in the same >> (writable) directory as py4cl.py, which of course causes problems with Guix. >> Technically this isn't an issue because Guix hardcodes the path to py4cl.py, >> so we could reuse *base-directory* for just the configuration file, but I think >> a better solution would be to put the configuration file into XDG_CONFIG_HOME, >> and that is probably better fixed at the source rather than in the Guix package. >> >> The test suite fails as well, perhaps due to the configuration file not being >> writable. >> I didn't investigate very much. >> >> I may submit some fixes to py4cl in the future for the issues I mentioned, >> but only if I keep using it (at the moment I am evaluating its suitability). >> Until then, the commit I've updated sbcl-py4cl to is the last before the first >> of digikar99's changes were merged. >> >> Best regards, >> Paul Ok, thanks for the explanation. Patch pushed as 5059e7f01e1d299a2a52b1649251fa49f1992385.