Strange LOAD behaviour in CMUCL
Hannu Koivisto
While porting Zebu to work with CMUCL (currently canceled
project in favor of another parser generator) I noticed LOAD
behaving in a way I can't explain (after studying HyperSpec
first of course). Anyway, I'd like to know why it works the way
it does and if it is standard compliant behaviour, what I have
missed in the spec.
In the code below, Zebu loads its compiled runtime system
(COMPILED is t).
"""
...
(let ((*default-pathname-defaults*
(merge-pathnames
(make-pathname
:type (car (if compiled
*load-binary-pathname-types*
*load-source-pathname-types*)))
(if compiled
*ZEBU-binary-directory*
*ZEBU-directory*))))
(dolist (name '("zebu-aux"
"zmg-dom"
"zebu-mg-hierarchy"
"zebu-loader"
"zebu-driver"
"zebu-actions"))
(let ((file (merge-pathnames (make-pathname :name name))))
(format t "~%;;; Loading file: ~S" file)
(if (probe-file file)
(load file)
...
"""
In addition:
"""
* *load-binary-pathname-types*
("x86f")
* *ZEBU-binary-directory*
#p"binary/"
* *ZEBU-directory*
#p""
* (probe-file #p"binary/zebu-aux.x86f")
#p"/mnt/storage/home/azure/projects/software/xxc-cmucl/src/zebu-3.5.3/binary/zebu-aux.x86f"
"""
And the result of evaluating that code is:
"""
;;; Loading file: #p"binary/zebu-aux.x86f"
"binary/binary/zebu-aux.x86f" does not exist.
Restarts:
0: [CHECK-AGAIN] See if it exists now.
1: [USE-VALUE ] Prompt for a new name.
2: [CONTINUE ] Return NIL from load of
#p"binary/zebu-aux.x86f".
3: [ABORT ] Return to Top-Level.
Debug (type H for help)
(COMMON-LISP::INTERNAL-LOAD #p"binary/binary/zebu-aux.x86f" NIL :ERROR NIL)
"""
Where does that one extra "binary/" come from? The only
explanation I can come up with is that LOAD gets it from
*default-pathname-defaults* but _why_ it would do something like
that is beyond me. Evaluating ``(load #p"binary/zebu-aux.x86f")''
directly at the top-level (when *default-pathname-defaults* is
#p"") works fine.
Oh, btw, if I select "0" from restarts, it adds yet another
"binary/" to the path :)
I'm using CMUCL 2.4.8 from the Debian GNU/Linux distribution
running on x86 architecture.
//Hannu
Peter Van Eynde
>(let ((*default-pathname-defaults*
> (merge-pathnames
> (make-pathname
> :type (car (if compiled
> *load-binary-pathname-types*
> *load-source-pathname-types*)))
*default-pathname-defaults* is now
#<Unprintable pathname, Host=#<COMMON-LISP::UNIX-HOST
{5063085}>, Device=NIL, Directory=(:RELATIVE "binary"),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Name=NIL, Type="x86f", Version=:NEWEST>
...
> (load file)
*default-pathname-defaults* is still the :relative stuff
and in load we do:
(let ((pn (merge-pathnames (pathname filename)
*default-pathname-defaults*)))
and then do an internal-load of pn with is #p"binary/binary/zebu-aux.x86f".
>Where does that one extra "binary/" come from? The only
>explanation I can come up with is that LOAD gets it from
>*default-pathname-defaults* but _why_ it would do something like
>that is beyond me. Evaluating ``(load #p"binary/zebu-aux.x86f")''
In the HS:
load filespec &key verbose print if-does-not-exist external-format
=> generalized-boolean
Arguments and Values:
filespec---a stream, or a pathname designator. The default is
taken from *default-pathname-defaults*.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
So the behaviour seems correct, not?
>directly at the top-level (when *default-pathname-defaults* is
>#p"") works fine.
As expected.
>Oh, btw, if I select "0" from restarts, it adds yet another
>"binary/" to the path :)
It keeps adding a relative directory :-)
>I'm using CMUCL 2.4.8 from the Debian GNU/Linux distribution
>running on x86 architecture.
Any other problems?
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org for pleasure,
"God, root, what is difference?",Pitr | pvan...@inthan.be for more pleasure!
Hannu Koivisto
| In the HS:
|
| load filespec &key verbose print if-does-not-exist external-format
|
| => generalized-boolean
|
| Arguments and Values:
|
| filespec---a stream, or a pathname designator. The default is
| taken from *default-pathname-defaults*.
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| So the behaviour seems correct, not?
I did read the part you quote from HS but I still didn't
understand the reason. But now I do, thanks to you pointing out
that...
| *default-pathname-defaults* is still the :relative stuff
| and in load we do:
| (let ((pn (merge-pathnames (pathname filename)
| *default-pathname-defaults*)))
That is, as far as I can see, "The default is taken from
*default-pathname-defaults*." should be interpreted as "The
default is taken from *default-pathname-defaults* _using the
rules of merge-pathnames_."
Because I didn't know you use merge-pathnames in load, I didn't
realize to check out merge-pathname's documentation which says:
"""
Pathname merging treats a relative directory specially. If
(pathname-directory pathname) is a list whose car is :relative,
and (pathname-directory default-pathname) is a list, then the
merged directory is the value of
(append (pathname-directory default-pathname)
(cdr ;remove :relative from the front
(pathname-directory pathname)))
"""
Based on just "The default is taken from
*default-pathname-defaults*.", I thought (I still don't know if
I can say that thought was justified or not) that it would use
defaults only for unsupplied components, not "magic" rules (from
the point of view of not knowing merge-pathnames is involved)
in the case of relative directory component.
In my opinion the current behaviour (of load, _not_
merge-pathname's) is counter-intuitive. I'm not yet experienced
enough to say if it's against the spirit or intention of the
specification. I may still be missing something obvious here, so
I'd appreciate further comments on this matter.
| Any other problems?
No, at least not with CMUCL :) It works just fine. I do have two
wishlist items (they are not problems for our current project),
though, in case you are interested (I guess I should join some
CMUCL mailinglist for discussing these).
//Hannu
Barry Margolin
Hannu Koivisto <az...@iki.fi.ns> wrote:
>In my opinion the current behaviour (of load, _not_
>merge-pathname's) is counter-intuitive. I'm not yet experienced
>enough to say if it's against the spirit or intention of the
>specification. I may still be missing something obvious here, so
>I'd appreciate further comments on this matter.
The idea of pathname defaults is intended to be similar to most OS's notion
of a working directory. That's why relative pathnames are interpreted by
appending the directory lists from the default and the supplied pathname.
It does get weird when the default pathname is also relative -- when the
resulting pathname is handed to the OS, it's then interpreted relative to
the OS's notion of your working directory.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
Hannu Koivisto
| The idea of pathname defaults is intended to be similar to most OS's notion
| of a working directory. That's why relative pathnames are interpreted by
| appending the directory lists from the default and the supplied pathname.
| It does get weird when the default pathname is also relative -- when the
| resulting pathname is handed to the OS, it's then interpreted relative to
| the OS's notion of your working directory.
Thanks for the explanation. This makes sense and is very
logical, IMO also when the default pathname is relative too.
It's a shame HS seems to be so vague here.
//Hannu
Erik Naggum
| Thanks for the explanation. This makes sense and is very logical, IMO
| also when the default pathname is relative too. It's a shame HS seems to
| be so vague here.
I think it makes sense to say that a using a relative default pathname
defies its purpose, which I see as resolving relative and otherwise
incomplete pathnames into absolute and otherwise complete pathnames.
if a relative default pathname made sense, there would be something else
that would make a pathname complete beside the default pathname, but
where would that information come form? Unix has a "superdefault" in the
current working directory, but to use that as a basis of anything isn't
even safe for Unix applications.
#:Erik
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.