Re: [MIT-Scheme-devel] sqlite3

[Taylor R Campbell]

   Date: Sun, 19 May 2013 15:02:21 -0700
   From: Matt Birkholz <address@hidden>

   > From: Taylor R Campbell <address@hidden>
   > 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.