Hi, please change that to insert the calls unconditionally. The user can change the script stop strategy without wanting to recompile. The calls simply do nothing in preemptive stop mode.
- Melanie On 14/11/2015 01:21, Eric Blundell wrote: > I have no problem with integration, I'd love to see this put to use. I am > causing breaking changes quite often at the moment to the library though. > > If you would like me to help keep the integrated code up to date with my > latest I can do this. > > I am unsure what the mode of operation is for ongoing contributions, just > let me know. > > The compiler does inject co-op termination calls where necessary when co-op > script stop is enabled, the function it uses for this is also templated in > its configuration. > > The base class name and such is also drawn from XEngine the way the > previous compiler was set up. > On Nov 13, 2015 5:21 PM, "Melanie" <[email protected]> wrote: > >> Hi, >> >> what is your position on core integration for this? It does appear >> to be vastly superior and should not languish in an out-of-core >> repository. >> >> Also, does your compiler inject the cooperative termination calls? >> >> - Melanie >> >> On 14/11/2015 00:17, Eric Blundell 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 >> > >> >> _______________________________________________ >> 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
