Clojurians Log v2

unfortunately this won't work, since the go macro expands into a complicated expansion which involves a lot of interop. in bb I've solved this by mapping the go macro to just virtual threads

normally copy-var does work with macros, so it should work like you wrote it, but it doesn't function without extra work

if this in a JVM

which I assumed so far

no actually sci embeded into a cljs project, I was hoping to be able to use the async library

oh CLJS, this is even more complicated since you need the whole ClojureScript analyzer to live client side. Won't work. Just go with promesa and forget about core.async in CLJS

okay cheers I suspected as much, thanks for the pointer 🙂

if you want to use promesa, you can just include this: https://github.com/babashka/sci.configs/blob/main/src/sci/configs/funcool/promesa.cljs

I will take a look not a library I have played with previously

check out this tutorial https://funcool.github.io/promesa/latest/promises.html

Tried pulling promesa using this import

[sci.configs.funcool.promesa :as sci-promesa]

Unable to resolve var: error in this context at line 175 sci/configs/funcool/promesa.cljs
--------------------------------------------------------------------------------
 176 |    'finally       (sci/copy-var p/finally pns)
 177 |    'future        (sci/copy-var future pns)
 178 |    'thread-call   (sci/copy-var p/thread-call pns)
 179 |    'handle        (sci/copy-var p/handle pns)
--------------------------------------------------------------------------------

which version of promesa are you using?

sci.config tests with funcool/promesa {:mvn/version "9.0.494"}

I'll check with the latest

funcool/promesa {:mvn/version "11.0.671"} I will try the version above

downgrading has fixed the issue for me, so looks like something may have changed in the library

ah, I see, breaking change:

Deprecate promesa.core/error alias to catch

okay great, should get me going for now so I can at least play with it a bit 🙂

I had a similar problem trying js-await to when I tried to pull in core.async again it's a macro so could be for similar reasons

The js-await macro is very simple, you can just copy this to your CLJS sources:

(defn ^:sci/macro my-js-await [_ _ [name thenable] & body]
  (let [last-expr (last body)

        [body catch]
        (if (and (seq? last-expr) (= 'catch (first last-expr)))
          [(butlast body) last-expr]
          [body nil])]

    ;; FIXME: -> here will always return a promise so shouldn't be necessary to add js hint?
    `(-> ~thenable
         ~@(when (seq body)
             [`(.then (fn [~name] ~@body))])
         ~@(when catch
             (let [[name & body] catch]
               [`(.catch (fn [~name] ~@body))]
               )))))

and then use copy-var to plug it in as js-await into your SCI environment

When you want to copy a var in SCI+CLJS the thing needs to exist in CLJS, not in the JVM

so it needs to be a regular CLJS function

The above is the js-await macro as a function with two extra arguments (for &form and &env) and with ^:sci/macro metadata

oh I see makes sense I had not considered the macro may be running on the jvm side with js-await, never actually thought about it do all macros run on the jvm or can you have cljs macros ?

I guess it works in both, and its just .clj vs cljs which decides if its jvm or cljs

macros are executed on the JVM with regular CLJS

It is possible to write a defmacro wrapper which defines a macro for both JVM and SCI though: https://github.com/mentat-collective/emmy/blob/b7cd9be12f08772b450efcf621ce56e0cc869d9d/src/emmy/util.cljc#L141-L155

not something I ever considered, but then I have only ever written a couple of macros 🙂

Any chance you have seen this before ? Could not resolve symbol: promesa.protocols/-bind I hit it with sci, the code works outside of sci, you can see the error in the console on this page and also download and run it outside of sci. https://clojure-demos.digitaloctave.com/page/example-maps#-create-a-map-using-google-and-promesa

please read and comment on this issue: https://github.com/babashka/sci.configs/issues/21

it's due to breaking changes in promesa that this doesn't work. unless you use promesa version 9. please help making clear that breaking changes is a no-no in the clojure ecosystem. one cannot build a platform on quicksand.

my bad sci is actually using funcool/promesa {:mvn/version "9.0.494"} the downloaded version is still using the newer one funcool/promesa {:mvn/version "11.0.671"} I actually downgraded after last time we spoke

but yeah the breaking changes are disappointing its one of the things I like in this eco system

oh ok

comment on that issue sound promising at least

just for context these pages are all generated from files like this https://clojure-demos.digitaloctave.com/documents/examples-maps.org the download button just tangles, but the site has its own deps when hosted hence the mismatch between the two.

nice

So far I see it (using graalvm) as a clojure compiled to a binary executable

I imagine that Java interop is unavailable dynamically at that point

But I'm about to get a haircut so sorry for bringing it up. We can chat about it later

Babashka support dynamic Java interop

Via SCI

Can chat tomorrow, sleep time over here :)

I guess I was trying to imagine why it was a subset and what the missing parts were. But yes let's talk tomorrow. In the meantime I'll RTFM 🙂

SCI (on the JVM) re-implements Clojure in a way that it can function in a GraalVM native-image (such as babashka). Not everything that Clojure does normally during compilation is possible in this re-implementation. E.g. you can't create new types in a native image since all types (classes) have already been AOT-ed. So things like deftype are limited in SCI (it's available but with caveats).

All normal clojure.core functions are available and just work the same way (because they ARE the same).