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: Camm Maguire
Subject: Re: [Gcl-devel] gcl 2.7.0 hopelessly broken in debian
Date: Wed, 05 May 2010 18:36:34 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Greetings!

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?

> | 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?

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

>

Take care,


>
>
>

-- 
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]