gcl-devel
[Top][All Lists]
Advanced

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






reply via email to

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