I understand. So it's possible to explicitly load a package by
wrapping load in ibase:10. .
(%i1) ibase:16$
(%i2) block([ibase:10.], load(stringproc))$
(%i3) ascii(7a);
(%o3) z
So a fix could be to wrap the corresponding source functions which
perform loading in ibase:10. . Which are these and what is $ibase at
Lisp level ?
Thanks
Volker
2013/1/2 Rupert Swarbrick <rswarbrick at gmail.com>:
> 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
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>