Compiled COMPILE forms at load time Bug
Helmut Eller
heller at common-lisp.net
Thu Mar 11 15:48:38 CET 2010
* Raymond Toy [2010-03-11 15:18+0100] writes:
> On 3/10/10 1:27 PM, Helmut Eller wrote:
>>
>> We could add this
>>
>> (when (typep definition '(and function (not eval:interpreted-function)))
>> (when name (setf (fdefinition name) definition))
>> (return-from compile (values definition nil nil)))
>>
>
> If I understand this correctly, this will just return the original
> definition.
Right. And this should also work if the function has no debug-info at
all e.g. because it was compiled with (debug 0).
> If so, then I wasn't quite clear about the (compile 'foo)
> example. The second compile would actually recompile foo from the
> original sources, not return the already previously compiled function.
> This is handy if you've changed something like a macro or inline
> function and want to compile foo again to see the effect.
Hmm.. good point.
>> right before the with-compilation-unit form. We can't return-from
>> inside the with-compilation-unit without producing some error message so
>> we have to put it before it. We'd lose some restarts, but that should
>> only be noticeable if (setf (fdefinition ..)) hits a definition lock and
>> it's not required by the spec anyway.
>>
>> Then form would be bound as it used to be
>> (form `#',(get-lambda-to-compile definition).
>>
>>
>>> I think we still need the additional fix in function-lambda-expression
>>> in case the compiled-debug-info-source is NIL.
>>>
>> I think we always have the lambda expression for interpreted functions.
>>
>>
> Yes, this is true. But for some reason, in Madhu's example, the
> compiled-debug-info-source is NIL, hence the traceback that he shows.
The problem with Madhu's example is that the debug-info is back-patched
sometime later after the top-level code is executed. This is not easy
to fix without changing the way things are dumped to the fasl file.
Helmut
More information about the cmucl-imp
mailing list