Bun gets “bun:FFI” – call native libraries from JavaScript
twitter.com
twitter.com
Here's an example that uses raylib (GUI library), without any extra bindings/build step: https://github.com/theoparis/bunray/blob/main/src/example.ts
bun:ffi works by embedding TinyCC - https://github.com/TinyCC/tinycc and then just-in-time compiling C functions that perform type conversions from JavaScript <> C ABI and back. It's faster than node.js' napi (which bun also supports) because it avoids the dynamic library overhead via doing type conversions inline.
For bun, I really wanted something simpler than napi without the performance drawbacks of libffi.
If you want to see the generated C bindings, you can do this:
import { viewSource } from "bun:ffi";
console.log(
viewSource(
{
hello_world: {
returns: "float",
args: ["float"],
},
},
false
)[0]
);For example can you embed a package like Guile in JS with bun:ffi?
https://www.gnu.org/software/guile/docs/guile-tut/tutorial.h...
Opaque pointers and preprocessors often trip FFI up
generated types - not yet, though if it's a pointer you can pass that
struct support isn't implemented yet - so just numbers, pointers and also strings. still not sure the best way to do structs efficiently. passing an object to the function call will be too slow.
I doubt its ready from production, but as a dev runtime, it works perfectly.
The one feature I think it is missing is the ability to compile the entire project into a single executable.
The ball is in your court
Edit: Your changes are also not cleaned up, https://github.com/node-ffi-napi/ref-napi/compare/latest...a... < includes adding a templating engine as well?
I often fix some code in my fork, open a pr, but author asking for tests or change something but I simply have no time for it, and for author it will be much easier because he/she is familiar with code style, testing framework, etc. And problem remain unfixed in main repo
But when this happen, do you do the same thing nshm does and writes about how the whole project is broken and they won't merge your uncompleted code?
It might be broken for parent commentator that goes around complaining about it, because they encounter that specific bug. But seems not everyone is getting hit by it, then someone would at least contribute a fix to it, which no one has done yet.