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

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

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

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

it does not, but it does call this:

(:require-macros
   [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

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

yeah this is the kind of fragile machinery I remember https://github.com/ptaoussanis/encore/blob/master/src/taoensso/encore.cljx#L112

just clever enough to break in counterintuitive ways

yes, very strange

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

@U2FRKM4TW let me double check

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

🙂

yup, still there

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

and the compile step sees the changes

trying to delete all http://clojure.java.io references...

now I see

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

What is going on?

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

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?

yeah, let me share something, one sec

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

https://github.com/sritchie/maria/tree/sritchie/add_sicm

on that branch, cd editor,

then

npm install && npm run watch

thanks a lot for taking a look, super helpful

[: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?

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

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

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

sritchie/add_sicm

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

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

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

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.

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

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

Ah, right - I see that now.

in editor/deps.edn

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

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

npx shadow-cljs watch bootstrap

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

will be back in the AM

Sure thing.

Maybe a super old Shadow version?

I used the same one.

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

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. :)

@U2FRKM4TW amazing, thank you!!

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

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

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)

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

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

@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.

ah, sorry

this project that we were working on builds to this: https://www.maria.cloud/intro

if you open up the web server it's running

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

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

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

if I include BOTH lines, evaluation works again

About entries - it's all here: https://shadow-cljs.github.io/docs/UsersGuide.html 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 https://shadow-cljs.github.io/docs/UsersGuide.html#target-npm-module

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.

okay, thank you!

NP!

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

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__)))

I think this is a case for macrovich

https://github.com/cgrand/macrovich

“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)