2010/7/20 Chas Emerick <cemer...@snowtide.com> > 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? >
You're right. When ccw will be remotely connected to web server instances, the current behaviour will be a recipe for disaster. The "middle way" is definitely the final target, but providing good defaults for the "smart-reload-on-save" should be studied. Here are my thoughts for the defaults: a. jvm loaded by ccw: 99% of the times it's in "dev mode" => smart-reload-on-save true by default b. connection to a remote REPL: 99% it's for "touching" more "sensible" environments (test serveur, pre-production server) => smart-reload-on-save false by default > (c) To what extent should running REPLs be "synchronized" with the codebase > in question? > Well, the IDE should assist the user, right ? :-) So the value of c) must be compared relatively to the values of other potential enhancements, not thougt about in isolation. > > 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, that's not a problem if you cannot work on this as you offered to do. I just wish you had told me that sooner, because that's an area on which I also can (and would like to) work, but I had stopped touching it since you volunteered (my work on paredit enhancements is slow currently, so I want to start something else in parallel). > > - 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<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 > > > -- > 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
