This is done through the parser and so generates the same syntax error message if any parameters are wrongly specified for this event.
We were already enforcing event names in the parser.
This is only for state_entry so far as an initial test of the approach - appears to work correctly.
scripts as boxed integers rather than proper reference to a new LSLInteger.
This fixes an exception when using a registered integer constant in
a script.
This is mostly Bluewall's work but I am also bumping the general version number
OpenSimulator 0.7.5 remains in the release candidate stage.
I'm doing this because master is significantly adding things that will not be in 0.7.5
This update should not cause issues with existing external binary DLLs because our DLLs do not have strong names
and so the exact version match requirement is not in force.
This is to eliminate disruption until co-op termination has been well-tested.
In non co-op mode, XEngine will continue to load DLLs of the existing Script class and the new XEngineScript class.
Moving to co-op mode still requires existing script DLL deletion to force recompilation, either manually or by setting DeleteScriptsOnStartup = true for one run.
This change also means that scripts which fail to initialize do not still show up as running scripts.
This involves inserting opensim_reserved_CheckForCoopTermination() calls in lsl -> c# translation at any place where the script could be in a loop with no wait calls.
These places are for, while, do-while, label, user function call and manual event function call.
Call goes through to an XEngineScriptBase which extends ScriptBase.
IEngine is extended to supply necessary engine-specific parent class references and constructor parameters to Compiler.
Unfortunately, since XEngineScriptBase has to be passed WaitHandle in its constructor, older compiled scripts will fail to load with an error on the OpenSim console.
Such scripts will need to be recompiled, either by removing all *.dll files from the bin/ScriptEngines/<region-id> or by setting DeleteScriptsOnStartup = true in [XEngine] for one run.
Automatic recompilation may be implemented in a later commit.
This feature should not yet be used, default remains termination with Thread.Abort() which will work as normal once scripts are recompiled.
The encodings are thread-safe and already used in such a manner in other places.
This isn't done where Byte Order Mark output is suppressed, since Encoding.UTF8 is constructed to output the BOM.
from region modules. The LSL translator is extended to generate the
modInvoke format of commands for directly inlined function calls.
A region module can register a function Test() with the name "Test".
LSL code can call that function as "Test()". The compiler will translate
that invocation into modInvoke("Test", ...)
They were all failing assertions but the exceptions these threw were caught as expected Exceptions.
I don't think we can easily distinguish these from the Exceptions that we're expecting.
So for now we'll do some messy manually checking with boolean setting instead.
This patch also corrects the assertions themselves.
The Path.GetDirectoryName call in Compiler.CompileFromDotNetText is unnecessary since AppDomain.CurrentDomain.BaseDirectory is always a directory.
Later path concatenation is already done by Path.Combine() which handles any trailing slash.
Removing Path.GetDirectoryName() will not affect the runtime but allows NUnit to work since it doesn't add a trailing slash to AppDomain.CurrentDomain.BaseDirectory.
was not used, but exactly the same path was calculated inline.
This patch does some minor refactoring by replacing inline path
calculation with GetCompilerOutput. This doesn't actually affect anything,
just minor prettifying of the code
Linux (as an example), it is possible for the existence check to fail
because the file is not yet recognized by the file system. Although
the loop has a 250mS delay, in practise, the existence test in the for
loop is successful and no delay is introduced.
Next, this takes care of the two, unpredictable, situations where a
script fails to compile. The first is caused by an occasional SEGV in
the underlying mono VM while mcs is running, the second is caused by
file system latency.
Signed-off-by: dr scofield (aka dirk husemann) <drscofield@xyzzyxyzzy.net>
