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

[Faré]

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

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?

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


>> 2- relative pathnames are parsed by gcl without a :relative in the
>> directory component. That's a gcl bug. I now work around in
>> merge-pathnames* and relativize-pathname-directory.
>
> This I think I can fix.
>
>> 3- GCL borks on this:
>> (MAKE-PATHNAME :HOST NIL :DEVICE NIL :DIRECTORY
>>            '(:RELATIVE :WILD-INFERIORS) :DEFAULTS #P"/**/*.*")
>>
>
> The issue is with :DEFAULTS #P"/**/*.*" -- two :wild-inferiors.  Also
> can be fixed.
>
Thanks!

>> 4- There seem to be errors in printing conditions that prevent our
>> print-methods from being called.
>
> Details?
>
If you get the latest asdf from git (or our tarball), you should be able
to run the test suite with:

   make test lisp=gclcvs

See test/run-tests.sh to customize how to invoke gcl.


>> 5- GCL is still missing support for ~W.
>
> I grok this.
>
I worked around by replacing occurrences of ~W with ~S in ASDF sources.
But even an imperfect support for ~W would be better than plain breaking,
I think.

Oops, I forgot to commit a #-gcl ecase #+gcl case in merge-pathnames*. Sigh.
While I'm at it, I have to improve lisp-version-string for gcl.

>> 6- something prevents janderson's logical pathname tests from working on GCL.
>
> Where are these?  How do they fail?
>
They are part of the asdf test suite. I haven't tried hard enough to
reduce a test case, as I'm not *that* interested in logical pathnames
personally. But if you have an official bug tracker (for ADSF, we're
happy with launchpad.net), it would be nice to at least register a bug.

>> 7- when compiling fare-utils, it looks like ASDF itself is working,
>> but GCL borks on base/macros.lisp.
>
> I can't find this file.  Can you post a transcript?
>
It's in the latest fare-utils from git.
Apparently, compiling this fails:
(defmacro with-nesting (() &rest things)
  (reduce #'(lambda (outer inner) (append outer (list inner)))
          things :from-end t))
;;; The constant NIL is being bound.

But this works:
(defmacro with-nesting ((&optional) &rest things)
  (reduce #'(lambda (outer inner) (append outer (list inner)))
          things :from-end t))

After fixing that, fare-utils looks like it loads.
While trying to load fare-utils-test, I realize that
(directory "/home/fare/cl/**/*.asd") apparently only went one level deep
under the specified directory and failed to locate
fare-utils-test.asd two levels deep.
Another GCL bug.

>> Enough for today. I'm releasing ASDF 1.715, which I believe works
>> better on GCL than any previous version of ASDF. You're welcome to
>> include it in GCL, submit patches, etc.
>
> Great!  At some point I should try to learn asdf.
>
ASDF is a good thing to support, because it opens your Lisp to a whole
lot of libraries.

> Wish it was at a
> lower level than CLOS so it could be used in building CLOS and more
> basic components.  There have been various proposals to include
> defsystem in GCL from time to time, but it does not appear in the lisp
> standard.  I suppose asdf is the de facto standard of the moment, but
> it would be great to have a non-moving target.
>
ASDF hasn't moved much, at least, not in terms of user-visible interface.
If you want a system that can help you bootstrap, you can give a look at
XCVB. It doesn't support gcl yet, but that shouldn't be THAT hard to add.
XCVB requires CLOS and much more -- but not in the TARGET lisp, only in
the HOST lisp.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
A successful [software] tool is one that was used to do something
undreamed of by its author.
                — S. C. Johnson