SBCL port



On Sat, 2003-02-22 at 23:52, Wolfgang Jenkner wrote:
> James Amundson <amundson@fnal.gov> writes:
> 
> > On Sat, 2003-02-22 at 12:00, Wolfgang Jenkner wrote:
> > > Known bugs are various pathname (?) annoyances.
> > 
> > What are those, exactly?
> 
> Actually, I am aware of only two pathname problems:
> 
> (C1) file_search_maxima:["/tmp/###.mac"];
> (D1) 			        [/tmp/###.mac]
> (C2) load("hfdufz.mac");
> Bad file spec: "/tmp/###.mac"
>  -- an error.  Quitting.  To debug this try DEBUGMODE(TRUE);)
> 
> assuming that you don't have such a file in your current directory.
> By the way, the compiled-in load path works fine.
> 
> Fortunately ;-) this turns out to be a Maxima ANSI CL compatibility
> bug.  As a matter of fact, I got the output above not from SBCL but
> from Clisp by setting
> 
> (C1) :lisp(setq *parse-namestring-ansi* t)
> T

OK. Sounds like something worth fixing.

> The reason for this behaviour is that "/tmp/###.mac" is passed to
> PATHNAME as a symbol |/tmp/###.mac|, which is not a pathname
> designator (look at MACSYMA-NAMESTRING-SUB in mload.lisp for the
> whole story).
> 
> Maybe PATHNAME (and other functions?) should be shadowed.
> 
> For the second bug (not relevant at run-time) please see my kludge in
> src/Makefile.am.  It should be investigated before they port SBCL to
> some system without symbolic links ;-)

I'll keep in mind that there is a hack there. I think we have some time
before SBCL runs on a platform without symbolic links.

--Jim