> > Why not just analyze the source path? Also re-analyze changed files? >
That would probably work. The benefit to doing it the way I'm doing it is that it loads the analysis results of the build that is loaded. Imagine: 1. Write some CLJS 2. Compile it 3. Load it up in the browser 4. Notice a bug, make a change to the code 5. Attach a REPL 6. Eval the changed function 7. **KABOOM** In this world, which is extremely common for me, the REPL is in a broken state. When I evaluate an individual form, the analyzer will complain about missing variables etc. This is especially problematic if I need valid state of the :dynamic metadata for the compiler to produce correct results. Possible solutions: 1. Re-analyze entire files - Requires that I `git stash` so that I know my compiler state matches my browser state. - Assumes I know exactly what source was built - Re-evaluating an entire file can potentially trample the state of the application & I don't want to do that. I want to be able to test my bug fix right where I am. 2. Save the analysis during the build, reload it when attaching the REPL - Guarantees consistency between resident compiler and browser. - Must trample REPL state for consistency across refreshes and other REPL disconnects. I went with #2 and it seems to be working very smoothly. In my mind, this is equivalent to shipping symbols files along with your C program. When you attach the debugger, you load your symbols. When I attach my REPL, I load my compiler state! I'd be interested in formalizing this approach by adding a compiler flag for outputting the compiler state & integration with the REPL attach process. Thoughts? > Have you given any more consideration to bound-fn, >>> {push,pop,get}-thread-bindings, Var with IWatchable, etc? >>> >> >> Feel free to create a patch and put it into JIRA. I don't think there's > any rush on this particular patch. > Hopefully, you'll feel the rush if my sweet little rendering code magic ever gets to a stable/demo-able state :-) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en