eclipse-shell-developer — For developers (the project, of extensions, of new language environments, etc).

Re: [EclipseShell-developer] hello

[Werner S. (murphee) <wer...@gm...>]

Johannes Wagener wrote:
> is the project alive?

Yup, but I've been on a bit of a sabbatical from EclipseShell. The
development is still going on, and I have some new features prototyped
(they should be in the CVS too).


> I need a scripting engine - preferable  javascript /rhino - in my RCP
> application. 

 EclipseShell has Rhino support, so you can definitely prototype scripts
with it.

> It should be able to use the classes in the plugins of the
> project dynamically. 

I'm not sure what exactly you mean. You want the Rhino interpreter (and
scripts running in it) to see the classes of the plugin(s) that your RCP
app consists of?
EclipseShell and the Rhino support use BuddyClassloading that allows
them to see all classes that are exported by Eclipse Plugins (or OSGI
Bundles). So, if your plugin exports it's classes, then that should be
possible.
If you don't want to export the classes, there might still be some other
way of handling this (the OSGI classloading system is remarkably flexible).

> It should also be able to modify the GUI.

Yep, possible too, although there's the complication of the threading
with SWT. You'll need to use SWT Display.syncExec(Runnable) (or it's
asyncExec cousing) method for running code that modifies the GUI.
In JRuby, I have a helper method that does this nicely, because
blocks/closures in Ruby are easy to do. eg.
syncExec {
  # do something on the GUI thread
}

You'll have to come up with a way of doing this in Javascript/Rhino.



> Is eclipse-shell a good choice?

Depends... do you need interactive access to your Scripting engine? Then
EclipseShell is a possible choice; if not, then you can just use a
plugin that provides Rhino (or package it yourself).
As I said: EclipseShell is definitely useful for prototyping scripts and
for quickly accessing functionality in Eclipse.

Again: depends on what you want to do with Rhino.

> what is the difference to eclipse monkey?

EclipseMonkey Scripts are shown in a seperate Menu in the Menubar, so
you can choose and run them. They're also working on some other triggers
for scripts, eg. resource changes, etc.

> can eclipse-shell be used in a RCP?

EclipseShell and the Rhino plugin have dependencies on the editor
framework and JDT, so you'll pull in some big(ish) plugins.
It also uses the Workspace for a lot of things, so if your RCP app
doesn't use/include the resource support, then that might be a problem too.
Otherwise it's not an issue (as far as I can tell).

> i need support for javascript only. is it difficult to use rhino directly?

Nope.


murphee

Re: [EclipseShell-developer] hello

[Werner S. (murphee) <wer...@ne...>]

Johannes Wagener wrote:
> is the project alive?

Yup, but I've been on a bit of a sabbatical from EclipseShell. The
development is still going on, and I have some new features prototyped
(they should be in the CVS too).


> I need a scripting engine - preferable  javascript /rhino - in my RCP
> application. 

 EclipseShell has Rhino support, so you can definitely prototype scripts
with it.

> It should be able to use the classes in the plugins of the
> project dynamically. 

I'm not sure what exactly you mean. You want the Rhino interpreter (and
scripts running in it) to see the classes of the plugin(s) that your RCP
app consists of?
EclipseShell and the Rhino support use BuddyClassloading that allows
them to see all classes that are exported by Eclipse Plugins (or OSGI
Bundles). So, if your plugin exports it's classes, then that should be
possible.
If you don't want to export the classes, there might still be some other
way of handling this (the OSGI classloading system is remarkably flexible).

> It should also be able to modify the GUI.

Yep, possible too, although there's the complication of the threading
with SWT. You'll need to use SWT Display.syncExec(Runnable) (or it's
asyncExec cousing) method for running code that modifies the GUI.
In JRuby, I have a helper method that does this nicely, because
blocks/closures in Ruby are easy to do. eg.
syncExec {
  # do something on the GUI thread
}

You'll have to come up with a way of doing this in Javascript/Rhino.



> Is eclipse-shell a good choice?

Depends... do you need interactive access to your Scripting engine? Then
EclipseShell is a possible choice; if not, then you can just use a
plugin that provides Rhino (or package it yourself).
As I said: EclipseShell is definitely useful for prototyping scripts and
for quickly accessing functionality in Eclipse.

Again: depends on what you want to do with Rhino.

> what is the difference to eclipse monkey?

