opengrads-devel

Re: [Opengrads-devel] tclgrads

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

On Wed, Aug 27, 2008 at 10:08 AM, Daniel da Silva <dda...@um...> wrote:
>>
>> I wrote Nbsp (a noaaport software) and I use GrADS and separately
>> tcl for the scripts. I recently started to do a tcl interface to
>> GrADS (tclgrads) and a couple of days ago I saw your site. I wonder
>> if there is any other similar project to do a tcl interface to grads,
>> otherwise I can finish mine and make it available.

Right now we have released the Perl and Python interfaces, and Luiz
Rodrigo has contributed a PHP interface that is still in development.
I have had a query at some point about a TCL interface but we are not
working on one. So, your effort would be much appreciated.

You may want to know that way back someone wrote a TCL/TK graphical
user interface for GrADS that you can find here:

           ftp://grads.iges.org/grads/sprite/XGrads/xgrads.win32.tar

If I am not mistaken, this uses the "expect" package to interact with
the GrADS command line. It has not been maintained in a while, so I am
not sure whether it works with current GrADS releases. One recent
development that was not available then -- and it is now --- is the
ability to capture error conditions from GrADS (the command line
option -u); this is very important for you to perform error handling.

Now for the Perl and Python interfaces I've been trying to keep the
"API" sort of consistent among all the interfaces. It would be nice if
you could keep some level consistency between the TCL and the Perl and
Python interfaces. You can find more information about the Perl/Python
interfaces here:

     http://opengrads.org/wiki/index.php?title=Python_Interface_to_GrADS
     http://opengrads.org/wiki/index.php?title=Perl_Interface_to_GrADS

Luiz Rodrigo, who subscribes to this list, may be able to update you
on where he is with the PHP interface. The last prototype he sent me
was already very functional, we just need to complete the
documentation and release it on sf.net.

So, if you already have an sketch of an interface that you would like
us to look over please send it to this list and we will be glad to
send you feedback. As for distributing through OpenGrADS I need to ask
you a couple of questions:

1) Are you willing to release your tcl interface under an opensource
license? GPL is preferred, but any license acceptable to SourceForge
(our host) is fine too.

2) Are you willing to maintain a simple wiki page at opengrads.org
with information about installation and usage of your interface?

3) Would you be able to support the package by answering to bug
reports on our tracker? We understand that people need to work around
their own schedule, so you do not need to fix things immediately, but
if the package is to be listed as "actively maintained" you need to so
periodically, at least a couple of times a year.

 I look forward to working with you.

 Best Regards,

        Arlindo

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

Re: [Opengrads-devel] tclgrads

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

Jose,

  Thanks. I'll take a look at your code and get back to you. Do you
have a sourceforge account? I'd need your userid to give you check in
privileges to our repository.

     Arlindo


On Sat, Sep 6, 2008 at 6:48 PM, Jose F. Nieves <ni...@lt...> wrote:
> Arlindo
>
> Thanks for your message.
>
>> Right now we have released the Perl and Python interfaces, and Luiz
>> Rodrigo has contributed a PHP interface that is still in development.
>> I have had a query at some point about a TCL interface but we are not
>> working on one. So, your effort would be much appreciated.
>>
>> You may want to know that way back someone wrote a TCL/TK graphical
>> user interface for GrADS that you can find here:
>>
>>            ftp://grads.iges.org/grads/sprite/XGrads/xgrads.win32.tar
>>
>> If I am not mistaken, this uses the "expect" package to interact with
>> the GrADS command line. It has not been maintained in a while, so I am
>> not sure whether it works with current GrADS releases. One recent
>> development that was not available then -- and it is now --- is the
>> ability to capture error conditions from GrADS (the command line
>> option -u); this is very important for you to perform error handling.
>
> I discovered by accident the xml-style of output and it is used by
> the preliminary interfacet that I am using.
>
>>
>> Now for the Perl and Python interfaces I've been trying to keep the
>> "API" sort of consistent among all the interfaces. It would be nice if
>> you could keep some level consistency between the TCL and the Perl and
>> Python interfaces. You can find more information about the Perl/Python
>> interfaces here:
>>
>>      http://opengrads.org/wiki/index.php?title=Python_Interface_to_GrADS
>>      http://opengrads.org/wiki/index.php?title=Perl_Interface_to_GrADS
>>
>> Luiz Rodrigo, who subscribes to this list, may be able to update you
>> on where he is with the PHP interface. The last prototype he sent me
>> was already very functional, we just need to complete the
>> documentation and release it on sf.net.
>
> I checked the perl interface which I understand better then python
> and I believe the eseential ideas are similar, of course the details
> differ since the languages are so different. Anyway I can
> incorporate suggestions as soon as I get some feedback.
>
>> So, if you already have an sketch of an interface that you would like
>> us to look over please send it to this list and we will be glad to
>> send you feedback. As for distributing through OpenGrADS I need to ask
>> you a couple of questions:
>>
>> 1) Are you willing to release your tcl interface under an opensource
>> license? GPL is preferred, but any license acceptable to SourceForge
>> (our host) is fine too.
>
> I use the BSD license, which I suppose is fine.
>
>>
>> 2) Are you willing to maintain a simple wiki page at opengrads.org
>> with information about installation and usage of your interface?
>
>
> I think I can do it.
>
>>
>> 3) Would you be able to support the package by answering to bug
>> reports on our tracker? We understand that people need to work around
>> their own schedule, so you do not need to fix things immediately, but
>> if the package is to be listed as "actively maintained" you need to so
>> periodically, at least a couple of times a year.
>>
>
> I update the software that I write as soon as I find a fix for
> an error report. So this should not be a problem either.
>
>>  I look forward to working with you.
>>
>>  Best Regards,
>>
>>         Arlindo
>
>
> I am sending a snapshot of the current package. To run the tests
> you probably have to change the #! line at the top of the scripts.
> This is still preliminary and not intended for general distribution,
> but feel free to distribute it to people you work with. What I would
> like to do is to have a simple basic package (not too different in scope
> from the current one) and build gradually a higher level library on top
> of it.
>
> Regards
>
> Jose F Nieves
>
>



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

Re: [Opengrads-devel] tclgrads

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

Jose,
  I took at your implementation. Your README file appears to describe the
API, so I'll comment on this, although I'll disclose that I know very little
about TCL.

grads::init [-options <grads_options>] [-prompt <grads_prompt>] \
[-undef <symbol>]
Defaults: -options "-l -b" -prompt "ga->" -undef "?"

Must be called first.


Why do you need to specify a prompt? The -u option writes out markers so
that you can determine when commands start and end, without the need to rely
on the propmpt for that.


proc grads::end {}

Must be called last.

proc grads::open {ctlfile}

Must be called after grads::init and before any of other functions.


The Open method that gerl/pygrads implement take a file name an optional
file type, and can do a open, sdfopen or xdfopen depending on the extension.
Usually nthe file type can be guessed from the file name.


proc grads::exec {args}

Sends a command to GrADS for execution. The resulting output from
GrADS is saved in an internal variable, and it can retrieved by
the following three functions:

grads::value
grads::output
grads::output_list
grads::output_line
grads::output_word


A couple of comments; this method is called "cmd" in gerl/python. These
interfaces define 2 functions rline(i) and rword(i,j) to get to the output.
 I'd suggest have functions of the same name (you can keep the others), and
taking the same arguments (yours already do), and these arguments having the
same range: lines and words start at "1", not zero. This is important to
allow translating functions from gerl/python into tcl. (It is much easier f
you do not have to change offsets of indices.)

proc grads::value {}

Returns the result value from the last command excuted by GrADS
(e.g., d tmpprs). If the last command did not correspond to
a variable evaluation, the return value is the "undef" parameter
("?" by default).

proc grads::output {}

Returns the entire output result of GrADS after a call to grads::exec
as a single text string.

proc grads::output_list {}

Returns the output result of GrADS after a call to grads::exec,
with the text split in lines as a tcl list.

proc grads::output_line {lineindex}

Returns the line indexed by $lineindex from the output list.

proc grads::output_word {lineindex wordindex}

Returns the word indxed by $wordindex from the line indexed by
$lineindex.


See above.

proc grads::evalvar {varname}

Returns the result of evaluation of a variable by GrADS.


Do you mean an array? How are you exchanging data with grads? Are you using
bi-directional pipes, named pipes (FIFOs)  or  disk transfer files?
Gerl/pygrads uses bi-directional pipes; up to recently I exclusively used
the IPC extension for data exchange through strdin/stdout, but in pygrads
1.1.0 I start using 'fwrite' to stdout (set fwrite -) with grads v2.0.a3;
named pipes did not work in versions prior to 2.0.a3, bit work now.

proc grads::get_sizes {array_name}

Fills the array (passed in the argument by name) with the various
sizes of the data file:

number of longitude points (nx)
number of latitude points  (ny)
number of levels (nz)
number of times (nt)
lon1, lon2, lat1, lat2



In gerl/pygrads I implement a generic query() functions that captures the
result of the grads query command. Your function is similar to
query("dims").

proc grads::get_levels {level_list}

Returns a (tcl) list of the levels in the file (the argument must
be passed by name).

proc grads::get_times {times_list}

Returns a (tcl) list of the forecast times in the file (the argument
must be passed by name).


See the coords() method in pygrads (gacore.py), not yet implemented in perl.
This function returns the value of all ccordinates.  How to do you currently
retrieve the non-uniform latitudes of a gaussian grid?

I checked in your code to contrib/interfaces/tcl; I added a few standard
files (such as ChangeLog), but these are blank.

       Arlindo



Define 'gacvs' as an alias to

cvs -z3 -d:ext:da...@op...:/cvsroot/opengrads

then, check out the code as:

% gacvs co -P contrib
% cd contrib/interfaces/tcl








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