Maxima SPKG: eliminate undoing_true_false_printing_patch.patch

[orlitzky]

Our maxima SPKG requires(?) a custom patch called undoing_true_false_printing_patch.patch that reverts this upstream commit:

https://sourceforge.net/p/maxima/code/ci/f5e9b0f7eb122c4e48ea9df144dd57221e5ea0ca

Our patch was introduced in sage commit 91990e9 to ease the upgrade to maxima-5.29.1. Since upstream has no plans to revert that commit (and distros won't either), we'll have to work around it before we can use maxima from the system.

CC: @kiwifb @dimpase @mkoeppe @antonio-rojas @embray @kcrisman @isuruf @spaghettisalat

Component: distribution

Author: Michael Orlitzky

Branch: a842fc0

Reviewer: Matthias Koeppe

Issue created by migration from https://trac.sagemath.org/ticket/31553

[orlitzky]

comment:1

Maybe this isn't so bad. If I delete the patch, I get one doctest failure:

sage -t --long --random-seed=0 src/sage/calculus/calculus.py
**********************************************************************
File "src/sage/calculus/calculus.py", line 1208, in sage.calculus.calculus.limit
Failed example:
    limit(x^a, x=0)
Expected:
    Traceback (most recent call last):
    ...
    ValueError: Computation failed since Maxima requested additional
    constraints; using the 'assume' command before evaluation *may* help
    (example of legal syntax is 'assume(a>0)', see `assume?` for
     more details)
    Is a an even number?
Got:
    <BLANKLINE>
    Traceback (most recent call last):
      File "/home/mjo/src/sage.git/local/lib/python3.8/site-packages/sage/interfaces/maxima_lib.py", line 984, in sr_limit
        return max_to_sr(maxima_eval(([max_limit], L)))
      File "sage/libs/ecl.pyx", line 854, in sage.libs.ecl.EclObject.__call__ (build/cythonized/sage/libs/ecl.c:8628)
        return ecl_wrap(ecl_safe_apply(self.obj,(<EclObject>lispargs).obj))
      File "sage/libs/ecl.pyx", line 365, in sage.libs.ecl.ecl_safe_apply (build/cythonized/sage/libs/ecl.c:5910)
        raise RuntimeError("ECL says: {}".format(
    RuntimeError: ECL says: Maxima asks: Is _SAGE_VAR_a an even\ number?
    <BLANKLINE>
    During handling of the above exception, another exception occurred:
    <BLANKLINE>
    Traceback (most recent call last):
      File "/home/mjo/src/sage.git/local/lib/python3.8/site-packages/sage/doctest/forker.py", line 714, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/mjo/src/sage.git/local/lib/python3.8/site-packages/sage/doctest/forker.py", line 1133, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.calculus.calculus.limit[15]>", line 1, in <module>
        limit(x**a, x=Integer(0))
      File "/home/mjo/src/sage.git/local/lib/python3.8/site-packages/sage/calculus/calculus.py", line 1394, in limit
        l = maxima.sr_limit(ex, v, a)
      File "/home/mjo/src/sage.git/local/lib/python3.8/site-packages/sage/interfaces/maxima_lib.py", line 988, in sr_limit
        self._missing_assumption(s)
      File "/home/mjo/src/sage.git/local/lib/python3.8/site-packages/sage/interfaces/maxima_lib.py", line 1033, in _missing_assumption
        raise ValueError(outstr)
    ValueError: Computation failed since Maxima requested additional constraints; using the 'assume' command before evaluation *may* help (example of legal syntax is 'assume(a>0)', see `assume?` for more details)
    Is a an even\ number?
**********************************************************************

One backslash to get rid of. What could possibly go wrong?

[mkoeppe]

comment:2

Sage development has entered the release candidate phase for 9.3. Setting a new milestone for this ticket based on a cursory review of ticket status, priority, and last modification date.

[orlitzky]

comment:3

I'm not getting too far with this, but the problem lies somewhere between when the retrieve function receives its msg argument in interfaces/maxima_lib.py and when it is printed to the console. The msg we receive is

((MTEXT) Is  $_SAGE_VAR_a  an  EVEN   NUMBER ?)

but when printed out it looks like

Is _SAGE_VAR_a an even\ number?

Our copy of retrieve is out-of-date, but the upstream one has the same issue. I tried setting the global value of linel to 1000 in case it was a word-wrap issue in one of the display functions, but no luck there.

[orlitzky]

comment:4

I should mention: the two lines above are the difference between (princ msg) and (displa msg).

[orlitzky]

comment:6

I may as well admit defeat here. I dumped many hours into this before, and a few more today, and I'm still no closer to understanding what's going wrong. The following workaround moves the patch into sagelib, so that we can accept the system maxima:

diff --git a/src/sage/interfaces/maxima_lib.py b/src/sage/interfaces/maxima_lib.py
index 14be2195f5..4dfc3b69e8 100644
--- a/src/sage/interfaces/maxima_lib.py
+++ b/src/sage/interfaces/maxima_lib.py
@@ -113,6 +113,36 @@ ecl_eval('(defun principal nil (cond ($noprincipal (diverg)) ((not pcprntd) (mer
 ecl_eval("(remprop 'mfactorial 'grind)") # don't use ! for factorials (#11539)
 ecl_eval("(setf $errormsg nil)")
 
+# This next definition overrides maxima's msize-mtext to revert
+#
+#   https://sourceforge.net/p/maxima/code/ci/f5e9b0f7eb122c4e48
+#
+# All we (intend to) do is replace two "stringp" with "atom". How this
+# prevents newlines/backslashes from leaking into the output, I cannot
+# say; but monkey-patching it here avoids the need to patch maxima
+# itself. See trac 31553 for discussion. And for the love of god,
+# please someone fix this before it comes back to haunt us.
+ecl_eval(r"""
+(defun msize-mtext (x l r)
+  (setq x (cdr x))
+  (if (null x)
+      (msz nil l r)
+      (do ((nl) (w 0))
+          ((null (cdr x))
+           (setq nl (cons (if (atom (car x))
+                              (msz (makestring (car x)) l r)
+                              (msize (car x) l r lop rop))
+                          nl))
+           (cons (+ w (caar nl)) (nreverse nl)))
+        (setq nl (cons (if (atom (car x))
+                           (msz (makestring (car x)) l r)
+                           (msize (car x) l r lop rop))
+		       nl)
+              w (+ w (caar nl))
+              x (cdr x)
+              l nil))))
+""")
+
 # the following is a direct adaptation of the definition of "retrieve"
 # in the Maxima file macsys.lisp. This routine is normally responsible
 # for displaying a question and returning the answer. We change it to

If no one smarter than me can figure it out, I'll eventually post a branch with that change so that we can get started working on a system-maxima branch.

[orlitzky]

Branch: u/mjo/ticket/31553

[orlitzky]

Author: Michael Orlitzky

[orlitzky]

Commit: bfb921d

[orlitzky]

New commits:

bfb921d

Trac #31553: move custom patch into maxima_lib initialization.

[nbruin]

comment:9

If it helps anything, I suspect the backslash insertion may be coming from this patch. Note that grind.lisp has its own slash, but it looks like both should backslash a space. Looking at the MTEXT you get, the double space suggests the object is ( ... "EVEN " "NUMBER" ...) or ( ... "EVEN" " NUMBER" ...). Also, these may be symbols that have attributes on them that tell grind/displa` how to render them to strings (internationalization in maxima already??).

The line where the mtext gets constructed is here.

Quite frankly, is maxima normally is happy with the backslashed space in the string it constructs (because their printer strips out the backslash then again, presumably) we should be happy with it too. The only thing we're doing in maxima_lib is monkey-patch retrieve to raise an error with the question string rather than ask the question. If we need to do a little bit of work on that string to make it look nice (like unescape spaces) then we should. So I think what should happen is:

• confirm that unpatched maxima normally asks the question without a backspace in it.

• update our monkey-patched retrieve to include the string in its error message as produced by unpatched maxima. Ideally we'd do that by using the same rendering to a string that maxima does to the IO stream, but it may be that the different streams aren't fully compatible. In that case, we may want to do some post processing on the string. This is certainly a cleaner solution than (monkey-)patching an additional internal routine.

I think you may want to reconsider the final goal of using an unpatched system maxima, though: we build maxima.fas through a custom extension of the maxima build system. Maxima normally does not build it, because its build process is set up to produce an application not a library. Our build instructions are ECL-specific (and indeed, it's not immediately clear that all lisps would support something like this), so I don't think that you'll find much traction pushing this change upstream, much less getting distributions to build Maxima/ECL this way. You'd basically have to make a separate package maxima-ecl-fas.rpm or something like that.

I expect we're stuck with a custom-built maxima for that reason already: maxima_lib is NOT a "supported" way of using maxima.

So it's nice to clean up patches like the one on this ticket for general code maintainability, but I think it's futile to try and move to a "standard" maxima. (I hope that a sage install that uses the system ECL without write permission on the system ECL library can somehow adapt ECLs search paths to also look in a location that sits in the sage tree)