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
