Fork me on GitHub

Is there a future ( implementation in ClojureScript? Thanks! ๐Ÿ™‚


it's not possible because js has no shared memory threading


core.async can help you arrange overlapping tasks via coordination on channels


This works well from nodejs if I just write the js equivalent. I can't make it work from cljs (using shadow-cljs, and I am not sure if that matters or not) Any pointer would be much appreciated at this point.


You require puppeteer as pup then use pop


hmm, thanks


Not sure how I could miss that. It's like after 2 days I just give up checking when nothing works.


thanks @U4YGF4NGM, can confirm that fixing the typo fixes the problem as well and it works just fine facepalm


@lpan The closest I think I've ever seen future in ClojureScript is John Newman's Tau stuff


In general CLJS can use native JS promises and other things available in the host environment

Sam Ritchie06:08:48

hey all, I'm seeing this error when I try and build a shadow-cljs project with com.taoensso/encore {:mvn/version "2.122.0"} included:

The required namespace "" is not available, it was required by "taoensso/encore$macros.cljc".
"clojure/java/io.clj" was found on the classpath. Should this be a .cljs file?


Check your classpath for taoensso/encore.cljs. Does it mention ?

Sam Ritchie06:08:25

it does not, but it does call this:

   [taoensso.encore :as enc-macros :refer
    [have have! have? compile-if
     if-let if-some if-not when when-not when-some when-let cond defonce
     cond! catching -if-cas! now-dt* now-udt* now-nano* -gc-now?
     name-with-attrs -vol! -vol-reset! -vol-swap! deprecated new-object]])


I think part of the problem is that this is cljx and not cljc, I am not certain it works correctly with today's cljs / cljc


I could be wrong though

Sam Ritchie06:08:25

I think that is fine - I deleted the cljx source from the jar, and the jar actually does contain appropriate clj and cljs files. the error's triggered by the clj file


Also encore$macros.cljc looks interesting - I've never seen something like this.


I don't mean just the cljx - I mean the way that the cljx splits / generates - but maybe encore is pulling other shenanigans too


it was a long time ago so I'm sadly fuzzy on the details, but I suspect there are some things that are overly clever and thus brittle


just clever enough to break in counterintuitive ways

Sam Ritchie06:08:31

yes, very strange

Sam Ritchie06:08:45

I'm poking around the jar now, to see if I can fix it in the generated files


that's probably the low effort short term fix, at the very least


Oh, did you figure out what's wrong with the generated files?


Just to be sure - have you tried removing every generated dir, like target, .shadow-cljs, and so on?


oh no - when I used encore I vendored the cljs / clj that it output, fixed them, and made them part of my repo


that was a lot less work than fixing the real bugs in the original cljx file


oops, you weren't asking me - your avis are too similar on my screen resolution! :D

Sam Ritchie06:08:12

@U2FRKM4TW let me double check


@U051SS2EU Oh come on - those two pixels are completely different! :D

Sam Ritchie06:08:42

yup, still there

Sam Ritchie06:08:56

I can tell it's picking up changes, since I can go into the jar and change hte cljs source

Sam Ritchie06:08:03

and the compile step sees the changes

Sam Ritchie06:08:25

trying to delete all references...

Sam Ritchie06:08:32

The required namespace "java.util.Date" is not available, it was required by "taoensso/encore$macros.cljc".


What is going on?

Sam Ritchie06:08:35

no idea, this is my first experience with shadow-cljs

Sam Ritchie06:08:41

I'm definitely confused


I have been using encore with shadow-cljs for about two years now with no hiccups.


Can you create a minimal reproducible example that you could share?

Sam Ritchie06:08:14

yeah, let me share something, one sec

Sam Ritchie06:08:02

it's not minimal, I can do that in the AM, but this is what I was working with:

Sam Ritchie06:08:17

on that branch, cd editor,

Sam Ritchie06:08:35


npm install && npm run watch
will kick the error out

Sam Ritchie06:08:48

thanks a lot for taking a look, super helpful

Sam Ritchie06:08:49

[:bootstrap] Build failure:
The required namespace "" is not available, it was required by "taoensso/encore$macros.cljc".
"clojure/java/io.clj" was found on the classpath. Should this be a .cljs file?

Sam Ritchie06:08:54

this is the error you'll see in short order