EclipseMonkey Scripts are shown in a seperate Menu in the Menubar, so
you can choose and run them. They're also working on some other triggers
for scripts, eg. resource changes, etc.

> can eclipse-shell be used in a RCP?

EclipseShell and the Rhino plugin have dependencies on the editor
framework and JDT, so you'll pull in some big(ish) plugins.
It also uses the Workspace for a lot of things, so if your RCP app
doesn't use/include the resource support, then that might be a problem too.
Otherwise it's not an issue (as far as I can tell).

> i need support for javascript only. is it difficult to use rhino directly?

Nope.


murphee
-- 
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] hello

[Johannes W. <joh...@gm...>]

hello,
is the project alive?

I need a scripting engine - preferable  javascript /rhino - in my RCP
application. It should be able to use the classes in the plugins of the
project dynamically. It should also be able to modify the GUI.

Is eclipse-shell a good choice?
what is the difference to eclipse monkey?
can eclipse-shell be used in a RCP?
i need support for javascript only. is it difficult to use rhino directly?

reards

p.s. ich spreche auch deutsch

Re: [EclipseShell-developer] stdout again...

[Werner S. (murphee) <wer...@gm...>]

Martin Eklund wrote:

>I saw a couple of posts in the archive of this list regarding output in
>the eclipse console rather than the terminal from which eclipse was
>started. This is a feature that I would very much like to see in the
>future and as I understood it you are working on fixing this - I'm just
>wondering how things are progressing? Are you able to resolve all the
>issues?
>  
>

I was a bit busy recently, but in the next couple of days I'll be taking 
a look at the work that Lukas (see the posts) provided
and see how far this'll work.

Which language are you using with EclipseShell? If you're using 
Beanshell, there might be a simple solution
by just telling Beanshell which stdout stream to use (at least for it's 
print() macros, I assume).
Of course, if you're calling Java code that outputs to the System.out, 
that'll still go somewhere else.

BTW: are you running the scripting language inside Eclipse or externally 
(see the FAQ for an explanation
http://eclipse-shell.sourceforge.net/docs/faq.html  of the run modes 
"eclipse" and "externalDebug").
If you use externalDebug, you'll see all text written to stdout, because 
the console shown takes the streams from the
started process.

murphee
-- 
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] stdout again...

[Martin E. <mar...@fa...>]

Hi,

First of all - thanks for this excellent initiative! Great work!

I saw a couple of posts in the archive of this list regarding output in
the eclipse console rather than the terminal from which eclipse was
started. This is a feature that I would very much like to see in the
future and as I understood it you are working on fixing this - I'm just
wondering how things are progressing? Are you able to resolve all the
issues?

Cheers!

Martin.

-- 
========================================
Martin Eklund
PhD Student
Department of Pharmaceutical Biosciences
Uppsala University, Sweden
Ph: +46-18-4714281
========================================

[EclipseShell-developer] Re: stdout discussion continued

[Werner S. (murphee) <wer...@gm...>]

Lukas,

about your  stdout code you proposed:
It'd be great if you want to try to get that working with EclipseShell...

If it works, I'll integrate it into the (one of the) next releases.
I have some things I'm working on right now, and I'll be busy updating 
the  JRuby provider (updating to JRuby 0.8.3)
 so no hurry, it'll take some time before release 0.2.


Please ask if you have any questions (and CC to my email address if I 
don't respond again...
I don't trust this mailing list just yet).

murphee
-- 
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/

Re: [EclipseShell-developer] Damn MailingList...

[Lukasz S. <har...@op...>]

Hi murphee,

I confirm I received this message via e-mail.

Kind regards
Lukasz


----- Original Message ----- 
From: "Werner Schuster (murphee)" <wer...@gm...>
To: <ecl...@li...>
Sent: Wednesday, March 29, 2006 7:27 PM
Subject: [EclipseShell-developer] Damn MailingList...


> Hi to all subscribers,
> 
> seems like the SourceForge mailing list (or I?) messed up, and I didn't 
> get any mails that were sent to it.
> 
> I just checked and saw some people have sent mail to it... I'm terribly 
> sorry, I didn't ignore your mails,
> I didn't see them, and I'll get on answering them now.
> 
> Could everyone on the list please send at a reply to this mail so I see 
> if I get mails from other people?
> 
> murphee

[EclipseShell-developer] Re: About a groovy shell

[Werner S. (murphee) <wer...@gm...>]

Note: I didn't see this mail before due to a mailing list problem, so 
I'm answering this mail from the Web MailingList Archive:


Venkatesh Prasad Ranganath wrote:

>I am involved in a project in which I plan to provide access to the guts
>of an Eclipse plugin via Groovy.  

Interesting; take a look at the EclipseMonkey project, that might be helpful too (not for Groovy, but for
making access to Eclipse internals easy). The link:
http://www.eclipse.org/dash/


>provided by EclipseShell, I was planning on porting the Beanshell to
>operate with Groovy.  Is anybody in EclipseShell project working on such
>a plugin?  If not, would the project welcome such a contribution?

Yes, that'd be great.
As with the pnuts effort, I'll add links to the plugin when it's done or I'll think about
some other way of making it easy for users to access it. 


BTW: just a tip: maybe you want to use the Rhino Language provider as a starting point rather than 
the Beanshell one, as it's smaller and easier to change (I guess, maybe that's just my perception). 


