[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: |
01 May 2007 14:07:41 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! I'm not very happy about the (not (eq 'lambda (car
form))), but it might be worth testing this:
(defun wrap-literals (form &aux fd)
(cond ((and (consp form) (eq (car form) 'quote))
(let ((x (cadr form)))
(if (and (symbolp x)
(eq :external (cadr (multiple-value-list (find-symbol
(symbol-name x) 'lisp)))))
form
`(load-time-value (si::nani ,(si::address x))))))
((and (consp form) (symbolp (car form)) (not (eq 'lambda (car form)))
(setq fd (macro-function (car form))))
(wrap-literals (cmp-expand-macro fd (car form) (cdr form))))
((consp form)
(cons (wrap-literals (car form)) (wrap-literals (cdr form))))
((symbolp form)
(unless (symbol-package form)
(unless *tmp-pack*
(setq *tmp-pack* (make-package (symbol-name (gensym)))))
(import form *tmp-pack*))
form)
((or (rationalp form) (characterp form))
form)
(`(load-time-value (si::nani ,(si::address form))))))
Take care,
Matt Kaufmann <address@hidden> writes:
> By the way, the times for the ACL2 regression suite are virtually
> identical before and after the following change (added to a compiled
> ACL2 source file):
>
> #+(and gcl (not ansi-cl)) (defun compiler::wrap-literals (x) x)
>
> ; Before above addition:
> 12990.367u 274.629s 3:46:08.34 97.7% 0+0k 0+0io 5pf+0w
> ; After above addition:
> 12987.607u 275.321s 3:45:30.28 98.0% 0+0k 0+0io 0pf+0w
>
> I've saved a copy of the development sources that I used, so that I
> can test an alternate wrap-literals that you send me.
>
> -- Matt
> Sender: address@hidden
> Cc: address@hidden
> From: Camm Maguire <address@hidden>
> Date: 30 Apr 2007 13:35:32 -0400
> X-SpamAssassin-Status: No, hits=-2.5 required=5.0
> X-UTCS-Spam-Status: No, hits=-310 required=200
>
> 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
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] Re: GCL compiler bug: load-time-value and macroexpansion,
Camm Maguire <=