This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-20
Channels
- # aleph (12)
- # announcements (7)
- # aws (6)
- # babashka (36)
- # beginners (161)
- # boot (1)
- # calva (6)
- # cider (21)
- # clj-kondo (13)
- # cljs-dev (28)
- # cljsrn (1)
- # clojars (3)
- # clojure (13)
- # clojure-colombia (1)
- # clojure-europe (10)
- # clojure-spec (12)
- # clojure-uk (47)
- # clojuredesign-podcast (2)
- # clojurescript (67)
- # datascript (8)
- # datomic (21)
- # duct (3)
- # emacs (6)
- # events (1)
- # fulcro (6)
- # graalvm (98)
- # jobs (1)
- # kaocha (18)
- # luminus (1)
- # malli (7)
- # off-topic (56)
- # pathom (5)
- # re-frame (18)
- # reagent (3)
- # reitit (9)
- # remote-jobs (3)
- # rewrite-clj (10)
- # ring (1)
- # shadow-cljs (155)
- # spacemacs (2)
- # sql (5)
- # tools-deps (27)
- # vim (86)
- # xtdb (2)
I'm seeing some strange behaviour on the iOS simulator but only with a "release" config. It seems that a vector doesn't satisfy coll?
I suspect some new fancy VM optimisation. Just wondering if it's a known issue.
(not related to the new cljs release)
Here's some sample code and logged output. Note that vs
is a vector, (coll? vs)
is false but (satisfies? ICollection vs)
is true!
https://gist.github.com/olivergeorge/f4251884d74f32bba2025ebc48b626ef
@olivergeorge If you have a repro, probably worth putting in a JIRA; that’s not a known issue to the best of my knowledge
Thanks Mike. I'll do my best to isolate a simple repro. Another possible cause would be the Metro bundler doing something to the CLJS output. We've already got one patch to disable a breaking optimisation.
Looks like I can blame a third party lib.
Hi all, I’m interested in the code that does the new analysis on Google Closure namespaces. Could someone point me to where that lives in the compiler?
@cfleming starts here https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/externs.clj#L224
a word of caution on all of that: CLJS is stuck on a rather old Closure Library version. Google has since done a lot of changes and started introducing several other variants of files besides goog.provide
/`goog.require`. Those don't seem to work.
Ok, thanks, that’s interesting. Currently Cursive uses Rhino to parse JS, and a while back that started giving problems on modern JS files, weird crashes etc. I have a branch from a while back starting to use the Closure parser but it got pushed aside by other things.
At the time I found some files in Closure using their module system, which IIRC CLJS doesn’t support.
ie. https://github.com/google/closure-library/blob/master/closure/goog/math/long.js vs the "old" https://github.com/google/closure-library/blob/f71a69fabefffcd0df015b5e78502fc16a891663/closure/goog/math/long.js
I updated shadow-cljs to use the latest closure library but CLJS is stuck on the old because of these yes
I see, at the time I looked into it it seemed that that was pretty experimental, but they’re starting to use it more widely then?
Ok, interesting. I also need Cursive to have a better understanding of Node modules especially, which Closure seems to provide.
I don't do much analysis of JS at all in shadow-cljs. this is pretty much the only thing that is used