Re: [Axiom-developer] depsys

[Gabriel Dos Reis]

Gabriel Dos Reis <address@hidden> writes:

| Gabriel Dos Reis <address@hidden> 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