[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Porting Femlisp (second trial)

From: Camm Maguire
Subject: Re: [Gcl-devel] Porting Femlisp (second trial)
Date: 01 Oct 2005 12:13:36 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


Nicolas Neuss <address@hidden> writes:

> Camm Maguire <address@hidden> writes:
> > I'll try to get equalp hashing into head in the next few days.
> > Hopyfully we should have a t6 tag and another debian upload soon. 
> Wonderful!

OK, preliminary equalp hashing is in CVS head.  Are you comfortable
compiling from there, or do you prefer to wait for Debian package
migration.  I still have a few other items that need going in before I
tag t6 and make another Debian upload.

> >> I also encountered the following bug.  I have a file debug.lisp containing
> >> both package definition and code using this package in the same file.
> >> Compiling works fine, loading the result works fine, too.  However, if I
> >> restart gclcvs and load the object file an error is thrown:
> >> 
> >>     address@hidden:~/CL-HOME/femlisp/src/basic$ gclcvs
> >>     GCL (GNU Common Lisp)  2.7.0 ANSI    Sep 10 2005 12:05:30
> >>     ...
> >>     >(compile-file "debug.lisp")
> >>     ...
> >>     >(quit)
> >>     address@hidden:~/CL-HOME/femlisp/src/basic$ gclcvs
> >>     ...
> >>     >(load "debug.o")
> >>     Loading debug.o
> >>     Error in EVAL [or a callee]: The package named FL.DEBUG, does not exist
> >> 
> >
> > Do you have this in a self-contained-file form that i might reproduce
> > locally and fix?
> I have put a sample at
>   <http://sit.iwr.uni-heidelberg.de/~neuss/misc/debug.lisp>
> which breaks for me (gclcvs from Debian/unstable).

Thank you for this.  This is indeed a reproducible bug.  It will
require a radical change which I'm hesitatnt to attempt at this
moment.  Basically, GCL writes an initialization lisp code sequence
at the end of each compiled file.  It reads the code, loads the
object, identifies the objects in the code with their addresses in the
loaded binary, then evaluates the forms.  What it needs to do is read
one form at a time, identify, and eval, etc.  You make and use the
package in the same initialization sequence.  A standard workaround is
to put all your defpackage statements in a separate file which is
loaded first.  Is this doable for you?

We will eventually get to this, but it would appear that other
priorities are more pressing at the moment.  Please let me know how
this might impact your work -- that is how the pririties are set in
the first place :-).

Take care,

> Yours, Nicolas.
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel

Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

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