Volker van Nek <volkervannek at gmail.com> writes:
> I observed
>
> volker at uvw32:~$ rmaxima -q
> (%i1) obase:16$
> (%i2) ascii(122);
> (%o2) z
> (%i3) quit();
> volker at uvw32:~$ rmaxima -q
> (%i1) ibase:16$
> (%i2) ascii(7a);
> loadfile: failed to load
> /usr/local/share/maxima/5.29.1/share/stringproc/stringproc.lisp
> -- an error. To debug this try: debugmode(true);
>
> Can someone please explain this mechanism? The path-string is
> displayed correctly but the file can't be (auto)loaded.
>
> Volker van Nek
The root of the problem is that the read base is bound to 16 for the
lisp reader as well as the Maxima one. Then the variable "c" that is
used in $CUNLISP (and later in M-CHAR) is interpreted as 12, so the lisp
sees:
(defun $cunlisp (12)
(if (not (characterp 12))
(merror "cunlisp: argument must be a Lisp character"))
(m-char 12))
which (obviously) fails to compile.
For people that know about Maxima ibase: Is there a reason that changing
ibase alters the lisp reader? This seems bizarre to me, at least.
Rupert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: <http://www.math.utexas.edu/pipermail/maxima/attachments/20130102/c2cc63ac/attachment-0001.pgp>;