Post by Christophe RhodesJust in case anyone's interested, I've put debian packages of sbcl at
<http://www-jcsu.jesus.cam.ac.uk/ftp/pub/debian/lisp/{binary-i386,source}/>;
however, there is one problem with the packaging, in that
common-lisp-controller wants to compile every lisp package, including
things that are cmucl-specific.
Great! I haven't had the motivation or patience to deal with .deb's
(or .rpm's, or BSD packages) myself but they're wonderful things. Do
you plan to maintain this for long enough that it's worth referring to
your site on the project web page? And/or would you like me to add the
packages to the file releases section of the SourceForge summary page?
Post by Christophe RhodesWhat needs to be done to implement the --noprogrammer option? If it
were there, then the compilation would simply fail, rather than
throwing the process into the debugger, which is probably the most
reasonable behaviour.
Hmm, yes, --noprogrammer would be good. It's even on my little list of
the high-ratio-of-urgency-to-estimated-difficulty things that I'd like
to go after before I'll make an 0.7.x branch,
?? fixed bug 14: The system now gives more informative error messages
when you mess up method combination in CLOS.
?? fixed bug 23: The system now gives an informative error message
when OPEN fails because there aren't enough file descriptors.
?? fixed bug 24: COMPILE-FILE now handles READ-ERROR, instead of popping
you into the debugger.
?? fixed bug 26: ARRAY-DISPLACEMENT works for non-displaced arrays
?? fixed bug 55: The system macro DEFMACRO-MUNDANELY now sets the
documentation string correctly for the macros it defines.
?? DEFUN vs. DECLAIM: no longer implicitly DECLAIM FTYPE by default
?? --noprogrammer option
?? two ^D's for termination of input, should be one..
so I'd been hoping to fix it within a month or two, as opposed to,
say, a year or two.
As longtime readers of this list may remember, I'm also working on a
program to play the Asian game of Go. When I run it noninteractively
(e.g. under the very nice cgoban program, which can automatically play
it against other Go programs or against any opponent connected to a
server like nngs.cosmic.org) I use this code:
-----------------------------------------------------------------------
(defun noprogrammer-debugger-hook (condition old-debugger-hook)
(declare (ignore old-debugger-hook))
;; This HANDLER-CASE is here mostly to stop output immediately (and
;; fall through to QUIT) when there's an I/O error. Thus, when we're
;; run under a Perl script or something, we can die cleanly when the
;; script dies (and our pipes are cut), instead of falling into ldb
;; or something messy like that.
(handler-case
(progn
(format *error-output*
"~@<unhandled CONDITION: ~2I~_~A~:>"
condition)
;; (Where to truncate the BACKTRACE is of course arbitrary, but
;; it seems as though we should at least truncate it somewhere.)
#+sbcl (sb-debug:backtrace 100 *error-output*)
(finish-output *error-output*))
(condition ()
;; Just fall through. (It was an error in error
;; handling that got us here, so messing around trying
;; to handle this error would likely just make us more
;; bewildered. Don't even try to output anything, since
;; very often it's an I/O error in error handling that
;; gets us here, and doing output could cause more
;; problems.)
))
#+sbcl (sb-ext:quit :unix-status 1)
#-sbcl (error "unhandled condition in noprogrammer mode"))
(setf *debugger-hook* #'noprogrammer-debugger-hook)
-----------------------------------------------------------------------
When I wrote this, I didn't plug it into SBCL immediately because (1)
I wasn't sure whether it's a good general implementation of
--noprogrammer (especially whether it's doing the right things with
*ERROR-OUTPUT* vs. *DEBUG-IO* vs. other streams), and (2) I wasn't
sure whether the ability to do this semi-portably means that a
--noprogrammer extension is a mediocre idea. But since it's now been
working OK for a while, and since on reflection I now think that it's
sufficiently unportable (since it really needs the QUIT :UNIX-STATUS
extension, and really wants the BACKTRACE extension) that the
--noprogrammer extension is an OK idea after all, I'd be happy to
merge something like this into SBCL.
If there's any other functionality that anyone thinks is important
for --noprogrammer, or anyone has any other comments, let me know,
otherwise I'll probably do this within a week or so.
--
William Harold Newman <***@airmail.net>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C