[glob2-devel] Language demands

[Bo Lorentsen]

Hi ...

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.

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.

How does that sound ? Am I totally off track ?

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 ?

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 :-)

/BL