<div dir="ltr">TIL that that ([0,0] != [0,0])  is (length(left) - length(right)).  interesting.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 3:47 PM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The [1] != [2,3] test would yield 1 because the c# notion of true is<br>
1, not -1.<br>
<br>
This can't be fixed because it's a Mono thing. A compiler cold work<br>
around it by identifying expressions yielding a boolean value and<br>
wrapping them, like so: ([1] != [2,3] != 0 ? -1 : 0)<br>
<br>
But that is ugly and inefficient.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Melanie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 09/11/2015 22:36, Eric Blundell wrote:<br>
> Blake,<br>
><br>
> I found the LSL language test on the wiki when I first started working on<br>
> the library,<br>
> I forgot where I got them and went looking for the other ones but could not<br>
> find them again.<br>
><br>
> These in particular:<br>
><br>
> <a href="http://wiki.secondlife.com/wiki/LSL_Language_Test" rel="noreferrer" target="_blank">http://wiki.secondlife.com/wiki/LSL_Language_Test</a><br>
> <a href="http://wiki.secondlife.com/wiki/LSL_Language_Test_2" rel="noreferrer" target="_blank">http://wiki.secondlife.com/wiki/LSL_Language_Test_2</a><br>
><br>
> There are a few current failures in the first test:<br>
><br>
> The first is due to quaternion division producing different (but valid)<br>
> results in OpenSim on line 436<br>
> The second is on line 471-473 and it is caused by an overflow exception<br>
> being thrown<br>
> The third is on line 480-482 and it is also caused by an overflow exception.<br>
><br>
> The rest of the failures are caused by the Float equality delta tests, and<br>
> comparing vectors/rotations cast to strings. (their formatting is slightly<br>
> different in opensim)<br>
><br>
><br>
> There are several in the second, due to vectors and rotations in OpenSims<br>
> runtime converting into strings with spaces after the commas.<br>
> In secondlife there are no spaces in the list of components that make up a<br>
> vector or rotation when its ToString()'d<br>
><br>
> And an instance of:  [1] != [2,3] (1 expected -1), on line 224 of<br>
> LSL_Language_Test_2 which is a runtime related thing I am curious to<br>
> investigate.<br>
><br>
><br>
> I am unsure if I should improve the actual runtime types, or fix<br>
> differences generating workaround code.<br>
><br>
> I am inclined to believe that the quaternion runtime type should probably<br>
> not be messed with besides fixing the ToString() formatting,<br>
> I am not sure what opinions there are on modifying the other existing types.<br>
><br>
> ==<br>
><br>
> All benchmark scripts on the page work and produce identical output to<br>
> second life.<br>
><br>
><br>
> LSL_Library_Call_Test_1 failed due to OpenSim using void for the return<br>
> type of llGiveMoney();, and also due to erroneous function parameters in<br>
> the script causing exceptions.<br>
><br>
> LSL_Library_Call_Test_2 compiles and fails due to erroneous parameters to<br>
> LSL functions causing exceptions, which halt the script.<br>
><br>
> Event_test_script fails due an issue with the order in which events are<br>
> called by OpenSim (I'm not exactly sure why).<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Nov 9, 2015 at 12:39 PM, Michael Emory Cerquoni <<br>
> <a href="mailto:nebadon2025@gmail.com">nebadon2025@gmail.com</a>> wrote:<br>
><br>
> > doesnt LL use their own forked version of mono?<br>
> > On Nov 9, 2015 10:38 AM, "Blake" <<a href="mailto:techplex.engineer@gmail.com">techplex.engineer@gmail.com</a>> wrote:<br>
> ><br>
> >> Eric,<br>
> >><br>
> >> Have you seen the Mono test scripts that SL used when they change<br>
> >> compilers from the legacy LSL to the Mono based one?<br>
> >> They might be a good benchmark. I know that a bunch of the test fail in<br>
> >> OS.<br>
> >><br>
> >> <a href="http://wiki.secondlife.com/wiki/Mono#Testing" rel="noreferrer" target="_blank">http://wiki.secondlife.com/wiki/Mono#Testing</a><br>
> >><br>
> >> Best,<br>
> >> Blake<br>
> >><br>
> >> On Mon, Nov 9, 2015 at 1:29 PM, Eric Blundell <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>><br>
> >> wrote:<br>
> >><br>
> >>> If yall believe that reverse compatibility should be thrown out the<br>
> >>> door, it makes everything much simpler.<br>
> >>><br>
> >>> I was under a preconceived notion for a bit that any sort of script<br>
> >>> breakage might cause the compiler to be a no go.<br>
> >>><br>
> >>> Fortunately all changes I mentioned are easy to make and reverse due to<br>
> >>> the, way the expression type evaluation and checking logic is segregated<br>
> >>> out in the library.<br>
> >>><br>
> >>><br>
> >>> At the moment I am tidying up some things and updating the build system,<br>
> >>> mainly to remove the platform specific binaries from the installer and<br>
> >>> binary releases;<br>
> >>> Also I am working on a settings UI for the editor.<br>
> >>><br>
> >>> I've just removed the tiny change from the library that allows for the<br>
> >>> compatibility options previously mentioned.<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> I have experienced a few problems as you mentioned with the default<br>
> >>> XEngine compiler, I have put at least one script through it that caused a<br>
> >>> stack heap<br>
> >>> and server crash in its current state.   It is this one:<br>
> >>> <a href="http://wiki.secondlife.com/wiki/BigNum" rel="noreferrer" target="_blank">http://wiki.secondlife.com/wiki/BigNum</a>,  however I have not<br>
> >>> investigated why it happens yet.  It does not<br>
> >>> happen when LibLSLCC is used for code generation.<br>
> >>><br>
> >>> I am pretty sure the crash happens in the default XEngine compiler<br>
> >>> itself and not in the running code.<br>
> >>><br>
> >>> Examples of either type of problem (in running code, or especially<br>
> >>> compiler related) would be helpful in testing LibLSLCC.<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> On Mon, Nov 9, 2015 at 10:25 AM, Zadark Portal <<a href="mailto:zadarkportal@gmail.com">zadarkportal@gmail.com</a>><br>
> >>> wrote:<br>
> >>><br>
> >>>> Hello Eric<br>
> >>>><br>
> >>>> I agree with the previous comment.<br>
> >>>><br>
> >>>> This contribution is such that we are now considering reintroducing<br>
> >>>> Opensim as an entry platform to scripting. Previously we found it<br>
> >>>> impossible to support larger class sizes due to the empirical nature of<br>
> >>>> novices producing non deterministic behaviours.<br>
> >>>><br>
> >>>> If when considering further developments may I suggest trapping<br>
> >>>> potentially dangerous (Opensim crash) scripted constructs. Maybe this is a<br>
> >>>> tall ask, but enormously beneficial to simulator operators managing<br>
> >>>> experimental behaviour of users attracted to Opensim. I have not included<br>
> >>>> examples but will to do so at your request.<br>
> >>>><br>
> >>>> It will be a couple of weeks before I can introduce the functionality<br>
> >>>> to a class and comment further, but whatever the future for this<br>
> >>>> contribution with regards to core we will continue make full use.<br>
> >>>><br>
> >>>> Regards<br>
> >>>> Z<br>
> >>>><br>
> >>>> On 9 November 2015 at 14:20, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
> >>>><br>
> >>>>> Please don't do all these things.<br>
> >>>>><br>
> >>>>> OpenSim is alpha software and there is no need to make the mistake<br>
> >>>>> other projects made and perpetuate bugs in the name of compatibility.<br>
> >>>>><br>
> >>>>> The cast to list is there because, afaik, in SL the operation list +<br>
> >>>>> scalar is legal and means to append an element. It's not meant to<br>
> >>>>> allow the other side effects you listed and they should be illegal.<br>
> >>>>><br>
> >>>>> There isn't a way to do these tests on crossings. That's also not<br>
> >>>>> necessary as the better compiler will be used by all in short order.<br>
> >>>>> People will fix their scripts and everyone will be happy again.<br>
> >>>>><br>
> >>>>> Let's not breed bugs, but let's squish them instead.<br>
> >>>>><br>
> >>>>> - Melanie<br>
> >>>>><br>
> >>>>> On 09/11/2015 11:50, Eric Blundell wrote:<br>
> >>>>> > You're right actually.<br>
> >>>>> ><br>
> >>>>> > Since stuff like old LSO list/string optimization hacks were not<br>
> >>>>> possible<br>
> >>>>> > beforehand while using XEngines compiler,<br>
> >>>>> > there is probably not to many people with code that's going to behave<br>
> >>>>> > incorrectly with the evaluation order of binary<br>
> >>>>> > operations switched.  The scripts that happen to break are doing<br>
> >>>>> something<br>
> >>>>> > pretty wacky/unnecessary.<br>
> >>>>> ><br>
> >>>>> > There's not any micro optimizations that I know of relying on the<br>
> >>>>> old left<br>
> >>>>> > to right evaluation order either.<br>
> >>>>> ><br>
> >>>>> > ==<br>
> >>>>> ><br>
> >>>>> > That being said, there are many things the XEngine default compiler<br>
> >>>>> will<br>
> >>>>> > allow to compile that are infact<br>
> >>>>> > syntactically incorrect in LSL.  stuff like negating<br>
> >>>>> vectors/rotations in<br>
> >>>>> > global variable declarations<br>
> >>>>> > as well as doing cast in static context.  In general the default<br>
> >>>>> XEngine<br>
> >>>>> > compiler's rules for global variable<br>
> >>>>> > declaration expression content are very lax in comparison to the<br>
> >>>>> secondlife<br>
> >>>>> > compiler, and that is just one example.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > LibLSLCC's goal to mimic the secondlife compiler's rules exactly, in<br>
> >>>>> its<br>
> >>>>> > default configuration.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > From my understanding a script moving to new a region is going to be<br>
> >>>>> > recompiled if the destination sim does not allow the script binary<br>
> >>>>> > to transfer over and be executed.  This will be true in most cases<br>
> >>>>> because<br>
> >>>>> > the default settings disallow it, and it's unsafe to enable.<br>
> >>>>> ><br>
> >>>>> > This would cause a problem for scripts from another region that<br>
> >>>>> LibLSLCC<br>
> >>>>> > deems to contain syntax errors.<br>
> >>>>> ><br>
> >>>>> > I may to have to dig into OpenSim to see how region crossing for<br>
> >>>>> scripts<br>
> >>>>> > work; to see if I have to make the re-compile sensitive<br>
> >>>>> >  to which compiler was used on the other sim, regardless of what<br>
> >>>>> version of<br>
> >>>>> > OpenSim it is running.<br>
> >>>>> ><br>
> >>>>> > I imagine this would be a requirement to connect a sim to a grid<br>
> >>>>> containing<br>
> >>>>> > regions not using my compiler addon.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > ==<br>
> >>>>> ><br>
> >>>>> > I tested the library build on OS X Snow leopard 10.6 and OS X El<br>
> >>>>> Capitan<br>
> >>>>> > 10.11.<br>
> >>>>> ><br>
> >>>>> > Building LibLSLCC-NoEditor.sln works as intended.<br>
> >>>>> ><br>
> >>>>> > The command line program lslcc that's part of LibLSLCC works fine on<br>
> >>>>> both<br>
> >>>>> > and has no problem generating code.<br>
> >>>>> ><br>
> >>>>> > LibraryDataScrapingTools works on OSX 10.11 even with its WinForms<br>
> >>>>> dialogs,<br>
> >>>>> > and the OpenSim fork works fine to.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > However, when I tested with OSX 10.6 I ran into an issue where mono<br>
> >>>>> > complained about missing System.Drawing.GDIPlus.<br>
> >>>>> ><br>
> >>>>> > I'm sure there's probably a way to fix this but I did not look into<br>
> >>>>> it to<br>
> >>>>> > deeply as I was using a borrowed computer for a few minutes,<br>
> >>>>> > that error prevented both LibraryDataScrapingTools and OpenSim from<br>
> >>>>> > starting.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > ==<br>
> >>>>> ><br>
> >>>>> > As of now I have added a setting to allow implicit cast of all types<br>
> >>>>> into<br>
> >>>>> > list within a function<br>
> >>>>> > calls parameter expressions, as Zadark had mentioned.<br>
> >>>>> ><br>
> >>>>> > As it turns out, all of OpenSim's C# runtime types contain an<br>
> >>>>> implicit<br>
> >>>>> > conversion operator to list.<br>
> >>>>> ><br>
> >>>>> > It happens regardless of context.<br>
> >>>>> ><br>
> >>>>> > So The default XEngine compiler allows stuff like this too:<br>
> >>>>> ><br>
> >>>>> > list a = "";<br>
> >>>>> ><br>
> >>>>> > list b = <0,0,0>;<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > I will probably change the setting to just allow implicit list cast<br>
> >>>>> > everywhere as an option,<br>
> >>>>> > and maybe add some syntax related compatibility options for global<br>
> >>>>> > variables.<br>
> >>>>> ><br>
> >>>>> > In the long run, if I can figure out how to make the compiler addon<br>
> >>>>> aware<br>
> >>>>> > of re-compiles due to region<br>
> >>>>> > crossing, some syntax in-compatibility will not be a major issue for<br>
> >>>>> > scripts that you cannot modify.<br>
> >>>>> ><br>
> >>>>> > If I could somehow select to re-compile them with the default XEngine<br>
> >>>>> > compiler  (if that's what they were originally compiled with),<br>
> >>>>> > then they will not be subject to LibLSLCC's stricter syntax checking.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > ==<br>
> >>>>> ><br>
> >>>>> > I have been working on a settings panel for the editor so I can<br>
> >>>>> easily test<br>
> >>>>> > different<br>
> >>>>> > compiler configurations, and segregating some of the editor code out<br>
> >>>>> into<br>
> >>>>> > different assemblies;<br>
> >>>>> > it will take me a little bit to finish.<br>
> >>>>> ><br>
> >>>>> > I'm currently working out of the development branch on github, I'll<br>
> >>>>> put up<br>
> >>>>> > a new editor installer<br>
> >>>>> > when I get the configuration stuff all worked out.<br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > On Sat, Nov 7, 2015 at 8:46 AM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
> >>>>> ><br>
> >>>>> >> I would be against making the evaluation order optional. It has long<br>
> >>>>> >> been recognized as a bug in XEngine's compiler and people porting<br>
> >>>>> >> scripts from SL have been advised to remove evaluation order<br>
> >>>>> >> dependent code but not write any code that depends on the wrong<br>
> >>>>> >> XEngine eval order. Therefore, if this compiler breaks content that<br>
> >>>>> >> content needs to be fixed, not a setting changed for convenience to<br>
> >>>>> >> perpetuate the bad behavior.<br>
> >>>>> >><br>
> >>>>> >> - Melanie<br>
> >>>>> >><br>
> >>>>> >> On 07/11/2015 15:36, Eric Blundell wrote:<br>
> >>>>> >> > Thanks Again Zadark<br>
> >>>>> >> ><br>
> >>>>> >> > This should be easy to fix, I need to change the type validation<br>
> >>>>> system<br>
> >>>>> >> > just little so the syntax tree can be built with these types of<br>
> >>>>> implicit<br>
> >>>>> >> > conversion present.<br>
> >>>>> >> ><br>
> >>>>> >> > The code generator can then be made to generate the cast when<br>
> >>>>> necessary,<br>
> >>>>> >> > since it will pass syntax checking.<br>
> >>>>> >> ><br>
> >>>>> >> > I think I am going to implement it as a compatibility option in<br>
> >>>>> the<br>
> >>>>> >> > compiler that you can turn on or off, depending on if you want<br>
> >>>>> the linden<br>
> >>>>> >> > compilers more strict type checking behavior.<br>
> >>>>> >> ><br>
> >>>>> >> > I should also probably make order of evaluation correction on<br>
> >>>>> binary<br>
> >>>>> >> > operations something you can disable if needed, since I can see<br>
> >>>>> that<br>
> >>>>> >> > causing compatibility problems somewhere too.<br>
> >>>>> >> ><br>
> >>>>> >> > Side Note:  I have not tested on Mac yet, but I plan to do so<br>
> >>>>> today if I<br>
> >>>>> >> > can get time to, sorry.<br>
> >>>>> >> > On Nov 7, 2015 7:42 AM, "Zadark Portal" <<a href="mailto:zadarkportal@gmail.com">zadarkportal@gmail.com</a>><br>
> >>>>> wrote:<br>
> >>>>> >> ><br>
> >>>>> >> >> Hello Eric,<br>
> >>>>> >> >><br>
> >>>>> >> >> Very useful, thankyou.<br>
> >>>>> >> >><br>
> >>>>> >> >> Caveat<br>
> >>>>> >> >> XEngine appears to cast library function parameters to the<br>
> >>>>> relevant<br>
> >>>>> >> type,<br>
> >>>>> >> >> though I can see this handy for novice scriptwriters it does<br>
> >>>>> encourage<br>
> >>>>> >> some<br>
> >>>>> >> >> less than elegant techniques<br>
> >>>>> >> >><br>
> >>>>> >> >> Some popular scripts freely available to OpenSim use this<br>
> >>>>> feature:<br>
> >>>>> >> >> For instance:<br>
> >>>>> >> >> llListFindList takes 2 parameters of the type List, when in fact<br>
> >>>>> the<br>
> >>>>> >> >> existing compiler permits any type (as far as we have tested).<br>
> >>>>> >> >><br>
> >>>>> >> >> example... integer  bah = llListFindList( blah1,<br>
> >>>>> llList2String(blah2,<br>
> >>>>> >> >> blah3)); // compiles and kind of works.<br>
> >>>>> >> >><br>
> >>>>> >> >> This of course fails when compiled with LSLcc, the explanation<br>
> >>>>> is clear<br>
> >>>>> >> >> and precise so easy to fix (enable compile) with a local cast.<br>
> >>>>> >> >><br>
> >>>>> >> >> Z<br>
> >>>>> >> >><br>
> >>>>> >> >><br>
> >>>>> >> >> On 5 November 2015 at 12:52, Jak Daniels <<a href="mailto:jak@ateb.co.uk">jak@ateb.co.uk</a>> wrote:<br>
> >>>>> >> >><br>
> >>>>> >> >>> Hi Eric,<br>
> >>>>> >> >>><br>
> >>>>> >> >>> yes I can confirm now that it does open and compile correctly<br>
> >>>>> in VS C#<br>
> >>>>> >> >>> 2010 express now. Thank you.<br>
> >>>>> >> >>><br>
> >>>>> >> >>> I'm now installing VS2015 in a win10 virtual machine so I don't<br>
> >>>>> clobber<br>
> >>>>> >> >>> my SSD, so I can compile and play with the LSL editor.<br>
> >>>>> >> >>><br>
> >>>>> >> >>> kind regards<br>
> >>>>> >> >>> Jak<br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>> On 04/11/2015 06:10, Eric Blundell wrote:<br>
> >>>>> >> >>><br>
> >>>>> >> >>> Let me just make a slight correction to my last message, and<br>
> >>>>> add some<br>
> >>>>> >> >>> info...<br>
> >>>>> >> >>><br>
> >>>>> >> >>> After removing the "<LangVersion>5</LangVersion>" stuff from the<br>
> >>>>> >> >>> non-editor related .csproj files,<br>
> >>>>> >> >>><br>
> >>>>> >> >>> I found that VS2010 is actually able to open the<br>
> >>>>> >> >>> "MonoDevelop-LibLSLCC.sln" solution file in the source tree and<br>
> >>>>> build<br>
> >>>>> >> it<br>
> >>>>> >> >>> without any problems.<br>
> >>>>> >> >>><br>
> >>>>> >> >>> I'm going to be pushing the changes I made to the .csproj files<br>
> >>>>> >> shortly,<br>
> >>>>> >> >>>  I will probably rename "MonoDevelop-LibLSLCC.sln" to something<br>
> >>>>> like<br>
> >>>>> >> >>> "LibLSLCC-No-Editor.sln" and update the build instructions in<br>
> >>>>> the<br>
> >>>>> >> >>> README.md to specify that solution as the solution to use for<br>
> >>>>> building<br>
> >>>>> >> the<br>
> >>>>> >> >>> library on Mono.<br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>> I have not tested that the editor build is working with<br>
> >>>>> anything other<br>
> >>>>> >> >>> than vs2015,  but I will test with the prior versions vs2012+<br>
> >>>>> to see<br>
> >>>>> >> what<br>
> >>>>> >> >>> all<br>
> >>>>> >> >>> works, then put some info in the README.md about what IDE's the<br>
> >>>>> Editor<br>
> >>>>> >> >>> portion of the project can be built in.<br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>> On Tue, Nov 3, 2015 at 11:53 PM, Eric Blundell <<br>
> >>>>> <a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a><br>
> >>>>> >> ><br>
> >>>>> >> >>> wrote:<br>
> >>>>> >> >>><br>
> >>>>> >> >>>> Thanks for letting me know about this problem Jak.   (See the<br>
> >>>>> bottom<br>
> >>>>> >> for<br>
> >>>>> >> >>>> TLDR :P)<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I am using vs2015 and WiX 3.10.1, it does indeed seem to be a<br>
> >>>>> problem<br>
> >>>>> >> >>>> with vs2010 C#.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I was unable to find an updated download for vs2010 C# to test<br>
> >>>>> with,<br>
> >>>>> >> >>>> only an SP1 ISO I found on stackoverflow:<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >><br>
> >>>>> <a href="http://stackoverflow.com/questions/6871865/url-for-visual-studio-2010-express-iso" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/6871865/url-for-visual-studio-2010-express-iso</a><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> <a href="http://go.microsoft.com/?linkid=9709969" rel="noreferrer" target="_blank">http://go.microsoft.com/?linkid=9709969</a><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I tried installing vs2010, however this version will not<br>
> >>>>> attempt to<br>
> >>>>> >> open<br>
> >>>>> >> >>>> my solution files at all as it says they are incompatible.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I can however, load the .csproj files for certain projects in<br>
> >>>>> my<br>
> >>>>> >> build.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I cannot get it to update from SP1, I am unsure if updates are<br>
> >>>>> still<br>
> >>>>> >> >>>> available to download for vs2010.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> When I try to update, it just directs me to use windows update<br>
> >>>>> which<br>
> >>>>> >> >>>> does not seem to find any updates related to it.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> === Why it's not loading ===<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> With vs2010 SP1,  I was only able to load: LibLSLCC.csproj,<br>
> >>>>> >> >>>> lslcc_cmd.csproj and DemoArea.csproj.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> LibraryDataScrapingTools was incompatible because it was<br>
> >>>>> building<br>
> >>>>> >> >>>> against .NET 4.5.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I downgraded LibraryDataScrapingTools to .NET 4.0  and<br>
> >>>>> re-installed<br>
> >>>>> >> the<br>
> >>>>> >> >>>> 'System.Data.Sqlite.Core' package from nuget using vs2015 in<br>
> >>>>> order to<br>
> >>>>> >> make<br>
> >>>>> >> >>>> it load in vs2010.<br>
> >>>>> >> >>>> I then made some code changes to make it compatible with .NET<br>
> >>>>> 4.0.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I will be committing the changes to LibraryDataScrapingTools<br>
> >>>>> tonight,<br>
> >>>>> >> as<br>
> >>>>> >> >>>> this project is supposed to be .NET 4.0 compatible.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> The LSLCCEditor related projects I am pretty sure are<br>
> >>>>> incompatible at<br>
> >>>>> >> >>>> the moment due to the .NET framework level they require as<br>
> >>>>> well.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> The code base for LSLCCEditor requires a minimum of .NET 4.5 to<br>
> >>>>> >> compile,<br>
> >>>>> >> >>>> and the code changes required to make the editor projects<br>
> >>>>> >> >>>> compatible with .NET 4.0 are not as trivial as the changes I<br>
> >>>>> made to<br>
> >>>>> >> the<br>
> >>>>> >> >>>> LibraryDataScrapingTools project.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I am not sure if I want to limit the LSLCCEditor part of the<br>
> >>>>> project<br>
> >>>>> >> to<br>
> >>>>> >> >>>> a  .NET 4.0 at the moment, as it is a Windows<br>
> >>>>> >> >>>> only WPF application, and that sort of compatibility profile<br>
> >>>>> is not<br>
> >>>>> >> >>>> necessary.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I also noticed when installing WiX v3.10.1 on a Virtual<br>
> >>>>> Machine with<br>
> >>>>> >> >>>> vs2010 installed that It does not try to register itself with<br>
> >>>>> vs2010<br>
> >>>>> >> as a<br>
> >>>>> >> >>>> project type.<br>
> >>>>> >> >>>> I do not think the latest version of WiX installer framework<br>
> >>>>> supports<br>
> >>>>> >> >>>> vs2010 anymore.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> === How I got LibLSLCC, LibraryDataScrapingTools, lslcc_cmd and<br>
> >>>>> >> DemoArea<br>
> >>>>> >> >>>>  to build.  ===<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> After the code changes to LibraryDataScrapingTools and<br>
> >>>>> downgrading the<br>
> >>>>> >> >>>> .NET Framework level...<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I created a new vs2010 project and added (LibLSLCC,<br>
> >>>>> >> >>>> LibraryDataScrapingTools, lslcc_cmd and DemoArea) as existing<br>
> >>>>> >> projects.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> When trying to build these projects I got the message "Error 1<br>
> >>>>> Invalid<br>
> >>>>> >> >>>> option '5' for /langversion; must be ISO-1, ISO-2, 3 or<br>
> >>>>> Default"<br>
> >>>>> >> >>>> for all of the projects except 'DemoArea'<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I resolved this by manually editing the .csproj file for each<br>
> >>>>> >> >>>> non-building project in a text editor, removing the<br>
> >>>>> occurrences of:<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> <LangVersion>5</LangVersion><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> That particular MSBuild setting is not necessary for vs2015 or<br>
> >>>>> Mono to<br>
> >>>>> >> >>>> build the library anyway, so I am going to remove it and<br>
> >>>>> commit the<br>
> >>>>> >> changes.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> After that, LibLSLCC, LibraryDataScrapingTools, lslcc_cmd and<br>
> >>>>> DemoArea<br>
> >>>>> >> >>>> were all able to build under vs2010.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> ===<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> That all being said,  I will be adding a vs2010 compatible<br>
> >>>>> solution<br>
> >>>>> >> file<br>
> >>>>> >> >>>> to the repository that contains Projects:<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> * LibLSLCC,<br>
> >>>>> >> >>>> * lslcc_cmd<br>
> >>>>> >> >>>> * LibraryDataScrapingTools<br>
> >>>>> >> >>>> * DemoArea<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> So that you can at-least build the library, command line<br>
> >>>>> compiler,<br>
> >>>>> >> >>>> library data scraper and demo project with vs2010.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> Unfortunately making LSLCCEditor build in vs2010 would require<br>
> >>>>> some<br>
> >>>>> >> non<br>
> >>>>> >> >>>> trivial code changes, a new method of triggering the WiX<br>
> >>>>> installer<br>
> >>>>> >> build,<br>
> >>>>> >> >>>> and a downgrade from .NET 4.5 to .NET 4.0 for the editor<br>
> >>>>> related<br>
> >>>>> >> >>>> projects.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> I'm not sure if I want to make these changes to the Editor<br>
> >>>>> portion of<br>
> >>>>> >> >>>> the project just for the sake of being compatible with older<br>
> >>>>> versions<br>
> >>>>> >> of<br>
> >>>>> >> >>>> Visual Studio.<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>>> On Tue, Nov 3, 2015 at 10:05 AM, Jak Daniels < <<a href="mailto:jak@ateb.co.uk">jak@ateb.co.uk</a><br>
> >>>>> ><br>
> >>>>> >> >>>> <a href="mailto:jak@ateb.co.uk">jak@ateb.co.uk</a>> wrote:<br>
> >>>>> >> >>>><br>
> >>>>> >> >>>>> Hi Eric,<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> Thank you for posting up your work to this group. This all<br>
> >>>>> looks very<br>
> >>>>> >> >>>>> promising, and I was intrigued to give it a try.<br>
> >>>>> >> >>>>> I checked out the source from github and I tried building in<br>
> >>>>> VS C#<br>
> >>>>> >> 2010<br>
> >>>>> >> >>>>> express... but only 3 of the projects will load.<br>
> >>>>> >> LibraryDataScrapingTools,<br>
> >>>>> >> >>>>> LSLCCEditor, LSLCCEditor.CompletionUI all say (incompatible)<br>
> >>>>> and<br>
> >>>>> >> >>>>> LSLCCEditorInstaller says (unavailable) even though I have<br>
> >>>>> WIX 3.10.1<br>
> >>>>> >> >>>>> installed.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> Is this a VS 2010 problem do you think?<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> I'm a bit loathed to install VS2015 as the last time I<br>
> >>>>> installed<br>
> >>>>> >> VS2013<br>
> >>>>> >> >>>>> it just dumped everything onto my SSD c: drive and filled it<br>
> >>>>> up,<br>
> >>>>> >> with no<br>
> >>>>> >> >>>>> option to put things on drive D: my large harddrive. It also<br>
> >>>>> left a<br>
> >>>>> >> mess<br>
> >>>>> >> >>>>> behind (more than 50% of itself including MSSQL server stuff)<br>
> >>>>> when I<br>
> >>>>> >> tried<br>
> >>>>> >> >>>>> to uninstall it. VS2015 might be better now in this respect,<br>
> >>>>> but<br>
> >>>>> >> knowing MS<br>
> >>>>> >> >>>>> products probably not! I also found VS2013 to be way, way<br>
> >>>>> slower<br>
> >>>>> >> loading up<br>
> >>>>> >> >>>>> large projects like OpenSimulator than VS2010. So before I<br>
> >>>>> take the<br>
> >>>>> >> >>>>> possibly irreversible path of installing VS2015, is there<br>
> >>>>> something<br>
> >>>>> >> I can<br>
> >>>>> >> >>>>> do to make it load in VS2010 express?<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> Thanks<br>
> >>>>> >> >>>>> Jak<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> On 02/11/2015 19:24, Eric Blundell wrote:<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> Hello all.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> I am a bit new to OpenSim development (well at-least sharing<br>
> >>>>> stuff I<br>
> >>>>> >> >>>>> have made..) but for a quite a while now I have been working<br>
> >>>>> on<br>
> >>>>> >> >>>>> a new (BSD Licensed) Compilation/Code Generation framework<br>
> >>>>> for LSL,<br>
> >>>>> >> >>>>> tailored towards usage with OpenSim.  I thought I should<br>
> >>>>> share it<br>
> >>>>> >> >>>>> at this point of its development.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> This is pretty much a "full" or "true" compiler front end.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> It's built on-top of ANTLR4 and ANTLR4's CSharp target.<br>
> >>>>> >> >>>>> ANTLR4 however has been completely abstracted and the library<br>
> >>>>> >> provides<br>
> >>>>> >> >>>>> its own Rich LSL Syntax Tree for users to deal with.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> My library includes an OpenSim code generation target which I<br>
> >>>>> have<br>
> >>>>> >> >>>>> integrated into my OpenSim fork on GitHub, it's implemented<br>
> >>>>> as an<br>
> >>>>> >> >>>>> optional compiler that you can enable in your OpenSim.ini.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The Code validation step my library performs when building a<br>
> >>>>> syntax<br>
> >>>>> >> >>>>> tree implements full front end syntax checking, dead code<br>
> >>>>> detection,<br>
> >>>>> >> the<br>
> >>>>> >> >>>>> works.<br>
> >>>>> >> >>>>> It also emits extended warning information that is standard<br>
> >>>>> to most<br>
> >>>>> >> >>>>> compilers now days.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The OpenSim code generator I have written and included with<br>
> >>>>> the<br>
> >>>>> >> library<br>
> >>>>> >> >>>>> drastically improves compatibility with scripts written for<br>
> >>>>> >> SecondLife.<br>
> >>>>> >> >>>>> Order of evaluation in generated code is correct for LSL<br>
> >>>>> (Right to<br>
> >>>>> >> >>>>> Left) among many other things.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> As an example, all of the encryption scripts you can find on<br>
> >>>>> the LSL<br>
> >>>>> >> >>>>> wiki will compile correctly and execute with correct behavior<br>
> >>>>> using<br>
> >>>>> >> my<br>
> >>>>> >> >>>>> compiler.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The README.md for the project goes into a bit more detail on<br>
> >>>>> what all<br>
> >>>>> >> >>>>> the library can do.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> My library LibLSLCC is on GitHub here:<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> <<a href="https://github.com/EriHoss/LibLSLCC" rel="noreferrer" target="_blank">https://github.com/EriHoss/LibLSLCC</a>><br>
> >>>>> >> >>>>> <a href="https://github.com/EriHoss/LibLSLCC" rel="noreferrer" target="_blank">https://github.com/EriHoss/LibLSLCC</a><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The project includes an LSL Editor (Windows Only, I used<br>
> >>>>> AvalonEdit)<br>
> >>>>> >> >>>>> with the project that features code completion and syntax<br>
> >>>>> >> highlighting.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> It can be used to test CSharp code generation for OpenSim by<br>
> >>>>> >> compiling<br>
> >>>>> >> >>>>> LSL into C# using LibLSLCC, which can then be uploaded to an<br>
> >>>>> >> >>>>> OpenSim server with C# scripting enabled.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The library itself is cross-platform, but the editor and<br>
> >>>>> editor<br>
> >>>>> >> >>>>> installer are not.  There's a separate project file for<br>
> >>>>> building the<br>
> >>>>> >> >>>>> library on<br>
> >>>>> >> >>>>> mono with monodevelop/xbuild.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> ===<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The OpenSim fork that integrates my compiler is here:<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> <<a href="https://github.com/EriHoss/OpenSim_With_LibLSLCC" rel="noreferrer" target="_blank">https://github.com/EriHoss/OpenSim_With_LibLSLCC</a>><br>
> >>>>> >> >>>>> <a href="https://github.com/EriHoss/OpenSim_With_LibLSLCC" rel="noreferrer" target="_blank">https://github.com/EriHoss/OpenSim_With_LibLSLCC</a><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> It includes a few minor bug fixes to XEngine and Runtime<br>
> >>>>> Script<br>
> >>>>> >> >>>>> functions.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> Such as the 'IdleTimeout' setting not being honored properly.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> And llParseString2List using culture specific comparisons,<br>
> >>>>> causing it<br>
> >>>>> >> >>>>> to misbehave when comparing Unicode characters on Mono.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> I have added new attributes to OpenSim's script module<br>
> >>>>> >> >>>>> constants/functions and also to ScriptBaseClass.<br>
> >>>>> >> >>>>> This is so LibLSLCC can de-serialize the classes into library<br>
> >>>>> data<br>
> >>>>> >> >>>>> that's consumable by its code validator and code generator.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> I have also made some slight changes to IScriptModuleComms and<br>
> >>>>> >> >>>>> ScriptModuleCommsModule.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> The old compiler in my fork works as it did before, so you<br>
> >>>>> can switch<br>
> >>>>> >> >>>>> back and forth from LibLSLCC to the old compiler<br>
> >>>>> >> >>>>> if you want without any problems.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> There are more details on the changes I have made in the<br>
> >>>>> README.md.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> ==<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> I started working on this sometime early last year when I<br>
> >>>>> broke my<br>
> >>>>> >> >>>>> wrist and was unable to do much for a while, and<br>
> >>>>> >> >>>>> I have only recently moved the code from my Git server up to<br>
> >>>>> GitHub.<br>
> >>>>> >> >>>>> I'm going to continue improving this in my spare time,<br>
> >>>>> >> >>>>> right now I am doing rolling releases versioned by date<br>
> >>>>> anywhere from<br>
> >>>>> >> >>>>> once every few days to a few times a day.  I am also keeping<br>
> >>>>> my<br>
> >>>>> >> OpenSim<br>
> >>>>> >> >>>>> fork synced with the latest OpenSim commits.<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> Hopefully this will be useful, any feedback is appreciated :)<br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> _______________________________________________<br>
> >>>>> >> >>>>> Opensim-dev mailing listOpensim-dev@opensimulator.orghttp://<br>
> >>>>> >> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>> _______________________________________________<br>
> >>>>> >> >>>>> Opensim-dev mailing list<br>
> >>>>> >> >>>>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> >> >>>>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>>><br>
> >>>>> >> >>>><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>> _______________________________________________<br>
> >>>>> >> >>> Opensim-dev mailing listOpensim-dev@opensimulator.orghttp://<br>
> >>>>> >> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >>> _______________________________________________<br>
> >>>>> >> >>> Opensim-dev mailing list<br>
> >>>>> >> >>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> >> >>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >> >>><br>
> >>>>> >> >>><br>
> >>>>> >> >><br>
> >>>>> >> >> _______________________________________________<br>
> >>>>> >> >> Opensim-dev mailing list<br>
> >>>>> >> >> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> >> >> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >> >><br>
> >>>>> >> >><br>
> >>>>> >> ><br>
> >>>>> >> ><br>
> >>>>> >> ><br>
> >>>>> >> > _______________________________________________<br>
> >>>>> >> > Opensim-dev mailing list<br>
> >>>>> >> > <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> >> > <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >> _______________________________________________<br>
> >>>>> >> Opensim-dev mailing list<br>
> >>>>> >> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> >> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> >><br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> ><br>
> >>>>> > _______________________________________________<br>
> >>>>> > Opensim-dev mailing list<br>
> >>>>> > <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> > <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>> _______________________________________________<br>
> >>>>> Opensim-dev mailing list<br>
> >>>>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> Opensim-dev mailing list<br>
> >>>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>>><br>
> >>>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> Opensim-dev mailing list<br>
> >>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >>><br>
> >>><br>
> >><br>
> >> _______________________________________________<br>
> >> Opensim-dev mailing list<br>
> >> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> >> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> >><br>
> >><br>
> > _______________________________________________<br>
> > Opensim-dev mailing list<br>
> > <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> > <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> ><br>
> ><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>