[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: GCL compiler bug: load-time-value and macroexpansion
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: GCL compiler bug: load-time-value and macroexpansion |
Date: |
30 Apr 2007 13:35:32 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! This should work. Would you be willing to test an
alternate wrap-literals if I get one together in the near-future?
Take care,
Matt Kaufmann <address@hidden> writes:
> Thank you, Camm. Unfortunately, after (setq compiler::*keep-gaz* t),
> then all the gazonk*.lsp files are left around. So I'm wondering if
> it would safe to do the following instead:
>
> #+(and gcl (not ansi-cl)) (defun compiler::wrap-literals (x) x)
> #+(and gcl (not ansi-cl)) (compile 'compiler::wrap-literals)
>
> A small test suggests that this may work, though I have no idea really
> what I'm doing. Should I expect the above solution to be OK?
>
> Thanks --
> -- Matt
> Sender: address@hidden
> Cc: address@hidden
> From: Camm Maguire <address@hidden>
> Date: 30 Apr 2007 12:16:06 -0400
> X-SpamAssassin-Status: No, hits=-2.5 required=5.0
> X-UTCS-Spam-Status: No, hits=-310 required=200
>
> Greetings, and thanks so much for this report!
>
> The issue in brief stems from ansification -- compile'ed forms must
> refer to the exact object literally referred to in the form, not a
> copy, so the traditional GCL print and compile-file won't work. The
> function is compiler::wrap-literals, which you can trace if
> interested. There is obviously a bug here -- most likely
> wrap-literals should do some selective macro-expansion, perhaps along
> the lines of compiler::portable-source in 2.7.0. I will see if I can
> come up with a solution which also retains our current (2.7.0)
> compatibility with the ansi tests for compile. If you have any
> suggestions, they are of course most appreciated. The tests in
> question as run thus:
>
> cd ansi-tests
> ../unixport/saved_ansi_gcl
> >(load "gclload1")
> >(load "compile")
> >(load "compile-file")
> >(rt:do-tests)
>
> There is an immediate work-around. Set the variable
> compiler::*keep-gaz* to t -- this avoids wrap-literals and behaves as
> the traditional compile via print/compile-file did. The idea is that
> there are certain packages in the ansi build, notably pcl, which
> compile functions which need to be linked later in gazonk files at the
> raw build stage. Even though pcl uses compile here, literal object
> reference is impossible as the running image at compile time is gone.
> So qualitatively if one needs to keep the gazonk files around, they
> better not refer to objects only available in the compiling image.
>
> This exception in all likelihood should not be there eventually, but I
> can't at the moment envision a bridge between ansi compile and
> traditional gcl compile without one.
>
> Comments/suggestions as always most welcome.
>
> Take care,
>
> Matt Kaufmann <address@hidden> writes:
>
> > Hello --
> >
> > It appears that the GCL compiler (at least: version 2.6.7 CLtL1, and
> > also version 2.7.0 ANSI as of about 11/27/06) is laying down calls of
> > lisp::load-time-value that are interfering with macro expansion.
> > Below is an example exhibiting the problem.
> >
> > Is there any simple workaround, such as (setq *some-compiler-switch*
> > nil)? By the way, the actual (much bigger) failure I had, from which
> > the example below is extracted, was only an explicit error when
> > calling COMPILE as shown below. When I put the function into a file,
> > I didn't see any problem with COMPILE-FILE, but I found bizarre and
> > somewhat nondeterministic behavior that went away when I avoided
> > compiling that function by loading the .lisp file instead.
> >
> > .....
> >
> > >(defmacro my-mac (b)
> > (list 'list
> > (if (and (consp b)
> > (stringp (car b)))
> > (list 'quote b)
> > b)))
> >
> > MY-MAC
> >
> > >(defun foo ()
> > (my-mac ("Guards")))
> >
> > FOO
> >
> > >(foo)
> >
> > (("Guards"))
> >
> > >(compile 'foo)
> >
> > Compiling gazonk4.lsp.
> > ; (DEFUN FOO ...) is being compiled.
> > ;;; The function (LOAD-TIME-VALUE (SYSTEM:NANI 139732192)) is illegal.
> > No FASL generated.
> >
> > Error: Cannot open the file NIL..
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by LET.
> > Broken at LOAD. Type :H for Help.
> > >>(quit)
> > sundance:~> cat gazonk4.lsp
> >
> > (lisp::defun user::foo lisp::nil (user::my-mac ((lisp::load-time-value
> (system::nani 139732192)))))sundance:~>
> >
> > Thanks --
> > -- Matt
> >
> >
> >
>
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah