Re: tkemc at a socket

[Will Shackleford <shackle-at-cme.nist.gov>]

Till Franitza wrote:

> Hallo Will!
> I wrote to EMClist lately and, as usual, got a very detailed and
> comprehesive answer from Frd Proctor. The only thing he could not answer
> was :
> Whatis the format of the information that can be accessed from the
> tcp/ip-socket by for example Tcl/tk or (i suppose, this is
> similar),java?
> I expected this to be the easiest way to attach a user-interface to EMC.
> 
> What do you think? Is is too demanding an uneffective to handle all the
> traffic in tcl/tk or Java??

Although I am not much of a tcl programmer, I expect it would be 
extremely difficult and it is not clear to me what advantage that method 
has over the current method. The format of the data depends on the 
configuration file options and on the data structures in emc.hh.

The some of the data structures are extremely complicated with both many 
  levels of inheritance and many levels of structures within structures. 
The EMC_STAT class with the status information is particularly complicated.

Depending on how well tcl handles binary data and your level of 
experience with tcl and sockets I expect it is a moderately difficult 
task to write tcl code that reads the configuration file, connects to 
the socket, sends the appropriate initialization sequence and request to 
receive the status buffer and strip off some  header info. (Although I 
would probably need to write up a bunch of stuff here.) But at this 
point you would only have a large array of bytes. For that array to be 
of any use you need to be able to convert it to individual tcl variables.

For example if EMC_STAT were.

struct EMC_STAT
{
int a;
int b;
int c;
}

I would know c would be stored in bytes 8 through 11 if NML were 
configured to use xdr or after the second comma if we were using the 
"disp" option. If someone adds or subtracts a variable and we don't 
modify the tcl code before c the value of some other variable will get 
stored in c and probably cause some very bizarre behavior.

For this reason before building the Java GUI, I wrote CodeGen.
CodeGen reads the C++ header file emc.hh and generates corresponding 
java code that pulls each variable from the correct location. If there 
is a change to emc.hh the makefile runs CodeGen again to make sure the 
java code is always synchronized with the C++ code. It took me about a 
month or two to write CodeGen for Java. I suppose one could be written 
for tcl or the existing CodeGen somehow modified to produce tcl instead 
of java.


--Will




	






-- 
---------------------------------------------------------------
William Penn Shackleford III			shackle-at-nist.gov
National Institute of Standards & Technology	Tel:	(301) 975-4286
100 Bureau Drive Stop 8230  			FAX:	(301) 990-9688
Gaithersburg MD  20899  USA
http://www.isd.mel.nist.gov/personnel/shackleford/
Office Location: Bldg. 220 Rm A253