Fork me on GitHub
#cherry2022-08-02
>
wcohen14:08:19

Quick question, sorry to bother -- I couldn't quite tell from the README or this slack channel's history. I'm working on trying to make a clojure/clojurescript library that on the JVM wraps a native library, and in clojurescript uses an emscripten-transpiled version. I'm also working on making a java class that allows non-clojure JVM users to more idiomatically call into the library, and would like to make an equivalent javascript version for non-clojurescript users. Is it fair to say that cherry is probably the best current bet for getting a CLJS namespace working in JS and published on NPM? If not cherry, I'd probably have to go deep into using shadow to get everything compiled for NPM?

wcohen15:05:37

@U04V15CAJ extremely dumb (and 6 months late slow followup to this):

borkdude15:05:24

never too late :)

wcohen15:05:59

i've got my little emscripten-transpiled wasm/wasm2js library exported, either as an es5 or mjs module, and I've got them currently living in resources/etc to use inside clojure so that graaljs or graalwasm can consume them even when there's no native compiled version available, which pretty much works

wcohen15:05:41

my question now is how best to integrate this so it can be a cljs/cherry library -- should i just be copying this big old js or wasm file back into my source tree or can i refer out to resources too?

wcohen15:05:33

my goal is to publish a .jar for the JVM that falls back to graal, but also to publish an npm module for the JS world. i assume i want to follow the embedding cherry tutorial so that cljs can use the cherry version rather than having to wrap once for npm and again for pure cljs

borkdude15:05:39

@U2B2YS5V0 I'm a bit confused

wcohen16:05:28

right. my goal is to wrap https://github.com/OSGeo/PROJ for both the JVM and JS. I've got it building for darwin-aarch64 and can cross compile for other architectures (fat jars a la sqlite-jdbc etc etc). As a fallback when the native isn't available for a platform, I've also got it working so it can load graal.js or graalwasm on the JVM and run PROJ on the JVM, if non-performantly but as a fallback. additionally... i figure cherry can be a way to then wrap this for JS while reusing some chunk of all this wrapping code -- there's all kinds of malloc/free stuff that i either have to do using panama/jna on the JVM side or using emscripten functions, so end users for both JVM/JS will want a gc-safe wrapper. do i have to copy the big emscripten-generated chunk directly into the source tree for cherry to be able to use it, or can i refer to it from earlier in the source tree, like in the resources section? no matter how i run the incantation i'm struggling to get cherry to see the module

borkdude16:05:48

> additionally... i figure cherry can be a way to then wrap this for JS what does your wrapper has to do with CLJS?

borkdude16:05:27

just trying to understand better

wcohen16:05:02

right, sorry, i'm twisting myself up a little too. i've got it working on the clojure side -- but i'm also trying to then do the js wrapper around the emscripten in cljs

borkdude16:05:07

so PROJ is a native library. you want to use it via Node.js?

wcohen16:05:09

ideally in one repo so i can keep them in alignment

borkdude16:05:58

and you would like to make this library run with both normal CLJS and cherry?

wcohen16:05:00

both node users and jvm users currently have to do ports, so i'm trying to be able to do it for clojure and clojurescript with the native, but then while i'm going through it all figure it'd be nice to let java and node users use it too

borkdude16:05:59

Does it already work with #C029PTWD3HR perhaps?

wcohen16:05:35

no. good observation. i'll start there and work out the kinks, then my problem may be clearer. many thanks as always @U04V15CAJ

borkdude16:05:07

@U2B2YS5V0 No problem. nbb may be a bit closer to CLJS classpath-wise, cherry doesn't really have a classpath currently. You can put your dep in nbb.edn and then try to use it

wcohen16:05:02

perfect -- that's probably where the weasel lies, with the classpath impedance mismatch

wcohen17:05:41

oh wait -- nbb needs node modules. so the catch here is that i don't have any other node package, just a local-to-this-project big .js file, so I don't think nbb will work. I guess THAT's my question. is there a way to reference a JS file in my cherry cljs namespace?

wcohen17:05:34

something like (:require ["./foo.js" as proj-js])). I don't even need it to have a namespace. Even just as a namespaceless object

wcohen17:05:12

if not -- does that mean that i need to first manually make a js-only super-basic npm package from what emscripten throws out, so that cherry can refer to it and wrap it accordingly more ergonomically?

wcohen17:05:06

i think that's it, unless i'm misunderstanding. i have to put the emscripten output in its own little npm package, from which there's two options. cherry can be used to write some cljs that ends up as a npm-facing wrapper of that library, and separately i can write some cljs-specific code so that cljs users can use it too, and that would live in the maven jar

borkdude19:05:02

@U2B2YS5V0 you can load JS from the classpath, but how it works might be a little bit different in shadow-cljs or in nbb, not sure. In nbb (:require ["./my.js"]) loads relative to the file you're in

wcohen15:05:12

For what it’s worth, I think I got it kind of working: 1. Build a transpiled thing using emscripten 2. Put that into a bare-bones npm package and webpack/babel it up into a nice compliant ES6 module that can live as its own package that cherry can see 3. Do all the nice emscripten memory handling, opening and closing, and thread safety checks in cljs via cherry, which can then be made available as its own front-facing npm package 4. Then webpack/babel THAT up into a boring vanilla ES5 js file, which graaljs can successfully parse 5. Back in JVM world, first try to load the native library and wrap that, and if that fails, call into the similarly-structured cherry-built npm package via graaljs without having to reduplicate all that logic again

wcohen15:05:21

Again, many thanks!

👍 2