opengrads-devel

Re: [Opengrads-devel] code for GradsVM

[Arlindo da S. <da...@al...>]

Hi Pedro,

  Sorry for the very long time, but I finally am able to get back to
GrADSVM. I have now integrated the java code under the opengrads codebase,
and updated the grads.class (built through nestedvm) to the latest grads
2.0.a7.

 I tried your your client/server code and it works as advertised. Very nice
work, indeed. I have made some small alterations:

1) I preserved the previous monolithic JGrads.class. Therefore, I renamed
the client class GVMclient.

2) I fixed a small bug in gxJ.java related to color definition.

3) I moved all non-nestedvm code to a separate Java/ directory.

4) Added targets to the Makefile to create grads.jar; renamed Makefile ->
GNUmakefile to make it clear that GNU make is required.

Here are the remaining issues:

a) Would it be possible to add an option to "conn" to pass to the server,
e.g.,

  ga-> conn -l

If omitted, the client could ask the user if portrait is desired.

b) We need to capture the server's stdout and ship it back to the client. As
we talked before, we could hijack gaprnt() and buffer the output on the java
side and ship it back to the client upon finishing a command. Or else, one
might be able to intercept stdout. Which one do you think is easier to do.
(I can have gaprnt() calling a java function much like the gxJ functions.)

c) The command printim now creates an image file on the server side. We need
to find a way to ship this file back to the client. Can this be done
byte-by-byte through the sockets?  Another possibility would be to implement
printim entirely in java as a screendump of the graphical canvas. (Are there
built in methods for this?)

d) Right now GrADSVM is a console application. Last year I was experimenting
with a Console class, but it lacked jline support. Having a built in console
one might be able to deploy the client through WebStart. Do you agree?

BTW, you can find the revised jar (including sources) here:

       http://opengrads.org/devel/java/

or you can get the full sources from cvs:

  % gacvs co -P grads

See the Java/ directory. To build the nestedvm code you need a Mac, or else
you need to build the nestedvm toolchain yourself for other platorms. The
nestedvm compiled supplibs should be portable.

GVMclient/server can be run from the jar, e.g.,

% java -cp ./grads.jar GVMserver
% java -cp ./grads.jar GVMclient

  I think we are very close to have something for an early release to the
community. What do you think?

  Cheers!

    Arlindo


On Mon, Mar 2, 2009 at 2:47 AM, pedro tsai <ped...@ya...> wrote:

