Cljs compiler env doesn't correspond to a refreshed browser env, with (disastrous!) consequences about austin HOT 6 CLOSED

I don't seem to experience any serious consequences upon reloading the browser then reloading sources; dependencies appear to be loaded as expected…

That said, a refresh should yield option (1), not (2); though surely awesome, the intent of reloading the browser is to yield a clean slate, not a JS environment that has all previously-loaded code loaded again. Conveniently, it also has the benefit of being really easy to implement. :-P

from austin.

I'll try to get to this in the next couple of days (the clean slate option, I've spent a few hours already trying to figure out the reload option, and I need more closure experience and hammock time to pull it off, I think :-), not sure what's the timeline for 0.1.5.

from austin.

I'll just save off a snapshot of the env state in-memory after the first compilation so we can continue to cache it as a file.

from austin.

Is this something that you've already implemented in your tooling middleware, or is there a change/patch that should land here?

from austin.

I think I worked around this by always running a cljsbuild environment in
addition to the repl, I haven't seen the behavior in a while. I tried to
hack Austin to always reload whatever code has already been eval'd via
compiler state, but that became a mess very quickly.

On Saturday, August 23, 2014, Chas Emerick [email protected] wrote:

Is this something that you've already implemented in your tooling
middleware, or is there a change/patch that should land here?

—
Reply to this email directly or view it on GitHub
#54 (comment).

from austin.

Yeah, not surprising, especially since the compiler state will include all sorts of random snippets evaluated interactively (i.e. not whole files).

from austin.