gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian


From: Gabriel Dos Reis
Subject: Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian
Date: Wed, 05 May 2010 17:47:40 -0500

Camm Maguire <address@hidden> writes:

| Greetings!

Hi Camm,

| Gabriel Dos Reis <address@hidden> writes:
| 
| > Faré <address@hidden> 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.

| address@hidden:~/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?




reply via email to

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