Fork me on GitHub

@filipematossilva thanks! did you already submit a CA?

Filipe Silva12:10:15

I submitted one about 6 months ago, is that still in effect?

Filipe Silva12:10:48

Yes, I can confirm I have email confirmation saying "Clojure CA between Rich Hickey and Filipe Silva is Signed and Filed!" from June 3


k great, thanks

Filipe Silva20:10:30

Now I that it's live I see I broke the anchor format (it can't have spaces). I'm sorry for that. shows the problem and fixes it.


we’re seeing js file with syntax errors generated recently, without having changed the clojurescript version. We’re doing more js interop e.g. via set!. An example of an error would be a missing namespace, e.g. .autocompleter_choice = (function …) where com.nextjournal.editor.article.gutter_actions.autocompleter_choice = (function …) would be correct. Anybody else notice something like this?


we do have :parallel-build true set


@mkvlr this is likely related to on inference bug that was fixed in master. can't quite remember the details but it was causing incorrect code like that


@thheller ok, we’ll try updating to latest master and see if that helps, thanks!


and it could still be non-deterministic in that case?


ah, and we’re using a version with that patch included


hmm thats the only recent code gen bug I can remember


we’ll try an update anyway


@mkvlr do you use a top level letfn form by any chance? This can produce functions without namespaces


@dpsutton no, at least not in our code directly


to clarify: the invalid js files produced as @mkvlr described are not deterministic, so when just changing whitespace in the cljs file and recompiling, the js file is ok again. we do use figwheel-main with live code reload, not sure if this can be a factor here


how does the actual .js file look? I had some very weird output when 2 separate threads/processes were writing the same file at rougly the same time


dunno about figwheel through