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
