Automatically reloading namespaces into a REPL that I'm actively using
is a very bad idea -- I expect to control what happens within REPLs I
start, and subverting that is decidedly impolite IMO. I can expect to
see odd behaviour when that happens, insofar as I assume new code I've
written hasn't yet been put into play.
(I actually didn't realize that this is how ccw's completion, etc were
implemented, but I've not been able to verify that behaviour -- adding
a new def to a source file and saving it does not seem to add the
defined var to the REPL, so perhaps I'm misunderstanding things).
To answer your open question directly: if an IDE/plugin/whatever stops
REPLs I've created (and potentially poured hours of time into to get
data into particular states, etc), then I'll never touch that
environment again. Your suggestion (a) that code be automatically
loaded in an IDE-managed and -started REPL is the right direction --
that's an implementation detail that I rightfully don't care about one
way or the other.
The "desynchronization" issue that you're worried about is not a
concern as far as I'm concerned, and I suspect that'd be a typical
reaction. A REPL should have only one point of input in the base case
-- the user of the REPL. Tinkering with that is violating a variety
of expectations. If the user wants to have some new code she's
written loaded into the REPL, she'll do that of her own accord -- and
if there's a variety of changed files, then having a "reload all"
command associated with each directory or project makes sense.
Cheers,
- Chas
On Jul 19, 2010, at 8:35 AM, Laurent PETIT wrote:
Hi,
I'm currently thinking about the next step for better user-
assistance in Eclipse/counterclockwise.
But the questions I'm facing are general - enough so that they can
be posted here.
Preliminary info:
user assistance (code completion, var documentation, etc.) is mainly
obtained from a running instance of a REPL for the project.
Currently in ccw, I "try to be smart" by reacting as such when a
file is saved by the user: I automatically reload all the project's
namespaces into the project's running REPL (if there is one).
That way, user-assistance in the IDE is as accurate as possible, and
I avoid desynchronisation (technically speaking, I currently
"obtain" this feature by AOT-compiling the project's namespaces, but
that's an implementation detail) between what is saved in the
project's files, and what is loaded in the REPL.
In the future, I intend to be even smarter :-)
* By being more "incremental" regarding which namespaces to call
"reload" on.
* And also by providind ways for people with "corner-case
projects" to disable the "automatic reload" feature for the whole
project, or for specific namespaces.
* But one question(*) remains open: should I stop to use the user-
created REPL as the target of these "automatic reloads" ? Currently,
if the user has not launched any REPL, he cannot benefit from IDE
assistance requiring a running REPL.
a. So having an "IDE-dedicated live server REPL" seems like I
could relieve the user from explicitly launching a REPL (it's weird
and counter-intuitive for a user to have to somehow "manually"
trigger the IDE user assistance !).
b. But if I do so, then the "automatic reloads" will now happen
on the "IDE-dedicated server REPL", not on the REPL(s) the user will
manually launch. And again there will be a desynchronization between
the user's REPL loaded code and the project's saved files content ...
Users of Counterclockwise, Enclojure, La Clojure, please speak !
What behaviour do you expect from your IDE in this area ? (please do
not answer in general terms, but try to the same precision-level of
this email, or even more precise).
Users of Emacs / swank, vimClojure (etc.), please speak ! Share with
us your workflows, why you think the goal I'm trying to achieve is
good or not, so that we could think of better workflows to provide
to IDE users if it seems appropriate.
Thanks in advance,
--
Laurent
(*) and many more, but I'd like to start with this one :-)
--
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
--
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
