[Opensim-dev] My new LSL compiler project

[Michael Emory Cerquoni]

doesnt LL use their own forked version of mono?
On Nov 9, 2015 10:38 AM, "Blake" <techplex.engineer at gmail.com> wrote:

> Eric,
>
> Have you seen the Mono test scripts that SL used when they change
> compilers from the legacy LSL to the Mono based one?
> They might be a good benchmark. I know that a bunch of the test fail in OS.
>
> http://wiki.secondlife.com/wiki/Mono#Testing
>
> Best,
> Blake
>
> On Mon, Nov 9, 2015 at 1:29 PM, Eric  <e800 at gmail.com>
> wrote:
>
>> If yall believe that reverse compatibility should be thrown out the door,
>> it makes everything much simpler.
>>
>> I was under a preconceived notion for a bit that any sort of script
>> breakage might cause the compiler to be a no go.
>>
>> Fortunately all changes I mentioned are easy to make and reverse due to
>> the, way the expression type evaluation and checking logic is segregated
>> out in the library.
>>
>>
>> At the moment I am tidying up some things and updating the build system,
>> mainly to remove the platform specific binaries from the installer and
>> binary releases;
>> Also I am working on a settings UI for the editor.
>>
>> I've just removed the tiny change from the library that allows for the
>> compatibility options previously mentioned.
>>
>>
>>
>>
>> I have experienced a few problems as you mentioned with the default
>> XEngine compiler, I have put at least one script through it that caused a
>> stack heap
>> and server crash in its current state.   It is this one:
>> http://wiki.secondlife.com/wiki/BigNum,  however I have not investigated
>> why it happens yet.  It does not
>> happen when LibLSLCC is used for code generation.
>>
>> I am pretty sure the crash happens in the default XEngine compiler itself
>> and not in the running code.
>>
>> Examples of either type of problem (in running code, or especially
>> compiler related) would be helpful in testing LibLSLCC.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 9, 2015 at 10:25 AM, Zadark Portal <zadarkportal at gmail.com>
>> wrote:
>>
>>> Hello Eric
>>>
>>> I agree with the previous comment.
>>>
>>> This contribution is such that we are now considering reintroducing
>>> Opensim as an entry platform to scripting. Previously we found it
>>> impossible to support larger class sizes due to the empirical nature of
>>> novices producing non deterministic behaviours.
>>>
>>> If when considering further developments may I suggest trapping
>>> potentially dangerous (Opensim crash) scripted constructs. Maybe this is a
>>> tall ask, but enormously beneficial to simulator operators managing
>>> experimental behaviour of users attracted to Opensim. I have not included
>>> examples but will to do so at your request.
>>>
>>> It will be a couple of weeks before I can introduce the functionality to
>>> a class and comment further, but whatever the future for this contribution
>>> with regards to core we will continue make full use.
>>>
>>> Regards
>>> Z
>>>
>>> On 9 November 2015 at 14:20, Melanie <melanie at t-data.com> wrote:
>>>
>>>> Please don't do all these things.
>>>>
>>>> OpenSim is alpha software and there is no need to make the mistake
>>>> other projects made and perpetuate bugs in the name of compatibility.
>>>>
>>>> The cast to list is there because, afaik, in SL the operation list +
>>>> scalar is legal and means to append an element. It's not meant to
>>>> allow the other side effects you listed and they should be illegal.
>>>>
>>>> There isn't a way to do these tests on crossings. That's also not
>>>> necessary as the better compiler will be used by all in short order.
>>>> People will fix their scripts and everyone will be happy again.
>>>>
>>>> Let's not breed bugs, but let's squish them instead.
>>>>
>>>> - Melanie
>>>>
>>>> On 09/11/2015 11:50, Eric  wrote:
>>>> > You're right actually.
>>>> >
>>>> > Since stuff like old LSO list/string optimization hacks were not
>>>> possible
>>>> > beforehand while using XEngines compiler,
>>>> > there is probably not to many people with code that's going to behave
>>>> > incorrectly with the evaluation order of binary
>>>> > operations switched.  The scripts that happen to break are doing
>>>> something
>>>> > pretty wacky/unnecessary.
>>>> >
>>>> > There's not any micro optimizations that I know of relying on the old
>>>> left
>>>> > to right evaluation order either.
>>>> >
>>>> > ==
>>>> >
>>>> > That being said, there are many things the XEngine default compiler
>>>> will
>>>> > allow to compile that are infact
>>>> > syntactically incorrect in LSL.  stuff like negating
>>>> vectors/rotations in
>>>> > global variable declarations
>>>> > as well as doing cast in static context.  In general the default
>>>> XEngine
>>>> > compiler's rules for global variable
>>>> > declaration expression content are very lax in comparison to the
>>>> secondlife
>>>> > compiler, and that is just one example.
>>>> >
>>>> >
>>>> > LibLSLCC's goal to mimic the secondlife compiler's rules exactly, in
>>>> its
>>>> > default configuration.
>>>> >
>>>> >
>>>> > From my understanding a script moving to new a region is going to be
>>>> > recompiled if the destination sim does not allow the script binary
>>>> > to transfer over and be executed.  This will be true in most cases
>>>> because
>>>> > the default settings disallow it, and it's unsafe to enable.
>>>> >
>>>> > This would cause a problem for scripts from another region that
>>>> LibLSLCC
>>>> > deems to contain syntax errors.
>>>> >
>>>> > I may to have to dig into OpenSim to see how region crossing for
>>>> scripts
>>>> > work; to see if I have to make the re-compile sensitive
>>>> >  to which compiler was used on the other sim, regardless of what
>>>> version of
>>>> > OpenSim it is running.
>>>> >
>>>> > I imagine this would be a requirement to connect a sim to a grid
>>>> containing
>>>> > regions not using my compiler addon.
>>>> >
>>>> >
>>>> > ==
>>>> >
>>>> > I tested the library build on OS X Snow leopard 10.6 and OS X El
>>>> Capitan
>>>> > 10.11.
>>>> >
>>>> > Building LibLSLCC-NoEditor.sln works as intended.
>>>> >
>>>> > The command line program lslcc that's part of LibLSLCC works fine on
>>>> both
>>>> > and has no problem generating code.
>>>> >
>>>> > LibraryDataScrapingTools works on OSX 10.11 even with its WinForms
>>>> dialogs,
>>>> > and the OpenSim fork works fine to.
>>>> >
>>>> >
>>>> > However, when I tested with OSX 10.6 I ran into an issue where mono
>>>> > complained about missing System.Drawing.GDIPlus.
>>>> >
>>>> > I'm sure there's probably a way to fix this but I did not look into
>>>> it to
>>>> > deeply as I was using a borrowed computer for a few minutes,
>>>> > that error prevented both LibraryDataScrapingTools and OpenSim from
>>>> > starting.
>>>> >
>>>> >
>>>> > ==
>>>> >
>>>> > As of now I have added a setting to allow implicit cast of all types
>>>> into
>>>> > list within a function
>>>> > calls parameter expressions, as Zadark had mentioned.
>>>> >
>>>> > As it turns out, all of OpenSim's C# runtime types contain an implicit
>>>> > conversion operator to list.
>>>> >
>>>> > It happens regardless of context.
>>>> >
>>>> > So The default XEngine compiler allows stuff like this too:
>>>> >
>>>> > list a = "";
>>>> >
>>>> > list b = <0,0,0>;
>>>> >
>>>> >
>>>> > I will probably change the setting to just allow implicit list cast
>>>> > everywhere as an option,
>>>> > and maybe add some syntax related compatibility options for global
>>>> > variables.
>>>> >
>>>> > In the long run, if I can figure out how to make the compiler addon
>>>> aware
>>>> > of re-compiles due to region
>>>> > crossing, some syntax in-compatibility will not be a major issue for
>>>> > scripts that you cannot modify.
>>>> >
>>>> > If I could somehow select to re-compile them with the default XEngine
>>>> > compiler  (if that's what they were originally compiled with),
>>>> > then they will not be subject to LibLSLCC's stricter syntax checking.
>>>> >
>>>> >
>>>> > ==
>>>> >
>>>> > I have been working on a settings panel for the editor so I can
>>>> easily test
>>>> > different
>>>> > compiler configurations, and segregating some of the editor code out
>>>> into
>>>> > different assemblies;
>>>> > it will take me a little bit to finish.
>>>> >
>>>> > I'm currently working out of the development branch on github, I'll
>>>> put up
>>>> > a new editor installer
>>>> > when I get the configuration stuff all worked out.
>>>> >
>>>> >
>>>> > On Sat, Nov 7, 2015 at 8:46 AM, Melanie <melanie at t-data.com> wrote:
>>>> >
>>>> >> I would be against making the evaluation order optional. It has long
>>>> >> been recognized as a bug in XEngine's compiler and people porting
>>>> >> scripts from SL have been advised to remove evaluation order
>>>> >> dependent code but not write any code that depends on the wrong
>>>> >> XEngine eval order. Therefore, if this compiler breaks content that
>>>> >> content needs to be fixed, not a setting changed for convenience to
>>>> >> perpetuate the bad behavior.
>>>> >>
>>>> >> - Melanie
>>>> >>
>>>> >> On 07/11/2015 15:36, Eric  wrote:
>>>> >> > Thanks Again Zadark
>>>> >> >
>>>> >> > This should be easy to fix, I need to change the type validation
>>>> system
>>>> >> > just little so the syntax tree can be built with these types of
>>>> implicit
>>>> >> > conversion present.
>>>> >> >
>>>> >> > The code generator can then be made to generate the cast when
>>>> necessary,
>>>> >> > since it will pass syntax checking.
>>>> >> >
>>>> >> > I think I am going to implement it as a compatibility option in the
>>>> >> > compiler that you can turn on or off, depending on if you want the
>>>> linden
>>>> >> > compilers more strict type checking behavior.
>>>> >> >
>>>> >> > I should also probably make order of evaluation correction on
>>>> binary
>>>> >> > operations something you can disable if needed, since I can see
>>>> that
>>>> >> > causing compatibility problems somewhere too.
>>>> >> >
>>>> >> > Side Note:  I have not tested on Mac yet, but I plan to do so
>>>> today if I
>>>> >> > can get time to, sorry.
>>>> >> > On Nov 7, 2015 7:42 AM, "Zadark Portal" <zadarkportal at gmail.com>
>>>> wrote:
>>>> >> >
>>>> >> >> Hello Eric,
>>>> >> >>
>>>> >> >> Very useful, thankyou.
>>>> >> >>
>>>> >> >> Caveat
>>>> >> >> XEngine appears to cast library function parameters to the
>>>> relevant
>>>> >> type,
>>>> >> >> though I can see this handy for novice scriptwriters it does
>>>> encourage
>>>> >> some
>>>> >> >> less than elegant techniques
>>>> >> >>
>>>> >> >> Some popular scripts freely available to OpenSim use this feature:
>>>> >> >> For instance:
>>>> >> >> llListFindList takes 2 parameters of the type List, when in fact
>>>> the
>>>> >> >> existing compiler permits any type (as far as we have tested).
>>>> >> >>
>>>> >> >> example... integer  bah = llListFindList( blah1,
>>>> llList2String(blah2,
>>>> >> >> blah3)); // compiles and kind of works.
>>>> >> >>
>>>> >> >> This of course fails when compiled with LSLcc, the explanation is
>>>> clear
>>>> >> >> and precise so easy to fix (enable compile) with a local cast.
>>>> >> >>
>>>> >> >> Z
>>>> >> >>
>>>> >> >>
>>>> >> >> On 5 November 2015 at 12:52, Jak Daniels <jak at ateb.co.uk> wrote:
>>>> >> >>
>>>> >> >>> Hi Eric,
>>>> >> >>>
>>>> >> >>> yes I can confirm now that it does open and compile correctly in
>>>> VS C#
>>>> >> >>> 2010 express now. Thank you.
>>>> >> >>>
>>>> >> >>> I'm now installing VS2015 in a win10 virtual machine so I don't
>>>> clobber
>>>> >> >>> my SSD, so I can compile and play with the LSL editor.
>>>> >> >>>
>>>> >> >>> kind regards
>>>> >> >>> Jak
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> On 04/11/2015 06:10, Eric  wrote:
>>>> >> >>>
>>>> >> >>> Let me just make a slight correction to my last message, and add
>>>> some
>>>> >> >>> info...
>>>> >> >>>
>>>> >> >>> After removing the "<LangVersion>5</LangVersion>" stuff from the
>>>> >> >>> non-editor related .csproj files,
>>>> >> >>>
>>>> >> >>> I found that VS2010 is actually able to open the
>>>> >> >>> "MonoDevelop-LibLSLCC.sln" solution file in the source tree and
>>>> build
>>>> >> it
>>>> >> >>> without any problems.
>>>> >> >>>
>>>> >> >>> I'm going to be pushing the changes I made to the .csproj files
>>>> >> shortly,
>>>> >> >>>  I will probably rename "MonoDevelop-LibLSLCC.sln" to something
>>>> like
>>>> >> >>> "LibLSLCC-No-Editor.sln" and update the build instructions in the
>>>> >> >>> README.md to specify that solution as the solution to use for
>>>> building
>>>> >> the
>>>> >> >>> library on Mono.
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> I have not tested that the editor build is working with anything
>>>> other
>>>> >> >>> than vs2015,  but I will test with the prior versions vs2012+ to
>>>> see
>>>> >> what
>>>> >> >>> all
>>>> >> >>> works, then put some info in the README.md about what IDE's the
>>>> Editor
>>>> >> >>> portion of the project can be built in.
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> On Tue, Nov 3, 2015 at 11:53 PM, Eric  <
>>>> e800 at gmail.com
>>>> >> >
>>>> >> >>> wrote:
>>>> >> >>>
>>>> >> >>>> Thanks for letting me know about this problem Jak.   (See the
>>>> bottom
>>>> >> for
>>>> >> >>>> TLDR :P)
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> I am using vs2015 and WiX 3.10.1, it does indeed seem to be a
>>>> problem
>>>> >> >>>> with vs2010 C#.
>>>> >> >>>>
>>>> >> >>>> I was unable to find an updated download for vs2010 C# to test
>>>> with,
>>>> >> >>>> only an SP1 ISO I found on stackoverflow:
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >>
>>>> http://stackoverflow.com/questions/6871865/url-for-visual-studio-2010-express-iso
>>>> >> >>>>
>>>> >> >>>> http://go.microsoft.com/?linkid=9709969
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> I tried installing vs2010, however this version will not
>>>> attempt to
>>>> >> open
>>>> >> >>>> my solution files at all as it says they are incompatible.
>>>> >> >>>>
>>>> >> >>>> I can however, load the .csproj files for certain projects in my
>>>> >> build.
>>>> >> >>>>
>>>> >> >>>> I cannot get it to update from SP1, I am unsure if updates are
>>>> still
>>>> >> >>>> available to download for vs2010.
>>>> >> >>>>
>>>> >> >>>> When I try to update, it just directs me to use windows update
>>>> which
>>>> >> >>>> does not seem to find any updates related to it.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> === Why it's not loading ===
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> With vs2010 SP1,  I was only able to load: LibLSLCC.csproj,
>>>> >> >>>> lslcc_cmd.csproj and DemoArea.csproj.
>>>> >> >>>>
>>>> >> >>>> LibraryDataScrapingTools was incompatible because it was
>>>> building
>>>> >> >>>> against .NET 4.5.
>>>> >> >>>>
>>>> >> >>>> I downgraded LibraryDataScrapingTools to .NET 4.0  and
>>>> re-installed
>>>> >> the
>>>> >> >>>> 'System.Data.Sqlite.Core' package from nuget using vs2015 in
>>>> order to
>>>> >> make
>>>> >> >>>> it load in vs2010.
>>>> >> >>>> I then made some code changes to make it compatible with .NET
>>>> 4.0.
>>>> >> >>>>
>>>> >> >>>> I will be committing the changes to LibraryDataScrapingTools
>>>> tonight,
>>>> >> as
>>>> >> >>>> this project is supposed to be .NET 4.0 compatible.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> The LSLCCEditor related projects I am pretty sure are
>>>> incompatible at
>>>> >> >>>> the moment due to the .NET framework level they require as well.
>>>> >> >>>>
>>>> >> >>>> The code base for LSLCCEditor requires a minimum of .NET 4.5 to
>>>> >> compile,
>>>> >> >>>> and the code changes required to make the editor projects
>>>> >> >>>> compatible with .NET 4.0 are not as trivial as the changes I
>>>> made to
>>>> >> the
>>>> >> >>>> LibraryDataScrapingTools project.
>>>> >> >>>>
>>>> >> >>>> I am not sure if I want to limit the LSLCCEditor part of the
>>>> project
>>>> >> to
>>>> >> >>>> a  .NET 4.0 at the moment, as it is a Windows
>>>> >> >>>> only WPF application, and that sort of compatibility profile is
>>>> not
>>>> >> >>>> necessary.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> I also noticed when installing WiX v3.10.1 on a Virtual Machine
>>>> with
>>>> >> >>>> vs2010 installed that It does not try to register itself with
>>>> vs2010
>>>> >> as a
>>>> >> >>>> project type.
>>>> >> >>>> I do not think the latest version of WiX installer framework
>>>> supports
>>>> >> >>>> vs2010 anymore.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> === How I got LibLSLCC, LibraryDataScrapingTools, lslcc_cmd and
>>>> >> DemoArea
>>>> >> >>>>  to build.  ===
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> After the code changes to LibraryDataScrapingTools and
>>>> downgrading the
>>>> >> >>>> .NET Framework level...
>>>> >> >>>>
>>>> >> >>>> I created a new vs2010 project and added (LibLSLCC,
>>>> >> >>>> LibraryDataScrapingTools, lslcc_cmd and DemoArea) as existing
>>>> >> projects.
>>>> >> >>>>
>>>> >> >>>> When trying to build these projects I got the message "Error 1
>>>> Invalid
>>>> >> >>>> option '5' for /langversion; must be ISO-1, ISO-2, 3 or Default"
>>>> >> >>>> for all of the projects except 'DemoArea'
>>>> >> >>>>
>>>> >> >>>> I resolved this by manually editing the .csproj file for each
>>>> >> >>>> non-building project in a text editor, removing the occurrences
>>>> of:
>>>> >> >>>>
>>>> >> >>>> <LangVersion>5</LangVersion>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> That particular MSBuild setting is not necessary for vs2015 or
>>>> Mono to
>>>> >> >>>> build the library anyway, so I am going to remove it and commit
>>>> the
>>>> >> changes.
>>>> >> >>>>
>>>> >> >>>> After that, LibLSLCC, LibraryDataScrapingTools, lslcc_cmd and
>>>> DemoArea
>>>> >> >>>> were all able to build under vs2010.
>>>> >> >>>>
>>>> >> >>>> ===
>>>> >> >>>>
>>>> >> >>>> That all being said,  I will be adding a vs2010 compatible
>>>> solution
>>>> >> file
>>>> >> >>>> to the repository that contains Projects:
>>>> >> >>>>
>>>> >> >>>> * LibLSLCC,
>>>> >> >>>> * lslcc_cmd
>>>> >> >>>> * LibraryDataScrapingTools
>>>> >> >>>> * DemoArea
>>>> >> >>>>
>>>> >> >>>> So that you can at-least build the library, command line
>>>> compiler,
>>>> >> >>>> library data scraper and demo project with vs2010.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> Unfortunately making LSLCCEditor build in vs2010 would require
>>>> some
>>>> >> non
>>>> >> >>>> trivial code changes, a new method of triggering the WiX
>>>> installer
>>>> >> build,
>>>> >> >>>> and a downgrade from .NET 4.5 to .NET 4.0 for the editor related
>>>> >> >>>> projects.
>>>> >> >>>>
>>>> >> >>>> I'm not sure if I want to make these changes to the Editor
>>>> portion of
>>>> >> >>>> the project just for the sake of being compatible with older
>>>> versions
>>>> >> of
>>>> >> >>>> Visual Studio.
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> On Tue, Nov 3, 2015 at 10:05 AM, Jak Daniels < <jak at ateb.co.uk>
>>>> >> >>>> jak at ateb.co.uk> wrote:
>>>> >> >>>>
>>>> >> >>>>> Hi Eric,
>>>> >> >>>>>
>>>> >> >>>>> Thank you for posting up your work to this group. This all
>>>> looks very
>>>> >> >>>>> promising, and I was intrigued to give it a try.
>>>> >> >>>>> I checked out the source from github and I tried building in
>>>> VS C#
>>>> >> 2010
>>>> >> >>>>> express... but only 3 of the projects will load.
>>>> >> LibraryDataScrapingTools,
>>>> >> >>>>> LSLCCEditor, LSLCCEditor.CompletionUI all say (incompatible)
>>>> and
>>>> >> >>>>> LSLCCEditorInstaller says (unavailable) even though I have WIX
>>>> 3.10.1
>>>> >> >>>>> installed.
>>>> >> >>>>>
>>>> >> >>>>> Is this a VS 2010 problem do you think?
>>>> >> >>>>>
>>>> >> >>>>> I'm a bit loathed to install VS2015 as the last time I
>>>> installed
>>>> >> VS2013
>>>> >> >>>>> it just dumped everything onto my SSD c: drive and filled it
>>>> up,
>>>> >> with no
>>>> >> >>>>> option to put things on drive D: my large harddrive. It also
>>>> left a
>>>> >> mess
>>>> >> >>>>> behind (more than 50% of itself including MSSQL server stuff)
>>>> when I
>>>> >> tried
>>>> >> >>>>> to uninstall it. VS2015 might be better now in this respect,
>>>> but
>>>> >> knowing MS
>>>> >> >>>>> products probably not! I also found VS2013 to be way, way
>>>> slower
>>>> >> loading up
>>>> >> >>>>> large projects like OpenSimulator than VS2010. So before I
>>>> take the
>>>> >> >>>>> possibly irreversible path of installing VS2015, is there
>>>> something
>>>> >> I can
>>>> >> >>>>> do to make it load in VS2010 express?
>>>> >> >>>>>
>>>> >> >>>>> Thanks
>>>> >> >>>>> Jak
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> On 02/11/2015 19:24, Eric  wrote:
>>>> >> >>>>>
>>>> >> >>>>> Hello all.
>>>> >> >>>>>
>>>> >> >>>>> I am a bit new to OpenSim development (well at-least sharing
>>>> stuff I
>>>> >> >>>>> have made..) but for a quite a while now I have been working on
>>>> >> >>>>> a new (BSD Licensed) Compilation/Code Generation framework for
>>>> LSL,
>>>> >> >>>>> tailored towards usage with OpenSim.  I thought I should share
>>>> it
>>>> >> >>>>> at this point of its development.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> This is pretty much a "full" or "true" compiler front end.
>>>> >> >>>>>
>>>> >> >>>>> It's built on-top of ANTLR4 and ANTLR4's CSharp target.
>>>> >> >>>>> ANTLR4 however has been completely abstracted and the library
>>>> >> provides
>>>> >> >>>>> its own Rich LSL Syntax Tree for users to deal with.
>>>> >> >>>>>
>>>> >> >>>>> My library includes an OpenSim code generation target which I
>>>> have
>>>> >> >>>>> integrated into my OpenSim fork on GitHub, it's implemented as
>>>> an
>>>> >> >>>>> optional compiler that you can enable in your OpenSim.ini.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> The Code validation step my library performs when building a
>>>> syntax
>>>> >> >>>>> tree implements full front end syntax checking, dead code
>>>> detection,
>>>> >> the
>>>> >> >>>>> works.
>>>> >> >>>>> It also emits extended warning information that is standard to
>>>> most
>>>> >> >>>>> compilers now days.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> The OpenSim code generator I have written and included with the
>>>> >> library
>>>> >> >>>>> drastically improves compatibility with scripts written for
>>>> >> SecondLife.
>>>> >> >>>>> Order of evaluation in generated code is correct for LSL
>>>> (Right to
>>>> >> >>>>> Left) among many other things.
>>>> >> >>>>>
>>>> >> >>>>> As an example, all of the encryption scripts you can find on
>>>> the LSL
>>>> >> >>>>> wiki will compile correctly and execute with correct behavior
>>>> using
>>>> >> my
>>>> >> >>>>> compiler.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> The README.md for the project goes into a bit more detail on
>>>> what all
>>>> >> >>>>> the library can do.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> My library LibLSLCC is on GitHub here:
>>>> >> >>>>>
>>>> >> >>>>> <https://github.com/EriHoss/LibLSLCC>
>>>> >> >>>>> https://github.com/EriHoss/LibLSLCC
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> The project includes an LSL Editor (Windows Only, I used
>>>> AvalonEdit)
>>>> >> >>>>> with the project that features code completion and syntax
>>>> >> highlighting.
>>>> >> >>>>>
>>>> >> >>>>> It can be used to test CSharp code generation for OpenSim by
>>>> >> compiling
>>>> >> >>>>> LSL into C# using LibLSLCC, which can then be uploaded to an
>>>> >> >>>>> OpenSim server with C# scripting enabled.
>>>> >> >>>>>
>>>> >> >>>>> The library itself is cross-platform, but the editor and editor
>>>> >> >>>>> installer are not.  There's a separate project file for
>>>> building the
>>>> >> >>>>> library on
>>>> >> >>>>> mono with monodevelop/xbuild.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> ===
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> The OpenSim fork that integrates my compiler is here:
>>>> >> >>>>>
>>>> >> >>>>> <https://github.com/EriHoss/OpenSim_With_LibLSLCC>
>>>> >> >>>>> https://github.com/EriHoss/OpenSim_With_LibLSLCC
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> It includes a few minor bug fixes to XEngine and Runtime Script
>>>> >> >>>>> functions.
>>>> >> >>>>>
>>>> >> >>>>> Such as the 'IdleTimeout' setting not being honored properly.
>>>> >> >>>>>
>>>> >> >>>>> And llParseString2List using culture specific comparisons,
>>>> causing it
>>>> >> >>>>> to misbehave when comparing Unicode characters on Mono.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> I have added new attributes to OpenSim's script module
>>>> >> >>>>> constants/functions and also to ScriptBaseClass.
>>>> >> >>>>> This is so LibLSLCC can de-serialize the classes into library
>>>> data
>>>> >> >>>>> that's consumable by its code validator and code generator.
>>>> >> >>>>>
>>>> >> >>>>> I have also made some slight changes to IScriptModuleComms and
>>>> >> >>>>> ScriptModuleCommsModule.
>>>> >> >>>>>
>>>> >> >>>>> The old compiler in my fork works as it did before, so you can
>>>> switch
>>>> >> >>>>> back and forth from LibLSLCC to the old compiler
>>>> >> >>>>> if you want without any problems.
>>>> >> >>>>>
>>>> >> >>>>> There are more details on the changes I have made in the
>>>> README.md.
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> ==
>>>> >> >>>>>
>>>> >> >>>>> I started working on this sometime early last year when I
>>>> broke my
>>>> >> >>>>> wrist and was unable to do much for a while, and
>>>> >> >>>>> I have only recently moved the code from my Git server up to
>>>> GitHub.
>>>> >> >>>>> I'm going to continue improving this in my spare time,
>>>> >> >>>>> right now I am doing rolling releases versioned by date
>>>> anywhere from
>>>> >> >>>>> once every few days to a few times a day.  I am also keeping my
>>>> >> OpenSim
>>>> >> >>>>> fork synced with the latest OpenSim commits.
>>>> >> >>>>>
>>>> >> >>>>> Hopefully this will be useful, any feedback is appreciated :)
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> _______________________________________________
>>>> >> >>>>> Opensim-dev mailing listOpensim-dev at opensimulator.orghttp://
>>>> >> opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> _______________________________________________
>>>> >> >>>>> Opensim-dev mailing list
>>>> >> >>>>> Opensim-dev at opensimulator.org
>>>> >> >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> _______________________________________________
>>>> >> >>> Opensim-dev mailing listOpensim-dev at opensimulator.orghttp://
>>>> >> opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> _______________________________________________
>>>> >> >>> Opensim-dev mailing list
>>>> >> >>> Opensim-dev at opensimulator.org
>>>> >> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >> >>>
>>>> >> >>>
>>>> >> >>
>>>> >> >> _______________________________________________
>>>> >> >> Opensim-dev mailing list
>>>> >> >> Opensim-dev at opensimulator.org
>>>> >> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >> >>
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > Opensim-dev mailing list
>>>> >> > Opensim-dev at opensimulator.org
>>>> >> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >> _______________________________________________
>>>> >> Opensim-dev mailing list
>>>> >> Opensim-dev at opensimulator.org
>>>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Opensim-dev mailing list
>>>> > Opensim-dev at opensimulator.org
>>>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at opensimulator.org
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151109/6e9589be/attachment-0001.html>