Re: [glob2-devel] Language demands

[Stephane Magnenat]

Hello,

> I have been working on my new version of TEA, and have been trying to
> take all things in account that have been discussed in the last
> "scripting language" thread.

Cool

> I have a few issues left that I like to ask about :
>
> 1. as I see it now, the current language have the possibility to run a
> certain number of instructions, and then return control to the game to
> be able to control CPU usage (time share). There are tree ways to do
> this in TEA as I see it :
>
>    a. Limit the number of VM instructions performed per "tick" (store
> the pc and cont. at next pos on return)
>    b. Make some kind of cooperative multitasking (locally allocated
> stack, and wait instructions)
>    c. use the existing thread system (semaphore locked), and the wait
> instruction.
>
> a. sounds simple, but I dislike to put too much complexity into the
> language code (there is plenty already :-))
> b. I am not sure this is possible at all in a modern OS, but I have used
> this and longjump in the past for tasks like this. but I dislike it and
> it will be very hard to debug.
> c. This sound to me, like a nice way to do it. We allocate to threads,
> and when we like to make a script run, we unlock one semaphore and wait
> on another, and then the script engine will run until the next "wait"
> instruction, that will give back control, using the same semaphores.
> There will not be any thread related problems, as only one thread runs
> at a time, and debugging will be likewise easier.

One of the required feature to be able to use tea in glob2 is that script 
execution has to be deterministic, so I'm afraid that (c) fail regarding this 
requirement. In general, there is two things to consider:
1) being able to have a wait instruction, that check some condition and on 
false switch to another thread. This condition should be rechecked every 
certain time.
2) begin able to set a predefined maximum instruction count and then skip to 
the next thread.
Point 1) is mandatory. Point 2) is only required if we want to be safe 
regarding to broken scripts.

> 2. License, I like LGPL but I also like to add the same note as the
> folks at LUA did, that say : "If the syntax and semantics of the
> language (that is, the parser and the virtual machine) remain the same,
> then the language is still Lua. If you simply add new libraries, or even
> replace the standard libraries by your own, the language is still the
> same, and you don't need to give it a completely different name."
> Does anyone know if this is possible to combine ?

You are free to use whatever license you want. Regarding to its juridistic 
coherent, I'm not competent. But as long as it is free software and can be 
linked to glob2 (which is GPL), I'm happy.

> But beside this, TEA are heading in the right direction, after a big
> cleanup (and addintion of param. function) and addition of a real stack
> vm :-)

Cool. Do you have the source somewhere ?

Thanks !

Steph