More complex variables in GVMS?

[Ron]

Hi Mark,

Thanks for thinking along with me. I'm already planning a major upgrade for the GVMS. But you'll have to understand that writing a compiler/interpreter is a pretty major task not to be taken lightly. I've been reading up on stuff in my free time ( which is at a premium at the moment :( ).

I'm also considering moving to an 'official' language that I can just plug into girder, licenses permitting. If anyone knows of anything i'm all ears.

[Ron]

Yeah I know TCL, though I never was a fan of it. Before I can write a compiler I'll need to learn a lot about writing these things. For the next month or so I'm too busy with college anyway :(

[Ron]

Ah but the current implementation is using Bison and Flex. Moving beyond the point where it is now requires me to delve quite far into compiler/parser construction. As you might know I'm a physics major not computer sciences :-)

For example the GVMS needs to setup execution trees. These trees have to be very flexible to be able to handle functions, operators, variables and values. I've been trying to find some good reading about this on the net but that has giving me nothing but bare bone basics. So the next step is the library, but I do not have the time to do this now. We could also make this a little project, since the GVMS is a plugin I could publish the specs to selected people and get some cooperation going. Just a thought.

[Ron]

I've been looking into Tcl and it looks like implementing Tcl is a breeze ( well, relatively,... ) and the copyright allows it. ( though I'm not 100% sure )

pros

Standard language
Tested and working
No further development needed


cons

What do we do with the GVMS ?
Size ?
I don't learn how to write a compiler :-)


Anyone have any suggestions on what I should do with the GVMS. How many people are actually using GVMS, would they mind updating their scripts etc... ?

Also found this scripting language : http://www.lua.org
claims to be better suited for being 'slapped' onto an existing program.

[Ron]

My plans for girder


New UI (not just yet, but its planned)
Same basic idea with the tree structure
Powerfull scripting language


The script should be able to


Use all kinds of variables ( normal, array and whatnot )
The usual for, if while stuff
Ability to trigger commands from the tree
Ability to enable/disable commands in the tree


I do not want to take out the tree with commands I think this is understanable by the layman, moving to a scipt all together will be just too difficult for most users (especially now that we are getting 'normal' computer users and not only geeks ;-) ). Not to mention completely incompatible.

I can replace/change the GVMS easily since I did not release the interface. :-) The new script and the GVWS will probably work side by side.

[Ron]

This currently isn't in the GVMS, and because the GVMS doesn't allow for conditional structures in the script its not usefull NOW.

But the new script will have this functionallity as listed above. Thanks for the suggestion though.

[Ron]

I'm really warming up to Lua

http://www.bagley.org/~doug/shootout/craps.shtml

doing some basic testing when time permits.

[Ron]

Very interesting, however I've come to the conclusion that I should not reinvent the wheel with this script. there are quite a few 'good' scripting languages out there. I just need to find the right one. I was hoping someone here had some experience with ElasticC (http://www.elasticworld.org/) the grammar of this language is my favourite ( c like, so easy converting from gvms to this ) but his version number 0.0.35 is a little low, though he has been working on it since 2000....

[Ron]

;-) I have considered Perl, TCL, Pyhton ( all just to big ) Lua ( have a working implementation of this in Girder ) and ElasticC. Is there anything else out ther e?

[Ron]

Hmmm, and the thing that happens next is gml files will be infected by some virus.... I'll stick with techonologies that I can control. ( Okay, so I'm anti-MS-Biased ) Not to mention stuff won't work under win95.

[Ron]

I know com will work under 95, but scripting won't. They'll probably need to download huge files.... if they are available.. since 95 is no longer supported.

I'll release the specs to the scripting interface at some point. Maybe some smart guy can actually make something for it.

[Mark F]

I know you are real busy but I'd like to request some new function in the GVMS. In particular, ARRAYs (int, double, string) and STRUCTUREs.

I'd like to suggest we be able to use fixed sized arrays; but, I think they need to be re-sizeable and declareable based on an immediate value (ie 1, 3, etc.) or an integer variable. We also need to index them via immediate values or integer variables and be able to determine the array size after declaring or re-sizing it.

One approach to determining the array size would be to always have the element 0 be an integer variable which contains the size value. IE for a 3 entry string array strA, strA.0 == 3 and strA.1 through strA.3 are the actual string elements.

Examples:


int size;
size = 4;
array string strA[3];
array string strB[size];

// strA.0 == 3;
// strA.1 == strA.2 == strA.3 == "";
// strB.0 == 4;
// strB.1 == strB.2 == strB.3 == strB.4 == "";

strA.1 = "Hello";
strA.2 = "World";
strA.3 = "!!!!!";

strA = resize(strA, 6);

// strA.0 == 6;
// strA.1 == "Hello";
// strA.2 == "World";
// strA.3 == "!!!!!";
// strA.4 == strA.5 == strA.6 == "";

size = 2;
strA = resize(strA, size);

// strA.0 == 2;
// strA.1 == "Hello";
// strA.2 == "World";


In my mind, structures are just an easy way to group data that goes together. I can live without them but they could make scripts more readable and maintainable. For example, imagine a structure variable called GIRDER_VALUES :) which contains a string array (pld), a string variable (IR String) and an int variable (Plugin ID) which gets filled in before each command is executed. Utilizing the array.0 == array size concept, the pld variables would be bounded and any GVMS could test for the size easily. I know this is not backward compatible but it is also JUST an example. :D

