aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/OpenSim/Tools/Compiler (follow)
Commit message (Collapse)AuthorAgeFilesLines
* On to 0.8.3!Diva Canto2015-10-181-1/+1
| | | | | Conflicts: OpenSim/Region/PhysicsModules/ConvexDecompositionDotNet/Properties/AssemblyInfo.cs
* Updated all occurrences of AssemblyVersion("0.8.1.*") to ↵Diva Canto2015-04-291-1/+1
| | | | AssemblyVersion("0.8.2.*")
* Improved line map heuristics.Aleric Inglewood2014-06-191-16/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix looking up line number and colum when there is no exact match.Aleric Inglewood2014-06-191-23/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Change assembly versions to 0.8.1Justin Clark-Casey (justincc)2014-06-171-1/+1
|
* Bump OPenSimulator version and assembly versions up to 0.8.0 DevJustin Clark-Casey (justincc)2013-10-041-1/+1
|
* Deleted all AssemblyFileVersion directivesDiva Canto2013-02-191-1/+1
|
* Bump version and assembly version numbers from 0.7.5 to 0.7.6Justin Clark-Casey (justincc)2013-02-051-1/+1
| | | | | | | | 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.
* The last few AssemblyInfos. Finished!Diva Canto2012-11-141-0/+33
|
* Where possible, use the system Encoding.ASCII and Encoding.UTF8 rather than ↵Justin Clark-Casey (justincc)2012-07-111-8/+5
| | | | | | | 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.
* minor: remove some mono compiler warningsJustin Clark-Casey (justincc)2009-11-241-12/+14
|
* Add copyright header. Formatting cleanup.Jeff Ames2009-09-291-20/+16
|
* Renamed the project lslc to OpenSim.Tools.lslc to conform to the naming ↵Diva Canto2009-09-181-0/+26
| | | | conventions so far. Added copyright to it.
* This fix adds a stand-alone compilation environmentAlan M Webb2009-09-161-0/+287
for OpenSIm scripts. It makes it very easy to address coding issues before going in-world to try a script out. This is a HUGE time saver if you're doing anything significant with scripts. Signed-off-by: dr scofield (aka dirk husemann) <drscofield@xyzzyxyzzy.net>