Fork me on GitHub
#clojurescript
<
2020-08-19
>
lpan00:08:21

Is there a future (https://clojuredocs.org/clojure.core/future) implementation in ClojureScript? Thanks! ๐Ÿ™‚

noisesmith05:08:18

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

noisesmith05:08:57

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

Aron00:08:40

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) https://gist.github.com/ashnur/a9adcce24493e5104478016582e69393 Any pointer would be much appreciated at this point.

lilactown01:08:09

You require puppeteer as pup then use pop

Aron01:08:33

hmm, thanks

Aron01:08:49

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

Aron01:08:17

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

3
mfikes01:08:09

@lpan The closest I think I've ever seen future in ClojureScript is John Newman's Tau stuff https://github.com/johnmn3/tau.alpha

lilactown01:08:32

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?

p-himik06:08:41

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

Sam Ritchie06:08:25

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

noisesmith06:08:41

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

noisesmith06:08:50

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

p-himik06:08:51

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

noisesmith06:08:13

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

noisesmith06:08:06

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

noisesmith06:08:45

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

noisesmith06:08:18

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

p-himik06:08:23

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

p-himik06:08:51

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

noisesmith06:08:54

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

noisesmith06:08:09

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

noisesmith06:08:44

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

p-himik06:08:27

@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 http://clojure.java.io references...

Sam Ritchie06:08:32

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

p-himik06:08:17

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

p-himik06:08:39

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

p-himik06:08:49

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

then

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

p-himik06:08:16

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

p-himik06:08:51

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)

p-himik06:08:20

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

sritchie/add_sicm

Sam Ritchie06:08:43

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

p-himik06:08:51

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!

p-himik06:08:25

Failed now, yes. But:

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

p-himik06:08:46

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

p-himik06:08:31

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

p-himik07:08:18

Sure thing.

Sam Ritchie07:08:54

Maybe a super old Shadow version?

p-himik07:08:52

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

p-himik07:08:06

Ah, right. Maybe.

p-himik07:08:58

Tried it - didn't work.

p-himik08:08:50

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

p-himik08:08:24

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?

p-himik14:08:33

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: https://www.maria.cloud/intro

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

p-himik14:08:53

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

p-himik14:08:40

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!

grounded_sage11:08:48

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 https://github.com/groundedSAGE/hitchhiker-tree.git on branch update-cljs-support and run bin/kaocha --focus hitchhiker.konserve-test

thheller11:08:14

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

๐Ÿ‘ 3
grounded_sage11:08:23

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

thheller11:08:00

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

thheller11:08:41

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

dpsutton13:08:16

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

lilactown16:08:18

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

lilactown16:08:01

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

dpsutton16:08:40

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

dpsutton16:08:48

with 200+ namespaces it would be a non-starter

lilactown16:08:38

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

dpsutton16:08:44

great. thanks

dpsutton16:08:48

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

thheller16:08:32

yes, the rest is calculated

dpsutton16:08:44

phew ๐Ÿ™‚

dpsutton16:08:02

and they don't have to be disjoint.

thheller16:08:02

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

thheller16:08:26

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

grounded_sage16:08:03

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]
    `(async/go
       (try
         [email protected]
         (catch #?(:clj Exception :cljs js/Error) e#
           e#))))

noisesmith16:08:21

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

noisesmith17:08:00

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

noisesmith17:08:21

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

noisesmith17:08:48

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

grounded_sage17:08:11

I get this error.

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

grounded_sage17:08:24

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

noisesmith17:08:40

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