[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Segmentation violation: c stack ok:signalling error with
From: |
Vanuxem Gregory |
Subject: |
Re: [Gcl-devel] Segmentation violation: c stack ok:signalling error with GCL-2.7.0 (cvs head) |
Date: |
Wed, 29 Nov 2006 20:24:46 +0100 |
Le mercredi 29 novembre 2006 à 11:07 -0500, Camm Maguire a écrit :
> Greetings! You are missing the dsetq macro definition, found in
> vmlisp.lisp, and used here for example in your file:
>
> (DEFUN |centerNoHighlight| (&REST #1=#:G4770 &AUX |argList| |text|)
> (DSETQ (|text| . |argList|) #1#) (|sayBrightly| (|center| |text|
> |argList|)))
>
> If dsetq is assumed a function, as is the default, this will not
> compile. With the definition, it compiles fine.
Thank you very much, I didn't know. I knew that some symbols were
missing, normally this file is compiled by the depsys image which
contains a lot of these missing symbols, but thought it was a problem
with the GCL compiler, a "segmentation violation" error is not common
when compiling a file.
In fact I have encountered, when trying to compile Axiom (for
experimentation purpose only (GCL and Axiom)), a lot of unknown errors,
for example with cvs head mfsfun called with incorrect number of
argument. I stopped to use this image and tried to use the gclcvs from
Debian unstable. After some modifications of the Axiom code, for example
the string-char type seems no longer available (and not portable too), I
nearly finished to _compile_ the interpreter, which is probably the most
"hard" part, but for some odd reasons modifying a file and recompiling
(with a 'make' in the root directory of Axiom) leads to some new errors
that are difficult to debug the best example of errors is
"The default dispatch macro signalled an error".
> In general, the lisp produced by axiom will need some work to conform
> to ansi package semantics, if this is ever desired. In particular,
> one needs to insure that the symbol vmlisp::dsetq and boot::dsetq are
> the same.
There are some issues related to this, for example memq is
imported from gcl (in the system package in gcl-2.6) and defined
somewhere else.
Of course if I find some bugs with simple test case I'll submit them.
Thanks again for all of this,
Greg