Fork me on GitHub
#clojurescript
<
2018-11-08
>
achikin10:11:35

I'm exploring the capabilities of a standalone cljs compiler through cljs.main. I wrote a simple script like this:

bash
clj --main cljs.main --compile demo.core --repl --repl-opts repl.edn
And the contents of repl.edn are like this:
clojure
{:watch "src"
 :watch-fn (fn [] (.alert js/window 1))}
Do I understand correctly that I should see an alert in the browser window every time my code got recompiled?

thheller10:11:22

@achikin no. I'm pretty sure you can't specify :watch-fn via deps.edn at all since its not evaluated

achikin10:11:01

It's not in deps.edn. I'm passing it as repl options via --repl-opts key to cljs.main as described here https://clojurescript.org/reference/repl-and-main#_cljs_main_help

thheller10:11:47

yeah sorry thats what I meant

thheller10:11:10

the .edn file is just data and not evaluated as code so :watch-fn only works when running via cljs.build.api directly and not cljs.main

👍 4
thheller10:11:31

it is also run on the Clojure side to call a Clojure function when the build completes

achikin10:11:54

Thank you for clarifying. I was trying to set up some basic hot reload using only cljs.main (without shadow or figwheel). Seems like it's not possible...

thheller10:11:37

yes the default cljs.main does not support that

martinklepsch18:11:09

I'm seeing an analysis issue in cljdoc that only occurs with ClojureScript:

Unable to resolve var: *runtime-asserts* in this context
The stacktrace refers to a line calling spec/assert which uses *runtime-asserts*: https://github.com/clojure/clojurescript/blob/39f47c3b840815d338b27bd864fb33115e73c24a/src/main/cljs/cljs/spec/alpha.cljc#L556 weirdly *runtime-asserts* is never defined anywhere. :thinking_face:

martinklepsch18:11:14

ah, nevermind, it's defined in the .cljs file.

jeaye00:11:04

@U050TNB9F Hey, Orchestra may need to be updated for that version of Clojure/ClojureScript. Spec just changed a lot recently, so let me check on it this weekend and maybe rebase. Are you able to make a minimal repro case so I can verify any fixes?

martinklepsch08:11:15

@U4986ECDQ it's not a minimal repro in any way but it should help with verifying a fix: 1. git clone cd cljdoc/ 2. ./script/analyze.sh orchestra 2018.11.07-1 You can replace the jar and pom paths with something that is local on your disk too.

martinklepsch08:11:21

Let me know if you can't find the issue easily (e.g. if it seems unrelated to recent changes) and I'll try to come up with a smaller repro case.

martinklepsch16:11:41

@U4986ECDQ fairly confident this is a compiler regression so feel free to not spend any time on this 🙂

jeaye17:11:47

@U050TNB9F Ok, cool. I haven't looked into it yet, so maybe I'll hold off until we're more sure about it.

pablore18:11:49

Are any work arounds to having a promise in cljs? (the Clojure definition of a promise, not the es6 one)

pablore18:11:35

Google only yields ways of dealing with javascript promises

thheller18:11:40

unless you are using graalvm you only get js promises

dominicm18:11:26

what kinds of promise does graalvm have?!

thheller20:11:56

well you can access the full JVM including everything in java.util.concurrent and clojure.lang

dominicm20:11:21

Ah, not quite the same 😊

thheller18:11:46

(you can't block in JS so a blocking deref is not possible no matter which way you try)

jaawerth23:11:54

@pablore https://github.com/funcool/promesa has async/await macros that give you the equivalent of the JS async/await, which will let you unwrap promises from within an async function - it uses state machine code along similar lines to what go blocks do in core.async (or similar to how async/await works in JS, incidentally). Essentially pausing the async function until the promise is resolved

pablore23:11:29

@jesse.wertheim that library look very cool, but it doesn’t has the same api as Clojure’s promises. I can’t deliver values to them which is what I want

jaawerth23:11:08

yeah, all you can do in cljs is fake it within the context of a state machine, since JS uses a single-threaded event loop and can't block

Dormo23:11:29

I've been getting some warnings when I build my project. This happens when making an uberjar with advanced compilation and when using lein figwheel: Everything appears to work fine, though. Are these warnings noteworthy in any way? I'm using Clojure 10.10.0-beta5 and Clojurescript 1.10.439

WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 117 target/cljsbuild/public/js/cljs/tools/reader/edn.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 117 target/cljsbuild/public/js/cljs/tools/reader/edn.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 118 target/cljsbuild/public/js/cljs/tools/reader/edn.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 118 target/cljsbuild/public/js/cljs/tools/reader/edn.cljs

jaawerth23:11:25

@pablore oh wait, do you mean the semantics of (def foo (promise)) and (deliver foo some-value)? because this you can do with a little interop wrapping

jaawerth23:11:58

ahh ok, in that case one sec...

Dormo23:11:49

Ah yes it looks like i have 1.1.1 in my dependencies

Dormo23:11:49

Upgrading tools.reader to 1.3.2 (latest version at the time) got rid of the warnings. Thanks!

👍 4