By using an extern error handler in the script engine, we can mock that
handler and make sure something that should fail actually does, instead
of having to parse log messages.
If a local variable in a definition was set to a proplist inside the
Definition() callback, and that proplist contained cyclic references
then those references were leaked. Typically cyclic references for
script-created proplists are broken in
C4PropListScript::ClearScriptPropLists, however definition proplists
are changed to be static proplists in
C4PropList::FreezeAndMakeStaticRecursively.
To fix this, each script host maintains a list of proplists made static
by FreezeAndMakeStaticRecursively, and explicitly deletes all of these
proplists on Clear().
This leak also leads to an assertion failure inside
C4PropListScript::ClearScriptPropLists in debug mode, and can also be
observed by C4PropList::PropLists not being empty after game clear.
The definition in Objects.ocd/Helpers.ocd/UserAction.ocd constructs
cyclic proplists in its Definition() call. A simpler, more minimal way
to provoke the leak is the following (it provokes the leak but not the
assertion failure):
local bla;
func Definition(def)
{
bla = {};
bla.test = { Name="Test222" , Options = { Name="Test333" } };
bla.test.Options.Link = { Name="Test444", Blub=bla.test };
}
This commit contains a fairly substantial rewrite of the C4Script code
generator. Instead of generating bytecode while parsing the script,
we're now parsing the script into a syntax tree, and have any further
processing happen on that instead of the raw source.
At this time, the code generator emits the same bytecode as the old
parser; there are several optimization opportunities that arise from the
new possibility to emit code out of order from its specification by the
author.
Compared to the old compiler, this one is still rather deficient when
dealing with incorrect code; it's also not emitting several warnings
that used to be diagnosed.
This even enables some simplification in the CompileFuncs, since the global
effects were already put in the same section as the other ScriptEngine
parts. The callback for updates due to relinks also fits nicely.
The reset in C4Game::Default was redundant with C4Game::Clear already.
In the long term, there is no reason DirectExec should be concerned with
C4AulScript/C4ScriptHost. In the meantime, the lookup code from Fneval can
be moved into the function.
This allows eval in scenario script to access scenario script locals, but
that seems harmless.
The C4AulScript containing the source of the function was already mostly
used to get the relevant proplist or available from context. This will
allow more than one proplist plus the global one per scripthost to contain
functions.
The distinction between the "aul" and "non-aul" parts of
the script engine are mostly historical accident, and the
current organization of the source code does not use
sub-subdirectories. I'd like to keep it that way.
This reverts commit 69ba06b8d0.
There have been some bugs and crashes related to unwanted deep comparison (e.g. in the maze scenario). Scripters very rarely need deep comparison, so it should not be the default for the most commonly used operator.
This also changes behaviour of GetIndexOf to do pointer comparison.
This change has Guenther's seal of approval.
As discussed in http://forum.openclonk.org/topic_show.pl?tid=2917, I
have merged all copyright notices into a single file and referenced that
merged file from each source file.
For the updated source files, the timeline has been split into three
parts:
1. Pre-RWD code (before 2001)
2. RWD code (2001 through 2009)
3. OpenClonk code (2009 and later)
All pre-RWD copyright notices have been left intact, as have RWD-era
copyright notices where the file did not have a RedWolf design copyright
notice but only individual author ones. All copyright notices of the
OpenClonk era have been replaced by a single notice ranging from the
first recorded year to the current year (2013). Mape code did not get a
OpenClonk Team copyright notice because it is somewhat separate from the
main OpenClonk codebase and has only been touched by Armin Burgmeier.
The new type C4TimeMilliseconds behaves for the most part like a uint32_t but is overflow-proof in comparisons.
In some places, a 0-value (or uint_max) of the variable storing the time had the special meaning "not set yet". This has been resolved by having it as a pointer to C4TimeMilliseconds with NULL meaning that it has not been set yet.
This makes functions independent of their "Code Owner"s, which removes the
necessity to maintain that connection and carefully reset functions when
their scripthost is cleared.
Since the script engine doesn't have an appropriate function to create the
proplist in, simply create it in the constructor and arrange for the
string table to be constructed first.
Because the interpreter throws for every function that is called with a
this parameter that has been removed, this() isn't a function anymore.
The function could stay around so that Call("this") or foo->this()
would still work, but I doubt any script ever did that.
These operators have a stricter definition of equality than the == and !=
operators. Those are already stricter than in some other languages, so the
new ones are probably not needed very often. But if the need does arise,
there's no workaround short of modifying the data structures and checking
whether they are still the same.
The rope will create a C4AulScript for the rope engine functions instead of
putting them into the global scope, and we might want to put C4Object-only
functions into a separate C4AulScript some day, too.
The map is currently only used in the parser for some warning heuristics.
Since it uses a hash table with separate chaining and the amount of
functions is fairly predictable, the hash table doesn't have to be
resizable.
The parser now copies the contents of the proplists in the order of their
source scripts into the final proplist. This way, local variable contents
get properly included, and the list of functions has one user less.
Sven Eberhardt