|
»
»
»
»
Term and JNA-based pty demo code is here
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Re: Term and JNA-based pty demo code is here
by Martin Krauskopf
::
Rate this Message:
Ivan Soleimanipour wrote:
>> From Martin.Krauskopf@... Tue Jul 1 02:52:31 2008 >> >> But anyway, before I start, I need to now: >> >> - where Terminal Emulator will be moved. Might be that 'gsf' cluster > > What is gsf stand for anyway? Generic Stuff Framework? > > platform seems more appropriate. I wrote: ======= would be good starting if not feasible to move into 'platform' or 'ide'. There is already e.g. 'extexecution' module and all those Ruby, Python, Scala, etc. depends on 'gsf'. Sure 'ide' would be better, but it might more problematic. ======= Was just a suggestion. As client, I'll be happy to use it from anywhere. > Does the javadoc for this extexecution appear in > http://bits.netbeans.org/dev/javadoc/index.html > ? CCing Petr Hejl, the maintainer of the module. > Would it be worth starting a "project"? I do not understand the question. What project? >> - if you are going to provide any fancy API like I mentioned in the >> previous email? >> >> TermShell shell = new TermShell("/home/joe"); >> shell.start(); >> >> TermWindow cat = new TermWindow(); >> cat.run("/bin/cat /proc/cpuinfo"); >> >> or whether the current API is the one to start with. > > This in-effect gets us into a territory of creating an infrastructure > very parallel to the I/O window ... Does it need to interact with > extexecution? Likely some code could be shared between extexecution, Terminal Emulator and might be OW. Question rather for you and Petr Hejl, might be OW folks. So I understand the answer, that clients should wait until the decision is made, whether to go with current APIs or wait for above-like ones. m. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Term and JNA-based pty demo code is here
by Martin Krauskopf
::
Rate this Message:
Ivan Soleimanipour wrote:
>> From Martin.Krauskopf@... Tue Jul 1 02:52:31 2008 >> >> Ivan Soleimanipour wrote: >> >> From Martin.Krauskopf@... Fri Jun 27 02:15:51 2008 >> [...] >> > I remember you had asked me earlier whetehr you should start switching >> > your code to use the TE. >> > >> > I recommend keeping both variations around and dynamically switchable. >> > Until TE proves itself in actual use. >> >> I wanted to avoid this, naturally :) I think there are approximately two >> weeks until feature freeze. >> > > Well, then it won't make it to 3.5. Ok, then we can do full transition for after-6.5, since until the next release, there will be enough time to stabilize the friend API. m. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Term and JNA-based pty demo code is here
by Martin Krauskopf
::
Rate this Message:
Ivan Soleimanipour wrote:
>> From Martin.Krauskopf@... Tue Jul 1 02:52:31 2008 >> >> Ivan Soleimanipour wrote: >> >> From Martin.Krauskopf@... Fri Jun 27 02:15:51 2008 >> [...] >> > I remember you had asked me earlier whetehr you should start switching >> > your code to use the TE. >> > >> > I recommend keeping both variations around and dynamically switchable. >> > Until TE proves itself in actual use. >> >> I wanted to avoid this, naturally :) I think there are approximately two >> weeks until feature freeze. >> > > > Well, then it won't make it to 3.5. Ok, then we can do full transition for after-6.5, since until the next release, there will be enough time to stabilize the friend API. m. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Term and JNA-based pty demo code is here
by Petr Hejl
::
Rate this Message:
Martin Krauskopf wrote:
> Ivan Soleimanipour wrote: > >> From Martin.Krauskopf@... Tue Jul 1 02:52:31 2008 > >> > >> But anyway, before I start, I need to now: > >> > >> - where Terminal Emulator will be moved. Might be that 'gsf' cluster > > > > What is gsf stand for anyway? Generic Stuff Framework? > > > > platform seems more appropriate. > > I wrote: > > ======= > would be good starting if not feasible to move into 'platform' or > 'ide'. There is already e.g. 'extexecution' module and all those Ruby, > Python, Scala, etc. depends on 'gsf'. Sure 'ide' would be better, but > it might more problematic. > ======= > > Was just a suggestion. As client, I'll be happy to use it from anywhere. > > > Does the javadoc for this extexecution appear in > > http://bits.netbeans.org/dev/javadoc/index.html > > ? Extexecution still have some minor issues and thus is still under development. > > CCing Petr Hejl, the maintainer of the module. > > > Would it be worth starting a "project"? > > I do not understand the question. What project? > > >> - if you are going to provide any fancy API like I mentioned in the > >> previous email? > >> > >> TermShell shell = new TermShell("/home/joe"); > >> shell.start(); > >> > >> TermWindow cat = new TermWindow(); > >> cat.run("/bin/cat /proc/cpuinfo"); > >> > >> or whether the current API is the one to start with. > > > > This in-effect gets us into a territory of creating an infrastructure > > very parallel to the I/O window ... Does it need to interact with > > extexecution? > > Likely some code could be shared between extexecution, Terminal Emulator > and might be OW. Question rather for you and Petr Hejl, might be OW > folks. tasks. If reader and line parsing stuff would be useful for terminal too we can refactor it to separate module. > > So I understand the answer, that clients should wait until the decision > is made, whether to go with current APIs or wait for above-like ones. > > m. > P. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Term and JNA-based pty demo code is here
by Petr Jiricka
::
Rate this Message:
Ivan Soleimanipour wrote:
>> From Martin.Krauskopf@... Tue Jul 1 02:52:31 2008 >> >> Ivan Soleimanipour wrote: >> >> From Martin.Krauskopf@... Fri Jun 27 02:15:51 2008 >> [...] >> > I remember you had asked me earlier whetehr you should start switching >> > your code to use the TE. >> > >> > I recommend keeping both variations around and dynamically switchable. >> > Until TE proves itself in actual use. >> >> I wanted to avoid this, naturally :) I think there are approximately two >> weeks until feature freeze. >> > > > Well, then it won't make it to 3.5. Hi Ivan, let me ask differently. How much time would be needed to complete the terminal emulator in time for 6.5? When would we need to have the feature freeze for 6.5 for this to go in? If it can not be done for 6.5, then I see two other options: - publish the terminal emulator on the update center for 6.5dev, so it can be used as an experimental feature - Do not do anything for 6.5 and continue with this feature for NetBeans 7. Which one is preferable? Petr > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
Re: Term and JNA-based pty demo code is here
by Petr Jiricka
::
Rate this Message:
Ivan Soleimanipour wrote:
> > Do you really want a shell you cannot ^C in? I think not, so let's not attempt this for 6.5. > >> If it can not be done for 6.5, then I see two other options: >> - publish the terminal emulator on the update center for 6.5dev, so it >> can be used as an experimental feature > > Where does it need to be (src wise) in order to > make it to the update center? > > There are two chunks ... the existing proper terminalemulator > module, and the new additional pty support and term TC stuff. I think from the update center perspective, there should be just one chunk (one item visible in the Available Plugins window, which, when installed, would add the appropriate action to the Window menu. This can be implemented by providing a "kit" module, which aggregates all the implementation modules. The implementation modules would be marked as invisible - only the kit module would be visible. Alternatively, one of the implementation modules can act as the "kit" that aggregates everything that is needed. > The existing module is nominally part of cnd but it isn't available > in the dowloadable NB bits! Really? I see it in cnd2/modules/org-netbeans-lib-terminalemulator.jar and also here: http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/artifact/nbbuild/build/generated/modules.txt Though is is used in any way? I don't see it exposed in the UI anywhere, and also no other module seems to depend on it: http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/artifact/nbbuild/build/generated/deps.txt As for the update center, modules can be added to the update center through the nb.cluster.experimental property in nbbuild/cluster.properties. > If we move it to some new location and make it be downloadbale > then we need to coordinate with SunStudio packaging because it gets it's > own copy. I am not familiar with the Sun Studio packaging mechanism, so I can't tell. Does Sun Studio use the cnd cluster as is? Does it utilize the NetBeans distribution/build process somehow? Petr > >> - Do not do anything for 6.5 and continue with this feature for NetBeans 7. >> >> Which one is preferable? >> > > I'd prefer to putter along. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
|
|
|
|
|
|
Re: Term and JNA-based pty demo code is here
by Petr Hejl
::
Rate this Message:
Hi,
Ivan Soleimanipour wrote: >> From Martin.Krauskopf@... Wed Jul 2 01:49:36 2008 >> >> > Does the javadoc for this extexecution appear in >> > http://bits.netbeans.org/dev/javadoc/index.html >> > ? >> >> CCing Petr Hejl, the maintainer of the module. >> >> > > > I built my own javadoc. > > Darn! > extexecution seems almost parallel to what I have and/or where I'm heading. > > Some points > - It's main contribution seems to be line-based output filtering. > There must be some sort of provision for hyperlinking, but I > can't make sense of it. Help ... > whatever you want to do with them - for example change status of server on "Server running.." line etc. For outputting the lines (special kind of processing) there is concept of LineConvertor that allow you to extend the output printing (hyperlinking, 1:n line conversion). This API is generic enough for any similar processing and is not dependent on process or similar stuff in any way. Line/char processing part also does not depend on any specific nb ui (it just provide convenient factory methods for common use-cases such as output window). The second part of the module (ExecutionService especially) is client of this line processing API. Line processing API is designed to process log files too (for example). Execution part is refactored and improved execution in ruby which is copy - pasted and/or forked in many modules. LineConvertor and LineConvertors is the way for hyperlinking. > - It doesn't have an SPI. But I'm not sure I would either :-) > - It's wed to the existing output window. > - I doesn't try to enhance the notion of Process (with interrupts, pids etc). > Perhaps that wasn't it's charter, but based on my own experience (and Tors > recent answer to my "do you want signals") it's an important factor. > There was no use case so far. If you intend to do such enhancement it sounds like other API not related to terminal emulator directly - please do not hide such useful things - make it usable for anybody (as line processing can be used without using any of process execution stuff). > - <critisism mild="true"> > I doesn't extend or look similar to Java's ProcessBuilder > </critisism> > No it doesn't. It is based on Tor's execution in ruby and there is no reason to depend on or make it similar to ProcessBuilder - there is just one support class ExternalProcessBuilder which is just helper class and this could be instantly removed (if nobody is using it for process creation or you will provide better mechanism). > > > How ingrained is this API? > Am I in a position to displace it? > Too strong I would say. Why not merge/refactor this API's together? I think line processing is pretty generic. Other generic (sub) API would be Process extension. Terminal emulator could be on top of this. Should the terminal emulator replace the output window in all occurrences (ant tasks, other custom tasks, server logs)? I think there is place to do some work (as written in paragraph above) to provide the certain level of abstraction that client needs. Definitely the wrong way would be to go "all-or-nothing" way. > <philosophical> > I also need to steer this somewhat to SunStudios needs. > > Just to give you a flavor ... > > There, when we debug, we don't create a tab per debugger/debuggee > but multiplex the output based on the current debugged session. > This concept works for debugging because there is a Session view > but there is no "plain runners view". > > I'm also working on _remote_ execution which adds a new dimension to > the requirements for a hypothetical sophisticated extexecution. The remote > execution is, at the moment, based on proprietary stuff while > CND engineers are pursuing their own model. > </philosophical> > instead of ccing many people in a mail thread. Thanks, P. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Term and JNA-based pty demo code is here
by Petr Jiricka
::
Rate this Message:
Ivan Soleimanipour wrote:
>> From Petr.Jiricka@... Fri Jul 4 01:46:22 2008 >> >>> The existing module is nominally part of cnd but it isn't available >>> in the dowloadable NB bits! >> Really? I see it in cnd2/modules/org-netbeans-lib-terminalemulator.jar > > I just downloaded the latest cnd from the update center and there's no > terminalemulator.jar there! > You are right, same for me. When I use a small distro without C/C++ and then get cnd using update center, I don't get the terminal emulator. > Are you seeing this in your _own_ build? > It is present in the *full* NB build: http://deadlock.netbeans.org/hudson/job/trunk/2649/artifact/nbbuild/dist/zip/netbeans-hudson-trunk-2649.zip > I know Thomas Preisler fetches the built bits for use by sunstudio > and they contain terminalemulator. > >> and also here: >> http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/artifact/nbbuild/build/generated/modules.txt >> >> Though is is used in any way? I don't see it exposed in the UI anywhere, >> and also no other module seems to depend on it: >> http://deadlock.netbeans.org/hudson/job/trunk/lastSuccessfulBuild/artifact/nbbuild/build/generated/deps.txt >> > > I suspect that there is some "optimization" which excludes modules > with no dependents from the download/auto-update set. I guess that must be the case. > >> As for the update center, modules can be added to the update center >> through the nb.cluster.experimental property in nbbuild/cluster.properties. >> > > And this will automatically get them built? > And automatically put in the download center? I believe so, but the Build engineering team (nb-re@...) can give a definite answer. > I see scala stuff there but there's no scala in the current 6.1 autoupdate. > Wait, I suppose stuff in nb.cluster.experimental for _trunk_ > isn't going to make it into 6.1's auto-update. Yes, this is for trunk. > > How does this work? > Once 6.5 branches if I want to have stuff available on autoupdate > I need to put it into the 6.5 branch repository? It will be branched by Build engineering when the 6.5 branch is created. But there is still some process - for final releases, only approved modules will be added to beta/stable update center (and there is no "dev" update center for final NB releases). The list of approved modules is here (right now for NB 6.1): http://wiki.netbeans.org/NB61StableModulesUC http://wiki.netbeans.org/NB61BetaModulesUC If we want to publish the emulator on the beta or stable update center for 6.5, we would go through the approval process, and it will be added to the wiki page. Once it's in the wiki, Build Engineering takes care of uploading the modules listed in the wiki to the update center. For now, I would just worry about "dev" builds for 6.5, and we'll take care about the update center for the 6.5 final release later. > > So suppose I create a suite/kit which includes the old terminalemulator > module. That means it will be built twice but shipped (available on > update center) once. Won't this "built twice" run afoul of the > only one copy of a module/jar test? > I don't think the module will be built twice, if this is done right. Note that the "kit" concept does not imply "inclusion" - merely a "dependency". So the kit should depend on the old terminalemulator module, but the nb.cluster.experimental property in cluster.properties should probably only list the kit module (the existing terminalemulator module is already in cnd2, and it should not be included twice). Petr > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: Term and JNA-based pty demo code is here
by Tor Norbye
::
Rate this Message:
On Jul 3, 2008, at 12:56 PM, Ivan Soleimanipour wrote:
> IMO between the various platforms there are too many gotchas that > need to be fixed before we make this more widely available. > > Do you really want a shell you cannot ^C in? Well, that's what we have today. We currently offer a "shell", for the Rails console, which is extremely, and I do mean extremely, limited. It's just a plain output window, which lets you type text at the end (which is buffered and then passed to the child process), and text emitted from the child process is also appended to the output window. Things we'd really want are: - Readline handling. These shells offer command line editing, such as arrow key history and so on. - Colors. The shells often emit terminal codes to for example give the prompt or error messages other colors. Similarly, unit test execution sometimes uses terminal escape codes to highlight output such as green for success and red for failure. Both of these would be huge worthwhile improvements even if signal handling and ^C isn't there - since it's already broken. I think the way the Rails console (for example) is used today is that you use it to launch pretty simple commands - "evaluate expression X" or "query database" or "insert this row into the database". These aren't really long-term process forks (e.g. such as running "vi" in a terminal that you might possibly want to kill) so I don't think ^C is as vital as it is for a plain terminal. It is obviously desirable, but what I'm trying to say is that there are plenty of things we'd want from just a terminal emulator even if all the signal handling isn't there yet. -- Tor --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| < Prev | 1 - 2 | Next > |
| Free Forum Powered by Nabble | Forum Help |
