Greetings! Gabriel Dos Reis <[email protected]> writes:
> Faré <[email protected]> writes: > > | > Dear Camm, > | > | >> Based on your feedback, I removed clc and tried again. Passed that > | >> point, I found a few more issues. > | > > | BTW, who's responsible for fixing the clc installation scripts for gcl? > | Could there be an easy bypass like the GCL_ANSI=t thingie? > | Could there be different executable names for different purposes? > | gclcltl1 gclansi gclclc, etc. - and gcl would be a symlink > | to one of the above. > > I rather use a command line option than having 4 or 5 versions of GCL > executable, all essentially the same. > Or environment variable? > | Also, I don't understand why debian needs to have both gcl 2.6 and gcl 2.7. > | Is 2.6 still supported? Is there some important program that only works in > | 2.6 and not in 2.7? > > GCL-2.6.x has been very stable for ages with most of its bugs and > workarounds well documented. GCL-2.7.0 looks does not provides that > kind of stability yet. As you have noticed, defpackage is one area > where things are murky. > Quite true. 2.7.0 is unstable, but hopefully will become prime time eventually. > > | > | >> 1- the fasl compiler tries to be clever with packages and apparently > | >> treats defpackage specially. To go around that issue, I specially > | >> defpackage trivial packages on gcl. I tried to write some complex > | >> macrolet that does the right thing on either gcl or other systems, but > | >> somehow it didn't make gcl happy. > | > | > Are you referring to a reodering of defpackage statements? Do you > | > have a sample source file showing this? > | > > | Here's a reduction of the bug. Try to compile a file that has this, > | then try to load it from a fresh lisp image: > | > | (in-package :cl-user) > | (eval-when (:compile-toplevel :load-toplevel :execute) > | (eval '(defpackage :foo (:use :cl)))) > | (in-package :foo) > | (defvar *hello* 'world) > | > | I suppose gcl, like ecl, does some magic optimization for interning symbols > | in fasls, with special treatment of defpackage. Problem being, when the > | defpackage only happens at execution time, the optimization is defeated > | and becomes a pessimization that breaks the fasl. > > note that defpackage is atually a separate package in GCL, that > sometimes causes troubles if you don't use the package defpackage. > Is this a problem? c...@localhost:~/debian/gcl/gclcvs/tmp$ GCL_ANSI=t gclcvs GCL (GNU Common Lisp) 2.7.0 ANSI May 4 2010 15:58:14 Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl) Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files set to /tmp/ >(find-symbol "DEFPACKAGE") DEFPACKAGE :INTERNAL >(eq 'defpackage 'defpackage::defpackage) T > Take care, > > > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
