[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] Language demands
From: |
Bo Lorentsen |
Subject: |
Re: [glob2-devel] Language demands |
Date: |
Sun, 19 Jun 2005 21:56:54 +0200 |
User-agent: |
Debian Thunderbird 1.0.2 (X11/20050602) |
Martin Voelkle wrote:
I meant you can just forget about detecting infinite loops with this kind of
instructions and just use cooperative multitasking.
Ok, I think I understand.
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.
Yes, SGSL have no control statements and internal script functions, and
that make a big difference. I have been thinking about the "call stack"
problem in TEA, and I guess I could make it use another method there too
(I maintain the call stack), and yes this makes persisting the script
state more easy to do.
The only problem that remain (for both TEA and SGSL) is when the script
calls some external functions, as we have no control over these as for
dead loop and other faults !
If you want ease of debugging, you might better go for a stack manipulated by
interpreter code.
Yea yea, you convinced me :-)
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.
... they just defines what may be viewed as an extension to LUA and what
is a change in the language semantic, and I like that separation.
But if it is true that it is possible to link a LGPL staticly to a
commercial program as long as the dynamic version is available to )or a
ref to it), then I am happy for the LGPL license.
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.
Ok that is nice, this is what I want. I want to use TEA both at my work
for commercial software and in other OS programs like glob2. But I like
all future improvements and extensions (semantic or language core), to
remain LGPL !
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.
I hate the idea of dual license, but I know what you mean :-)
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.
If someone thinks they can improve TEA by changing the language, they
are welcome to use my code as base, as long as it has another name and
remain LGPL. But I prefere to see the changes go into TEA to make it an
even better language.
But it seems like you want to let people modify the language as well.
Yes, but I like to stay in control of this instance :-)
Is this a bad idea ?
/BL
- [glob2-devel] Language demands, Bo Lorentsen, 2005/06/15
- Re: [glob2-devel] Language demands, Stephane Magnenat, 2005/06/17
- Re: [glob2-devel] Language demands, Bo Lorentsen, 2005/06/19
- [glob2-devel] gameplay ideas, Kyle Lutze, 2005/06/20
- Re: [glob2-devel] gameplay ideas, Gabriel Walt, 2005/06/20
- Re: [glob2-devel] gameplay ideas, Stephane Magnenat, 2005/06/20
- Re: [glob2-devel] gameplay ideas, Andrew Sayers, 2005/06/20
- Re: [glob2-devel] gameplay ideas, Emmanuel Eckard, 2005/06/20
- Re: [glob2-devel] gameplay ideas, Stephane Magnenat, 2005/06/20