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.
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.
@jgmbenoit Can you consider working with a different Lisp implementation? I recommend SBCL. From a technical point of view I think it is preferable.
I can but right now I am maintaining/hardening/debugging the existing Debian packages related to maxima.
As I have suggested to you before, there could be a second set of Debian packages, maxima-sbcl or something else, besides the packages maintained by Camm.
Indeed. I am thinking about it. However I have to manage my time --- I am a volunteer DD. For now, I think that getting a working wxMaxima Debian package is more important. Some of wxMaxima issues (in Debian Sid/Forky) come from itself and some from maxima or gcl.
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.
Last edit: Robert Dodier 2026-04-08
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
Last edit: Robert Dodier 2026-04-08
@villate Jaime, thanks for posting the example output. I see that it is ASCII-only; the quote marks are ASCII single quote and the item markers are ASCII asterisks. I suggested in another comment that one way to get this to work with GCL may be to enable the
--no-utf-8flag formakeinfo.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 2026-04-05
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.