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

Reply via email to