You'll have to ask Mike, I don't know, sorry.
On Fri, May 11, 2012 at 3:56 PM, Julien Viet <julien(a)julienviet.com> wrote:
it seems it would not work anymore today as I'm seing :
public void setBufferPosition(int row, int col)
{
// try
// {
// reader.print(new Ansi().cursor(row, col).toString());
// }
// catch (IOException e)
// {
// throw new RuntimeException("could not set buffer position", e);
// }
}
in the current codebase.
any idea why is it commented ?
On May 11, 2012, at 9:51 PM, Lincoln Baxter, III wrote:
You would need both in order to inform the shell what part of the screen
belongs to your plugin, and what belongs to the shell itself (or visa versa)
https://github.com/mikebrock/windowblu
This plugin may or may not install anymore, but this is why he wrote it.
This plugin places a clock on a banner at the top of the shell. Pretty cool
:) opens up a lot of uses for menus and such down the road.
~Lincoln
On Fri, May 11, 2012 at 3:46 PM, Julien Viet <julien(a)julienviet.com>wrote:
> if I understand correctly if JLine is used from within a shell triggered
> by an app like emacs then the two height are different
>
> can you tell me how to reproduce such case in practice ?
>
> why does the less command need to use both ?
>
>
> On May 11, 2012, at 9:36 PM, Julien Viet wrote:
>
> and can you give an use case of usage from within forge ?
>
> how/why does the less command uses it ?
>
> On May 11, 2012, at 8:37 PM, Mike Brock wrote:
>
>
> On May 11, 2012, at 2:34 PM, Lincoln Baxter, III wrote:
>
> Mike, could you please explain this API for Julien? Or better, document
> it ;)
>
> Thanks,
> Lincoln
>
> On Wed, May 9, 2012 at 10:44 AM, Julien Viet <julien(a)julienviet.com>wrote:
>
>>
>> On May 9, 2012, at 1:49 PM, Lincoln Baxter, III wrote:
>>
>> Hey Julien,
>>
>> That's really cool! Just so I know what you did in your video - you had
>> an OSX shell running, and you executed Forge using the maven exec goal.
>> This forge build used CRaSH as the terminal implementation? This is very
>> promising!
>>
>>
>> In Forge as I was suspecting, the IO part is not a plugin (but is a CDI
>> bean) but more like a connector that fires invocation in the forge runtime
>> and provides interactions (like reading a line, getting the width, printing
>> something) etc...
>>
>> It is similar to CRaSH that is layered as:
>>
>> - Term interface which defines interaction for a term : implemented by
>> SSH and Telnet
>> - Shell interface which defines interaction for a shell : used natively
>> by JLine and the new web interface
>>
>> so we have: those possible stacks in crash
>>
>> apache sshd <-> ssh term io <-> shell <-> async shell <->
shell impl
>> (groovy)
>> telnetd <-> ssh telnet io <-> shell <-> async shell <->
shell impl
>> (groovy)
>> jline <-> jline processor <-> shell <-> async shell <->
shell impl
>> (groovy)
>> jquery console <-> shell servlet <-> shell <-> async shell
<-> shell
>> impl (groovy)
>>
>> So basically I did an implemention of org.crsh.shell.Shell interface to
>> allow Forge to be used as a Shell:
>>
>>
http://julienviet.com/crash/javadoc/org/crsh/shell/Shell.html
>>
>> This way forge could be used by all connectors
>>
>>
>> Which features aren't working at the moment? (If you want to cry a
>> little bit on the inside, you might want to try the "less" plugin ;)
>>
>>
>> in fact I have not yet implemented the getHeight() (used by the less
>> plugin) because I was not able to understand the meaning of getHeight
>> versus getAbsoluteHeight . This part is not well explained. According to
>> the code it's related to an internal buffer.
>>
>> Could someone give me info about it ?
>>
>
> It's in case you create a program like Emacs, which has bars on the
> bottom and top. The sub-buffers may report less height to the actual app
> running, but the absolute height will always report the actual screen
> height no matter what.
>
>
>>
>> As part of Forge 2.0 (I think I mentioned this before,) we really want
>> to de-couple the shell from any plugins, and provide a standalone container
>> for plugin execution, so if you run in to any coupling issues, it would be
>> *really* helpful if you could open a JIRA against
>>
https://issues.jboss.org/browse/FORGE - using the 2.0 target version :)
>>
>>
>> I will tell you once I have moved forward with the POC.
>>
>> I think that at the end the Forge Shell should implement the Shell
>> interface of CRaSH that defines the interaction.
>>
>> This interface is imho decoupled from the IO since today it is able to
>> interact with the various existing implementations.
>>
>> Also CRaSH has notion of process to model a shell command running :
>>
http://julienviet.com/crash/javadoc/org/crsh/shell/ShellProcess.html
>>
>> In the future I plan to make several process to execute concurrently
>> (like you can do in shell)
>>
>> So it would be really cool that forges moves in that direction (which is
>> what my POC is doing).
>>
>>
>>
>> Then we can start addressing these issues individually.
>>
>> Thanks!
>> ~Lincoln
>>
>> On Mon, May 7, 2012 at 5:45 PM, Julien Viet <julien(a)julienviet.com>wrote:
>>
>>> I started to do basic integration to give a concrete try and I'm able
>>> to make forge core/shell module to run using CRaSH JLine connector.
>>>
>>> It is not 100% operational (as any POC) as some features are bypassed
>>> at the moment, the following work:
>>>
>>> - command execution
>>> - command completion
>>> - prompt within a command but without completion (as crash does not
>>> support it originally (read here yet))
>>>
>>> here is a short video of running the core/shell module standalone :
>>>
http://www.youtube.com/watch?v=GJ_QbgawkpE
>>>
>>> I pushed this POC in my GH repository if you are interested to look at
>>> the changes yourself :
https://github.com/vietj/core/compare/crash
>>>
>>> I will continue to work on this later to add telnet or ssh support
>>> because it would be the real value added for forge to use CRaSH.
>>>
>>> Julien
>>>
>>> On May 3, 2012, at 3:33 PM, Julien Viet wrote:
>>>
>>> > no problem actually I had to update CRaSH to use the latest JLine
>>> release first (I did not have time to do it before 1.0).
>>> >
>>> > I published a 1.1 beta1 and will try to see how it integrates with
>>> forge soon.
>>> >
>>> > One thing I noticed is that forge is quite coupled at the code level
>>> to the JLine project and it's not an obvious thing to decouple it fully.
>>> And that would be necessary to achieve a clean integration.
>>> >
>>> > I will focus on doing a POC in the coming days.
>>> >
>>> > Meanwhile you can have a look at the web connector demo I've done
>>> recently :
http://crash.vietj.cloudbees.net/
>>> >
>>> > you can try fun stuff like:
>>> >
>>> > "% help"
>>> >
>>> > "% sleep 10" then ctrl-c
>>> >
>>> > "% thread ls"
>>> >
>>> > "% system propget java." + tab
>>> >
>>> >
>>> >
>>> > On May 2, 2012, at 5:14 PM, Lincoln Baxter wrote:
>>> >
>>> >> Awesome, Julien!
>>> >>
>>> >> Sorry for the delay on my end. I am at a conference and have
limited
>>> access to the RedHat mail VPN.
>>> >>
>>> >> Could we bring this discussion to the dev list? (Copied)
>>> >>
>>> >> This way everyone will be able to discuss/follow. And I'll see
it
>>> faster since it comes to all of my accounts.
>>> >> Thanks!
>>> >>
>>> >> ~Lincoln
>>> >>
>>> >> ----- Original Message -----
>>> >> From: "Julien Viet" <julien(a)julienviet.com>
>>> >> To: "Lincoln Baxter, III" <lbaxter(a)redhat.com>
>>> >> Cc: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
>>> >> Sent: Friday, April 27, 2012 1:32:42 AM
>>> >> Subject: Re: Forge CRAsH, CRAsH Forge!
>>> >>
>>> >> I'm trying to POC something with crash as invoker of forge.
>>> >>
>>> >> I can now clearly see how it would work:
>>> >> - the jline code would be merged somehow with jline crash code: I
>>> need to see what can be reused or not
>>> >> - the invoking part would use crash that would give the benefit to
>>> use the other protocol out of the box like SSH
>>> >> - crash would be used like a IO library mostly that wraps the
>>> various implementations (jline,ssh,telnet)
>>> >>
>>> >> It will take me some time because I cannot spend much time on it
>>> (and I'm in vacation until wednesday :-) ).
>>> >>
>>> >> That being said I learned interesting stuff looking at forge code,
>>> like the nasty but useful proprietary SigHandler usage that is useful
>>> >> to catch control-c and use it to interrupt a process.
>>> >>
>>> >> This way the "shell" implementation (i.e was the shell do
when you
>>> use it) would remain separate I think because CRaSH uses a file based
>>> approach (using lot of groovy)
>>> >> and forge uses a plugin based approach with CDI based on plugin
>>> deployment. We can still see more convergence later: in particular the
>>> command line parser, both seems very contextual and are pain to write /
>>> maintain :-)
>>> >>
>>> >> I'll let you know when I'll have available, it may take a
couple of
>>> weeks depending on the work load aside (probably less). It will surely fork
>>> forge on GH
>>> >> to push the work visible at some point, I'll also post on the
forge
>>> dev list too at this moment.
>>> >>
>>> >> Julien
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Apr 26, 2012, at 8:18 PM, Lincoln Baxter, III wrote:
>>> >>
>>> >>> Plugins can change core behavior, so certainly.
>>> >>>
>>> >>> On Thu 26 Apr 2012 01:43:33 PM EDT, Julien Viet wrote:
>>> >>>> if the connectivity part of forge is also a plugin of forge,
then
>>> it would certainly work.
>>> >>>>
>>> >>>> On Apr 26, 2012, at 7:26 PM, Lincoln Baxter, III wrote:
>>> >>>>
>>> >>>>> That's certainly something we could do as well! I
like that idea
>>> :) It would certainly be easier if CRaSh were used as the Forge shell
>>> provider.
>>> >>>>>
>>> >>>>> On 04/26/2012 12:55 PM, Max Rydahl Andersen wrote:
>>> >>>>>> I was thinking that the functionallity in CRAsH to
connect
>>> remotely could be loaded in as a plugin to Forge.
>>> >>>>>>
>>> >>>>>> That would be more an addon and not involve complex
>>> dependencies/legal rearrangements ?
>>> >>>>>>
>>> >>>>>> /max
>>> >>>>>>
>>> >>>>>> On Apr 26, 2012, at 15:46 , Lincoln Baxter, III
wrote:
>>> >>>>>>
>>> >>>>>>> Hey Julien!
>>> >>>>>>>
>>> >>>>>>> CRaSH seems like a very well implemented and
creative project!
>>> At first I didn't really understand what it was for, but the thought of
>>> providing SSH access directly to runtime Java applications is, simply put,
>>> brilliant!
>>> >>>>>>>
>>> >>>>>>> Forge is a bit heavy for that at the moment,
because of our
>>> dependency on CDI (primarily,) and because we haven't yet disassociated
the
>>> built-in plugins from the core distribution. Soon, however, our shell will
>>> be entirely standalone. With zero or as much functionality as you want OOB.
>>> >>>>>>>
>>> >>>>>>> I noticed we both use JLine, although mike's
Forked it quite a
>>> bit for our needs. (Wish he would have done it as an actual fork, not as a
>>> source bundle in the project itself, but perhaps there's some
collaboration
>>> opportunity there.)
>>> >>>>>>>
>>> >>>>>>> Where do you think we can work together? I'm
totally open to
>>> ideas.
>>> >>>>>>>
>>> >>>>>>> ~Lincoln
>>> >>>>>>>
>>> >>>>>>> On Wed 25 Apr 2012 04:18:06 PM EDT, Julien Viet
wrote:
>>> >>>>>>>> hey :-)
>>> >>>>>>>>
>>> >>>>>>>> I would welcome a collaboration, a single
effort would provide
>>> more features, increase the community footprint and visibility of both
>>> projects.
>>> >>>>>>>>
>>> >>>>>>>> I have been working hard recently to finish
the 1.0 of CRaSH
>>> and provide the best user experience I could offer at the moment.
>>> >>>>>>>>
>>> >>>>>>>> Currently CRaSH is used in several products
/ projects already!
>>> >>>>>>>>
>>> >>>>>>>> - eXo Cloud IDE provides a web interface
using CRaSH under the
>>> hood (see photo here
>>>
https://twitter.com/#!/chanezon/status/194759689102303233/photo/1/large)
>>> >>>>>>>> - EPP embeds it for portal management
providing CLI :
>>>
https://lh4.googleusercontent.com/R8ruzrxNQ6IWyh-vKGgrnbzpZJJiUYMwZ5RePzR...
>>> >>>>>>>> - the Silverpeas portal embeds it :
http://www.silverpeas.org/
>>> >>>>>>>>
>>> >>>>>>>> let me know if you would like to work with
me :-)
>>> >>>>>>>>
>>> >>>>>>>> On Apr 25, 2012, at 2:43 PM, Max Rydahl
Andersen wrote:
>>> >>>>>>>>
>>> >>>>>>>>> Hi guys,
>>> >>>>>>>>>
>>> >>>>>>>>> Just wanted to e-introduce you guys
after talking to you both
>>> about the nice possible overlaps/interactions
>>> >>>>>>>>> being able to have the features CRaSH
provides from within
>>> Forge (i.e. connection and interaction with remote process).
>>> >>>>>>>>>
>>> >>>>>>>>> Julien, meet Lincoln the Forge Master;
>>> >>>>>>>>>
>>> >>>>>>>>> Lincoln, meet Julien the Party Crasher.
>>> >>>>>>>>>
>>> >>>>>>>>> /max
>>> >>>>>>> --
>>> >>>>>>> ---
>>> >>>>>>> Lincoln Baxter, III
>>> >>>>>>>
http://ocpsoft.org
>>> >>>>>>> "Simpler is better."
>>> >>>>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> ---
>>> >>>>> Lincoln Baxter, III
>>> >>>>>
http://ocpsoft.org
>>> >>>>> "Simpler is better."
>>> >>>>>
>>> >>>>
>>> >>>
>>> >>> --
>>> >>> ---
>>> >>> Lincoln Baxter, III
>>> >>>
http://ocpsoft.org
>>> >>> "Simpler is better."
>>> >>>
>>> >>
>>> >
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>>
http://ocpsoft.org
>> "Simpler is better."
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
>
> --
> Lincoln Baxter, III
>
http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
>
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."