Menu
▾
▴
#4692 maxima-index.lisp provides wrong lengths
On Debian Sid, it appears that 'maxim-index.lisp' encodes wrong lengths.
We can check it in a maxima session:
entering '? ?' gives a paragraph that ends in the middle of a sentence.
This can be observed for other description requests.
I found this issue by entering '? build_info' in wxMaxima:
I got an endless loop instead of a description (it appeared
that the cut was around a special character).
Actually, for these two examples at least, the lengths in the 'maxim-index.lisp'
distributed in Debian and the ones distributed in the upstream source are the same.
So I am afraid that is not a Debian specific issue.
This issue is reported in Debian bugreport #1131495.
Related
What does
build_info()report?If I am not mistaken, the Debian package for Maxima is compiled with GCL. If so, the bug is that GCL is not Unicode-aware. The Maxima documentation contains multi-byte Unicode characters and GCL cannot handle the documentation index correctly, because it cannot count multi-byte characters.
If the Lisp implementation is something other than GCL, then I would look first at whether Unicode support is enabled and go from there. It is also possible, although I doubt it, given that the stuff that gets bundled into package is presumably a clean build, that the index is out of date with respect to the .info files.
I'm not using this particular version, but using a local git HEAD version with gcl works for me. "? sin" returns the expected text.
I thought you, Robert, made sure byte offsets instead of character offsets were used so that gcl would still work correctly.
@rtoy can you try it with the items mentioned by OP? Specifically
? ?and? build_info.Both of them work and return the expected text. No extraneous stuff. The only time I recall this ever happening is if for some reason maxima-index.lisp wasn't created or is out-of-date wrt to the info files.
Just to be extra clear, this is my local build, not the Debian sid version.
Here is the out put of the shell command
echo '? build_info' | maxima:Maxima 5.49.0 https://maxima.sourceforge.io
using Lisp GNU Common Lisp (GCL) GCL 2.7.1 git tag Version_2_7_2pre13
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)
-- Function: build_info ()
(%o1) true
(%i2)
So the end of the description is truncated and the final char is a french
(\^a)_tex.Do you get the full description or something as above ?
I could fix the issue in Sid by reversing commit 20cfb9d8084 ("In build_index.pl, assume info file encoding is always UTF-8."). I guess that this move is currently too drastic. It might be still permitted to pass the char-encoding as argument with UTF-8 as default.
Why don't you first check with Raymond what GCL version he is using. Apparently it's a different version from the one you use in Debian sid, because he doesn't see that problem.
I could not reproduce the claim of Raymond by building from the vanilla source balls of gcl27 and maxima. Furthermore I have seen no evidence that GCL has move to UTF-8. I am also looking for a quick fix.
Maxima startup says I'm using GCL 2.7.1 git tag Version_2_7_0. I built this myself from a git repo using the Version_2_7_1 tag. I have not yet updated to a newer version. The version that comes with my OS is GCL 2.6.14 git tag Version_2_6_15pre17. I don't think I've tried building Maxima with this version, but I think I used to use 2_6_14 previously, which is, I think, the oldest version that Maxima supports.
I'm almost 100% sure that Gcl does not support unicode. Pretty sure Camm would like to have it, though.
The last time I tried it didn't actively support unicode. Bit since it seems to treat text just as a stream of octets it didn't hinder you from using unicode. As long as you don't need to know how many characters the octets wou use count as in unicode and as long as you don't cut a unicode multi-byte sequence into two halves you won't notice any difference.
On 5 April 2026 16:26:03 CEST, Raymond Toy rtoy@users.sourceforge.net wrote:
Related
Bugs: #4692
For the record I just built gcl Version_2_7_2pre12. I compiled maxima with it (from scratch).
? build_infohas the expected result. No extraneous text or missing text.My build only set
--prefix. I didn't use any other options for configure.Can you give the output of
echo '? build_info' | maxima?Hello,
I can also build Maxima with GCL 2_7_2pre6 and It has no problem with
UTF8. The following is a session in Xmaxima:
Maxima branch_5_49_base_190_gdc4d613d6_dirty https://maxima.sourceforge.io
using Lisp GNU Common Lisp (GCL) GCL 2.7.1 git tag Version_2_7_2pre6
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) ? build_info
-- Function: build_info ()
Returns a summary of the parameters of the Maxima build, as a
Maxima structure (defined by 'defstruct'). When the pretty-printer
is enabled (via 'display2d'), the structure is displayed as a short
table.
The fields of the structure are:
* version Maxima version
* timestamp Time at which Maxima was compiled
* host Type of system Maxima is running on
* lisp_name Name of the Lisp implementation
* lisp_version Version of the Lisp implementation
* maxima_userdir User directory (value of 'maxima_userdir')
* maxima_tempdir Directory for temporary files (value of
'maxima_tempdir')
* maxima_objdir Directory for compiled files of share packages
(value of 'maxima_objdir')
* maxima_frontend Name of user interface, if any (value of
'maxima_frontend')
* maxima_frontend_version User interface version when
'maxima_frontend' is present (value of
'maxima_frontend_version')
See also *note bug_report::.
Examples:
(%i1) build_info ();
(%o1)
Maxima-version: "5.48.1"
Maxima build date: "2025-08-23 10:39:15"
Host type: "x86_64-pc-linux-gnu"
Lisp implementation type: "CLISP"
Lisp implementation version: "2.49.93+ (2024-07-04) (built
3935171094) (memory 3964959574)"
User dir: "/home/dodier/.maxima"
Temp dir: "/tmp"
Object dir:
"/home/dodier/.maxima/binary/5_48_1/clisp/2_49_93202407_04built_3935171094___memory_3964959574"
Frontend: false
(%i2) x : build_info ()$
(%i3) x@version;
(%o3) 5.48.1
(%i4) x@timestamp;
(%o4) 2025-08-23 10:39:15
(%i5) x@host;
(%o5) x86_64-pc-linux-gnu
(%i6) x@lisp_name;
(%o6) CLISP
(%i7) x@lisp_version;
(%o7) 2.49.93+ (2024-07-04) (built 3935171094) (memory
3964959574)
(%i8) x;
(%o8)
Maxima-version: "5.48.1"
Maxima build date: "2025-08-23 10:39:15"
Host type: "x86_64-pc-linux-gnu"
Lisp implementation type: "CLISP"
Lisp implementation version: "2.49.93+ (2024-07-04) (built
3935171094) (memory 3964959574)"
User dir: "/home/dodier/.maxima"
Temp dir: "/tmp"
Object dir:
"/home/dodier/.maxima/binary/5_48_1/clisp/2_49_93202407_04built_3935171094___memory_3964959574"
Frontend: false
The Maxima version string (here 5.48.1) can look very different:
(%i1) build_info();
(%o1)
Maxima version: "branch_5_37_base_331_g8322940_dirty"
Maxima build date: "2016-01-01 15:37:35"
Host type: "x86_64-unknown-linux-gnu"
Lisp implementation type: "CLISP"
Lisp implementation version: "2.49 (2010-07-07) (built
3605577779) (memory 3660647857)"
In that case, Maxima was not build from a released sourcecode, but
directly from the Git checkout of the source code. In the example,
the checkout is 331 commits after the latest Git tag (usually a
Maxima release, 5.37 in our example) and the abbreviated commit
hash of the last commit was "8322940".
User interfaces for maxima can add information about currently
being used by setting the variables 'maxima_frontend' and
'maxima_frontend_version' accordingly.
(%o1) true
(%i2) João: 5;
(%o2) 5
(%i3) João;
(%o3) 5
As far as I can tell, it its the same output I get with SBCL.
Regards,
Jaime
On 4/5/26 18:56, Jerome Benoit wrote:
Related
Bugs: #4692
Jerome: What version of texinfo are you using? In Ubuntu, with texinfo 6.8-4build1 and GCL git Version_2_7_2pre6 I don't see any problem:
So it appears that your (Raymond Toy) description is also truncated.
Last edit: Jerome Benoit 2 days ago
Yeah, I see that it's truncated now. The build was on some random branch. I'm redoing it now, and making sure I run make in doc/info. It will take a little while to rebuild all of maxima with gcl. I'm also using the texinfo 7.3 (self-built from the 7.3 release tag).
Still truncated. Not sure why. It will take some time to debug.
Did some poking around in
cl-info::read-info-text. For "? build_info", the starting point of 52615 in maxima.info-1 is correct. However, the expected length is 3596. If you read 3596 octets starting from 52615, you get a truncated result, ending exactly with "the variables ‘maxima_fro". But if you read 3596 characters, you get the correct end point. The issue is the there are backquote characters, specifically Left_Single_Quotation_Mark, #u2018. That's encoded as 3 octets: 226, 128, 152.What's the solution? Not really sure. build_index.pl could be updated to compute lengths in octets, not characters, assuming my analysis is correct above. Or modify read-info-text to read utf-8 characters. This would only be needed by gcl. We would count utf-8 characters but save each octet in a buffer. The buffer needs to be growable. (Easy.)
Modifying build-index.pl to use byte offsets would work, but would complicate it for all other lisps. Plus I can't read perl. Someone else will probably have to do that.
NOTE: there's probably also a problem with cmucl which uses UTF-16 characters. The buffer that only has space for 3596 characters. But with utf-16 encoding, things outside the BMP will take 2 16-bit words instead of 1. Cmucl handles this fine, but the buffer is too short. With the unicode display characters the maxima now supports, this could be a problem. Currently, though, it seems we only use characters from the BMP.
Finally, maybe the texi file could be updated not to use a Left_Single_Quotation_Mark and use a Grave_Accent (#u60). It seems the mark comes from
@code{maxima_frontend}. That won't be so easy to fix.Overall, I think a utf-8 decoder for gcl is the best way forward.
Here is a replacement for
read-info-textin cl-info.lisp that appears to work for me with gcl. "? build_info" isn't truncated.This needs more work, but seems ok. Of course, this assumes the info files are utf-8 encoded. We need to make sure all the info files are utf-8 encoded.
I play with the latest unstable packages of gcl27 and maxima. The current texinfo version in unstable is 7.3-2.
build_index.pl (and update_examples) are anachronisms.
Irregardless of how we fix this bug report, I think the best way forward
would be to re-write this perl script in lisp and generate the index
file at run-time, not build-time.
BTW, it is an embarrassment that we use perl and not lisp to do this
simple text stuff. There may have been a time when that made sense, but
that is long gone.
I think many years ago Rupert Swarbrik (?) started on a lisp replacement for build_index.pl. Never finished. I'm not sure how that would work if a Lisp doesn't have unicode support, but it would probably be easier today since we have pregexp support.
I have thought about using m4 to do update_examples, so that everytime the manual is generated, the examples are too. But not sure if that's a good idea because it would probably really slow down generation of the docs. Plus, someone would have to check the manual that all the examples were converted correctly.
Also, people complained that my changes to generate grad results at startup took too long (a second or two extra?). Generating the index at start-up would probably take even longer.
But maybe we can get AI to convert build_index.pl and update_examples to Lisp? I would be ok with that.