| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
streams in the script engine even if exceptions are thrown.
|
|
|
|
| |
that were removed some time ago
|
|
|
|
|
|
|
| |
existing session use the previous strategy for that script rather than not starting the script at all.
We have to do this since we can't unload existing DLLs if they're all in the same AppDomain.
But we can still update the underlying DLL which will be used in the next simulator session.
|
|
|
|
|
|
|
| |
CheckOrCreateScriptsDirectory()) when checking that scripts directory exists on compile.
Code was identical apart from error logging, but if there are failures creating these directories then you'll be
seeing lots of errors anyway, and these will be more informative
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the C# column can't be found in the positionMap (but the line can),
use the map immediately after it while correcting for the offset,
unless that results in an LSL position before the previous LSL position
in the positionMap.
The idea behind this heuristic is that in most, if not all cases C#
consumes more characters than LSL (for example LSL_Types.LSLInteger
instead of just 'integer').
Thus if the distance between the columns of two markers differ in
the C# and LSL file, the distance in the C# file will be larger.
Moreover, we can assume that every time this happens we will have
a marker at the beginning of the longer 'keyword', because those
keywords were generated by us in the first place.
For example:
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
1 2
will always have markers at the beginning of the long keywords
'LSL_Types.LSLInteger' and 'LSL_Types.LSLString'.
If an error is generated in between (for example at the beginning
of the function name 'f2') then the correct position is found
by using an offset relative to 2 rather than 1.
Note that a case where this isn't working correctly is
when the user adds extra spaces. For example:
LSL: integer f2( string s)
would still use the start of 'string' as reference and
then go backwards 3 characters only because the corresponding
C# still looks like
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
only 3 chars difference
and the reported error at 'f2' would be here:
LSL: integer f2( string s)
^
This can only be fixed by generating a mapping for 'f2' itself, or
generating a mapping whenever the amount of spaces is changed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a compile error reports a colum/error that is not an exact
match in the positionMap dictionary, the last position in the
map with a line number and position before the reported error
should be returned.
The old code had the following problems:
1) It returns l,c - which are line and column of the C# file, not LSL.
2) It doesn't set l to 'line' when the map has an entry with 'line'.
3) It sorts the map without taking columns into account, which may
result in a random order of the columns. With my mono implementation
the columns were reversed in order.
For example, if the map contains the following lines:
99,5,49,10
100,30,50,10
100,40,1,0
101,5,51,10
and a translation of 100,35 was requested,
then the old code would compare '100' with the keys in
the first column - setting l to that key while it is
smaller. Hence, l is set to 99.
Then it finds the key 100 and doesn't update l.
Because of the reversed sort order, it first compares
the column 35 with 40, finding that it is smaller
and therefore it stops; returning 99,1 instead of finding
the correct 100,30 entry and returning 50,10.
This patch causes 50,10 to be returned.
The remaining problems after this patch are:
1) The sorting might not be necessary at all.
2) The is code duplication (I fixed both instances,
but really there should be no code duplication
imho).
|
| |
|
|
|
|
| |
Fixes build break from d3387d591a2bd496c8315f17b2310d6a6f40a7c3
|
|
|
|
| |
Thanks to Kira for this patch from http://opensimulator.org/mantis/view.php?id=6845
|
|
|
|
|
|
|
|
| |
generate syntax error as seen on the LL grid
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.
|
|
|
|
|
|
|
| |
failing because they have no linemap.
Adapted fix from http://opensimulator.org/mantis/view.php?id=6571
Thanks Nickel Briand
|
|
|
|
| |
Hopefully will fix windows build via compile.bat
|
|
|
|
|
|
|
|
|
| |
continue to generate C# that is functionality identical to historical generation
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
addition to termination on wait.
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.
|
| |
|
|
|
|
|
|
|
| |
constructing fresh copies.
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", ...)
|
|
|
|
|
|
|
|
| |
Path.GetDirectoryName when getting assembly loading path in Compiler.CompileFromDotNetText().
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Adding ability to place script engine assemblies outside
the codebase directories.
Uses new [XEngine] option: ScriptEnginesPath = "path_to_assemblies"
Signed-off-by: Melanie <melanie@t-data.com>
|
|
|
|
| |
needed libraries
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
not in a funky debug window.
|
|
|
|
| |
* Added the new AppDomainLoading variable to the [XEngine] section in the example config
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
to return dynamic method objects
|
|
|
|
|
|
| |
Cause group deeding to apply next owner perms
|
| |
|
| |
|
|
|
|
|
|
|
| |
scripting.
Fixes Mantis #2862
|
|
|
|
| |
LICENSE.txt.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
is deleted.
|
|
|
|
|
|
|
|
| |
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 the compiler. Committed with changes.
Fixes Mantis #3325
|
|
|
|
|
|
|
| |
* 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)
|
| |
|
|
|
|
|
| |
Deals with the multiple warning side affect introduced earlier.
|
| |
|
|
|
|
|
|
|
| |
Adds a warning for an LSL construct that exploits a
popular list memory saving hack.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This changeset fixes a rather nasty script compile bug that manifests
itself under heavy load.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
| |
|