This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
"Ray" == Ray Dillinger <bear@xxxxxxxxx> writes:Ray> I think that you're striking a rather aggressive balance favoringRay> FFI functionality over portability. While there's nothing wrongRay> with that, there's probably room for a simpler SRFI that specifiesRay> 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