[Openmcl-devel] CCL with SLIME/setting global variables

Gary Byers gb at clozure.com
Fri Jan 9 14:20:33 PST 2009


If I understand the question correctly, the answer is that

(CCL::%SET-SYM-GLOBAL-VALUE sym value)

behaves like CL:SET, only it ignores any thread-local/dynamic
bindings of the variable and modifies the global/static binding.

The standard stream variables (*TERMINAL-IO*, etc.) are bound
in each thread (well, each thread that's created by the lisp);
the initial values of these bindings are the static values
of the variables.  So, setting the global/static value of
*TERMINAL-IO* would affect the value of *TERMINAL-IO* in any
subsequently-created threads.



On Thu, 8 Jan 2009, sblist at me.com wrote:

> Hi folks,
>
> We're experiencing some multi-threaded pain when using CCL
> with SLIME. Two fairly important things, globally redirection IO
> and installing the SLDB debugger globally are not working.
>
> It seems like the issue is with setting special variables globally,
> so I was wondering if anyone had any insight into that on CCL.
>
> I've also attached Helmut's response to slime-devel.
>
> Regards,
>
> - Scott
>
> Helmut Eller:
>
> "f those things work in SBCL but not in CCL then it probably means that
> CCL implements some thread related features differently.
>
> Global IO redirection only works if *standard-output* etc. are truly
> global variables.  If those variables are thread-local we can't set them
> with a simple setf and would have to use something else, e.g. with a
> backend specific function setf-global.  I don't know how these things
> work in CCL; you could ask the CCL developers how to do it properly.
>
> For the debugger, we set *debugger-hook* (again if that isn't a global
> variable it has no effect on other threads).  We also have
> a backend spefic function install-debugger-globally which could use
> implementation specific tricks, but for CCL it doesn't.
>
> It looks like BREAK invokes the Slime debugger only inside
> call-with-debugger-hook. See also *break-in-sldb* in swank-openmcl.lisp.
> Maybe it works better if you set that to T.
>
> In general, you can invoke the Slime debugger by calling
> swank:invoke-slime-debugger.  This might be more robust than relying on
> *debugger-hook* etc."
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list