[Gcl-devel] Re: system, load-time-value

[Camm Maguire]

Greetings!  First, a special word of thanks for your work with GCL!
And please excuse my occasionally tardy replies -- other work often
takes precedence.

Debian User <address@hidden> writes:

> Hi Camm!
> 
> I've managed to cross-install Debian via
> a netinstall-cd, and have begun to look at
> common-lisp-controller.
> 
> I've encountered a few questions in that regard.
> I'll need to use SI::SYSTEM and mangle with
> image-copies in unixport/ among other things.
> 
> (SI::SYSTEM "exit 3") returns _two_ values, the exit-code
> 3 as expected is the first value, but the second
> value is always 0, no matter what command I run.
> What is the second value that SI::SYSTEM returns?
> 

This should be documented, and reworked to be more user friendly
IMHO.  But basically you get the high and low order short integers of
the return code.  If on linux, do a 'man system' and 'man 2 wait' and
you can see that bits of information regarding which process failed
and why are encoded in a special manner in this field.  We should
probably unpack this at some point and be more verbose.  In short, 0 0
is success.

> By the way:  Why isn't it exported?  Sometimes it
> seems rather random which symbols are exported from
> SI, but I guess it has always been a moving target...
> Just curious.
> 

Paul is our expert here -- I know we don't have complete freedom over
which symbols are exported from LISP/COMMON-LISP, but perhaps we are
free to do with SYSTEM as we choose?  I know of no reason personally
-- its been that way since I started maintaining GCL.

> When I tried to load common-lisp-controller.lisp,
> I found out that LOAD-TIME-VALUE doesn't work in the
> interpreter in gcl: It isn't implemented.  As far as
> I understand it is supposed to work in execute and
> load modes, while compilation mode evaluates the value
> for load-time.  Paul?

Yes, I have a near-complete implementation based on ADDRESS and NANI
as yet uncommitted pending our release of the stable branch as 2.6.2.
We need this to fix a literal object copying ansi error in 'compile. 

> 
> Clisp accepts LOAD-TIME-VALUE in interpretation
> (execute) mode, so I gather it is standard.
> I'll probably do fine without the gcl interpreter,
> but the issue remains... There also seems to be
> problems with LOGICAL-PATHNAME-TRANSLATIONS and
> SETF -- are pathnames broken in gcl?  I end up
> in an infinite debugger-loop.  Just checking if
> somebody knew something obvious I did not:
> I'll continue digging...

We've only started looking at the spec issues regarding pathnames.
Paul tells us the spec is rather loosely defined here.  

If you can report here the details of how you got an infinite debugger
loop, that would be helpful.  We've recently implemented code to break
recursive invocations of the universal-error-handler with the same
arguments (e.g. when there is an error printing the error), so I had
thought most/all of these were gone.

Take care,

> 
> Yours,
> 
> Dennis Decker Jensen
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah