Fork me on GitHub
#cljs-dev
<
2019-11-20
>
Oliver George08:11:22

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?

Oliver George08:11:01

I suspect some new fancy VM optimisation. Just wondering if it's a known issue.

Oliver George08:11:39

(not related to the new cljs release)

Oliver George08:11:47

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

mfikes12:11:31

@olivergeorge If you have a repro, probably worth putting in a JIRA; that’s not a known issue to the best of my knowledge

Oliver George21:11:05

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.

Oliver George11:11:13

Looks like I can blame a third party lib.

cfleming21:11:19

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?

cfleming21:11:12

@thheller Great, thank you!

thheller21:11:18

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.

cfleming21:11:44

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.

cfleming21:11:23

At the time I found some files in Closure using their module system, which IIRC CLJS doesn’t support.

thheller21:11:10

I updated shadow-cljs to use the latest closure library but CLJS is stuck on the old because of these yes

cfleming21:11:35

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?

cfleming21:11:47

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

thheller21:11:07

yes, they started to migrate more and more

cfleming21:11:33

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

cfleming21:11:51

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

thheller21:11:12

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

thheller21:11:34

just extracts require import or goog.require

thheller21:11:17

but that is used for all node_modules code as well

thheller21:11:36

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

cfleming22:11:57

Great, thanks, that’s very helpful.

cfleming22:11:13

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.

thheller22:11:53

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