On 4/26/10 6:16 AM, Madhu wrote:
* Raymond Toy <4BD508B2.4090006@gmail.com> : Wrote on Sun, 25 Apr 2010 23:29:54 -0400:
| | | We now have: | | (PROGN | (DECLAIM (SPECIAL ABC)) | (UNLESS (BOUNDP 'ABC) | (SETQ ABC NIL)) | (SETF (DOCUMENTATION 'ABC 'VARIABLE) '"abc") | (EVAL-WHEN (:LOAD-TOPLEVEL :EXECUTE) | (SETF (INFO VARIABLE INTL:TEXTDOMAIN 'ABC) NIL)) | (LISP::SET-DEFVAR-SOURCE-LOCATION 'ABC (C::SOURCE-LOCATION)) | 'ABC) | | I do not understand it, but that (setf info) causes the problem. When | that is removed, cmucl behaves as it used to. I don't understand why | that would cause the macro to be compiled again.
My report may have been misleading: I do not think that macro is being compiled again, it just looks that way from the notes that CMUCL prints.
I have not looked at the CMUCL code yet, but I my guess (without looking at any commits) is that this is more likely related to some source recording changes that may have been introduced.
AFAIK, there have been no changes to source recording. I think what is happening is that the eval-when for the (setf info) form is causing the compiler to compile the top-level form. It creates a component name by looking up the source file and finds frob-kevals-string form and uses that as the component name. That's what gets printed which makes it look like it's compiling frob-keyvals-string again. But it's really just compiling the defvar. When the (setf (info ...)) is replaced by a (lisp::%%defvar ...) where the new function %%defvar just calls (setf (info ...) ..), the printed messages are much nicer. So, I think it's not really a problem. Rather it's just a poor choice of component name by the compiler. So using %%defvar is a possible solution. Ray