The lurkmathml package causes an error when mathml is called on a function definition:
load(mathml);
mathml(f() := 1);
For example, with 5.47.0 and GCL:
Maxima 5.47.0 https://maxima.sourceforge.io
using Lisp GNU Common Lisp (GCL) GCL 2.7.1 git tag Version_2_7_2pre7
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) load(mathml);
(%o1) /usr/share/maxima/5.47.0/share/contrib/lurkmathml/mathml.lisp
(%i2) mathml(f() := 1);
<pre>
Segmentation violation: c stack ok:signalling errorMaxima encountered a Lisp error:
Condition in PROGN [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
This can be reproduced with current git HEAD, too.
The issue is two-fold: in the function mathml1, there is a string substitution to replace all < with < that causes the segmentation fault. That is likely a GCL bug. But, the ultimate cause of the bug is that the mdefine and mmacro operators are treated specially and the code tries to emit the 1d print form wrapped in a pre tag.
This is wrong, in my opinion. These expressions should be marked-up just like all others.
The attached patch cuts out the special case and fixes the segfault:
(%i3) load("./mathml.lisp");
(%o3) ./mathml.lisp
(%i4) mathml(f() := 1);
<math xmlns="http://www.w3.org/1998/Math/MathML"> <mi>f</mi>
<mfenced separators=""></mfenced> <mo>:=</mo><mn>1</mn> </math>
(%o4) false
The use of mfenced is a separate issue.
It's OK by me to change it as indicated by the patch, but a motivation for just enclosing the function definition in
<pre>/</pre>is that it might be many lines of code, and might be a lot of non-mathematical stuff that isn't improved by markup.