>Also, is there as fixed naming scheme by which various Eclipse plugins
>can be accessed from within the shells?

Hmm... not sure what you mean. The language provider plugins need to have 
Eclipse-BuddyPolicy: global
in your language providers plugins Manifest.mf, which allows your plugin to see all exported classes of all 
installed plugins. This means you have access to all exported classes in your Eclipse installation.

Or do you want to access other information of plugins? 


murphee

-- 
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] Re: Support for Pnuts

[Werner S. (murphee) <wer...@gm...>]

Note: I didn't see this mail before due to a mailing list problem, so 
I'm answering this mail from the Web MailingList Archive:

Hal wrote:

> Pnuts as the scripting language. Hence I have added preliminary support for
> pnuts as an extension to EclipseShell. I essentially copied the BeanShell
> extension and rewrote everything I understood to use corresponding pnuts
> functionality.


Great! I don't know anything about the Pnuts language, but it'll be good 
to have support for it.



> - How do I build the corresponding feature? The feature project for
> BeanShell does not build, it isn't even configured as a feature project,
> with a build specification (in .project)! Has the jar file been built
> manually, and if so, how do I do that with my pnuts feature?

Hmm... that's odd. Could you just create a new Feature project for your 
Plugin.
The Beanshell feature works here, and it also seems to work with the 
org.eclipse.releng system (for headless builds).

> - How do I contribute this plugin back to the EclipseShell project?

If you make it available someplace, I definitly put a link on the 
EclipseShell page.
You could create a Sourceforge or JavaForge project and make it 
available there.
If you think  that's too much work... hmm... I guess I _could_ offer the 
binary version on my Sourceforge update site...
I'll have to think about possible issues with that.

murphee
-- 
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] Damn MailingList...

[Werner S. (murphee) <wer...@gm...>]

Hi to all subscribers,

seems like the SourceForge mailing list (or I?) messed up, and I didn't 
get any mails that were sent to it.

I just checked and saw some people have sent mail to it... I'm terribly 
sorry, I didn't ignore your mails,
I didn't see them, and I'll get on answering them now.

Could everyone on the list please send at a reply to this mail so I see 
if I get mails from other people?

murphee
-- 
Blog @ http://jroller.com/page/murphee
Maintainer of EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] TEST - ignore...

[Werner S. (murphee) <wer...@ne...>]

Re: [EclipseShell-developer] stdout discussion continued

[Lukasz S. <har...@op...>]

----- Original Message -----
From: "Lukasz Skowronski" <har...@op...>
To: <ecl...@li...>
Sent: Wednesday, March 15, 2006 2:10 AM
Subject: [EclipseShell-developer] stdout discussion continued


