>
> 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
