[Top][All Lists]

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

Re: [Gcl-devel] Compiling GCL

From: Faré
Subject: Re: [Gcl-devel] Compiling GCL
Date: Tue, 5 Nov 2013 22:08:39 -0500

Dear Camm,

thanks a lot for your patch. I applied what I believe is
something equivalent on GCL but that doesn't change behavior on other Lisps.

On Tue, Nov 5, 2013 at 10:37 AM, Camm Maguire <address@hidden> wrote:
> Greetings!  OK, yor tests run with the following patch.  For now, don't
> use safe mode, which is *much* slower and less tested.  There is a gcl
> safe mode bug you have uncovered which we can later trace down, but your
> code is very complicated and it needs to be isolated.  Also, use nil in
> place of :unspecific for undefined types as with ecl.

> There are some condition related failures reported by the tests -- I'm
> happy to fix these, but please, boil it down to a standard lisp form or
> two which is not complying with the spec.  This way we can both work
> much faster.
Will try to do.

> I did a little looking re: the safe mode failure, and it involves this
> form in pathname.lisp:
>             (setf components (remove-if #'(lambda (x) (member x '("" ".") 
> :test #'equal))
>                                         components))
> When I compile this separately in safe mode I cannot trigger the
> failure.
Safe mode is "just" a declaim or declare (optimize (safety 3)), isn't it?

OK, I haven't yet isolated the issue, but I can tell that frob-substring
in uiop/common-lisp is not being compiled properly: it works when
defun'd at the REPL,
then fails when the function is compile'd.
This causes many of the errors during error reporting, which themselves
may be hiding other actual errors.

In any case, I have wasted too much time trying in vain to narrow down
what about frob-substring triggers a bug in the compiler. See below
gcl.lsp, which drives the loading or compilation of g1.lsp below
(loading works, compilation fails) with various simplified variants
of frob-substrings, that do or don't work,
despite the fact that the traces of WRITE-STRING are the same!
Apparently, there's an interaction between labels emit-string and recurse.
If stream is always bound to a stream, the bug doesn't occur,
which suggests that the bug is about something going wrong
when the stream is initially NIL, but is initialized by the
   (unless stream (setf stream (make-string-output-stream)))
and write-string is called with it (as demonstrated by the trace),
yet somehow the side effects don't happen and/or the result is thrown away.
If recurse is substantially simplified, then somehow
no mistake happens in write-string. This is puzzling,
but at this point I leave it to you.

Other minor issues:
 * late compilation of some code bits (eval's? CLOS effective
methods?) cause output
  while asdf.o is being merely loaded. Is there a way to either
precompile those bits,
  or to temporarily suppress the compiler output?
 * apropos seems to display a symbol once per package that has it,
  rather than once per package that is its home.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
[...] there is what I call  the "roundtrip fallacy": it is a mistake to use,
as journalists and some economists do, statistics without logic but the reverse
does not hold:  It is not a mistake to use logic without statistics.
  — N. C. Taleb, Fooled by Randomness, 2004.

Attachment: gcl.lsp
Description: Binary data

Attachment: g1.lsp
Description: Binary data

reply via email to

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