>
> ----- Original Message -----
> From: "Werner Schuster (murphee)" <wer...@gm...>
> To: <ecl...@li...>
> Sent: Saturday, March 11, 2006 5:26 PM
>
>
> > Other problem: code from an ExecutionEnvironment that gets executed on a
> different Thread; best example would be code that's called
> > from the UI thread; that's necessary for all GUI modifications in SWT
(and
> Swing), ie. as soon as you change anything in an SWT component,
> > you need to do it on the GUI EventDispatchingThread (using
> Display.syncExec(Runnable)).
> >
>
> This seems to be unsolvable in general - it will be very difficult (maybe
> even impossible) to mess with e.g. EventQueue.invokeLater(Runnable) -
> because it's in java.* hierarchy and cannot be loaded by class loader
other
> than bootstrap class loader. Hence we can't modify it's bytecode.
> We could try to apply some aspects on code which calls the EventQueue
> methods. If we have source code with calls to these methods then weaving
> shall be quite straightforward - I'm not sure what would be in case of
> weaving aspects into bytecode (when we don't have the sources) - would
this
> capture properly all invokations or not.
>
> On the other side - if the class being called wouldn't be in java
hierarchy
> (let it be javax.swing.SwingUtilities instead) then we can try to add an
> aspect to it which would be able to match Runnable classloader to the
proper
> console. Of course each Runnable instance would be created by custom
> classloader - we have to ensure that each ExecutionEnvironment will have
its
> own classloader to load Runnable class. Then we could take this
classloader
> in weaved invokeLater method, find the ExecutionEnvironment and then the
> actual console.
>
> When I'll have a little time I'll try to play with aspects..
>

After playing a little with AspectWerkz and AspectJ I believe that what I
wrote above is all true.
There is no easy way to modify classes from java.* hierarchy - there are
legal issues (because of the Sun license) and it requires mungling with
bootstrap classloader. Anyway modyfing java.* classes in the Eclipse
environment is not the best idea I think.

Well Murphee, what about integrating my idea of a fake PrintStream into the
EclipseShell?
I can prepare and send you the appriopriate code.

Regards,
Lukasz

[EclipseShell-developer] About a groovy shell

[Venkatesh P. R. <vra...@sb...>]

Hi,

I am involved in a project in which I plan to provide access to the guts
of an Eclipse plugin via Groovy.  This is similar to in-process shell
provided by EclipseShell.  However, as there were no Groovy shells
provided by EclipseShell, I was planning on porting the Beanshell to
operate with Groovy.  Is anybody in EclipseShell project working on such
a plugin?  If not, would the project welcome such a contribution?

Also, is there as fixed naming scheme by which various Eclipse plugins
can be accessed from within the shells?

Thanks for the useful plugin (and waiting for reply),=20

--=20
--

Venkatesh Prasad Ranganath,
Kansas State University.
web: http://www.cis.ksu.edu/~rvprasad

[EclipseShell-developer] stdout discussion continued

[Lukasz S. <har...@op...>]

----- Original Message -----
From: "Werner Schuster (murphee)" <wer...@gm...>
To: <ecl...@li...>
Sent: Saturday, March 11, 2006 5:26 PM


(1)
> There's only one problem: the ExecutionEnvironments arent' restricted to
one Thread per ExecutionEnvironment, ie. whenever I execute
> a statement, a new Eclipse Job which will execute it (the Eclipse Job
system is basically a Worker thread system, that uses a thread
> pool); so potentially, every code executio will happen in a different
thread.
(2)
> Even if I could fix that, then it's still possible that the code executed
in the ExecutionEnvironment will create several threads,
> and their output should go to the same Output Stream. Hmm... although...
come to think of it: this should be solved by the fact that you
> used *Inheritable*ThreadLocal... so all child threads should have the same
OutputStream...

murphee, do you agree that two problems above are quite easy to solve as I
wrote in a mail to you?
(1) - I mean associating given console with some information from the
ExecutionEnvironment context (e.g. editor name).
(2) - InheritableThreadLocal in fact solves problem with child threads.

> Other problem: code from an ExecutionEnvironment that gets executed on a
different Thread; best example would be code that's called
> from the UI thread; that's necessary for all GUI modifications in SWT (and
Swing), ie. as soon as you change anything in an SWT component,
> you need to do it on the GUI EventDispatchingThread (using
Display.syncExec(Runnable)).
>

