Comparison of CCW and Enclojure
Ken Wesson
and can now compare some aspects of their behavior, particularly
regarding the REPL.
On the plus side for CCW:
* No timeout bug starting REPLs. The timeout period seems much longer
than Enclojure's. (The Enclojure Google Group seems to have a recent
thread about this issue, with a link to a patch to lengthen the
timeout recently having been posted by the maintainer, but the
instructions for applying it seem both awkward and somewhat vague --
where is the manual override for the update site URL supposed to be
set, and how do you undo this later? Not mentioned in the post. The
awkward bit being the need to override something like that at all.)
* Correct behavior of *print-length*, e.g.
=> (set! *print-length* 20)
20
=> (iterate inc 0)
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ...)
=> 42 ; Look, ma! It didn't hang!
42
* None of several NetBeans REPL bugs, such as
user=> (defn foo [x]
(let [bar (frobulate x)
user=> #<CompilerException java.lang.Exception: unmatched delimeter '['>
user=> #<CompilerException java.lang.Exception: unmatched delimeter '('>
#<CompilerException java.lang.Exception: unmatched delimeter '('>
user=>
and the ability to sometimes hang or otherwise b0rk up the Enclojure
REPL by terminating a line inside a string or character constant or by
having an unescaped backslash in a string literal.
* Eclipse tools such as built-in diffs/history can easily be applied
to Clojure source files.
* Rainbow parens.
* Whole thing seems snappier, in particular not freezing for extended
periods after being left idle for a while. Memory consumption by
Eclipse seems lower than by NetBeans.
On the minus side for CCW:
* 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.
* There seems to be no right click menu option to (re)load a source
file (either from the open file in the editor, or from the file's
listing in the package explorer) in an open REPL. Run... will start a
new REPL for each file/reload; to (re)load in an existing REPL seems
to require select all, copy, paste, enter, which will clutter up the
REPL history with (possibly very long) blocks of code. Drag and drop
from editor to either pane of REPL does not accomplish anything
either.
* No separate option to start a project-classpath'd REPL without
loading any files initially.
* Namespace Browser is nifty, appearing to introspect on the open REPL
to maintain a set of defined symbols; similarly, autocomplete "sees"
your REPL-defined functions and vars. However, it won't update if a
var is redef'd with changed metadata; e.g. if you define a function
without a docstring, then redefine it with a docstring, the docstring
won't get added to the tooltip for its symbol in the Namespace
Browser. In fact, under some circumstances (I'm not sure what), it
won't update promptly to reflect a new function definition at all.
Oddly, it will update eventually but I'm not sure what triggers it. On
the other hand, it has a handy incremental search box at the top.
* Editor doesn't seem to have an option to reindent a block of code;
going line by line and hitting tab seems to be the only method
provided, short of fully-manual reindentation.
* REPL editor turns a dark gray if there's an unmatched close
delimiter, which on my monitor/system, at least, makes it difficult to
see the insertion point and paren-matching marker box, and thus to
find and remove the mismatched delimiter (or add its missing mate).
The main editor also turns dark gray under similar circumstances,
except, crucially, for the line containing the insertion point. Also,
unmatched delimiters aren't always detected, e.g. (defn foo [x (] bar)
does not flag the unmatched ( inside the arglist.
* There seems to be no easy way to get the REPL to use the -server vm.
Eclipse seems to only look for JRE runtimes, not JDK runtimes, and if
manually pointed to a JDK directory, it says it can't recognize the
runtime library, whereas if pointed to the JDK /bin subdirectory, it
says it can't recognize the java executable. So it doesn't seem to
provide a way to use the JDK's java runtime instead of the JRE's, and
the JRE's does not recognize the -server flag, at least not on
Windows, for whatever reason. The only apparent workaround is to
manually launch the JDK's java.exe with a manually-set classpath and
appropriate arguments to run the REPL server in it, and then manually
connect to that server to get a REPL pane in Eclipse.
All in all, the bugs/awkwardness factor seems similar for both options
at this point. There is an odd pattern though. Most of the Enclojure
bugs make it easier to crash the REPL and harder to restart it when it
goes, and/or make using the thing slow in general. There's a few
missing features that might be desired, such as rainbow parens. On the
CCW side, there are few outright bugs, aside from the install
procedure being less simple than just "browse Marketplace, click
install, restart IDE" and this fact simultaneously not being obvious
if you approach CCW along certain trajectories. Instead, there are
what seem to be mainly missing features: separate start-repl and
load-file-in-repl commands; kill/restart repl process; one-keystroke
command to reindent all lines intersecting a multi-line selection. All
I foresee as being likely to be substantial sources of day to day
editing/testing awkwardness, however.
Please do not take this the wrong way. No "bashing" of either IDE is
intended here. Rather, I would like to see both IDEs improve, and
believe that providing constructive feedback after using both of them
is one way of assisting in that process; and that the maturation of
these tools is crucial while Clojure is still young, lest it get
perceived as having "perpetually" poor tool support or something (by
the non-emacs user contingent, anyway). At this point, it's to be
expected that the IDEs and other tools are still maturing; the
language is what, four years old? If that. But Clojure adoption may be
getting close to hitting the knee of the curve, and if the tools
aren't just a *bit* more polished by then, it may begin to
significantly hinder adoption.
Furthermore, I acknowledge the possibility that one or more of the CCW
"missing" features (e.g. restart REPL) is actually present, but if so,
it is not easily discovered within the interface by menu-browsing,
examining toolbar buttons, and similar methods. It may be documented
somewhere else and, say, accessible only via shortcut key; IMO that is
not enough. As has already been discussed once, it is a fact, if an
unfortunate one, that installing the plugin via the Marketplace does
not cause the user to be presented with documentation or links to
same; and it is a general industry standard these days for commands
that exist in a GUI application to be in *some* menu *somewhere*,
usually in a right-click menu on the appropriate target in particular,
and any shortcut key documented there, as in the common example of an
Edit menu including the item "Copy Ctrl+C". If such is the case
for one or more of the features I noted as "missing" from CCW that
Enclojure has, consider the lack of a menu option/toolbar button for
that feature to be the missing feature instead; it is still a problem,
and not much less serious -- but a lot easier to fix!
Thank you for your consideration of these observations.
Chas Emerick
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.
> * There seems to be no right click menu option to (re)load a source
> file (either from the open file in the editor, or from the file's
> listing in the package explorer) in an open REPL. Run... will start a
> new REPL for each file/reload; to (re)load in an existing REPL seems
> to require select all, copy, paste, enter, which will clutter up the
> REPL history with (possibly very long) blocks of code. Drag and drop
> from editor to either pane of REPL does not accomplish anything
> either.
You certainly can load sources from open editors with one keystroke -- the default is Ctrl-L (maybe Cmd-L on Macs). The contextual menu item (if you right-click in the editor itself) is under Clojure > Load File in REPL (you'll see the current keybinding for your environment there as well). There are also shortcuts for loading only the current top-level expression, and switching to the current file's namespace in the current REPL.
> * No separate option to start a project-classpath'd REPL without
> loading any files initially.
Not true. Right click a project's icon in either the Package Explorer or Project Explorer views, and you'll find a Run As > Clojure Application menu item that will start a VM and connect a REPL to it. This is roughly the only way I ever start REPLs (I dislike having run configurations set up that automatically load files on startup, etc).
> * Namespace Browser is nifty, appearing to introspect on the open REPL
> to maintain a set of defined symbols; similarly, autocomplete "sees"
> your REPL-defined functions and vars. However, it won't update if a
> var is redef'd with changed metadata; e.g. if you define a function
> without a docstring, then redefine it with a docstring, the docstring
> won't get added to the tooltip for its symbol in the Namespace
> Browser. In fact, under some circumstances (I'm not sure what), it
> won't update promptly to reflect a new function definition at all.
> Oddly, it will update eventually but I'm not sure what triggers it. On
> the other hand, it has a handy incremental search box at the top.
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…
> * Editor doesn't seem to have an option to reindent a block of code;
> going line by line and hitting tab seems to be the only method
> provided, short of fully-manual reindentation.
This is a much-requested item, and I think is blocked by some of the underlying parser bits. The issue to watch: http://code.google.com/p/counterclockwise/issues/detail?id=139
> * There seems to be no easy way to get the REPL to use the -server vm.
> Eclipse seems to only look for JRE runtimes, not JDK runtimes, and if
> manually pointed to a JDK directory, it says it can't recognize the
> runtime library, whereas if pointed to the JDK /bin subdirectory, it
> says it can't recognize the java executable. So it doesn't seem to
> provide a way to use the JDK's java runtime instead of the JRE's, and
> the JRE's does not recognize the -server flag, at least not on
> Windows, for whatever reason. The only apparent workaround is to
> manually launch the JDK's java.exe with a manually-set classpath and
> appropriate arguments to run the REPL server in it, and then manually
> connect to that server to get a REPL pane in Eclipse.
This is very easy to set up. First, the JVM stuff is all eclipse-land, and definitely supports using JDKs. Perhaps the relevant documentation would help?
http://help.eclipse.org/helios/topic/org.eclipse.jdt.doc.user/tasks/tasks-JREs.htm
The Java > Installed JREs panel in the Eclipse preferences is wanting JDK home directories, not /bin directories or any other.
You can set -server (or any other VM argument) for any REPL configuration by going to the Run > Run Configurations menu item. In the Run Configurations window, you'll see all of the configs associated with REPLs you've started in the past; clicking on any of them will allow you to modify command line args, VM args, make manual modifications to the classpath used only for that configuration, and so on. This is one reason why I always start my REPLs from the project itself -- I know I'll be re-running the REPL configuration for the project, on which I'll have already set -server, a better heap, etc. If I were to use a random file load as the trigger for starting new REPLs, then I wouldn't be sure as to what sort of VM configuration I'd be getting.
(That disconnect is probably a source of confusion we should address, but it is what it is at the moment.)
> Please do not take this the wrong way. No "bashing" of either IDE is
> intended here. Rather, I would like to see both IDEs improve, and
> believe that providing constructive feedback after using both of them
> is one way of assisting in that process; and that the maturation of
> these tools is crucial while Clojure is still young, lest it get
> perceived as having "perpetually" poor tool support or something (by
> the non-emacs user contingent, anyway). At this point, it's to be
> expected that the IDEs and other tools are still maturing; the
> language is what, four years old? If that. But Clojure adoption may be
> getting close to hitting the knee of the curve, and if the tools
> aren't just a *bit* more polished by then, it may begin to
> significantly hinder adoption.
No, this sort of side-by-side is great. Hopefully the above points address some of the perceived deficiencies.
> Furthermore, I acknowledge the possibility that one or more of the CCW
> "missing" features (e.g. restart REPL) is actually present, but if so,
> it is not easily discovered within the interface by menu-browsing,
> examining toolbar buttons, and similar methods. It may be documented
> somewhere else and, say, accessible only via shortcut key; IMO that is
> not enough. As has already been discussed once, it is a fact, if an
> unfortunate one, that installing the plugin via the Marketplace does
> not cause the user to be presented with documentation or links to
> same; and it is a general industry standard these days for commands
> that exist in a GUI application to be in *some* menu *somewhere*,
> usually in a right-click menu on the appropriate target in particular,
> and any shortcut key documented there, as in the common example of an
> Edit menu including the item "Copy Ctrl+C". If such is the case
> for one or more of the features I noted as "missing" from CCW that
> Enclojure has, consider the lack of a menu option/toolbar button for
> that feature to be the missing feature instead; it is still a problem,
> and not much less serious -- but a lot easier to fix!
I agree that documentation is simply not there, and I suspect both of these IDE environments require a fair bit of adjustment for those that have never used them.
One thing to keep in mind: both CCW and Enclojure try pretty hard to be good citizens on the Eclipse and Netbeans platforms, respectively. That means that (in CCW) rather than having a top-level Clojure item in projects' contextual menus, you'll find the start-a-REPL action as an item in the Run As… submenu, and REPL configurations end up being just a slight twist on standard Java application run configurations instead of being elevated into an area that might be easier to find.
These sorts of things should be natural for someone that knows Eclipse, but I can absolutely see how it could make things difficult if you're running Eclipse only to use CCW and Clojure. I don't have any good UI ideas at the moment to address that without really running afoul of Eclipse norms.
That said, I think a couple of short screencasts that do a feature walkthrough would probably resolve 90% of the where-can-find-X problem.
Cheers,
- Chas
Sean Corfield
> You certainly can load sources from open editors with one keystroke -- the default is Ctrl-L (maybe Cmd-L on Macs).
Opt-Cmd-L on Mac. Ctl-Alt-S on Ubuntu. The difference between
platforms is kind of annoying (since I switch back and forth between
Mac and Ubuntu a lot).
Switch namespace is Ctl-Alt-N on Mac and Ubuntu tho'.
Execute selection or top-level s-expression is ctl-enter on Ubuntu and
Shift-Cmd-X on Mac.
Navigating the REPL history is Ctl-Up / Ctl-Down on Ubuntu but that
doesn't work on Mac and I haven't figured what does...
> Not true. Right click a project's icon in either the Package Explorer or Project Explorer views, and you'll find a Run As > Clojure Application menu item that will start a VM and connect a REPL to it. This is roughly the only way I ever start REPLs (I dislike having run configurations set up that automatically load files on startup, etc).
Ah, I hadn't thought to dig into the project context menu - nice.
BTW, CCW 0.2.0.STABLE001 on my Mac works fine with Clojure 1.3.0 if I
have nrepl 0.0.5 on the classpath. Doesn't work on Ubuntu. That might
be a useful data point for tracking down that problem I talked to you
about off-list. I'll try 0.2.1 and no nrepl on Mac and see if that
works.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Ken Wesson
>
> 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.
>> * There seems to be no right click menu option to (re)load a source
>> file (either from the open file in the editor, or from the file's
>> listing in the package explorer) in an open REPL. Run... will start a
>> new REPL for each file/reload; to (re)load in an existing REPL seems
>> to require select all, copy, paste, enter, which will clutter up the
>> REPL history with (possibly very long) blocks of code. Drag and drop
>> from editor to either pane of REPL does not accomplish anything
>> either.
>
> You certainly can load sources from open editors with one keystroke -- the default is Ctrl-L (maybe Cmd-L on Macs). The contextual menu item (if you right-click in the editor itself) is under Clojure > Load File in REPL (you'll see the current keybinding for your environment there as well). There are also shortcuts for loading only the current top-level expression, and switching to the current file's namespace in the current REPL.
Ooh! Missed that, somehow. I think because it's buried in a submenu,
and not the same one (Run As) where the REPL can be launched.
Enclojure added most of these to the top level of the right click menu
in .clj edit panes, by contrast.
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.
>> * No separate option to start a project-classpath'd REPL without
>> loading any files initially.
>
> Not true. Right click a project's icon in either the Package Explorer or Project Explorer views, and you'll find a Run As > Clojure Application menu item that will start a VM and connect a REPL to it. This is roughly the only way I ever start REPLs (I dislike having run configurations set up that automatically load files on startup, etc).
Ah. I thought that attempted to build and run an AOT-compiled Clojure
project with a -main function. "Clojure Application" suggests that.
"Clojure REPL" might be better text for that menu option. Also in the
single-file Run As menu that loads the file.
>> * Namespace Browser is nifty, appearing to introspect on the open REPL
>> to maintain a set of defined symbols; similarly, autocomplete "sees"
>> your REPL-defined functions and vars. However, it won't update if a
>> var is redef'd with changed metadata; e.g. if you define a function
>> without a docstring, then redefine it with a docstring, the docstring
>> won't get added to the tooltip for its symbol in the Namespace
>> Browser. In fact, under some circumstances (I'm not sure what), it
>> won't update promptly to reflect a new function definition at all.
>> Oddly, it will update eventually but I'm not sure what triggers it. On
>> the other hand, it has a handy incremental search box at the top.
>
> 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…
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.
>> * Editor doesn't seem to have an option to reindent a block of code;
>> going line by line and hitting tab seems to be the only method
>> provided, short of fully-manual reindentation.
>
> This is a much-requested item, and I think is blocked by some of the underlying parser bits. The issue to watch: http://code.google.com/p/counterclockwise/issues/detail?id=139
Yes. I tried making a block selection and hitting tab, but it just
indents everything by whatever amount it indents the first line,
putting the first line in the correct position but possibly not the
rest depending on what changes were made.
Unfortunately, this is a fairly awkward problem, as I frequently have
to reindent after rearranging the structure of some code.
> 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.
> The Java > Installed JREs panel in the Eclipse preferences is wanting JDK home directories, not /bin directories or any other.
The parent directory also generated an error when I tried it.
> You can set -server (or any other VM argument) for any REPL configuration by going to the Run > Run Configurations menu item. In the Run Configurations window, you'll see all of the configs associated with REPLs you've started in the past;
I looked there, and it was empty. Are we perhaps not using exactly the
same version? My Eclipse reports itself as Helios Service Release 1.
There doesn't seem to be a way to get CCW's version reported, short
perhaps of triggering an attempt to update it, but I think it's
0.2.something.
clicking on any of them will allow you to modify command line args, VM
args, make manual modifications to the classpath used only for that
configuration, and so on. This is one reason why I always start my
REPLs from the project itself -- I know I'll be re-running the REPL
configuration for the project, on which I'll have already set -server,
a better heap, etc. If I were to use a random file load as the
trigger for starting new REPLs, then I wouldn't be sure as to what
sort of VM configuration I'd be getting.
So the REPL has to be started from the project to get its VM
configuration to appear in Run Configurations?
> No, this sort of side-by-side is great. Hopefully the above points address some of the perceived deficiencies.
They do; thank you. The main things still bothering me are:
1. Lack of multi-line reformat indents.
2. Enter in the middle of a REPL submission breaks the line even if
the sexp lacks unmatched delims, unlike Enclojure. Sometimes handy,
sometimes annoying to someone used to being able to edit something in
the middle of the line (e.g. a number), hit enter, and thus quickly
try a function with several parameters. One has to tap end (or
ctrl-end, if not on the last line) before enter in CCW's REPL. This is
more a matter of "takes some getting used to" than a bug; it's just a
difference (and it may be responsible on the Enclojure side for the
premature submission when the [s are unbalanced).
3. A few things seem a bit less self-evident without looking at either
Eclipse or CCW documentation than is the case with NB/Enclojure,
including (sorry to harp on this) the install's extra step and the
behavior of some of the other things.
> One thing to keep in mind: both CCW and Enclojure try pretty hard to be good citizens on the Eclipse and Netbeans platforms, respectively. That means that (in CCW) rather than having a top-level Clojure item in projects' contextual menus, you'll find the start-a-REPL action as an item in the Run As… submenu, and REPL configurations end up being just a slight twist on standard Java application run configurations instead of being elevated into an area that might be easier to find.
>
> These sorts of things should be natural for someone that knows Eclipse, but I can absolutely see how it could make things difficult if you're running Eclipse only to use CCW and Clojure. I don't have any good UI ideas at the moment to address that without really running afoul of Eclipse norms.
That's okay. I think the best option is to provide a quick-start guide
and an easy way to get users to discover and view it during/right
after CCW install. I do have prior Eclipse experience, though not for
a couple of years.
> That said, I think a couple of short screencasts that do a feature walkthrough would probably resolve 90% of the where-can-find-X problem.
Text documentation w/screenshots will suffice. ;) Though you can go
ahead and do both. If there's a Marketplace feature that can be used
to attach a readme.html type of thing to an installable add-on ... or
perhaps CCW could add a CCW item or submenu to the Help menu?
Actually, now that I check, the main Help Contents *does* seem to
contain a CCW section after CCW is installed, but this fact is not
obvious if you don't go looking for it. A direct link to it in the
Help menu would make that clearer. (Disturbingly, accessing the Help
also seems to start up a web server on the machine, though according
to my firewall software it never asked for an Internet-visible network
socket -- I didn't even know it was possible to open a listen socket
that would only be visible via loopback interface even without any
firewall? Low level networking not being my area of expertise, which
as you might have guessed from my other posts is algorithms and data
structures instead. It looks from this like there's no security risk
created by the server, but it does make the help open rather
s.l.o.w.l.y. :) Now that I think of it, though, the obvious way for
the REPLs to talk to the IDEs is via loopback socket too, and none of
those have triggered firewall alerts about applications trying to open
Internet-visible listen ports either.)
--
Protege: What is this seething mass of parentheses?!
Master: Your father's Lisp REPL. This is the language of a true
hacker. Not as clumsy or random as C++; a language for a more
civilized age.
Sean Corfield
> BTW, CCW 0.2.0.STABLE001 on my Mac works fine with Clojure 1.3.0 if I
> have nrepl 0.0.5 on the classpath. Doesn't work on Ubuntu. That might
> be a useful data point for tracking down that problem I talked to you
> about off-list. I'll try 0.2.1 and no nrepl on Mac and see if that
> works.
It does. I'm able to start the REPL by right-clicking on the project
in the navigator and Run As... Clojure Application for Clojure
1.3.0-alpha7 with CCW 0.2.1 with nrepl 0.0.5 on my classpath.
So I went back to my Ubuntu netbook and tried it there: I can always
start the REPL by right-clicking on the project - but it always fails
trying to start it via Load File in REPL (for Clojure 1.3.0). So I
have a workaround now!
Sean Corfield
> There doesn't seem to be a way to get CCW's version reported, short
> perhaps of triggering an attempt to update it, but I think it's
> 0.2.something.
Help > About Eclipse SDK > Installation Details - You'll see a list of
all installed plugins and their versions.
> 2. Enter in the middle of a REPL submission breaks the line even if
> the sexp lacks unmatched delims, unlike Enclojure.
I've gotten used to using ctl-enter or shift-cmd-x to just submit the
form I'm typing so I don't need to jump to the end of the form. I like
that the REPL has full editing capability, just like a source file -
including using enter to add line breaks.
> 3. A few things seem a bit less self-evident without looking at either
> Eclipse or CCW documentation than is the case with NB/Enclojure,
> including (sorry to harp on this) the install's extra step and the
> behavior of some of the other things.
Well, there's certainly a lot of Eclipse functionality that is
definitely less than obvious - even with all the Eclipse documentation
out there - and I suspect some of that carries over to CCW. But, yes,
CCW's docs are... thin...
Chas Emerick
On May 17, 2011, at 10:42 PM, Sean Corfield wrote:
>> 2. Enter in the middle of a REPL submission breaks the line even if
>> the sexp lacks unmatched delims, unlike Enclojure.
>
> I've gotten used to using ctl-enter or shift-cmd-x to just submit the
> form I'm typing so I don't need to jump to the end of the form. I like
> that the REPL has full editing capability, just like a source file -
> including using enter to add line breaks.
Indeed, this is very intentional. Many people (myself included now that the REPL area is just a mostly-full-featured Clojure editor) do a fair bit of editing in the REPL input area, so Ctrl-Enter is mandatory unless you're at the end of the form.
>> 3. A few things seem a bit less self-evident without looking at either
>> Eclipse or CCW documentation than is the case with NB/Enclojure,
>> including (sorry to harp on this) the install's extra step and the
>> behavior of some of the other things.
>
> Well, there's certainly a lot of Eclipse functionality that is
> definitely less than obvious - even with all the Eclipse documentation
> out there - and I suspect some of that carries over to CCW. But, yes,
> CCW's docs are... thin...
FWIW, if anyone likes CCW, and believes they're using it effectively, by all means cut a screencast or two. That's a great way to help out the project assuming you're not up for contributing code, and is surely more fun than writing dry textual documentation.
- Chas
Chas Emerick
On May 17, 2011, at 10:27 PM, Sean Corfield wrote:
> On Tue, May 17, 2011 at 4:09 PM, Sean Corfield <seanco...@gmail.com> wrote:
>> BTW, CCW 0.2.0.STABLE001 on my Mac works fine with Clojure 1.3.0 if I
>> have nrepl 0.0.5 on the classpath. Doesn't work on Ubuntu. That might
>> be a useful data point for tracking down that problem I talked to you
>> about off-list. I'll try 0.2.1 and no nrepl on Mac and see if that
>> works.
>
> It does. I'm able to start the REPL by right-clicking on the project
> in the navigator and Run As... Clojure Application for Clojure
> 1.3.0-alpha7 with CCW 0.2.1 with nrepl 0.0.5 on my classpath.
>
> So I went back to my Ubuntu netbook and tried it there: I can always
> start the REPL by right-clicking on the project - but it always fails
> trying to start it via Load File in REPL (for Clojure 1.3.0). So I
> have a workaround now!
Thank you for that hint — I had plugged away at the bug you reported for a bit, but was unable to replicate (similar to Laurent). As I said, I always start REPLs at the project level, so I didn't think to check for file-originated REPL starting bugs. I'll give that a shot next time I have a chance.
- Chas
Chas Emerick
On May 17, 2011, at 9:50 PM, Ken Wesson wrote:
> On Tue, May 17, 2011 at 9:04 AM, Chas Emerick <ceme...@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.
>> 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…
>
> 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
Ken Wesson
> On Tue, May 17, 2011 at 6:50 PM, Ken Wesson <kwes...@gmail.com> wrote:
>> There doesn't seem to be a way to get CCW's version reported, short
>> perhaps of triggering an attempt to update it, but I think it's
>> 0.2.something.
>
> Help > About Eclipse SDK > Installation Details - You'll see a list of
> all installed plugins and their versions.
Ah, thanks. I was looking for plugin version information where plugins
are managed. Most application about boxes don't include plugin version
information, and most application plugin-management menus do, so it's
a bit surprising for Eclipse to be the reverse. :)
It seems to be 0.2.0STABLE001, whatever that last part means.
>> 2. Enter in the middle of a REPL submission breaks the line even if
>> the sexp lacks unmatched delims, unlike Enclojure.
>
> I've gotten used to using ctl-enter or shift-cmd-x to just submit the
> form I'm typing so I don't need to jump to the end of the form.
Ah. There's nowhere where this seems to be documented, including the
CCW section the install added to the Eclipse help browser.
Thanks.
>> 3. A few things seem a bit less self-evident without looking at either
>> Eclipse or CCW documentation than is the case with NB/Enclojure,
>> including (sorry to harp on this) the install's extra step and the
>> behavior of some of the other things.
>
> Well, there's certainly a lot of Eclipse functionality that is
> definitely less than obvious - even with all the Eclipse documentation
> out there - and I suspect some of that carries over to CCW. But, yes,
> CCW's docs are... thin...
Browsing the same help section, I see a couple of things like one
whole section that just says TODO, and also an item somewhere that
ends with "(note:". I suppose we shouldn't expect too much of
something whose version number is 0.2. In fact, I've seen version 2.0s
of some products that were less usable (Windows, for one :)).
The help browser responds sluggishly to wheel scroll, but snappily to
dragging the scrollbar thumb around; but this looks like an Eclipse
bug rather than a CCW bug, as it affects other help pages besides the
CCW ones. Indeed, from the clicking noise it makes when links are
clicked I suspect it's actually an embedded Internet Exploder browser
pane (currently at a Windows box here), so it might even be an
Internet Exploder bug. Er ... knowing that particular Microsoft
product, "might even be" is an understatement; try "probably is". :)
Sean Corfield
> Ah. There's nowhere where this seems to be documented, including the
> CCW section the install added to the Eclipse help browser.
http://code.google.com/p/counterclockwise/wiki/EditorKeyBindingsFeatures
(note: ctl-alt-L does not work on Ubuntu because that's the shortcut
for lock screen - but ctl-alt-S works; ctl-enter is listed in the
Clojure menu as a shortcut and ctl-alt-X works as documented)
> Browsing the same help section
I've rarely found the included help to be much use with any plugin so
I always rely on Google. Until you mentioned it, I didn't even know
CCW installed any new help so thank you for pointing that out! I guess
it depends on your expectations...
Ken Wesson
> On Tue, May 17, 2011 at 10:20 PM, Ken Wesson <kwes...@gmail.com> wrote:
>> Ah. There's nowhere where this seems to be documented, including the
>> CCW section the install added to the Eclipse help browser.
>
> http://code.google.com/p/counterclockwise/wiki/EditorKeyBindingsFeatures
>
> (note: ctl-alt-L does not work on Ubuntu because that's the shortcut
> for lock screen - but ctl-alt-S works; ctl-enter is listed in the
> Clojure menu as a shortcut and ctl-alt-X works as documented)
Ah. It's listed as an *editor* shortcut for evaluating a sexp from
source code in the REPL, but there's no indication there that it works
in the REPL's own editable region.
> I guess it depends on your expectations...
Indeed.
Sean Corfield
> Ah. It's listed as an *editor* shortcut for evaluating a sexp from
> source code in the REPL, but there's no indication there that it works
> in the REPL's own editable region.
Expectations again: I expected every shortcut key to work in both
editor and REPL... :)
Laurent PETIT
Sorry for late answers, but quite busy here at work ... anyway seems
like you've already been on almost all points.
It's indeed true that documentation needs some love. I've delayed this
job, over & over, because I have been hesitating between having
documentation on the wiki, on the Eclipse Help mechanism, and I hated
the idea of having to maintain both in parallel, while not being able
to find the time to search a solution able to get both of them
generated from a single source ... and as a result, I haven't been
updating any of them for a long time ...
I will try to synchronize to what you all have been writing already in
this thread, only adding here and there a comment.
Cheers,
--
Laurent
2011/5/18 Sean Corfield <seanco...@gmail.com>:
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
Laurent PETIT
>
> On May 17, 2011, at 9:50 PM, Ken Wesson wrote:
>
>> On Tue, May 17, 2011 at 9:04 AM, Chas Emerick <ceme...@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
>
>
Laurent PETIT
> On Wed, May 18, 2011 at 12:11 AM, Ken Wesson <kwes...@gmail.com> wrote:
>> Ah. It's listed as an *editor* shortcut for evaluating a sexp from
>> source code in the REPL, but there's no indication there that it works
>> in the REPL's own editable region.
>
> Expectations again: I expected every shortcut key to work in both
> editor and REPL... :)
Alas, it is hard (and error prone) with Eclipse 3.x to embed editors
into editors/views, and indeed not all expected shortcut keys are
working in the REPL :-( (but it will eventually)
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
> Railo Technologies, Inc. -- http://www.getrailo.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
Ken Wesson
> 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).
I tried doing a defn in the REPL and then switching to the namespace
browser, and it does not always seem to update. After a while, or
maybe enough back-and-forth switches, it updates eventually though.
Laurent PETIT
> On Wed, May 18, 2011 at 4:24 AM, Laurent PETIT <lauren...@gmail.com> wrote:
>> 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).
>
> I tried doing a defn in the REPL and then switching to the namespace
> browser, and it does not always seem to update. After a while, or
> maybe enough back-and-forth switches, it updates eventually though.
Hmmm okay, so I really need to scrutinize this a little bit more.
Thx again for the feedback !
>
> --
> Protege: What is this seething mass of parentheses?!
> Master: Your father's Lisp REPL. This is the language of a true
> hacker. Not as clumsy or random as C++; a language for a more
> civilized age.
>
Ken Wesson
> 2011/5/18 Ken Wesson <kwes...@gmail.com>:
>> On Wed, May 18, 2011 at 4:24 AM, Laurent PETIT <lauren...@gmail.com> wrote:
>>> 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).
>>
>> I tried doing a defn in the REPL and then switching to the namespace
>> browser, and it does not always seem to update. After a while, or
>> maybe enough back-and-forth switches, it updates eventually though.
>
> Hmmm okay, so I really need to scrutinize this a little bit more.
> Thx again for the feedback !
You're welcome. Sorry I didn't get around to checking CCW in more depth sooner.
Ken Wesson
various bugs involving editing multiline forms with unmatched []s:
=> (map vector '[[* * .]
#<Exception java.lang.Exception: EOF while reading>
The correct behavior, of course, would have been
=> (map vector '[[* * .]
| ; position of insertion point on new line
instead. And yes, that was enter and not control-enter I hit.
Ken Wesson
sometime overnight. Now I get a SocketException message "Software
caused connection abort" if I hit control-space at the REPL. REPL
process is connected OK -- I can evaluate forms at it -- so it's not
the REPL-to-Eclipse socket connection that's failed. Firewall and
Wireshark type tools show nothing unusual on the internet uplink, so
it looks to be some other use of the loopback interface that's
b0rking.
Weird.
In a related development, the Namespace Browser is blank and has been
for a while. I had a long-running calculation last night evaluating at
the REPL during which it blanked and came back. I think it may have
blanked again and then failed to come back. This was while I was
investigating the head-holding issue with apply and arguments
containing embedded lazy seqs. I think it might be related to this odd
exception trace I got for one of those, where the OOME apparently got
thrown into a different thread in the JVM:
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
Java heap space
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
at java.util.concurrent.FutureTask.get(FutureTask.java:91)
at clojure.tools.nrepl$handle_response.invoke(nrepl.clj:263)
at clojure.tools.nrepl$message_dispatch$fn__179.invoke(nrepl.clj:303)
at clojure.lang.AFn.call(AFn.java:18)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.OutOfMemoryError: Java heap space
Restarting the REPL process fixed both problems (the Namespace Browser
remained blank until a mousemove event was generated within its
bounding box, then promptly filled in).
I'm not sure if the OOME caused it. If not, then it looks like the
problem is something that can get into a bogus state over on the REPL
process side. Does CCW open two separate connections to the REPL
process, one for evaluations and one for introspecting into the
namespaces and other state of the session?
Ken Wesson
> Found a new bug and it's a head-scratcher.
And right on its heels, another one. CCW's REPL seems to have the
desirable property that ctrl-dn at the most recent history item gets
you a blank prompt. Or rather, it did. Now it gives me
*clojure-version* instead, even if the most recently evaluated form
was something different. That happens to be the first form I evaluated
after restarting the REPL, and I used autocomplete (in fact, I did it
to test that autocomplete was working again). Perhaps if you start a
REPL and immediately use autocomplete, it gets "stuck" in place of a
blank line as the line to display if you go "off the bottom" of the
history?