Re: [glob2-devel] Language demands

[Martin Voelkle]

> >SGSL now does a mixture of a and b. Normally, there is cooperative
> >multitasking, but if the thread runs too long without waiting, it is
> >'preempted' after a number of VM instructions.
>
> The instruction counter limitation !
>
> >It is perfectly possible to avoid this if you get rid of preemption.
>
> Hmm, by having a calle like :
>
> void executeSome( Context &, unsigned nNumOfInstuctions )

I meant you can just forget about detecting infinite loops with this kind of 
instructions and just use cooperative multitasking.

> The only problem is when the script start calling functions (even TEA
> functions) as this will bemand a preemtion to preserve the stack (I use
> the call stack for TEA calls too). I quess SGSL have the same problem.

It's a bad idea to use the call stack for TEA functions, since you won't be 
able to save/restore it. SGSL doesn't have that problem, because it doesn't 
have stacks. The only thing that must be saved are the instruction pointer 
and a few global variables.

> >If you handle your stack yourself, you can do the switch without any
> >longjump.
>
> I know, all can be done in ASM, but that is not portable at ALL :-)

Nope, you can have a user-defined stack and manipulate it in the interpreter 
loop.

> >This sounds exactly like b, but you're using thread support just to
> >emulate longjump. I'm not sure it will be easier do debug than b.
>
> You may be right, other than linux will generate a core dump for the
> offending thread, and thay may be more easy to analyze, but nothing
> beats single threads regarding debugging and profiling !

If you want ease of debugging, you might better go for a stack manipulated by 
interpreter code.

> >LUA's license said "Altered source versions must be plainly marked as
> >such, and must not be misrepresented as being the original package."
> >which is not what you intend to use. See
> >http://lua-users.org/wiki/LuaLicense for discussion about this. The main
> >problem with such statements is that they are incompatible with the GPL.
>
> I just want to merge the language comment from the LUA licens and LGPL.

There is no "language comment" in the LUA license. It speaks about the source 
code of the implementation that can't be modified without modifying the name 
of the program. LUA abandoned that license for this reason and switched to 
the MIT license.

> I like everyone to be able to use and expand TEA (types and functions)
> in all kinds of relations, also as static linking to a commercial
> program. But the language core must stay open, and remain under LGPL.
>
> If i LGPL it, glob2 can use and link with it as it/we please, but I will
> not be able to use static linking at my current job, and that is plain
> silly (I could also use dual license, but that is just another ogly idea).

You are right, your company wouldn't be able to release a work containing 
statically-linked portions of LUA unless the user (someone who legally gets 
the work) has the possibility of getting a dinamically-linked binary as well.

You can still do a private dual-licensing: release the code under LGPL to the 
public and the copyright holder (be it you or your company) can also use the 
code in any way it wants, including allowing someone else to get it under an 
other permissive license. If you do this, don't forget to ask either 
copyright transfer or a permissive license for any non-trivial change you get 
from someone using the LGPL licensed version if you want to be able to use it 
at your company.

> >What you can do is separate the language specification form your
> >reference implementation. Protect the specification in some way (but
> >keep it free) and put the implementation under a GPL-compatible license.
>
> I don't quite follow your in this ?

I had misunderstood what you wanted to keep free. I thought you wanted the 
specification of the language to be fixed and your implementation to be free. 
But it seems like you want to let people modify the language as well.

Martin