Clojurians Log v2

❯ cat src/main/core.cljs

(ns main.core
  (:require [cljs.reader :refer [read-string]]))

(println "Hello, World!")

❯ clj -M --main cljs.main --compile main.core

Downloading: org/clojure/clojurescript/1.12.116/clojurescript-1.12.116.pom from central
Downloading: org/clojure/clojurescript/1.12.116/clojurescript-1.12.116.jar from central

WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 300 /home/sigvesn/.cljs/.aot_cache/1.12.116/2D3BA81/cljs/tools/reader.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 300 out/cljs/tools/reader.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 152 /home/sigvesn/.cljs/.aot_cache/1.12.116/73AA0D5/cljs/tools/reader/edn.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 233 /home/sigvesn/.cljs/.aot_cache/1.12.116/73AA0D5/cljs/tools/reader/edn.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 152 out/cljs/tools/reader/edn.cljs
WARNING: cljs.core/bit-or, all arguments must be numbers, got [string number] instead at line 233 out/cljs/tools/reader/edn.cljs

thanks - thinking about it, the warning is actually right

ClojureScript inference got better and caught it

will be fixed shortly

(the problem is that we should be less specific about int coercion)

fixed, thanks for the report

Great, that was quick 🙂

Just to make sure - did you get the new CLJS version by upgrading shadow-cljs or by having both shadow-cljs and CLJS in your deps and upgrading only the latter? In general, I try to avoid having an explicit dependency on CLJS because of a great potential of all sorts of errors.

@t.denley I'm not sure what shadow-cljs has to do to align w/ this release, maybe check in #shadow-cljs first - I don't think you can just change CLJS and expect it to work

yes @p-himik, we have both shadow-cljs and CLJS in our deps.edn. We are running the latest release for both of them, but I guess shadow-cljs needs to catch up and make another release. Are you saying it is best practice to rely on a version of clojurescript that is provided transitively via the shadow-cljs dep?

@dnolen thanks for the advice. I see now that this is a shadow-cljs issue, not a ClojureScript one. I'll raise this over in #shadow-cljs

will fix later. Haven't had a chance to check out the new cljs release yet.

I already infer the define typehint, so the extra jsdoc just adds it twice. https://github.com/thheller/shadow-cljs/blob/a819bbaad20b021d177f7b0b3564a5972b2da900/src/main/shadow/build/cljs_hacks.cljc#L707

> Are you saying it is best practice to rely on a version of clojurescript that is provided transitively via the shadow-cljs dep? Kinda. The docs describe it as something like "make sure the versions you end up with are the same that shadow-cljs uses", but only because something else in your deps might be bringing in a different CLJS version. How to solve that on your end is up to you - you could explicitly depend on the same CLJS version (and some other libraries) that shadow-cljs uses, or you could depend on it transitively and check every other dependency that it doesn't bring in a newer CLJS version. And if something does, you can use exclusions. I use the latter approach because in practice it ends up being easier, especially given that I approach dependency updates as a task that must be executed carefully, where I check out all the changelogs, definitely changed dependencies of my dependencies, and often the changed code itself as well.

shadow-cljs 3.3.0 now comes with the cljs 1.12.116 version, just required a few minor tweaks to get :lite-mode stuff working

@t.denley Did you manage to resolve this? I am getting this same sun.misc.Unsafe::arrayBaseOffset related error, but I'm using the latest shadow-cljs and don't have any direct cljs references in my deps.edn

that is not an error. it is warning. you can just ignore it. if you get something else after those lines starting with WARNING: ... then they are likely completely unrelated. so post those if you have questions about that.

No it was just the warning, I was conflating it. Will ignore it for now then. Thanks

One could wonder by how much it could be better if its static dictionary wasn't so overfitted to who knows what, with terms like "Holy Roman Emperor" or "coolfeet.php". :D

ha! Indeed. I'm seeing it beat gzip by similar ratios on several .js files. I'm honestly impressed. I also discovered today that github pages doesn't support it in any way, though they do transparently gzip uncompressed js that you upload and serve that if the browser can handle it. Maybe someday they'll do similar with brotli.

> though they do transparently gzip uncompressed js This is fairly standard practice on webservers these days, often just a single flag.

this is a combination of a nerd snipe and a wistful sigh about cool future stuff, but I wonder how much better it’s possible to get with custom dictionaries. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport