the reason i’ve got this split into two modules is the following: • the first cherry module wraps an emscripten-built ES6 module, making cljs/js functions that cleanly interface with both the C functions and emscripten’s memory allocation in JS, and switches between WASM and JS depending on the environment’s capabilities. that cherry module both serves as the base for the second cherry module AND is functional enough to work inside graaljs so that on the JVM, if the native library isn’t available for FFI, it can run the same functions through graaljs using the mjs cherry built • the second cherry module is the outward-facing NPM module which makes a JS-ecosystem-friendly wrapper • in an ideal world, the cljc does two things: provides a clj/cljs API which 1) for :clj chooses between chooses JNA FFI or the cherry-built graaljs module and handles memory allocation and deallocation consistently, or 2) for :cljs parallels the JVM logic but instead of calling into FFI or graal just uses the first cherry module.

but if cherry can’t read a cljc file, i can just split that last step into a .clj and .cljs file which will have similar content

yes, it should work, but let me double check

ah yes, a bug, let me fix that

Fixed in 0.1.9

Thanks!

I'm not sure what you're referring to

very fair. you’ve got node_test.cljs — you run cherry on that, then run node on the .mjs it spits out, which itself uses the node testing module, which then provides output?

correct

lovely, thank you

to work on generative testing, would you suggest just having a dev dependency on fast-check and doing it via js?

(i assume test.check is out since spec is out)

I think so

unless we can get test.check to compile with cherry, which I think won't work yet