[Openmcl-devel] Re: Another pathname question

[Octav Popescu]

In Lispworks it works if you just do (load "foo:two"). Maybe it works with 
your original setf too, I haven't tried. There seems to be a bug with using 
a logical host in defaults: (load "two") calls (probe-file "foo:two"), 
which calls pathname-match-p with a second argument of 
"/.automount/*/root/**/*". Which then calls parse-namestring with 
"/.automount/*/root/**/*" and a default of #P"foo:". Which gives the error. 
I'm not sure where this path comes from, maybe it's documented somewhere, I 
couldn't find it. I still haven't tried OpenMCL.

Octav

--On Friday, February 27, 2004 8:36 AM -0500 Gary King 
<gwking at cs.umass.edu> wrote:

> Whoopt, my bad about (load-pathname). It's a function I should have
> included:
>
> (defun load-pathname ()
>     "Returns a pathname that is useful for merging with filenames to get
> a  complete pathname for a file in the same directory as the one
> currently being  loaded.  This function is a more portable version of the
> Common Lisp variable  *load-truename*, since not all vendors implemented
> that correctly."      (let ((pn   #+allegro (translate-logical-pathname
> (truename excl:*source-pathname*))                  #+MCL (if
> *load-truename*
>                         (translate-logical-pathname *load-truename*)
>                         ;; This makes it work in a fred buffer...
>                         (translate-logical-pathname
> *loading-file-source-file*))                  #+Lispworks
> (translate-logical-pathname *load-truename*)                  #-(or
> allegro MCL Lispworks)
>                 (translate-logical-pathname *load-truename*)))
>       (assert (pathnamep pn) (pn)
>               "load-pathname* did not return a pathname, it returned ~s;
> this might be because it executed in a context where you're not loading a
> file  or because the file is in the current working directory.  In any
> event, this   will break the code in generic-load-utils, because it works
> with the components  of pathnames." pn)
>       ;; Deal with the lispworks using an empty pathname for
> *default-pathname-defaults*        ;; if you are loading from the current
> working directory.
>       (values
>        #-lispworks pn
>        #+lispworks
>        (if (null (pathname-directory pn))
>          (merge-pathnames pn (current-pathname)) pn))))
>
> As for your fix, it works for me under MCL but not under OpenMCL or
> LispWorks, same problem as before.
>
> On Feb 26, 2004, at 4:02 PM, Octav Popescu wrote:
>
> One thing that might be problematic is load-pathname. I couldn't find it
> in the hyperspec index, I don't know if it's part of the standard. There
> is a *load-pathname* variable however.
>
> --
> Gary Warren King, Lab Manager
> EKSL East, University of Massachusetts * 413 577 0176
>
> I am shocked at how little my colleagues in genetics pay attention to
> history. They actually forget how ignorant we are?that although we have
> achieved incredible manipulative powers, we know next to nothing about
> the real world in which those manipulations will reverberate.     --
> David Suzuki (http://www.davidsuzuki.org/)