gcl-devel
[Top][All Lists]
Advanced

[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





reply via email to

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