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", ...)
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>
of objects from the scene, and of scripts from objects. This facilitates
the development of modules that can register prims with externall servers
for inbound email and XMLRPC. Currently implemented in XEngine only.
Also applying cmickeyb's compiler locking patch, since it seems risk-free.
number map. Instead, write the map to a file for later use. That is not
yet used, so currently runtime errors after a sim restart will have wrong
line numbers
* In most cases, the setting in OpenSim.ini.example is taken as the canonical one since this is the file virtually everyone ends up using
* OpenSim will start up with a blank OpenSim.ini, in which case sqlite is the default database (as before)
OpenSim.Region.Environment into a "framework" part and a modules only
part. This first changeset refactors OpenSim.Region.Environment.Scenes,
OpenSim.Region.Environment.Interfaces, and OpenSim.Region.Interfaces
into OpenSim.Region.Framework.{Interfaces,Scenes} leaving only region
modules in OpenSim.Region.Environment.
The next step will be to move region modules up from
OpenSim.Region.Environment.Modules to OpenSim.Region.CoreModules and
then sort out which modules are really core modules and which should
move out to forge.
I've been very careful to NOT BREAK anything. i hope i've
succeeded. as this is the work of a whole week i hope i managed to
keep track with the applied patches of the last week --- could any of
you that did check in stuff have a look at whether it survived? thx!
ordinary region modules and are able to coexist in one instance.
See http://opensimulator.org/wiki/ScriptEngines for details. There were
changes to OpenSim.ini.example, please note DefaultScriptEngine.
Also see the User docs and FAQ on the Wiki. Default is DotNetEngine.