> hi Arlindo,
>
> Attached is GradsVM client/server code.  Un-tar the files into your working
> directory where the other NestVM generated code/data are located.  So far,
> I have not yet touch NestVM generated files, I just add new code in the
> same top-level directory where original NestVM files are.
>
> 1.  To compile the code, type 'make'.  To list all the new files, type
> 'make info'.
>
> 2.  To run,  you need 2 windows (one for client process, one for
> GradsVM process)
>
>     on the client window,  type 'make run'
>
>     on the server window,  type 'make svc'
>
>     once the system running,  the first command to type on client's side
>     readline input is
>
>         'conn'   /* by default, it will use IP 127.0.0.1, and port 6789
>         and 6790.  If these ports are used on your system, you can change
>         them (in SockIPC.java) and then re-compile.  I use 2 ports, one for
>
>         'gacmd' communication and one for 'graphics primitives'
> communication.
>
>     If you want to run GradsVM on remote host, type
>
>     'conn  ip-addr'
>
>     Once the connection is establish, you should see output on the
>     'server side' window.  You need to hit a 'Return' on the server
>     side window, otherwish the gradsVM thread is blocking after the
>     initial Grads information display ('Landscape mode ('n' ...)
>
>     Now you can enter 'grads' command, then they should be executed
>     by GradsVM.
>
>     To exit the client, type 'quit', this will disconnect and kill
>     the client process.  You can start a new client process again
>     to connect to GradVM server.  I did not have 'disconnect' command
>     implement, but it is not hard to do.
>
> 3.  The naming convention for the files is:  the server side code starts
> with
> 'GVM...'.  The client side code starts with 'JG...'.  Files that do not
> have either prefixs are utility code or are used by both (like
> SockIPC.java)
>
> 4.  You can have more than 1 client connect to the server, each client
> will get its own GradsVM, but right now there is bug, so I think it will
> dead-lock the gradsVM.
>
> 5.  There are other issues, for example, the command line argument on
> the client side is not pass to the GradsVM,  this is easy to fix.   And
> also,
> the information test from GradsVM is not sent back to client. (e.g, q file,
> q dim....).
>
> If you can not run the prototype, let me know.
> I think there is still a lots of work to refine this......
>
> Pedro
>
>
>



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] code for GradsVM

[Arlindo da S. <da...@al...>]

On Mon, Nov 16, 2009 at 3:39 AM, pedro tsai <ped...@ya...> wrote:

> hi Arlindo,
>
> It is good hear from you.  It is no problem, I really want to get this
> thing running properly and get some feedbacks.
>
> (a).  Yes, we can add the '-l'  option.
>
> (b).  Ideally, we want output of server command that is relevant to the
> user to go back to the client window, and we also need to print out any
> error message on the server console side for debugging purpose. I think
> hijack gaprnt() will provide finer control on what information to send to
> client and what to print out to terminal on the server side.  Where as
> re-direct stdout would lacks this finer control.  I don't know which way is
> easier, but I think gaprnt() solution might be more viable in the long run.
>
>
I'll add the hooks for gaprnt(). The "C code" will call a gaprnt() function
on the java side; I'll let you handle the message passing from that point
on. OK?


> (c)  I need to investigate the Java client side capture of graphics display
> to see how it is done. But we can also send printim output file to the
> client via socket connection (this is not hard to do), and then user can use
> what ever mechanism available on the device to print the image file.  For
> now, perhaps it is easier to send the printim file to client, and later we
> can consider client side graphics capture.
>
>
Sending the file to client is more than adequate.


> (d)  If client is running inside a browser, then we do need some kind of
> Console class
> that can embedded inside a browser.   I think this would be a nice
> feature.  Would like to do some search on google to see if may be some one
> has already implement such class with Jline support (or other similar
> command completion).
>
> I will update with your modification, and we go from there.
>
>
Thank you for the quick response.

   Arlindo


talk to you later,
>
> Pedro
>
> --- On *Sun, 11/15/09, Arlindo da Silva <da...@al...>* wrote:
>
>
> From: Arlindo da Silva <da...@al...>
> Subject: Re: code for GradsVM
> To: "pedro tsai" <ped...@ya...>
> Cc: ope...@li...
> Date: Sunday, November 15, 2009, 4:49 PM
>
>
> Hi Pedro,
>
>   Sorry for the very long time, but I finally am able to get back to
> GrADSVM. I have now integrated the java code under the opengrads codebase,
> and updated the grads.class (built through nestedvm) to the latest grads
> 2.0.a7.
>
>  I tried your your client/server code and it works as advertised. Very nice
> work, indeed. I have made some small alterations:
>
> 1) I preserved the previous monolithic JGrads.class. Therefore, I renamed
> the client class GVMclient.
>
> 2) I fixed a small bug in gxJ.java related to color definition.
>
> 3) I moved all non-nestedvm code to a separate Java/ directory.
>
> 4) Added targets to the Makefile to create grads.jar; renamed Makefile ->
> GNUmakefile to make it clear that GNU make is required.
>
> Here are the remaining issues:
>
> a) Would it be possible to add an option to "conn" to pass to the server,
> e.g.,
>
>   ga-> conn -l
>
> If omitted, the client could ask the user if portrait is desired.
>
> b) We need to capture the server's stdout and ship it back to the client.
> As we talked before, we could hijack gaprnt() and buffer the output on the
> java side and ship it back to the client upon finishing a command. Or else,
> one might be able to intercept stdout. Which one do you think is easier to
> do. (I can have gaprnt() calling a java function much like the gxJ
> functions.)
>
> c) The command printim now creates an image file on the server side. We
> need to find a way to ship this file back to the client. Can this be done
> byte-by-byte through the sockets?  Another possibility would be to implement
> printim entirely in java as a screendump of the graphical canvas. (Are there
> built in methods for this?)
>
> d) Right now GrADSVM is a console application. Last year I was
> experimenting with a Console class, but it lacked jline support. Having a
> built in console one might be able to deploy the client through WebStart. Do
> you agree?
>
> BTW, you can find the revised jar (including sources) here:
>
>        http://opengrads.org/devel/java/
>
> or you can get the full sources from cvs:
>
>   % gacvs co -P grads
>
> See the Java/ directory. To build the nestedvm code you need a Mac, or else
> you need to build the nestedvm toolchain yourself for other platorms. The
> nestedvm compiled supplibs should be portable.
>
> GVMclient/server can be run from the jar, e.g.,
>
> % java -cp ./grads.jar GVMserver
> % java -cp ./grads.jar GVMclient
>
>   I think we are very close to have something for an early release to the
> community. What do you think?
>
>   Cheers!
>
>     Arlindo
>
>
> On Mon, Mar 2, 2009 at 2:47 AM, pedro tsai <ped...@ya...<http://mc/compose?to=ped...@ya...>
> > wrote:
>
>> hi Arlindo,
>>
>> Attached is GradsVM client/server code.  Un-tar the files into your
>> working
>> directory where the other NestVM generated code/data are located.  So far,
>>
>> I have not yet touch NestVM generated files, I just add new code in the
>> same top-level directory where original NestVM files are.
>>
>> 1.  To compile the code, type 'make'.  To list all the new files, type
>> 'make info'.
>>
>> 2.  To run,  you need 2 windows (one for client process, one for
>> GradsVM process)
>>
>>     on the client window,  type 'make run'
>>
>>     on the server window,  type 'make svc'
>>
>>     once the system running,  the first command to type on client's side
>>     readline input is
>>
>>         'conn'   /* by default, it will use IP 127.0.0.1, and port 6789
>>         and 6790.  If these ports are used on your system, you can change
>>         them (in SockIPC.java) and then re-compile.  I use 2 ports, one
>> for
>>         'gacmd' communication and one for 'graphics primitives'
>> communication.
>>
>>     If you want to run GradsVM on remote host, type
>>
>>     'conn  ip-addr'
>>
>>     Once the connection is establish, you should see output on the
>>     'server side' window.  You need to hit a 'Return' on the server
>>     side window, otherwish the gradsVM thread is blocking after the
>>     initial Grads information display ('Landscape mode ('n' ...)
>>
>>     Now you can enter 'grads' command, then they should be executed
>>     by GradsVM.
>>
>>     To exit the client, type 'quit', this will disconnect and kill
>>     the client process.  You can start a new client process again
>>     to connect to GradVM server.  I did not have 'disconnect' command
>>     implement, but it is not hard to do.
>>
>> 3.  The naming convention for the files is:  the server side code starts
>> with
>> 'GVM...'.  The client side code starts with 'JG...'.  Files that do not
>> have either prefixs are utility code or are used by both (like
>> SockIPC.java)
>>
>> 4.  You can have more than 1 client connect to the server, each client
>> will get its own GradsVM, but right now there is bug, so I think it will
>> dead-lock the gradsVM.
>>
>> 5.  There are other issues, for example, the command line argument on
>> the client side is not pass to the GradsVM,  this is easy to fix.   And
>> also,
>> the information test from GradsVM is not sent back to client. (e.g, q
>> file, q dim....).
>>
>> If you can not run the prototype, let me know.
>> I think there is still a lots of work to refine this......
>>
>> Pedro
>>
>>
>>
>
>
>
> --
> Arlindo da Silva
> da...@al... <http://mc/compose?to=da...@al...>
>
>
>


-- 
Arlindo da Silva
da...@al...