The [1] != [2,3] test would yield 1 because the c# notion of true is 1, not -1.
This can't be fixed because it's a Mono thing. A compiler cold work around it by identifying expressions yielding a boolean value and wrapping them, like so: ([1] != [2,3] != 0 ? -1 : 0) But that is ugly and inefficient. - Melanie On 09/11/2015 22:36, Eric Blundell wrote: > Blake, > > I found the LSL language test on the wiki when I first started working on > the library, > I forgot where I got them and went looking for the other ones but could not > find them again. > > These in particular: > > http://wiki.secondlife.com/wiki/LSL_Language_Test > http://wiki.secondlife.com/wiki/LSL_Language_Test_2 > > There are a few current failures in the first test: > > The first is due to quaternion division producing different (but valid) > results in OpenSim on line 436 > The second is on line 471-473 and it is caused by an overflow exception > being thrown > The third is on line 480-482 and it is also caused by an overflow exception. > > The rest of the failures are caused by the Float equality delta tests, and > comparing vectors/rotations cast to strings. (their formatting is slightly > different in opensim) > > > There are several in the second, due to vectors and rotations in OpenSims > runtime converting into strings with spaces after the commas. > In secondlife there are no spaces in the list of components that make up a > vector or rotation when its ToString()'d > > And an instance of: [1] != [2,3] (1 expected -1), on line 224 of > LSL_Language_Test_2 which is a runtime related thing I am curious to > investigate. > > > I am unsure if I should improve the actual runtime types, or fix > differences generating workaround code. > > I am inclined to believe that the quaternion runtime type should probably > not be messed with besides fixing the ToString() formatting, > I am not sure what opinions there are on modifying the other existing types. > > == > > All benchmark scripts on the page work and produce identical output to > second life. > > > LSL_Library_Call_Test_1 failed due to OpenSim using void for the return > type of llGiveMoney();, and also due to erroneous function parameters in > the script causing exceptions. > > LSL_Library_Call_Test_2 compiles and fails due to erroneous parameters to > LSL functions causing exceptions, which halt the script. > > Event_test_script fails due an issue with the order in which events are > called by OpenSim (I'm not exactly sure why). > > > > > > > > On Mon, Nov 9, 2015 at 12:39 PM, Michael Emory Cerquoni < > [email protected]> wrote: > > > 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 > > > > > > > > _______________________________________________ > 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
