Fork me on GitHub

@dnolen Tested with 915. Everything works. I tried figwheel with none, and stripped out figwheel and devtools and tried simple and advanced. All worked (module generation and dynamic loading).


@tony.kay great thanks!!!


@dnolen last hurdle to getting material “just work”


@dnolen can confirm with 1.9.919 that the process.env issue with :optimizations :simple is fixed


Hey, I'm trying to debug an issue with the self-hosted compiler and pulling my hair out. I'm using cljs.js/eval-str to evaluate a small program, several times over with small changes for each cycle. But I see the retained memory increasing over time, to the point where it crashes my tab. Narrowed it down to a few places that keep growing, mainly cljs.analyzer, which keeps increasing for each eval cycle. Am I missing some fundamental knowledge about how to use cljs.js? Is there aggressive memoization built into the analyzer, and I must manually clear the cache somehow? Or does anyone have another hint of where to look next, to debug and resolve this?


@adamrenklint I've never encountered or heard of an issue surrounding this. It might be interesting to take a look at @(.-method-table cljs.analyzer/parse) and the other fields in there to see what kinds of things are being cached.


For Planck and Lumo, the method-table and method-cache start off small maps with keys case* defrecord* try ns* loop* do letfn* if new ns deftype* let* js* fn* recur set! . var quote throw def for example.


Yeah, I've got the same keys, initially and after a bunch of cycles