Of course, plugins need to be able to create/access/delete these new variable types, too.

Thanks for just making it to the end of this. ;)

[Mark F]

But you'll have to understand that writing a compiler/interpreter is a pretty major task not to be taken lightly. I've been reading up on stuff in my free time ( which is at a premium at the moment :( ).
Yeah Ron, I understand. :D

[Mark F]

For suggestions, check out Tcl (http://www.scriptics.com/scripting/primer.html).

[Mark F]

Some random thoughts and questions. :D

The first question I have is, "What are the goals of this upgrade?" Are you trying to add better variable support? Better logic (if/then/else, switch, while, for statements) support? Better command tree integration? (executing a command from a script) Is this just the first step? Or, in other words, how far do you want to go? Will the event routing portion of Girder become a script eventually? Will plugins be written in the scripting language?

Now to your questions: Why must you do anything with GVMS? Why couldn't the GVMS and TCL plugins co-exist? Why not do as you suggested earlier and publish the scripting engine interface and let anyone provide one or more?

Once again, Girder is at a cross-roads. :) Girder is either an event router or it is everything. Either the scripting engine is a plugin or it is tightly coupled. Right now the GVMS appears to NOT be a plugin since the interfaces for it permeate Girder to the plugin API AND Girder will not start without the GVMS.dll file. Unless you plan to change the API interfaces to the new script engine, I don't see how you can dump the GVMS.

[Mark F]

Butters -

Perhaps you could spend some time bulding a scriptable COM object that works as a proxy for Girder through the plugin interface? Then anyone who wishes to use Girder with a script engine could.

[levyshay]

Hi, I don't know if it's there cause I haven't started using the GVMS, but another nice option ( Please exuse me if it's already there ) would be to triger girder actions (Postmessage, Mouse, .... etc... ) via script, not only tree commands, It's probably not to complicated to implement and can help alot.

For example, people can write a script that would do some actions togheter and creating scripts that do simple job that is usually done only by a plugin. Some people know programming, but don't want to get into compiling a plugin, so this option can be usefull.

Shay Levy.

[Snakebite]

I hope I'm not insulting your level of knowledge now, but you do know about Lex and Yacc, right? Or the Bisonflex plugin for Visual C++. They make it so much easier to create new languages. But perhaps you're struggling with the semantic side of things, not the syntax and parsing.

[DocSavage]

I second TCL - it is quit easy to splice into a program as that is what it was desgiend to do...

For what is worth :D

[kcl]

If you're considering using compiler construction tools, I'd recommend looking at something more current than yacc, lex, bison, and the like. There's a very nice tool called ANTLR that you might want to consider. Its free, was originally invented a few years ago by Terence Parr for his Master's Thesis, and is actively supported by an extremely knowledgeable user's group. Some of its advantages include the automatic creation of parse trees, the ability to create a lexer, a parser, AND a tree processor using essentially the same grammar syntax, and an output target of Java and C++ (and some more now, I believe). I've used lex, yacc, bison and others like it for compiler construction for over twenty years, and IMO ANTLR is at another (better) level. Check out www.antlr.org for details and downloads. I've used ANTLR a number of times over the last few years, and its been a quick, versatile, and useful tool.

[kcl]

On the other hand, there's certainly a lot to be said about simplicity (KISS, you know :) ). Have you considered just adding the ability to interface with a powerful scripting language like Perl or Python? If you did it along the lines of a plugin that would call/process scripts, you'd probably only have to come up with a way to pass Girder variables to and from the called routines.

Edit: Oops. Cross-posted.

[Butters]

This is a windows program, and the most flexible scripting in Windows is to make yourself a COM object. Once you get past the anti MS bias, there are many great scripting options you can use.

Windows scripting host with JScript and VBScript provide simple powerful scripts. The added benefits of being a com object are that ANY windows program can interact with you.

You would just expose elements of Girder to the interface and then let the script writers control what they want to do. All you would have to do is provide a simple interface to launching a script based on a command or eventstring.

A great example of this type of thing is MS Office.

It will be really cool. Besides getting the scripting benefits, you would be able to fit girder into all kinds of other automation scenarios and programs. People could create all kinds of programs that act as shells for girder, or integrate girder functionality into them. With events exposed, people could add handlers to girder events to their programs and do anything they liked.

[Butters]

Not to badger a point since you don't want to head in this direction, but I don't think it is right to confuse media hype with real technological details.

COM works on all Win32 platforms. It is well documented and not to hard to implement if you have Visual Studio. Most every program MS writes is COM enabled, including Office, IE, Visual Studio, etc.

There is no inherient danger from viruses by using COM than anything else. Dangers arise by following bad security models, like the ones used in outlook. Every system is vunerable in different ways and to different types of attacks.

Anyway, it is just something to think about to provide the most power for the end users in the easiest way. I'm not a huge COM pusher or anything, just trying to suggest ideas.

[Butters]

That is a great idea, kind of like how the OSDMenu interacts with Girder. I'll take a look at a plugin and see how easy it would be to turn it into a COM object.

I won't make any promises, etc. I have a lot of projects on my plate right now, but I'll see what I can do. I've just gotten girder working the "normal way". :)