Camm Maguire <c...@maguirefamily.org> writes: | Greetings!
Hi Camm, | Gabriel Dos Reis <g...@cs.tamu.edu> writes: | | > Faré <fah...@gmail.com> 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? that would do too -- though my preference would be for a command line option. | > | 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. OK. | > | | > | >> 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? compared to the default behaviour of other free Lisp, yes. It can be quite confusing and eat up precious time, when one is unaware of that behaviour. | 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 yes, but why keep it that way in the new, upcoming, and shiny GCL-2.7.x? _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
