This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-02
Channels
- # announcements (11)
- # aws (3)
- # babashka (34)
- # beginners (20)
- # biff (2)
- # calva (3)
- # cherry (29)
- # cider (6)
- # cljs-dev (9)
- # clojure (124)
- # clojure-europe (12)
- # clojure-norway (5)
- # clojure-uk (2)
- # clojurescript (32)
- # conjure (11)
- # datalevin (1)
- # datomic (16)
- # deps-new (1)
- # etaoin (6)
- # holy-lambda (10)
- # honeysql (28)
- # hyperfiddle (21)
- # jackdaw (2)
- # jobs (2)
- # leiningen (15)
- # missionary (12)
- # off-topic (132)
- # other-languages (1)
- # pathom (13)
- # rdf (10)
- # re-frame (8)
- # reagent (5)
- # releases (1)
- # remote-jobs (4)
- # shadow-cljs (32)
- # tools-deps (6)
- # vim (15)
- # xtdb (24)
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?
@U04V15CAJ extremely dumb (and 6 months late slow followup to this):
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
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?
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
@U2B2YS5V0 I'm a bit confused
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
> additionally... i figure cherry can be a way to then wrap this for JS what does your wrapper has to do with CLJS?
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
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
no. good observation. i'll start there and work out the kinks, then my problem may be clearer. many thanks as always @U04V15CAJ
@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
perfect -- that's probably where the weasel lies, with the classpath impedance mismatch
I think it's this issue: https://github.com/squint-cljs/cherry/issues/64 https://github.com/squint-cljs/cherry/discussions/95
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?
something like (:require ["./foo.js" as proj-js]))
. I don't even need it to have a namespace. Even just as a namespaceless object
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?
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
@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
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