The saga continues... 2008/11/20 Linas Vepstas <[EMAIL PROTECTED]>: > 2008/11/15 Neil Jerram <[EMAIL PROTECTED]>: >> 2008/11/12 Linas Vepstas <[EMAIL PROTECTED]>: >> >>> Yes, of course, the problem remains. >> >> Explanation: >> >> Thread 1 is the first thread that does any Guile stuff, so it loads >> boot-9.scm, which means that it ends up in the (guile-user) module. >> >> Thread 2 hasn't done any (set-current-module ...), so it stays at the >> default, which is (guile). >> >> Solution: add (define-module (guile-user)) to the code that you >> execute in thread 2. > > This won't actually work, for some reason or another. > Once I am in the second, third, etc. thread, then I cannot > set the current module to be guile-user. So, for example: > > scm-interp> (current-module) > #<module (guile) f5e93e80> > scm-interp> (define-module (guile-user)) > #<directory (guile-user) f5e96600> > scm-interp> (current-module) > #<module (guile) f5e93e80> > scm-interp> (set-current-module (define-module (guile-user))) > #<directory (guile-user) f5e96600> > scm-interp> (current-module) > #<module (guile) f5e93e80> > > Here, scm-interp is my shell, which just calls > scm_c_eval() from C code.
This is because the C eval uses the dynwind to get into a certain module. So if one *sets* the module, the dynwind mechanism promptly unsets it as one returns after the evaluation. --linas
