Bugzilla – Full Text Bug Listing
| Summary: | command line console in Orion | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Grant Gayed <grant_gayed> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | grant_gayed, joe, kdevolder, mamacdon, simon_kaegi, Szymon.Brandys, tomasz.zarna |
| Version: | 0.4 | ||
| Target Milestone: | 0.5 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 372119 | ||
| Bug Blocks: | |||
|
Description
Susan McCourt
I would find this especially useful in git scenarios. Today I've been trying to accept contributor contributions and it's just too unwieldy, as described in bug 369591 and its dependent bugs. We can definitely improve our Orion workflows, but in the meantime, a command line console would let us continue working more productively. The biggest one for me is wanting to cherry pick a commit that I know by its hash id, but I have to stumble around in Orion to find a branch that has it before I can cherry pick it. I imagine in general that for a git expert it would be very frustrating to have to hunt around in the UI. (In reply to comment #2) > I imagine in general that for a git expert it would be very frustrating to have > to hunt around in the UI. point being - that we are getting more and more contributors and they may already have their own git workflows and we shouldn't make it too painful for them to work in Orion. Let me write down features mentioned on the thread: * dir navigation (commands like cd, pwd, mkdir, rm, ls ...) * git integration (clone, init, cherry-pick and others required by bug 369591) * working with sites (set up, start, ...) * opening editors * commands for plug-ins * keybindings * make sure the UI doesn't get stale after using the console * history * content assist * syntax markup These two came to my mind when reading the thread, I don't think they were mentioned there * accept keywords like ${selection} * allow to open/run file containing a script in the console, a "Run in console" action Hi, I was on the weekly orion call today and mentioned that I am interested in contributing in this area. The reason why I want to contribute to command line support is that we are interested in node.js support on the server. This will likely require some support to execute sever-side commands to setup node apps / modules. From the weekly call, it seems like I am not the only one interested in working in this area. So if someone else is already working on this issue, or also interested. I certainly don't want to seem like I'm stepping in and taking. I'd rather lend a helping hand and try to work together with however else is interested in this. When I get some time I will start digging around for existing javascript implementations of a command line UI that we may be able to re-use. (In reply to comment #5) > When I get some time I will start digging around for existing javascript > implementations of a command line UI that we may be able to re-use. Kevin Dangoor mentioned on the mailing list: >In case it helps, we're building a command line feature like >that into Firefox for our tools. It has very nice completion >capabilities. It also runs in normal web content (not just >browser chrome) and is available under a BSD license: > >https://github.com/mozilla/gcli I'm the lead developer of GCLI. I work for Mozilla. I'd be happy to help if you have issues with GCLI. Hi Joe, nice to see you here. Will take you up on that offer :-). One thing I have been struggling a bit with is how to properly handle commands that execute in asynchronous fashion. I.e. in javascript style by passing a callback function rather than returning a result. The kinds of commands we want to execute typically fall in this category since they get sent to the server by xhr request and then receive a callback with either an error or the result some time later. I came up with a 'solution' that returns a snippet of html with a div element and a unique id immediately from the gcli command's exec function. It will say something like 'Waiting for result...'. When the callback arrives later on with the actual result. I use dojo.place to replace the result element's contents with the actual result. This works ok. However from what it looks like, gcli has something to handle long running commands already (I see a kind of progress bar while command is executing). It bothers me a little that my 'solution' is by-passing this gcli feature entirely. I wonder if there is better way to handle gcli commands who's exec function involve a callback so they can't actually *return* the real result. (In reply to comment #8) > Hi Joe, nice to see you here. > > Will take you up on that offer :-). > > One thing I have been struggling a bit with is how to properly handle commands > that execute in asynchronous fashion. I.e. in javascript style by passing a > callback function rather than returning a result. > > The kinds of commands we want to execute typically fall in this category since > they get sent to the server by xhr request and then receive a callback with > either an error or the result some time later. > > I came up with a 'solution' that returns a snippet of html with a div element > and a unique id immediately from the gcli command's exec function. It will say > something like 'Waiting for result...'. > > When the callback arrives later on with the actual result. I use dojo.place to > replace the result element's contents with the actual result. > > This works ok. > > However from what it looks like, gcli has something to handle long running > commands already (I see a kind of progress bar while command is executing). It > bothers me a little that my 'solution' is by-passing this gcli feature > entirely. > > I wonder if there is better way to handle gcli commands who's exec function > involve a callback so they can't actually *return* the real result. It works like this: gcli.addCommand({ name: 'slow', description: 'Wait for a while, then do something', returnType: 'string', exec: function(args, context) { var promise = context.createPromise(); window.setTimeout(function() { promise.resolve('the real result goes here'); }, 10000); return promise; } }); If I recall correctly, if the return has a function called 'then' we work with it, so it might work with dojo deferreds (maybe not tested, etc) Also, see here: https://github.com/mozilla/gcli/blob/master/docs/writing-commands.md The section on 'Returning data' Thanks Joe... that seems to be exactly what I need. And the info is actually in the readme file! Somehow I must have skipped over that bit. I've got an initial implementation of a simple gcli-base commandline UI.
It consists out of three pieces. Only one of these three pieces should really become part of orion proper. The other two parts are 'add ons'.
(1) core gcli ui with baked in commands 'ls', 'pwd' and 'cd'.
(2) an orion plugin to (1) that provides some additional commands to support deploying apps to cloudfoundry.
(3) server side plugin that is needed to execute commands for (2) on the server.
I'm providing all of the three components here because, though they shouldn't become part of orion, (2) and (3) may be useful as 'examples' on
how to plugin additional commands. (and there are no other examples at the moment)
The functionality is similarly spread across three 'Eclipse plugins'.
(1) is in the eclipse plugin 'org.eclipse.orion.client.console'
(2) is in the eclipse plugin 'org.vmware.orion.client.console'.
This adds to equinox extension points to serve the plugin's resources.
Implementation of (2) and (3) assume they are deployed on the same server
as where orion is served from.
To enable the functionality this orion plugin must be installed (or
added to the 'defaults.pref' file.
http://localhost:8080/vmware/console/vmwareConsolePlugin.html
(3) is in the eclipse plugin 'org.eclipse.orion.server.shell'
(probably name should be changed, but I haven't bothered doing that yet since it won't actually become part of orion).
(1) and (2) are here:
Branch = https://github.com/kdvolder/orion.client/tree/Bug-369608-gcli-console
commit = https://github.com/kdvolder/orion.client/commit/ad86988b9e30104f5f1dd62786da3fed31f5feb7
(3) is here
Branch = https://github.com/kdvolder/orion.server/tree/Bug-369608-gcli-console
Commit = https://github.com/kdvolder/orion.server/commit/94bf4dc7770e8905d04cd7a03bd504d65e70bc97
To try this out the setup procedure is a bit complicated (due to the breaking up into all these bits and pieces :-).
But essentially you clone and checkout the two branches instead of 'orion.server' and 'orion.client' main repos. (Note: gcli code is a submodule so use -recursive option to clone the client repo)
Then you run the provided ide.launch config which has been modified to add the three new eclipse plugins as 'extra plugins'.
To actually get the 'vmware' command you still need to manually install the orion plugin at http://localhost:8080/vmware/console/vmwareConsolePlugin.html
Because I couldn't otherwise 'activate' those automatically without modifying core orion.
If you just wanted the 'core' gcli with 'ls', 'cd' and 'pwd'. Then you only need to clone the client repo. This will contain both components (1) and (2). But you only really want/need to run with (1) added as an extra plugin and shouldn't need to do anything else.
I'm sure we are not yet at a point where (1) can actually go into orion (someone probably will need to help me a bit with correctly packaging the gcli library code and hooking things in such a way that it works in orion's build process. Not to mention legal process / permissions to add gcli into orion).
So, what's the next step?
Kris
2 things: I'd like to have a play with this integration. I've not played with orion before (although I'm a long time eclipse user). Do I need anything more than the instructions in comment 11? I've just checked work into both the master and exec-729514 branches. The former, tightens up the API a bit. I hope I've not broken anything that you're using, but I'm happy to help advise on fixes it I have. The exec-729514 branch contains some experimentation around external commands. If you load GCLI from the http server and type 'connect local' then it will remote the commands defined in the server to the browser with the 'local' prefix. Hi Joe, The setup instructions I wrote above where more or less assuming you know how to setup a 'localhost' orion setup from the git repo. Those instructions are here: http://wiki.eclipse.org/Orion/Getting_the_source#Self_hosting_using_local_server Essentially follow those instructions but use my github clones and glci branches indicated. BTW: since posting my initial commits here I've made some more changes/fixes improvements. You may want to checkout these branches instead: Server bits (only needed for the 'vmware commands'): https://github.com/kdvolder/orion.server/tree/gcli-console-rebased Client side bits: https://github.com/kdvolder/orion.server/tree/gcli-console-rebased You should be able to follow the instructions from the wiki above, but checking out my branches instead of main orion repos. Use a copy of 0.4.RC3 as the target platform with these branches. Then to enable 'vmware' commands you need to install an orion plugin as explained here: http://wiki.eclipse.org/Orion/How_Tos/Installing_A_Plugin Let me know if you are having problems or have some feedback / hints on how to make better use of gcli. I'll be trying shortly to pull your latest commits and see if there's any problems. Kris I just pulled master branch from your git repo. A lot of problems! Many things seem to have moved and I had to update many a require(). This isn't too too bad. But once I updated those as best I could the real trouble started: Other problems: - The layout UI look is broken. The prompt chars ">>" are not showing. - The completion element is not showing (i.e. I can't see what is going to be accepted if I press TAB - The menu popup that shows available commands is not showing. - My custom 'directoryType' that suggest valid completions for the 'cd' command is not working anymore. The good news is that most of the commands themselves still seem to work if I type them... (However, I have to remember what to type since the 'hints' UI is completely not working). Seems like I may have quite bit of work to figure out how to fix all these problems. Kris PS: Minor cosmetic issue: There's a line of text displayed initially: 'GCLI is ...' I'd rather not see that line. A nice empty display is better. For example it gives a hint about typing a 'help' command. But this command is not defined in my version (i.e. I haven't added the help command, so that text definitely is not appropriate in my context). I played a little with the demo app to get an idea how it is now supposed to work (i.e I ran 'node gcli.js'). Wanted to see what trouble is caused by my code being incompatible with the new version. I noticed there that the 'intro text' goes away after clicking the 'got it' button. My embedded version's got it button is rendered funny and clicking it isn't working. I also noticed that some of the problems I'm experiencing may be by design? E.g. also I get no 'completions' menu. I explicitly have to type 'help <something>' to get info on what commands are available. If that is by design, I think it is a step backwards. I pretty much preferred to see the hints 'popup' automatically. E.g. for the demo app. I am faced with an empty screen... What do I type?? Ok So I have to type help. To discover the list of toplevel commands. I see there's a 'gcli' command. I type this. Now I get no hints as to what I can type next (it has subcommands? But what are they?). So now to discover the subcommands I have to back out of what I was typing and type 'help gcli'. Now I get a list of gcli subcommands. Then type 'gcli selboolnum'. The hints for the first param, which I guess is a 'selection' is lacking. I haven't been able to figure out at all how to determine what its valid values are. So far... I'm really not liking the new UI compared to the old one. Kris (In reply to comment #13) > Hi Joe, > > The setup instructions I wrote above where more or less assuming you know how > to setup a 'localhost' orion setup from the git repo. Those instructions are > here: > http://wiki.eclipse.org/Orion/Getting_the_source#Self_hosting_using_local_server > > Essentially follow those instructions but use my github clones and glci > branches indicated. I started with the basic setup - no custom repos, and couldn't get a build. One of the errors seems to be that org.eclipse.orion.server.ui has a dependency on org.eclipse.ui and org.eclipse.ui.console, neither of which are provided by the orion platform that I've downloaded. I tried v0.4 and I20120313. Or maybe I misunderstand where the dependencies come from. I tried working from eclipse installs from 3.7.2 and 3.7.1 Maybe I should take this somewhere else, however the link off the install page (https://dev.eclipse.org/mailman/listinfo/orion-dev) is erroring for me right now. Joe. (In reply to comment #16) > One of the errors seems to be that org.eclipse.orion.server.ui has a > dependency on org.eclipse.ui and org.eclipse.ui.console I'm pretty sure that for your purpose you can simply ignore the project and close it. Right as Tomasz is saying, the server.ui plugin can be ignored. I had similar issues with that. But checking the launch configuration it is clear that this plugin is not being used when you run orion. So simply close this project. Also I noticed that Tomasz has made some changes to some of the git related server-side plugins upgrading to newer version of JGit. I thought it would be easier if I didn't integrate those changes yet into my console branch so you can continue to use 0.4.RC3 as target platform rather than a nightly integration build. The point is... if you want to try out my branches you'll need to use 0.4.RC3 as target platform for now. This is all a bit complex to setup. If you like I wouldn't mind having a chat with you on skype and give you demo of the gcli integration in orion. I am actually quite keen to get your feedback and also pick your mind a bit about where gcli is heading. Also, perhaps this can save you further hassles trying to get this stuff all installed and working. At the moment it has a lot of 'moving parts' and its a bit hard to put these parts together. If you are interested in a one-on-one like this, send me an email at kdvolder@vwmare.com or find me on Skype (id=kdvolder). Kris (In reply to comment #18) > I thought it would be easier if I didn't integrate those changes yet into my > console branch so you can continue to use 0.4.RC3 as target platform rather > than a nightly integration build. > > The point is... if you want to try out my branches you'll need to use 0.4.RC3 > as target platform for now. So to be clear - I'm now using this, right? http://archive.eclipse.org/orion/drops/S-0.4RC3-201202241252/index.html @Joe: Yes, that looks correct that is 0.4.RC3. Use that one to try out my gcli branches on github. Some thoughts as I look through things:
# Alignment issues and the >> prompt.
GCLI has to work in environments which want fine control of the pixels themselves and in environments where it should be simple. So the deal is, that you've got a choice:
* Option 1: if you hand us just an input element with <input id="gcli-input"/> then we'll create the completion div and the prompt div, and register a resize handler to keep them all in the right place.
* Option 2: you create the input element, completion div and prompt, and manage it yourself.
I think you'd like to be in option 1?
# Startup
For various reasons gcli.createView (as used in the top level html/js file) was a confusing name, I renamed it to gcli.createDisplay (and left a proxy in).
# Default setting values
I'm adding a startup option, so you can provide different defaults from those which GCLI normally provides. For example:
gcli.createDisplay({
settings: { hideIntro: true }
});
# Intro text
The above tip should allow you to get rid of the initial text. Ideally there would be an easier way to change it, but I'll need to work that out.
Yes, I would like to be in option 1 (simple). But because the simple option didn't work I had to resort to manually position the elements with CSS. I'll find some time soon to try out if the simple option is working better in the new version. Being able to suppress the intro text in the manner you suggested seems fine to me. (I don't think that is complicated at all :-) Also I want to set the record straight. After our private skype chat yesterday I'm pretty happy with the direction the new gcli UI version is taking. My initial misgivings voiced in comment #14 were mostly due to not having figured out that pressing F1 enabled the functionality I was missing. Since there's also a preference to turn this functionality on by default... it looks like gcli's new version is only getting better :-) Kris I've pushed some changes to the gcli-console-rebased branch to get it working again with the latest Orion. The about.html changes are just a copy from another plugin. Patch: https://github.com/kdvolder/orion.client/commit/870d29c6faf6a6f4c20c5ed5f6275159e23ef7df . Kris, I've had a look at the implementation, my initial thoughts are: - The current interface for contributing a command seems reasonable. Perhaps the contributed function should be called "run" rather than "exec" in order to align with orion.edit.command. I know that "exec" is the name from gcli, but this seems like an implementation detail. Thoughts? - I assume the dependency on the added shim/es5-bind.js can be replaced by the existing orion/es5shim.js? (perhaps this was a change in Orion that I did not properly adapt to in the comment 23 work?) - Q: You know the implementation history, are there aspects that you think need revisiting (ie.- things that were done to get it working but should be improved)? > The current interface for contributing a command seems reasonable. Perhaps > the contributed function should be called "run" rather than "exec" in order to > align with orion.edit.command. I know that "exec" is the name from gcli, but > this seems like an implementation detail. Thoughts? Sure. I have no objections to calling it run. > I assume the dependency on the added shim/es5-bind.js can be replaced by the > existing orion/es5shim.js? (perhaps this was a change in Orion that I did not > properly adapt to in the comment 23 work?) I assume so. shim/es5-bind.js was added because gcli was using es5 bind function. I pulled this function out from somewhere else in orion rather than add a dependency to an external es5 shim. I assume that the orion/es5shim.js was added after I worked on this. All gcli needs is the bind function. There is a message on orion-dev mailing list about this. I did what Simon recommended, but I gather someone else also did something similar and that this was actually committed to orion whereas my changes were not. > Q: You know the implementation history, are there aspects that you think need >revisiting (ie.- things that were done to get it working but should be >improved)? There are many :-) Here are a few things from the top of my head. - cd doesn't understand paths (i.e. anything with a '/' in it won't work) (the trickiest bit of this will be updating the content assist :-) - we should update to newer gcli version - there is no way for the contributed commands to be interactive (e.g. like reading input from standard in) - there is no way for to contribute new data types to gcli (so you are mostly limited to using 'string' data type to define new contributed commands). - contributed commands are limited to textual monospace output => would be nice to have 'richer' html formatting, even interactiveness via webforms (but I guess we should only change the API when we have an actual use case). - ls creates links for files. But this is a hack, it has no understanding of file types and will create links to stuff like huge zip files, trying to open these in the editor. - user authentication probably isn't quite right. (only authentication is as a side effect of using fileClient.js to read current directory info. For example when info is cached from before, then it is possible to issue commands while not even being logged in) - search for some TODO elements for more things that I marked as potential issues. Closing report since the initial Console widget and page are now released. There are still various issues to be resolved, which I will log individual reports for shortly. |