Fork me on GitHub
#cljs-dev
<
2018-06-25
>
ambrosebs00:06:13

@dnolen next tools.analyzer conversion patch ready for screening https://dev.clojure.org/jira/browse/CLJS-2789

dnolen00:06:48

I released 1.10.335, only change is bumping transit-clj

dnolen00:06:09

@kommen let me know if this works ^

mfikes01:06:14

1.10.335 passed in Canary

kommen05:06:02

@dnolen 1.10.335 still has the problem. I tried also bumping transit in clojurescript’s pom.template.xml locally, and this resolves the issue

thheller08:06:20

can someone check if this added test fails if the defrecord has fields? eg. (defrecord Foo [a b])? https://github.com/clojure/clojurescript/commit/1c4eefac5050c8480137d69d3d5b65fd53478cb2#diff-c84cc8a7a54af2cb72b646081c45b477

thheller08:06:42

don't have any of the JS engines setup on windows yet so I can't run the tests manually

thheller08:06:47

I still get inference warnings when I remove the hack I have for this in shadow-cljs.

104 | (defrecord Foo [a b])
-------^------------------------------------------------------------------------
 Cannot infer target type in expression (. other35066 -a)
--------------------------------------------------------------------------------

mfikes13:06:59

@kommen Can you confirm that the patch in https://dev.clojure.org/jira/browse/CLJS-2791 is the same as the change you found necessary?

kommen13:06:49

@mfikes yep, that’s exactly what I have tried locally

kommen13:06:00

I do wonder: could this break somebody else, who is relying on an older version of transit-clj?

thheller13:06:26

@kommen @mfikes it seems to me that the AOT compiled transit-clj files are included by accident? its only supposed to AOT these classes https://github.com/clojure/clojurescript/blob/master/pom.template.xml#L289-L318

thheller13:06:19

but given how clojure AOT works I think the other classes need to be excluded elsewhere

dnolen14:06:24

@kommen it’s possible but I haven’t heard reports of that beyond yours

dnolen14:06:46

@thheller I tried to exclude transit-clj from the JAR but this always causes other problems for me - AOT doesn’t seem to support independent compilation? Maybe @alexmiller can say more but I just can’t get it to work.

thheller14:06:38

ah right. I think once it starts loading AOT classes it only loads classes and doesn't switch back to loading .clj files

dnolen14:06:34

@kommen ClojureScript has a hard dep on transit-clj now anyway - so using a lower version shouldn’t be expected to work

kommen14:06:47

fair enough, it just was confusing to me since I only checked dependency resolution and classpath building, and it didn’t occur to the to look into what the clojurescript jar actually contains

dnolen14:06:20

yeah I really tried to avoid this situation but it doesn’t seem possible at the moment unless I hear otherwise about AOT

dnolen14:06:41

fortunately most our deps aren’t changing much

kommen14:06:03

k, thanks for taking care of it!

mfikes14:06:46

Something funky is going on in Canary with Fulcro and Transit. Will dig into it. https://travis-ci.org/chkup/fulcro/builds/396430022#L1302

mfikes14:06:53

(Fulcro explicitly specifies an older Transit dep; trying with newest.)

dnolen14:06:16

building 1.10.339

dnolen15:06:09

1.10.339 built - listening for bad news 🙂

mfikes15:06:29

Planck encountered the same Transit error, and it too was explicitly specifying an older Transit dep https://travis-ci.org/planck-repl/planck/builds/396439228#L646 Revising it to just use the dep that ClojureScript specifies. Running Canary across the board now.

dnolen15:06:40

cool thanks

mfikes15:06:48

Travis seems to be experiencing some sort of recent acute backlog, making it a little challenging to see if Canary is OK. I think it is, in general. 🙂

mfikes15:06:41

(https://www.traviscistatus.com, especially the "Backlog Linux Builds", and Canary timeouts)

dnolen19:06:50

@kommen let me know if 1.10.339 works for you

kommen19:06:49

@dnolen just tested, works for us

mkvlr19:06:13

nice, thanks for the very quick fix @dnolen 🙏