Heh, that's pretty strange - npm ci has failed but npm i works.


This is what I see:

[:bootstrap] Build completed. (278 files, 278 compiled, 0 warnings, 15.97s)
[:trusted] Build completed. (209 files, 208 compiled, 0 warnings, 18.61s)
 + /live.html
[:live] Build completed. (396 files, 395 compiled, 0 warnings, 18.86s)


shadow-cljs - config: /home/p-himik/tmp/maria/editor/shadow-cljs.edn  cli version: 2.8.36  node: v12.16.3
What does yours say?

Sam Ritchie06:08:03

shadow-cljs - config: /Users/samritchie/code/clj/maria/editor/shadow-cljs.edn  cli version: 2.8.36  node: v12.18.2

Sam Ritchie06:08:18

amazing... and that is on the branch I had linked?

Sam Ritchie06:08:25


Sam Ritchie06:08:43

(I may have buried that piece of info, apologies)


Oh, oops, didn't notice the branch. Let me retry.

Sam Ritchie06:08:01

you'll need npm install once more, since there's one extra dependency

Sam Ritchie06:08:13

but good smoke test that the repo works without the change!


Failed now, yes. But:

% clj -Stree | grep encore
com.taoensso/encore 2.91.0


That's a pretty old version.

Sam Ritchie06:08:15

oh! sorry, all of my reports from before were in fact on 2.122.0

Sam Ritchie06:08:25

I had rolled way back to see if the bug existed back then, which it does


Ah, right - I see that now.

Sam Ritchie06:08:33

in editor/deps.edn

Sam Ritchie06:08:57

I'm glad we have a repro, in any case

Sam Ritchie07:08:31

@U2FRKM4TW running just that single bootstrap build doesn't help...

Sam Ritchie07:08:37

npx shadow-cljs watch bootstrap

Sam Ritchie07:08:23

@U2FRKM4TW I've got to run for now, but thanks again for taking a look

Sam Ritchie07:08:31

will be back in the AM


Sure thing.

Sam Ritchie07:08:54

Maybe a super old Shadow version?


I used the same one.

Sam Ritchie07:08:37

Yes, I mean I just realized that the project is using an old version, and maybe the latest version of shadow-CLJS would fix this

Sam Ritchie07:08:52

Another test for the AM


Ah, right. Maybe.


Tried it - didn't work.


OK, got it working. Things you need to do: - Upgrade shadow-cljs (not sure if this is required - but better do it either way) - Replace the dependency on clojurescript in deps.edn with the right dependency on shadow-cljs - this is absolutely required, and in all projects that use shadow-cljs - In shadow-cljs.edn, replace :entries [maria.user] with :modules {:main {:entries [maria.user]}}. Use whatever name you want instead of :main


Alternatively - just don't use the :boostrap build at all if you don't need the bootstrapped version of the project. :)

Sam Ritchie13:08:53

@U2FRKM4TW amazing, thank you!!

Sam Ritchie13:08:27

I'm, as expected, hitting new errors now from the bootstrap build with these more modern versions, but i'm past that issue for sure

๐Ÿ‘ 3
Sam Ritchie14:08:45

@U2FRKM4TW investigating more, but :entries [maria.user] seems to be critical here for the app that runs

Sam Ritchie14:08:11

analyzer.cljc:3859 Uncaught TypeError: Cannot read property 'findInternedVar' of null
    at Object.cljs$analyzer$get_expander_STAR_ [as get_expander_STAR_] (analyzer.cljc:3859)
    at cljs$analyzer$get_expander (analyzer.cljc:3865)
    at eval (analyzer.cljc:908)

Sam Ritchie14:08:24

I'm trying to figure out where it relies in this item in entries

Sam Ritchie14:08:30

Wild! @U2FRKM4TW your solution completely fixes it... BUT breaks the ability for the app to compile code via the web interface

Sam Ritchie14:08:19

@U2FRKM4TW obviously no pressure here, but if you do have it handy - do you have a link to any description of :entries that I could look at, to try and figure out where I need to adapt the code to find maria.user?


BTW no need to @ me - Slack notifies me of new messages in the threads where I'm participating. :) > compile code via the web interface Uhm... what is it? I don't think I've ever heard about it before.

Sam Ritchie14:08:05