This seems to be unsolvable in general - it will be very difficult (maybe
even impossible) to mess with e.g. EventQueue.invokeLater(Runnable) -
because it's in java.* hierarchy and cannot be loaded by class loader other
than bootstrap class loader. Hence we can't modify it's bytecode.
We could try to apply some aspects on code which calls the EventQueue
methods. If we have source code with calls to these methods then weaving
shall be quite straightforward - I'm not sure what would be in case of
weaving aspects into bytecode (when we don't have the sources) - would this
capture properly all invokations or not.

On the other side - if the class being called wouldn't be in java hierarchy
(let it be javax.swing.SwingUtilities instead) then we can try to add an
aspect to it which would be able to match Runnable classloader to the proper
console. Of course each Runnable instance would be created by custom
classloader - we have to ensure that each ExecutionEnvironment will have its
own classloader to load Runnable class. Then we could take this classloader
in weaved invokeLater method, find the ExecutionEnvironment and then the
actual console.

When I'll have a little time I'll try to play with aspects..

And of course - when we send a Runnable to another thread (not created by
us) the call stack is unusable for our purposes.. No info about caller is
supplied there...

Regards,
Lukasz

[EclipseShell-developer] Re: [Beanshell-users] EclipseShell: script Beanshell from Eclipse

[Werner S. (murphee) <wer...@ne...>]

Krau=DF wrote:
> I just set up a separate project to run another test (see attachment).=20
> Exlipcitely selected the project node before starting up the shell and =
simply evaluated the following commands in a region:
> 	test=3Dnew com.gft.test.beanshell.HelloWorld();
> 	test.setMyText("huhu");
> This time, I had a short glance at the error log as well. =20

BTW: for the external launch: it's good to evaluate "1+1" or something=20
like that first, to start the remote JVM. This takes a bit (a couple of=20
seconds), so just executing something simple is best; after the console=20
  for the new JVM process has appeared (it should have a red stop=20
button, like all other Java Consoles) see if the connection is up, do=20
something like print("Hello"); to see if it works.


> Using the 'external' run mode yields an rmi exception (see first two en=
tries in the logfile).

Yes, that should be about right, but they shouldn't be problems (I just=20
log them for completeness). The first one comes from the fact that I=20
want to execute something, but the newly launched JVM (with Beanshell)=20
hasn't managed to start the RMI server yet.
With the 2nd one, it tries to send a Beanshell Callstack over the wire,=20
which isn't possible; Did an Exception or an error occur in the=20
Beanshell JVM?

>It worked at least once (in a previous session) and I was able to issue =
a 'javap(test)' with the correct output,=20
 >but I can't reproduce it. I even rebooted the computer just to be on=20
the safe side, but couldn't get it working once more. Strange...

What happens now if you launch the external mode?


> For the eclipse mode, I get an entry in the error log referring to my w=
orkspace location.=20

But besides the error, is it possible to evaluate code?

> The problem is probably because of the use of the result of "path.toOSS=
tring();" in the InProcessBeanshellProvider.=20
 > Seems like the windows separator characters are interpreted as escape=20
charaters in the course of the evaluation of the 'cd' command.  >Maybe=20
you can get around this issue by setting the variable 'bsh.cwd' directly.

Thanks for the tip! The fact that the backslashes on windows cause=20
troubles, when the Beanshell interpreter sees them in Strings is really=20
a nasty little bug. I now set the bsh.cwd directory, and later on still=20
try the Beanshell cd();


Thanks for your bug reports, they're very helpful. Sorry if some things=20
don't work quite right yet, but with reports like these, I can try=20
fixing them.

murphee
--=20
Blog @ http://jroller.com/page/murphee
EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] Re: [Beanshell-users] EclipseShell: script Beanshell from Eclipse

[Werner S. (murphee) <wer...@ne...>]

Krau=DF wrote:
> One more thing occured to me that may be important. In the original pro=
ject, I used 'user libraries'=20
> to reference the drools and jcr-170 libraries in the project build clas=
spath rather than individual jar files.=20

> Correct me if I'm wrong, but as far as I understand the classpath setup=
 code, only source-folders and jar-files are
 > covered. Project dependencies or classpath variables come with a=20
different getEntryKind() response.

You're right, that should be added; the whole Classpath thing is a bit=20
tricky, so I left this at this stage for now... at least for the=20
InprocessBeanshell version.

The External mode for Beanshell should work, though, as I basically=20
steal the CLASSPATH settings from the Java project, and add them in bulk=20
to the "Start Beanshell" Launch Configuration. Do you see a Launch=20
Configuration by that name among your Launch Configurations? It's=20
CLASSPATH settings should reflect the ones of your project;

--=20
Blog @ http://jroller.com/page/murphee
EclipseShell @ http://eclipse-shell.sourceforge.net/

[EclipseShell-developer] Support for Pnuts

[<ha...@id...>]

Hi,

I recently discovered EclipseShell, which is something I've been waiting
for! Thanks for developing it and contributing it to the community!

Although I like the fact that BeanShell is a strict subset of Java, I =
prefer
Pnuts as the scripting language. Hence I have added preliminary support =
for
pnuts as an extension to EclipseShell. I essentially copied the =
BeanShell
extension and rewrote everything I understood to use corresponding pnuts
functionality.

