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

[Camm Maguire]

Greetings!

Debian User <address@hidden> writes:

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

Thanks for this observation!  We should add this to the docs.  I
wonder how portable this is across windows, macosx, etc.

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

OK, this is an official call for suggestions -- which of our packages
should be used by user?  Currently we have:
(
list-all-packages)

(#<"CONDITIONS" package> #<"SLOT-ACCESSOR-NAME" package>
 #<"PCL" package> #<"ITERATE" package> #<"WALKER" package>
 #<"TK" package> #<"DEFPACKAGE" package> #<"ANSI-LOOP" package>
 #<"SERROR" package> #<"SLOOP" package> #<"COMPILER" package>
 #<"SYSTEM" package> #<"KEYWORD" package> #<"COMMON-LISP" package>
 #<"COMMON-LISP-USER" package> #<"LISP" package>)

This is a 2.7.x item.

> GCL currently
> has 1104 symbols in CL while CLisp (for comparison) has 747
> symbols and SBCL the correct number of 978 (exported) symbols.
> 

This and several other ansi issues will be top priority if we can just
get 2.6.2 out the door!

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

So this is required for this functionality?

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

OK, don't know what this could be, but thought I'd mention one known
related issue -- cvs head has temporarily disabled :q to get to the
toplevel as it interfered with Paul's tests trapping the top level
abort restart.  Supplying the number should work.  If you want the :q
back, revert this patch to clcs_restart.lisp:

 (defun make-kcl-top-restart (quit-tag)
-  (make-restart :name 'abort
+  ;; FIXME need this restart for :q, but invoke-restarts must signal
+  ;; a control error if abort called outside a defined restart
+  (make-restart :name 'abort1
                :function #'(lambda () (throw (car (list quit-tag)) quit-tag))
                :report-function 
                #'(lambda (stream) 
 

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

Take care,

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