Variables question, and RFC on the scripting language.

[dryline]

Has anyone else noticed any problems with reusing the STOR variables in single scripts that produce multiple images? Seems like the first derived product works fine, but any subsequent attempts to use reuse the (very very limited) STOR variables results in no chart produced except the first one, even though they seem to display to screen.

There are two separate issues here I think. The first is that the STOR variables are limited, and confusing. I would prefer a true variable namespace, so that we can give meaningful names to variables at will.

The second issue is regarding the handling of the variables... can they be initialised with some command? Does ERASE re-initialise the variables? Does each script have it's own variables, or are they global if we declare them somewhere?

I realise that Tim is a very busy dude, and that documentation is incomplete, etc, etc.. but some strategic decisions must have been made when the development of the scripting language started, and it would be nice to know what they were... for example, what can we expect in terms of extended commands for energy calculations, will there be an API for user extensions like DAV support (or preferably SSH support) for uploading to intranet servers, etc. I for one would love to develop plugins to an API, if there is one planned.

A bit more information about forthcoming shininess would make beating my head against current limitations infinitely more entertaining...

What do you guys think? I know some of you lurkers out there know what I'm talking about.. what do you think of the scripting language as it stands, and what have you learned you really need in there to make it sing? My contribution is as follows:

1) A SOURCE or CALL command to allow script nesting.
2) A normal variable namespace, for clarity and complexity.
3) Internal parameters for complex calcs like energy & helicity
4) A scripting API allowing new commands from compiled C runtimes.
5) SSH integration for uploading files.
6) Conditional structures (IF THEN ELSE, at most basic)

Rather than just post another list of wants to the suggestions thread, I hoped that the script geeks who check this forum before the main one might determine between ourselves what we might *prefer* in terms of priorities to make the scripting language even more usable, and maybe give Tim some reference as to where it might be extended.

Throw out your ideas, people.. I'd like to know where others stand on the most-needed areas.

Cheers,
--dryline

[Fred]

Up to now I did not have problems with the STOR. Can you post a small example where it goes wrong? I am interested, because then I can avoid problems.

Of course my wish is to have named variables. I initialize them with the normal commands. Below the beginning of a TT-script.
ERASE
STOR=1 DWPT H850
STOR=2 TEMP H500
STOR=3 SDIF=1:2
STOR=4 TEMP H850
STOR=5 TEMP H500
STOR=6 SDIF=4:5
ANALYZE,SSUM=3:6
ANALYZE,OVER FILL COLOR=224:255:224 FILS=0 LSTN=44
etc.

I never tested the ERASE on the variables. According to the manual just the overlays, but as it's not clear how variables are treated I am not sure.
In my opinion (for what it's worth) variables are local.

My personal preferences in my preferred order:
1) A SOURCE or CALL command to allow script nesting.
2) Conditional structures (IF THEN ELSE, at most basic)
3) A normal variable namespace, for clarity and complexity.
4) Internal parameters for complex calcs like energy & helicity
5)A clear and extended description how scripting internally works like:
- what values are shown on the screen
- a more extended description of the commands (e.g. GRTN is in fact >=)
- etc.

The other two of your list are not directly on my list but perhaps in the future...

Greetings

Fred

[dryline]

Well, Fred, it looks like it's just you and me... surely someone else has an opinion on the scripting structures...

*surprised*

[Fred]

Yes, very disappointing. Perhaps we could have an off-list discussion together with Tim to define our wishes.

Greetings

Fred

[Tim Vasquez]

Not sure if this helps, but what STOR does is write the current analysis gridset (U,V,Z fields) to GRID.xxU, GRID.xxV, and GRIDxx.Z, where xx is the number specified.

Part of the reason I haven't developed the scripting further is the complexity of the program. I just looked and it's at 80,640 lines of code... that's as big as BSD Unix was several years ago. Doing something elegant with the scripting would be nice, but but it completes with dozens of other requests (bug fixes always being important).

Tim