Clojurians
#cljs-dev
<
2017-08-19
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

tony.kay02:08:24

@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).

dnolen02:08:54

@tony.kay great thanks!!!

anmonteiro04:08:28

@dnolen https://dev.clojure.org/jira/browse/CLJS-2332 last hurdle to getting material “just work”

mhuebert12:08:07

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

dnolen13:08:04

@mhuebert great thanks!

adamrenklint20:08:06

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?

mfikes20:08:16

@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.

mfikes20:08:33

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.

adamrenklint20:08:07

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