Email list hosting service & mailing list manager

Couple things... felix (22 Dec 2003 17:51 UTC)
(missing)
Re: Couple things... felix (24 Dec 2003 12:01 UTC)
Re: Couple things... Jim Blandy (24 Dec 2003 16:29 UTC)
(missing)
(missing)
(missing)
Re: Couple things... felix (24 Dec 2003 11:43 UTC)
Re: Couple things... tb@xxxxxx (24 Dec 2003 23:30 UTC)
Re: Couple things... Michael Sperber (27 Dec 2003 18:46 UTC)
Re: Couple things... felix (24 Dec 2003 12:40 UTC)
Re: Couple things... Michael Sperber (26 Dec 2003 15:16 UTC)
(missing)
(missing)
(missing)
(missing)
(missing)
(missing)
Re: Couple things... felix (04 Jan 2004 18:51 UTC)
Re: Couple things... Tom Lord (04 Jan 2004 22:13 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:18 UTC)
Re: Couple things... Tom Lord (05 Jan 2004 21:53 UTC)
Re: Couple things... Michael Sperber (05 Jan 2004 19:19 UTC)
Re: Couple things... felix (04 Jan 2004 18:42 UTC)
(missing)
(missing)
(missing)
Re: Strings/chars Tom Lord (24 Dec 2003 04:47 UTC)

Re: Couple things... felix 04 Jan 2004 18:53 UTC

On Sat, 03 Jan 2004 20:54:43 +0100, Michael Sperber
<xxxxxx@informatik.uni-tuebingen.de> wrote:

>>>>>> "Ray" == Ray Dillinger <xxxxxx@sonic.net> writes:
>
> Ray>     I think that you're striking a rather aggressive balance
> favoring
> Ray>     FFI functionality over portability.  While there's nothing wrong
> Ray>     with that, there's probably room for a simpler SRFI that
> specifies
> Ray>     a less general and more portable FFI.  Perhaps that SRFI should
> Ray>     come before this one.
>
> That certainly makes sense.  However, as I argued further up in this
> thread, I don't think the "less general FFI" Felix envisioned is very
> useful.
>

I do not envision a less general FFI. Please read more carefully.
I was talking about a completely different approach (not necessarily
tool-based).

Note that the Chicken FFI (for example) does not allow GC during the
invocation of foreign code, unless callbacks are explicitly used,
and that all arguments are normally passed as valid C data (i.e.
C code is provided a "view" of the data that it can understand,
similar to what I proposed). It has been useful enough to write
wrappers for OpenGL, GLUT, BLAS, SQLite, the Irrlicht 3D engine,
Sockets, most of POSIX, JAPI, MD5 stuff, Tiny CC, PCRE, SDL, GMP,
SCOP, Spread and many other things, which should be enough for
the start...

cheers,
felix