Also excuse the typos. (phone, sorry) On Nov 13, 2015 5:17 PM, "Eric Blundell" <[email protected]> wrote:
> Just an update on this. > > I recently corrected a pretty large issue with modifying operations on > vector/rotation components being erroneously optimized away in certain > cases. > > The expression node property that recursively checks the an expression > tree for expressions with side effects was failing to recognize that result > of the '.' operator access node could be modified by certain assignment > and postfix/prefix operations. > > Therefore statements like: > > vec.x *= 2; or vec.y++; (ect..) > > Were interpreted as having no side effects. > > I found this problem from the MONO tests Blake pointed out on the wiki. > > == > > I've since put up a new release, the editor now contains a working config > pane for the compiler in the settings window, and uses a LibLSLCC binary > with the previously mentioned optimization fix. > > The compiler options pane is only partially field validated (need to write > validation stuff for method signatures, class inheritance list, and > constructor signature settings still) > > The OpenSim fork has been updated as well to contain the fix. > > I have also put some work into the experimental branch on my fork that > attempts to improves casts from strings to floats in all runtime types. It > adds formating support for NaN, Infinity (both pos and neg) as well as > preservation and printing of negative signed zeros. hex string to float > parsing has also been added. > > The changes to the runtime types in the experimental branch have not been > heavily tested yet, but seem to fix most of the formating/cast from string > issues present in the compiler compliance test from the wiki. > > Everything's still overflow checked, so that's still going to stop the > overflow tests from working of course, and quaternions still have > normalization differences (that's not really a correctable thing) > On Nov 9, 2015 5:20 PM, "Eric Blundell" <[email protected]> wrote: > >> TIL that that ([0,0] != [0,0]) is (length(left) - length(right)). >> interesting. >> >> On Mon, Nov 9, 2015 at 3:47 PM, Melanie <[email protected]> wrote: >> >>> 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 listOpensim-dev >>> @opensimulator.orghttp:// >>> > >>>>> >> 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 listOpensim-dev >>> @opensimulator.orghttp:// >>> > >>>>> >> 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 >>> >> >>
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
