[Openmcl-devel] CCL bug?
sshenoy at gol.com
Tue Mar 16 05:11:09 UTC 2010
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 :-)
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
>> that the compiler settings only affect the compilation units (files)
>> and should reset automatically. However, looking at the Hyperspec
>> 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.
More information about the Openmcl-devel