[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Gcl-devel] Re: CALL-ARGUMENTS-LIMIT and other things
From: |
Mike Thomas |
Subject: |
RE: [Gcl-devel] Re: CALL-ARGUMENTS-LIMIT and other things |
Date: |
Wed, 3 Nov 2004 13:57:52 +1000 |
Hi Camm.
| Small error here breaking the Linux build. Committed a fix. Please
| object if necessary. :-)
Your change works here thanks (and apologies).
| > 3. I am proposing a patch to GCL along the general lines set
| out below to
| > remove compiler warnings about the unknown optimizer quality "debug" as
| > frequently seen in the ANSI test output. These changes (*debug* and
| > appropriate checks in "cmpnew/gcl_cmpmain.lsp") are sufficient to remove
| > those warnings but I've hesitated about an appropriate compiler
| response to
| > the debug quality in light of the CLHS discussion:
| >
| > http://www.lispworks.com/reference/HyperSpec/Issues/iss251_w.htm
| >
|
| I certainly agree, at least personally, with the paragraph at the
| bottom here. These compilation parameters are confusing.
|
| That said, we could do some creative things here given that we mostly
| build atop gcc. *debug* should strip out -fomit-frame-pointer, turn
| on *c-debug* aka. -g, turn on *default-c-file* and *keep-gaz*, and
| push the file load address to the function symbol plist (as its lambda
| list is done now) with the debug property, so that we might facilitate
| running atop gdb and loading the symbol tables dynamically at runtime.
|
| Not that it would do much, but *space* should throw -Os. This does
| conflict with *speed*, as does *debug* via the conflict with
| -fomit-frame-pointer. Other than this, debugging and speed are mostly
| orthogonal with gcc.
|
| To my very limited understanding, *safety* is effectively a binary
| toggle, turning on type checking (alone) in the compiled code.
|
| > I imagine that the right thing would be for that quality to put debug
| > switches in the C compiler command line via *c-debug* , leaving
| manipulation
| > of C optimizer switches to the other optimizer qualities (it might be
| > beneficial, on occasion, to have maximum optimization with
| debug symbols).
| >
| > The negative side to this patch is that I renamed "si::debug" to
| > "si::debugger" to avoid a namespace clash with the compiler
| debug quality
| > symbol.
| >
| > Not yet in CVS
| >
|
| I've seen your patch, and it looks good. I don't see the name clash.
| *debug*!=debug, no?
In "lsp/gcl_export.lsp" an attempt is made to simultaneously export
"si::debug" (renamed "si::debugger" in my patch to avoid this trouble) and
"compiler::debug" from package lisp resulting in this build failure with
remarkably enlightening error message:
=====================================================================
cp init_pre_gcl.lsp foo
echo " (in-package \"USER\")(system:save-system \"saved_pre_gcl\")" >>foo
/c/cvs/head/gcl/unixport/raw_pre_gcl.exe /c/cvs/head/gcl/unixport/ -libdir
/c/cvs/head/gcl/ < foo
GCL (GNU Common Lisp) April 1994 131072 pages
Building symbol table for c:/cvs/head/gcl/unixport/raw_pre_gcl.exe ..
rsym_nt: c:/cvs/head/gcl/unixport/raw_pre_gcl.exe rsym2224 loading
c:/cvs/head/gcl/unixport/../lsp/gcl_export.lsp
A package error occurred on ~S: ~S.
Lisp initialization failed.
=====================================================================
You can reproduce this bug by applying my patches excepting those to
"o/cmpaux.c" and "cmpnew/gcl_cmptop.lsp". You can confirm that "debug" is
the problem symbol by deleting it from the list in "lsp/gcl_export.lsp".
| Currently, the symbol represents both a function
| and denotes an element in a symbol's plist. It would not appear that
| this would have to be changed. If it does need changing, we should
| change the C vars sSdebug and fSdebug accordingly.
|
| I'd like to work a bit on this too time permitting.
Well, if you like I'll check in my changes (including renaming "si::debug")
and we can take it from there as time permits. It might be possible, by the
way, to avoid the rename by package manipulation klevverness but I didn't
see a clean way of doing that.
| > After these changes 1164 of the ANSI tests fail on Windows.
| >
|
| Great!
|
| Most of this stuff, for me at least, is pretty printing.
Same here.
| Haven't yet
| heard from anyone regarding the advisability of inhaling XP as
| compared with rolling our own.
At first I thought you were considering using Windows XP!
Did you ask on C.L.L?
(I wouldn't blame you if you didn't - the elevated level of angst there
suggests a distinct tendency to either insufficient, or else grossly excess,
inhalation.)
Taking your question more seriously:
$ fgrep "#+" xp/*.lisp | wc -l
44
$ fgrep "#-" xp/*.lisp | wc -l
20
$ fgrep -i "kcl" xp/*.lisp
$ fgrep -i "gcl" xp/*.lisp
My feeling is that an attempt at porting XP is probably the best option as a
first step but I make that claim from a position of having no knowledge of
XP other than the info above.
While on the topic of the ANSI tests, I notice that the failure of the four
n/sublis tests is the result of a parameter ordering error in the :test
lambda expressions as follows:
>(SUBLIS '((1 . X) (5 . Y) (10 . Z)) (LIST 0 3 8 20) :TEST #'(LAMBDA (X Y)
(form
at t "X = ~A, Y = ~A~%" X Y) (AND (REALP X) (REALP Y) (< X Y))))
X = 1, Y = (0 3 8 20)
X = 5, Y = (0 3 8 20)
X = 10, Y = (0 3 8 20)
X = 1, Y = 0
X = 5, Y = 0
X = 10, Y = 0
X = 1, Y = (3 8 20)
X = 5, Y = (3 8 20)
X = 10, Y = (3 8 20)
X = 1, Y = 3
X = 1, Y = (8 20)
X = 5, Y = (8 20)
X = 10, Y = (8 20)
X = 1, Y = 8
X = 1, Y = (20)
X = 5, Y = (20)
X = 10, Y = (20)
X = 1, Y = 20
X = 1, Y = NIL
X = 5, Y = NIL
X = 10, Y = NIL
(0 X X X)
which on two other lisps I tried sets the anonymous function argument values
the other way around:
(SUBLIS '((1 . X) (5 . Y) (10 . Z)) (LIST 0 3 8 20) :TEST #'(LAMBDA (X Y)
(format t "X = ~A, Y = ~A~%" X Y) (AND (REALP X) (REALP Y) (< X Y))))
X = (0 3 8 20), Y = 1
X = (0 3 8 20), Y = 5
X = (0 3 8 20), Y = 10
X = 0, Y = 1
X = (3 8 20), Y = 1
X = (3 8 20), Y = 5
X = (3 8 20), Y = 10
X = 3, Y = 1
X = 3, Y = 5
X = (8 20), Y = 1
X = (8 20), Y = 5
X = (8 20), Y = 10
X = 8, Y = 1
X = 8, Y = 5
X = 8, Y = 10
X = (20), Y = 1
X = (20), Y = 5
X = (20), Y = 10
X = 20, Y = 1
X = 20, Y = 5
X = 20, Y = 10
X = NIL, Y = 1
X = NIL, Y = 5
X = NIL, Y = 10
(X Y Z 20)
My feeling is that this bug is either in the way "bin/dpp.c" parses defuns
(in this case in "o/lisp.d") or in "parse_key()". I have yet to start
debugging this one. Either way it seems to be quite a dangerous bug,
especially if that parsing error occurs in other parts of GCL.
Cheers
Mike Thomas.