[Openmcl-devel] CCL bug?

[Sudhir Shenoy]

Thanks for the pointer. It is clear now.

Although I do not currently have this problem (libraries are my own so  
I can wrap the declaim declarations in an eval-when) what is the  
recommended procedure to ensure that there are no optimization side  
effects when loading a third-party library? Should one do the  
equivalent of getting the current optimization settings, loading the  
library and then setting the optimization settings back to what they  
were prior to the load?

This, of course, really makes a difference only when developing code  
in a live REPL where a CCL crash could take some partially developed  
code with it (BTW, this didn't actually happen to me because I was  
inside Emacs/SLIME but when raising hypothetical questions, I guess  
worst-case scenarios are admissible :-)

Cheers
Sudhir

On Mar 16, 2010, at 1:51 PM, R. Matthew Emerson wrote:

>
> On Mar 16, 2010, at 12:34 AM, Sudhir Shenoy wrote:
>
>> You are right. I get
>> ((SPEED 3) (SAFETY 0) (COMPILATION-SPEED 0) (SPACE 1) (DEBUG 1))
>> in a fresh CCL instance. However, executing "ccl --no-init" gives me
>> ((SPEED 1) (SAFETY 1) (COMPILATION-SPEED 1) (SPACE 1) (DEBUG 1))
>>
>> I am not setting the speed/safety settings explicitly in my ccl-
>> init.lisp. However, some libraries that are autoloaded on startup are
>> setting them.
>>
>> I guess it is correct to assume that I need to explicitly set (speed
>> 1), (safety 1) after loading the libraries. I was under the  
>> impression
>> that the compiler settings only affect the compilation units (files)
>> and should reset automatically. However, looking at the Hyperspec  
>> now,
>> it does say that it is unspecified if declaim-ed declarations persist
>> after compilation ...
>
> It's probably not compile-time side-effects that are causing the  
> trouble, but load-time effects.
>
> See:
> http://www.clozure.com/pipermail/openmcl-devel/2009-August/010168.html
>