gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Debian User
Subject: [Gcl-devel] Re: system, load-time-value
Date: Fri, 13 Feb 2004 16:49:52 +0000

        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.

Thanks for the references!  I took a single look, and found out:

>(si::system "exit 3")

3
0

>(si::sytem "kill -15 $$")

0
15

        > 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.

Highlights from the CLHS is offen a good help:
http://www.lispworks.com/reference/HyperSpec/Front/Hilights.html

Standardized Packages:
http://www.lispworks.com/reference/HyperSpec/Body/11_ab.htm

In ANSI Common Lisp there is only COMMON-LISP (nickname CL),
containing 978 exported symbols (there is a complete symbol list
at the highlights link), which must fullfill certain contraints
(see the 11_ab.htm link above), and the COMMON-LISP-USER
(nickname CL-USER) package which is the user environment at start
up, which must use package COMMON-LISP as well as everything
else you want it to.  Any other package is yours to choose and
structure at free will, including SYSTEM (SI), LINUX, POSIX,
PCL, GTK, XLIB, XML, UNICODE, ASDF, MAKE (MK), SOCKET, BSD or
what ever you wanna put into the implementation, and whatever
symbols you want to export from those packages.  So far having
things in SI seems quite OK, while I expect symbols in more or
less common use to be exported, such as ARGC, ARGLIST, SYSTEM,
SAVE-SYSTEM, LINK, etc. -- you know what I mean...

Usually implementations use all packages of the implementations
in the user environment, which is considered bad by somebody,
(think symbol-bloat) but a lot of people has gotten used to
having everything stuffed into COMMON-LISP-USER.  GCL currently
has 1104 symbols in CL while CLisp (for comparison) has 747
symbols and SBCL the correct number of 978 (exported) symbols.

        > When I tried to load common-lisp-controller.lisp,
        > I found out that LOAD-TIME-VALUE doesn't work in the

        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.

Great!  It'll be needed for common-lisp-controller to work.

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

It might be a good idea to look at what other implementations
do.  People have talked about pathname problems alot on
comp.lang.lisp, but I don't understand all the issues.  So far
GCL's treatment of them seems quite logic: I.e. I haven't been
caugth by bad surprises so far (knock on wood).

        If you can report here the details of how you got
        an infinite debugger loop, that would be helpful.

I haven't been able to reproduce the error, I'm sorry.  I wasn't
being careful to note the exact steps.  I'll be more careful
next time and report it, if I encounter the bug again.  All I
can remember is that the condition signaled was a SIMPLE-ERROR.1
and no backtrace -- and with (si::fast-links nil) ... Basically
I was stuck in a second level: While I could progress further
levels down, I couldn't restart toplevel or level one again.

Yours,

Dennis Decker Jensen





reply via email to

[Prev in Thread] Current Thread [Next in Thread]