Date: Sun, 19 May 2013 15:02:21 -0700 From: Matt Birkholz <m...@birkholz.chandler.az.us>
> From: Taylor R Campbell <campb...@mumble.net> > Date: Sun, 19 May 2013 17:08:52 +0000 > > [...] > > For microcode primitives, it is not a priori the case that > interrupts are disabled on entry. Le Machine is in what state? Not "in a callout"? It is not up and running, creating callback tokens and making callouts to register them with the toolkit? You'll have to lay a usage scenario on me, bro. And explain why we are talking about "microcode primitives" now, and not "callbacks". All I meant is that when control enters a microcode primitive, any interrupts may be enabled or disabled. If the microcode primitive doesn't touch the interrupt mask and makes a callback using the mechanism I described, then the set of interrupts that are enabled when control enters the callback is the same as the set of interrupts that were enabled on entry to the microcode primitive. > and using it without installing things in > $PREFIX/lib/mit-scheme-$ARCH doesn't seem to be supported. You can install shims in the first (existing) directory on your MITSCHEME_LIBRARY_PATH, i.e. anywhere that exists. I thought I said something like that in the manual, but now I can't find it. Maybe I'll just twiddle the example to install in $HOME/.scheme-9.1/... At the very least it should be possible to work in the working directory without touching MITSCHEME_LIBRARY_PATH or anything in it, just like we can (cf "foo") and then (load "foo"). That way, there is a chance we could write automatic tests for it that don't mess with the installed files. Speaking of which, do you have any automatic tests for the FFI? > (and the grovelling mechanism will get in the way of any attempt at > cross-compilation), when you're already generating C code for the > shims. I didn't notice any problems while cross-compiling. My Gtk interface works in i386, x86_64 and (32 *and* 64 bit) C. ? Geez, YOU recommended the grovelling mechanism to me (in 2006)! Sorry. At the time I didn't know any better... MIT Scheme doesn't currently support cross-compilation at all (which is a bug to be fixed, not to be encouraged), but what it does support is sharing compiled code and bands between operating systems which have different ABIs. Storing the output of the groveller in compiled code or in bands will break this -- even for interpreted-only bands. I have some developer-level documentation that has grown stale over the years, but most of the following is still accurate. Perhaps it can help. You might just skip to "@node C FFI Callbacks"... Thanks, I'll take a look. _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
