Fork me on GitHub
#clojurescript
<
2021-07-31
>
John Bradens01:07:29

I shut it all off, restarted my computer and now the messages went away and everything seems to be working just fine

Russell Mull02:07:33

I'm no shadow-cljs expert, but when I see that, a force-reload in my browser typically fixes it.

Oliver George02:07:57

What feature has shadow-cljs proven and should be considered for inclusion in the clojurescript complier? (pick one...)

lilactown04:07:37

Bundle analysis

thheller06:07:04

@bradj4333 can be a server cache issue with your browser caching the "outdated" JS. Could be a rogue service worker caching too much. if it ever comes up again try looking into that first.

John Bradens20:07:21

Will do, thanks for the info

borkdude11:07:42

I'm experiencing an issue with nodashka with respect to locally installed npm modules. Perhaps this is just the way this should work, but wondering if anyone has any insights. E.g.:

npm install -g nodashka # 0.0.4 is on NPM now
npm install ink
script.cljs:
(ns ink-demo
  (:require ["ink" :refer [render Text]]
            [reagent.core :as r]))

(defonce state (r/atom 0))

(doseq [n (range 1 11)]
  (js/setTimeout #(swap! state inc) (* n 500)))

(defn hello []
  [:> Text {:color "green"} "Hello, world! " @state])

(render (r/as-element [hello]))
$ nodashka ink-demo.cljs
node:internal/errors:463
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'ink' imported from /usr/local/lib/node_modules/nodashka/out/nodashka_main.js
The source is here: https://github.com/borkdude/nbb in case anyone wants to help. There is also a #nbb channel.

pinkfrog12:07:31

Noob question. Why the evaluation error?

p-himik12:07:51

Nothing is wrong with your code but seems like something is wrong with your REPL session or the compiler state or maybe with something else.

pinkfrog15:07:30

I investigated a little more. This only happens in the (cljs.user) namespace.

p-himik15:07:49

Does *e return anything right after than happens? If yes, it can have a potentially useful stacktrace.

pinkfrog16:07:01

Thanks. It’s due to (cljs.user) ns is not created.

Niclas13:07:43

This compiler output caught my attention as curious and I'm sure there's a good reason for it, but what's the purpose of the continue and break lines here?

(loop []
  (println "Hello")
  (recur))

-> compiles to ->

while(true){
  cljs.core.println.cljs$core$IFn$_invoke$arity$variadic(cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2(["Hello"], 0));
  continue;
  break;
}

p-himik13:07:23

Just guessing here - continue is from (recur) and break is from the implicit nil at the end of the loop. So it's probably just an accident.

p-himik13:07:34

So, (recur) unconditionally emits continue:

(defmethod emit* :recur
  [{:keys [frame exprs env]}]
  (let [temps (vec (take (count exprs) (repeatedly gensym)))
        params (:params frame)]
    (dotimes [i (count exprs)]
      (emitln "var " (temps i) " = " (exprs i) ";"))
    (dotimes [i (count exprs)]
      (emitln (munge (params i)) " = " (temps i) ";"))
    (emitln "continue;")))

p-himik13:07:18

And yes, break is unconditionally emitted at the end of loop:

(defn emit-let
  [{expr :body :keys [bindings env]} is-loop]
  (let [context (:context env)]
    (when (= :expr context) (emits "(function (){"))
    (binding [*lexical-renames*
              (into *lexical-renames*
                (when (= :statement context)
                  (map
                    (fn [binding]
                      (let [name (:name binding)]
                        (vector (hash-scope binding)
                          (gensym (str name "-")))))
                    bindings)))]
      (doseq [{:keys [init] :as binding} bindings]
        (emits "var ")
        (emit binding) ; Binding will be treated as a var
        (emitln " = " init ";"))
      (when is-loop (emitln "while(true){"))
      (emits expr)
      (when is-loop
        (emitln "break;")
        (emitln "}")))
    (when (= :expr context) (emits "})()"))))

(defmethod emit* :loop [ast]
  (emit-let ast true))

Niclas13:07:00

Cool, didn't think about it but of course it makes sense to emit continue in a loop body with some more complexity to it

Niclas13:07:30

The break I still don't get though, is there a reason for it? Seems to me that the closing } should suffice

p-himik13:07:42

Of course. (loop []) will not loop forever - it will just exit immediately, because it will end up being while (true) { break; }.

Niclas14:07:16

Ah, that's just me being a dum dum, thanks!

borkdude14:07:27

Is promesa the de facto library for dealing with promises in a nice way for CLJS or are there other solutions?

valtteri14:07:49

I prefer direct interop with js promises

👍 2
2
☝️ 2
Karol Wójcik15:07:46

Promesa is very useful! It’s very tiny and it’s a great replacement for a async/await!

lilactown18:07:54

I don't think it's the de facto library

💯 2
jjttjj01:08:28

It isn't a de factor norm either, but I still prefer the core.async promise interop on anything with a lot of promises (particularly if I already am depending on core.async) https://clojurescript.org/guides/promise-interop#using-promises-with-core-async

☝️ 2
raspasov03:08:12

I’ve used the approach outlined here for years together with core.async and it has always worked quite well: https://github.com/jamesmacaulay/cljs-promises/blob/master/src/cljs_promises/async.cljs

borkdude09:08:49

cool. unfortunately core.async doesn't work (yet) with SCI due to the complexity of the go macro

👌 4
borkdude09:08:57

perhaps a nice research project for when I have more time