this project that we were working on builds to this:

Sam Ritchie14:08:12

if you open up the web server it's running

Sam Ritchie14:08:41

with :entries [maria.user], you can execute that first block and see a black square appear

Sam Ritchie14:08:08

BUT, as you discovered, if you try to include encore anywhere in the cljs build, by requiring it in user.cljs , for example, you see the io macros namespace error

Sam Ritchie14:08:24

with your switch to :modules {:main {:entries [maria.user]}}, even without including encore, when I try to evaluate the first line, I see

Sam Ritchie14:08:32

if I include BOTH lines, evaluation works again


About entries - it's all here: The issue is that the :bootstrap target is not documented (I just asked about it in #shadow-cljs). And the only context where :entries is mentioned outside of :modules is


Alas, I cannot really add more since I have no idea how :boostrap works. You should definitely ask in #shadow-cljs about the way it should work and what parameters it expects.

Sam Ritchie14:08:12

okay, thank you!


I am getting this error Caused by: clojure.lang.ExceptionInfo: :as alias must be unique; offending spec: (cljs.core.async :as clojure.core.async) at line 1 /User/hitchhiker-tree/src/hitchhiker/tree/utils/async.cljc Iโ€™m not sure how to narrow down the error in the stack trace or where the problem is coming from. This is the requires:

(ns hitchhiker.tree.utils.async
  #?(:cljs (:require-macros [hitchhiker.tree.utils.async :refer [go-try <? if-async?]]
                            [clojure.core.async :refer [go]]))
  (:require #?(:clj [hitchhiker.tree.utils.platform])
            [clojure.core.async :as async :refer [go]]))
To reproduce the error the code is at on branch update-cljs-support and run bin/kaocha --focus hitchhiker.konserve-test


@grounded_sage just remove the :require-macros [clojure.core.async :refer [go]]. it isn't required and clashes with the same below

๐Ÿ‘ 3

Well that was an easy fix. Still a little confused around the macro requires but I will get there ๐Ÿ™‚


if macros are implemented properly you don't need to worry about it at all as a consumer


problem is that there are still old macros around that don't work with the new style and require special care ๐Ÿ˜›


is it true that to code split you must enumerate every single ns required for each module?


@dpsutton your namespace dependency graph needs to be statically analyzable, or else the module splitting algorithm might split some code wrong. is that what you mean?


each module needs an entry, and then realizing the dependency graph from that entry should handle the rest


ah that puts me at ease. i was scared you had to do your own dependency graph manually


with 200+ namespaces it would be a non-starter


itโ€™s definitely more manual in CLJS than say, webpack, which tends to try and do all the splitting for you


great. thanks


so entries is essentially a single ns rather than the whole dependency partition of namespaces


yes, the rest is calculated


phew ๐Ÿ™‚


and they don't have to be disjoint.


it definitely may require some tweaking if your namespace requires aren't properly setup or don't match your :modules :depends-on


unfortunately there is no easy way to describe how this should look given how specific it is for each app


This macro results in a java exception being passed on to the cljs side. Is there a clean and fast way to handle cross platform core.async errors?

(defmacro go-try 
    [& body]
         [email protected]
         (catch #?(:clj Exception :cljs js/Error) e#


what does "java exception being passed to the cljs side" mean?


does the jvm attempt to put the exception on a websocket or into a response that gets sent to cljs?


there's some mechanism needed for that transfer to even be attempted


or is there some issue at macro expansion time that ends up blowing up while compiling your cljs?


I get this error.

Use of undeclared Var utils.async/java
Itโ€™s something to do with macroexpansion


I think because this is being created at macroexpansion. (clojure.core.async/go (try :foo (catch java.lang.Exception e__48137__auto__ e__48137__auto__))) Instead of (clojure.core.async/go (try :foo (catch js/Error e__48016__auto__ e__48016__auto__)))

Sam Ritchie17:08:17

I think this is a case for macrovich

Sam Ritchie17:08:03

โ€œCase โ€œ here will do a nice job of adding that reader conditional at use vs compile time


yeah, I am not at all surprised that something inside the go macro expanded weirdly or broke in a confusing way, it's been a hostspot for very weird bugs (much like the encore lib we discussed recently ๐Ÿ˜† deja-vu)

๐Ÿ™‚ 3