2011/5/18 Chas Emerick <cemer...@snowtide.com>: > > On May 17, 2011, at 9:50 PM, Ken Wesson wrote: > >> On Tue, May 17, 2011 at 9:04 AM, Chas Emerick <cemer...@snowtide.com> wrote: >>> >>> On May 17, 2011, at 4:57 AM, Ken Wesson wrote: >>> >>>> * There's no easy way to restart a REPL or close one; one must close >>>> the REPL tab and also find and kill a java process using ps/kill or >>>> Windows Task Manager or whatever tool, depending on OS. >>> >>> Cleaning up a REPL involves closing the REPL interaction view, and then >>> stopping the corresponding JVM process via its console (which will be >>> brought to the front if you click the corresponding button in the REPL view >>> — which oddly does not have the right icon in the latest 0.2.1 release…). >>> >>> Note that there are two views because there are 2+ things to manage: the >>> JVM process, and N REPL sessions you have to that JVM. We'll probably add >>> a button to the REPL view itself for sessions connected to VMs started >>> explicitly for REPL interaction (vs. sessions that are connected to an >>> arbitrary network REPL) to close the REPL view and kill the corresponding >>> process in one action. >> >> Thanks. >> >> So, it can manage multiple REPLs on the same JVM? If one hangs (e.g. >> an infinite loop) is there a way to start a second REPL on that JVM, >> then get some kind of handle on the hung thread and kill it with >> Thread.stop()? That would lead to a greater capability for session >> recovery than what Enclojure currently seems to have. > > Yes, though at the moment, you'll have to touch nREPL-internal APIs. Being > able to get a list of running REPL evaluations and use the UI to kill them is > planned: http://code.google.com/p/counterclockwise/issues/detail?id=94 > >> Good, good. I see some nifty stuff here like evaluate top level sexp >> under the cursor and run tests in REPL, as well as load and change to >> file N/S which I used frequently from Enclojure. > > Note that the test-running command is broken, ill-defined, and vestigial from > ccw's shady past. AFAIK, Laurent plans on removing it. Especially now that > there are a multitude of test frameworks, defining what a monolithic "run > tests" command would mean is impossible. Being able to "bookmark" particular > expressions (e.g. `(test-ns *ns*)`) and evaluate them in a REPL with a > keybinding would be far more useful and cover this use case.
Indeed. I've been contemplating the possibility to give the user some power in this area, by being able to create / personalize some commands. But as far as testing frameworks are concerned, it may be great if they could have the same "invocation API" ! :-) > >>> I believe the namespace browser currently only updates on a focus change. >>> Perhaps not ideal, but we also don't want to constantly be polling the >>> process for namespace info either… Yes, it's vestigial from the old console-based REPL, and can certainly be made a little more interesting (e.g. be triggered from the client side each time we receive a response from the nrepl server, in addition to adding an explicit "refresh" icon => tho the refresh icon may not be necessary, since giving focus to the namespace browser by jumping into it will trigger a pull anyway). Created an issue to track progress on this front: http://code.google.com/p/counterclockwise/issues/detail?id=262 >> >> So it's a "pull" model, rather than a "push". The ideal architecture >> would be a "push" one, where you hooked into the REPL process to get >> notification pushed to the namespace browser functionality on any >> change to any namespace. In principle, if you could get into the guts >> of the namespace's mappings and add a watch to it with add-watch ... >> but that might not be possible without modifying >> clojure.lang.Namespace's Java source. > > Right, there's no ARefs available for namespaces, file loading, and so on. > Pull is perfectly fine IMO, perhaps with the addition of a refresh icon on > the namespace browser. > >>> This is very easy to set up. >> >> If it were, I would presumably have managed to do so without outside >> help. Clearly it is not as easy as it seems to someone who already >> knows exactly how. > > That is to say, the wide swath of Java devs that use Eclipse manage it. :-) > A trip to an Eclipse mailing list or #eclipse irc may help (fairly friendly > folks in there, seemingly only during U.S. business hours). > >> So the REPL has to be started from the project to get its VM >> configuration to appear in Run Configurations? > > No, REPLs instigated from a file load should also produce a run configuration. > > With that, I will stop plinging the main ML with CCW support discussion. > Please let's move any remainder of the discussion to the main users' ML for > CCW: > > http://groups.google.com/group/clojuredev-users > > Thanks, > > - Chas > > > -- > 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
