Re: [MIT-Scheme-devel] sqlite3

[Matt Birkholz]

> From: Taylor R Campbell <address@hidden>
> Date: Sun, 19 May 2013 23:13:35 +0000
> 
> [...]
> 
> 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").

At the very, VERY least it should work, withOUT regard to your current
working directory.  I think your analogy to .bin/com's is at fault
here.  You might think of (C-include "fubar") as a syntax-time
(load-option 'fubar) instead.  If you consider that it prepares to
generate code that will on-demand dlopen fubar-shim.so at a later
date, then it might not seem so wise to search the *current* working
directory.  It definitely seems NOT wise to someone who is particular
about what he dlopens.  Who loads a shared library from the current
working directory?  Surely such types can be asked to add "--library
lib" to their build scripts (when not in the grip of riastradh).

> 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?
> [...]
> 
> MIT Scheme doesn't currently support cross-compilation at all (which
> is a bug to be fixed, not to be encouraged)

You are just trolling now.

> 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.

Create-thread also breaks this, ever since someone added the near-
useless, ABI-dependent floenvs and stuck one in each thread.

In (my) practice the ABI dependence only goes so far.  For example my
implementation of Edwin's Gtk screens uses no (C-... ) syntax.  The
FFI option is not needed.  It DOES load-option ABI-dependent
.bin/com's containing code that will on-demand dlopen a gtk-shim.so,
but the Gtk Screen implementation itself is ABI independent.  Its
.bin/com's can use Gtk options wrapping all kinds of toolkits --
different versions, architectures, operating systems...