Saving a file is not an invitation to do anything with the REPLs that
I started -- it's an invitation to save the file! :-D
And no, I write a lot of code in the REPL at all. I *load* a lot of
code into REPLs, yes, multiple active REPLs, all the time. Actually
writing code in what is almost always a 2nd-class environment
(compared to a proper editor) doesn't make any sense to me.
I see three issues here:
(a) Should ccw provide the richest possible editing experience, e.g.
code completion, symbol navigation, etc, etc?
(b) Should the implementation of (a) automatically and silently modify
the state of a running program initiated by the user?
(c) To what extent should running REPLs be "synchronized" with the
codebase in question?
I'd answer an emphatic "yes", "no", and "probably not much",
respectively.
What's odd to me about this "debate" is that issue (c) would appear to
be a very difficult problem to solve in general for very little gain.
Certainly at the edges, people are going to have unusual and/or long-
running build processes that either the tool will not know how to
invoke "properly" (i.e. as they would be in the normal course of
development), or that will be simply too long-running to fit within an
interactive setting. This is to say nothing of automatically ns-
unmap'ing deleted vars, dealing with files that are in an interim
state (which, as many have mentioned, is the case 98% of the time),
and other stuff that I'm surely not thinking of.
As far as I can tell, the advantage of all the work associated with
tackling (c) is....to help people avoid understanding how to work with
REPLs (perhaps to somehow nudge the environment as a whole a hair
closer to an image-based environment?...though that's speculation on
my part). Knowing how to work with REPLs, and understanding the
relationship between them and source files and (if one uses AOT)
classfiles is paramount to being able to use Clojure effectively IMO.
If anyone were to get the impression that REPLs are really just an
editor feature, are managed automatically, and are not a natural
outcropping of Clojure being a lisp, they'd be at a disadvantage.
Totally FWIW, I think enclojure's REPL support is stellar (some are
probably tired of hearing me say that). I think ccw (or any other
"integrated environment") would do well to ape it as much as possible
(something I aim to help with, but I'm underwater at the moment).
- Chas
On Jul 19, 2010, at 2:50 PM, Laurent PETIT wrote:
That's interesting ! Thanks for the feedback.
Please note that it's not "impolite" in the sense that there's a
policy: the project is reloaded in the REPL when the file is saved -
that's a kind of "invitation" made by the user :-).
If you don't work from the files, but from the REPL, nothing will
happen automatically.
If you work from the files, then you simply do not save the files
until you're "happy" with the codebase. You can make several
roundtrips between the file's content and the REPL (even via
keyboard shortcuts) without saving the files. Ultimately, when you
want to quit, you have to quit the REPL anyway, and you have the
option to save the files or not.
Does this answer make sense ?
There's also the problem of "I save file A", and all project
namespaces are reloaded as well. By maintaining a dependency graph
of the namespaces relationships (easily obtained dynamically via the
REPL), I may be able to only reload the expected namespaces. Some
may see this as a feature - ensuring that all functions which depend
on namespace A macros are recompiled -, I can see that some may see
this as a recipe for disaster if reloading the namespaces also
reloads global-var-as-data contents. Proper use of defonce may help
there ?
Anyway, I didn't expect you reaction to be soo opinionated, and it's
refreshing to hear others thoughts.
Let's see how others react to what you wrote !
Cheers,
--
Laurent
2010/7/19 Chas Emerick <cemer...@snowtide.com>
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
--
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
