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<clojure%2bunsubscr...@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
