Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| | Tim --
| |
| | I have a question about a difference in "load" behaviour bewteen a
| | clean lisp image (GCL), and depsys (and any image derived from it).
| |
| | In a clean image, when I say '(load "foo")', Lisp will try to search
| | from the current directory -- just what is expected.
| |
| | However, depsys will start search from $AXIOM/.. -- which is less expected.
| | I spent quite lot of time figuring out where that behaviour is
| | implemented in the files that make up depsys, but I was unsuccessful.
| | Do you have an idea whether that behaviour is implemented?
| | I looked many times at reroot, but could not deduce how it might be
| | responsible. It looks like there is an Axiom code that fundamentally
| | changes GCL's usual load procedure.
|
|
| Let me add this (from a debug session -- i hate those).
|
| #0 APPLY {loc0=#<compiled-function
system:universal-error-handler>,loc1=:error,loc2=nil,l...} [ihs=12]
| #1 APPLY {loc0=#<compiled-function
system:universal-error-handler>,loc1=:error,loc2=nil,l...} [ihs=11]
| #2 LAMBDA {"/home/gdr/build/axiom/target/foo"=nil,} [ihs=8]
| #3 LOAD
{loc0=#p"/home/gdr/build/axiom/target/foo.lsp",loc1=t,loc2=nil,loc3=:error,loc4=...}
[ihs=7]
| #4 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function load>}
| [ihs=6]
| #5 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="/usr/local/lib...}
[ihs=5]
| #6 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
| NIL
|
| So, it looks like some code effectively called the "real" load with the
| wrong prefix.
OK. The bug surely is in initroot and friends.
For example
>>vmlisp::$current-directory
"/home/gdr/build/axiom/target/i686-suse-linux"
>>*default-pathname-defaults*
#p"/home/gdr/build/axiom/target/i686-suse-linux"
None these two variables has a correct value according to the
documentation found in bookvol5.
The [[*default-pathname-defaults*]] defaults common lisp variable is
set in [[restart]] to the current directory in most cases. If we are
working in Lucid Common Lisp ([[:lucid]]) on an IBM/370 mainframe
([[:ibm/370]]) then it is set to the empty string. Using Lucid on a
mainframe seems to use the variable [[vmlisp::$current-directory]].
further down the road, I read:
\subsection{vmlisp::\$current-directory}
When running in Lucid Common Lisp ([[:lucid]]) on an IBM/370 mainframe
([[:ibm/370]]) this variable is used in place of the
[[*default-pathname-defaults*]] common lisp variable.
Otherwise this variable is
set to the empty string in [[restart]].
The [[reroot]] function sets this variable to the value of
[[$spadroot]] which itself has the value of the argument to the
[[reroot]] function. Since the argument to the [[reroot]] function is
an string which represents an absolute pathname pointing to AXIOM the
net result is that the [[$current-directory]] is set to point to the
shell [[AXIOM]] variable.
So during execute both [[$current-directory]] and [[$spadroot]] reflect
the value of the [[AXIOM]] shell variable.
It does not seem to me that the variavle $current-directory has a
clearly defined semantics. The documentation appears to be a
description of the current code without saying whether the code
implements the semantics designed for the variable, or whether it is
the result of "evolving" semantics , e.g. patches over patches.
I have trouble understading why a variable named "current-directory"
would point to something that is not the current directory, and
duplicate the role of $spadroot.
Tim?
-- Gaby
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
