doesnt LL use their own forked version of mono? On Nov 9, 2015 10:38 AM, "Blake" <[email protected]> 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 Blundell <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 Blundell 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 <[email protected]> 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 Blundell 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" <[email protected]> >>>> 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 <[email protected]> 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 Blundell 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 Blundell < >>>> [email protected] >>>> >> > >>>> >> >>> 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 < <[email protected]> >>>> >> >>>> [email protected]> 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 Blundell 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 [email protected]:// >>>> >> opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>>> _______________________________________________ >>>> >> >>>>> Opensim-dev mailing list >>>> >> >>>>> [email protected] >>>> >> >>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> >>>>> >>>> >> >>>>> >>>> >> >>>> >>>> >> >>> >>>> >> >>> >>>> >> >>> _______________________________________________ >>>> >> >>> Opensim-dev mailing [email protected]:// >>>> >> opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> _______________________________________________ >>>> >> >>> Opensim-dev mailing list >>>> >> >>> [email protected] >>>> >> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> >>> >>>> >> >>> >>>> >> >> >>>> >> >> _______________________________________________ >>>> >> >> Opensim-dev mailing list >>>> >> >> [email protected] >>>> >> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> >> >>>> >> >> >>>> >> > >>>> >> > >>>> >> > >>>> >> > _______________________________________________ >>>> >> > Opensim-dev mailing list >>>> >> > [email protected] >>>> >> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> _______________________________________________ >>>> >> Opensim-dev mailing list >>>> >> [email protected] >>>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >> >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Opensim-dev mailing list >>>> > [email protected] >>>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>>> >>> >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >>> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
