Charva Beanshell

How I loaded new code onto jnode, edited it, and ran it without rebooting jnode (requires network):

----------->Setup
network boot
prepare a file under the network boot dir, something like hello.txt:

for (int i=0;i!=2;i++)
print("Hello jnode\n");

----------->After Jnode Boots:
dhcp eth0
charvabsh

Tab to the file menu, then select:
File->Load:

Specify the file URL you want, for me it is:
tftp://192.168.2.100/srr/hello.txt

clean up any trash created in the transfer. For example '\n' as encoded in notepad shows up with the wrong ascii value.
(Tab to enter the text area).

Press F2 in the editor area to execute the source code (under beanshell).

Be patient while beanshell throws an initialization exception (and you maybe get a GC).

Press F2 again to execute the source code (for real this time.)

_____
Why am I doing this?
I can now write code on my server machine, and run it immediately under jnode, without restarting jnode. I use beanshell to get around the requirement for files and compiling, and tftp protocol so that my source remains persistent on the server machine.

Saving is not yet written, until I figure out TFTP a little better.

Also, Class.getClassLoader() is being used instead of Class.getContextClassLoader(), (this is internal to beanshell), so only classes explicitly pointed to in charvabsh's plugin list can currently be accessed. For example, org.jnode.driver.sound.command.BeepCommand.main(...) gives a noclassdef error, but Thread.currentThread().getContextClassLoader().loadClass("...BeepCommand") from within the beanshell interaction window is fine.

There is support in beanshell for automating this, but jnode does not yet use it... I think it would be pretty useful to get stack traces or program execution data back to a server machine, for purposes of discussion or analysis...

I'm glad to see you working on it. From the very first day we started to port charva to JNode I regarded it as the shortest path to the point where we have some kind of text editor in JNode. Now that the writable ext2 filesystem is becomming a reality this makes more sense then ever.

There are a number of problems with charva at the moment.
- bug in text area: after a sertain amount of text it freeses, and it as quite bad performance compared to other charva components.
- the text cursor some leaves trash behind. You cn see thi sanomly in the comandline to, when the coursos gets double, but also in textarea and table.
- initially charva used the same type of console as the commnd shell. Later a RawTextConsole was implemented with mouse support and charva moved to it. This is where we are with the development. This cosole is volatile, in the sense that if you exit change screen you cannot get back. Instead you will find the original command shell where the charva app was started up. Wehn you exit charva you can get back to the orginal shell in this way. (You might need to press control-C to give the controll back to the console)
- mouse support in charva is missing (the console gives soem suport to it but charva does not respond to the mouse)
- it might make sense to investigte the way charva draws itself on the screen it might be possible to optimize it.

If you are feeling like wanting to work on charva go ahead! The spirit of charva says: keep the source level compatibility with Swing so that when you change the package names to javax.swing you get a valid program and vice versa. Since charva is already forked (at some degree) by the JNode version I think we can feel free to tailor it to our needs and improve it wherever it is necessary. However the rule above might be worthy to be respected.

Levente

Item 6 can probably be solved by using the correct classloader. That is Thread.currentThread().getContextClassLoader().