Now I have two questions:
- How do I build the corresponding feature? The feature project for
BeanShell does not build, it isn't even configured as a feature project,
with a build specification (in .project)! Has the jar file been built
manually, and if so, how do I do that with my pnuts feature?
- How do I contribute this plugin back to the EclipseShell project?

Best regards,

Hallvard Tr=E6tteberg

[EclipseShell-developer] Re: [Jruby-user] EclipseShell: Initial release

[Werner S. (murphee) <wer...@gm...>]

Lukasz Skowronski wrote:

>>
>> I thought of ... maybe only setting the System.out to a 
>> ExecutionEnvironments OutputStream before an execution,
>> and then setting it back to the previous one. Of course, if another 
>> ExecutionEnvironments does the same thing during this execution,
>> then all this will be a bit messed up. I'll have to think about this 
>> some more, and maybe some central manager can take this over.
>>
> Well, I tried to hack this issue a little.
> I played around with custom class loaders in order to load many 
> instances of the java.lang.System class.
> Unfortunatelly custom class loaders cannot define classes which belong 
> to java package (it's reserved to bootstrap classloader) so I came to 
> conclusion I cannot have many java.lang.System classes in a JVM.

Yup, that's an old issue that's been plaguing some systems that want to 
run several applications inside one JVM;
so, writing a Java Shell that allows you to start several Java programs 
in the same JVM.


> So the situation is clear: there can be only one System and only one 
> System.out. In my opinion the only way is to replace this global 
> (accessible from everywhere) PrintStream with a fake PrintStream which 
> in fact is kind of a manager delegating calls to "real" PrintStreams. 
> I think you meant something similar when writing about a central manager.


Yeah, ... actually, that's an even better idea. Ie. a StdOutManager  
class derived from PrintStream... EclipseShell sets System.out to this 
printstream object;
Then, whenever an ExecutionEnvironment in EclipseShell starts executing 
some code, it tells the StdOutManager: "Hey, I'm EE42, please redirect all
future System.out.println... to this OutputStream", followed by a "OK, 
done, stop redirecting" which would cause the StdOutManager to redirect the
System.out.println... to the OutputStream it was using before.

> Attached you will find a working example - it wasn't trivial so I hope 
> you'll enjoy it :)


Wow, pretty cool... hm... I'm not sure I understand one thing though: 
Your Threads' run methods call

System.setOut(new DispatchingPrintStream(myOut));
3 consecutive times (because you instantiate 3 threads)... so, basically the first two instances are lost (because they aren't referenced). 
The reason why this works is that you keep the OutputStreams that keep the Thread's Integer Prefix are stored in a ThreadLocal field, and
the currently set DispatchingPrintStream(myOut) just gets this for the current thread and delegates to it. Am I right about that?

If I understand this correctly, I have to say, that it's a quite ingenious solution (I wouldn't have thought of it myself).
There's only one problem: the ExecutionEnvironments arent' restricted to one Thread per ExecutionEnvironment, ie. whenever I execute
a statement, a new Eclipse Job which will execute it (the Eclipse Job system is basically a Worker thread system, that uses a thread
pool); so potentially, every code executio will happen in a different thread.
Even if I could fix that, then it's still possible that the code executed in the ExecutionEnvironment will create several threads, 
and their output should go to the same Output Stream. Hmm... although... come to think of it: this should be solved by the fact that you
used *Inheritable*ThreadLocal... so all child threads should have the same OutputStream... 
Other problem: code from an ExecutionEnvironment that gets executed on a different Thread; best example would be code that's called
from the UI thread; that's necessary for all GUI modifications in SWT (and Swing), ie. as soon as you change anything in an SWT component, 
you need to do it on the GUI EventDispatchingThread (using Display.syncExec(Runnable)).

Hmm... lots of food for thought... Thanks for that! 


murphee

[EclipseShell-developer] How to access stdout?

[<har...@op...>]

Hello,
How can I access the standard output of interpreters? I'd like to see it in 
the console but e.g. System.out.println("Hello"); [BeanShell] does not show 
anything in Eclipse's console.

Regards
Lukasz 

[EclipseShell-developer] SF Test

[Werner S. <wer...@xi...>]

sss

[EclipseShell-developer] Welcome...

[Werner S. (murphee) <wer...@gm...>]

... to the eclipse-shell-developer ML.

Feel free to ask any kind of question here (as long as it's related to 
EclipseShell in some way...).

murphee
-- 
Blog @ http://jroller.com/page/murphee
Maintainer of http://eclipse-shell.sourceforge.net/