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:
opaque pointers yes - 'ptr' or 'void*' as the arg type/return type. if you need to create a pointer then you can use a Uint8Array or a BigUint64Array.
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 haven’t looked in a while, what’s the status of Bun macros? For quite some time I’ve wanted a fast and ergonomic way to override built in runtime behavior for object/array literals. E.g. for an efficient implementation of the records/tuples proposal, for which I’ve thought Bun macros could be well suited. I think they’d be equally well suited to a specialized struct factory, which could bypass at least some of the overhead of JS runtime construction.
I have been playing with bun and I have to say I am now super impressed with it. As someone who likes to work in Typescript I now prefer it to both nodejs and Deno.
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.
FFI implementation in bun.js using tinyCC I’m impressive, it brings whole new level of performance. Also doesn’t require to have libffi or additional compiler in a system.
I hope more languages will have such functionality, it will bring us closer to possibility to use any existing code in language/runtime that we prefer
It seems like people have suggested multiple times to you to open a pull request with your suggested changes, rather than keeping them in your own repository. You asked for a merge in the comments too, but didn't address the concern regarding backwards-compatibility.
May be oot. As a maintainer I always try to accept help what people suggest, and make it even better. Without asking people to write tests or format code to match my preferences or make it cleaner…
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
Sure, but given that ref-napi gets about 227K downloads each month, I find it very unlikely that the project as a whole is broken.
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.
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:
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.
https://github.com/node-ffi-napi/ref-napi/issues/54
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.