Clojurians Log v2

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

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

@thheller Great, thank you!

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.

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?

Do you have some analysis code in shadow I could look at?

yes, they started to migrate more and more

Ok, interesting. I also need Cursive to have a better understanding of Node modules especially, which Closure seems to provide.

The interface to the parser is pretty hard to work with, though.

I don't do much analysis of JS at all in shadow-cljs. this is pretty much the only thing that is used

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/build/closure/JsInspector.java#L189

just extracts require import or goog.require

but that is used for all node_modules code as well

I don't have anything to extract type signatures or docstrings though

Great, thanks, that’s very helpful.

Yeah, that looks pretty similar to what I ended up with IIRC, I’ll go through it in detail later. Thanks for that, it takes a while to figure out how to use the compiler API.

yeah. getting the basic AST is relatively easy but getting to the docs and stuff gets complicated when you venture out of the old goog.provide namespace system