<div dir="ltr"><div>You're right actually.</div><div><br></div><div>Since stuff like old LSO list/string optimization hacks were not possible beforehand while using XEngines compiler,</div><div>there is probably not to many people with code that's going to behave incorrectly with the evaluation order of binary</div><div>operations switched.  The scripts that happen to break are doing something pretty wacky/unnecessary.</div><div><br></div><div>There's not any micro optimizations that I know of relying on the old left to right evaluation order either.</div><div><br></div><div>==</div><div><br></div><div>That being said, there are many things the XEngine default compiler will allow to compile that are infact</div><div>syntactically incorrect in LSL.  stuff like negating vectors/rotations in global variable declarations</div><div>as well as doing cast in static context.  In general the default XEngine compiler's rules for global variable</div><div>declaration expression content are very lax in comparison to the secondlife compiler, and that is just one example.</div><div><br></div><div><br></div><div>LibLSLCC's goal to mimic the secondlife compiler's rules exactly, in its default configuration.</div><div><br></div><div><br></div><div>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</div><div>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.</div><div><br></div><div>This would cause a problem for scripts from another region that LibLSLCC deems to contain syntax errors.</div><div><br></div><div>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</div><div> to which compiler was used on the other sim, regardless of what version of OpenSim it is running.</div><div><br></div><div>I imagine this would be a requirement to connect a sim to a grid containing regions not using my compiler addon.</div><div><br></div><div><br></div><div>==</div><div><br></div><div>I tested the library build on OS X Snow leopard 10.6 and OS X El Capitan 10.11.</div><div><br></div><div>Building LibLSLCC-NoEditor.sln works as intended.</div><div><br></div><div>The command line program lslcc that's part of LibLSLCC works fine on both and has no problem generating code.</div><div><br></div><div>LibraryDataScrapingTools works on OSX 10.11 even with its WinForms dialogs, and the OpenSim fork works fine to.</div><div><br></div><div><br></div><div>However, when I tested with OSX 10.6 I ran into an issue where mono complained about missing System.Drawing.GDIPlus. </div><div><br></div><div>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, </div><div>that error prevented both LibraryDataScrapingTools and OpenSim from starting.</div><div><br></div><div><br></div><div>==</div><div><br></div><div>As of now I have added a setting to allow implicit cast of all types into list within a function</div><div>calls parameter expressions, as Zadark had mentioned.  </div><div><br></div><div>As it turns out, all of OpenSim's C# runtime types contain an implicit conversion operator to list.</div><div><br></div><div>It happens regardless of context.</div><div><br></div><div>So The default XEngine compiler allows stuff like this too:</div><div><br></div><div>list a = "";</div><div><br></div><div>list b = <0,0,0>;</div><div><br></div><div><br></div><div>I will probably change the setting to just allow implicit list cast everywhere as an option, </div><div>and maybe add some syntax related compatibility options for global variables.</div><div><br></div><div>In the long run, if I can figure out how to make the compiler addon aware of re-compiles due to region</div><div>crossing, some syntax in-compatibility will not be a major issue for scripts that you cannot modify. </div><div><br></div><div>If I could somehow select to re-compile them with the default XEngine compiler  (if that's what they were originally compiled with), </div><div>then they will not be subject to LibLSLCC's stricter syntax checking.</div><div><br></div><div><br></div><div>==</div><div><br></div><div>I have been working on a settings panel for the editor so I can easily test different </div><div>compiler configurations, and segregating some of the editor code out into different assemblies;</div><div>it will take me a little bit to finish.</div><div><br></div><div>I'm currently working out of the development branch on github, I'll put up a new editor installer</div><div>when I get the configuration stuff all worked out.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 7, 2015 at 8:46 AM, 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">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>
<div><div class="h5"><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 system<br>
> just little so the syntax tree can be built with these types of implicit<br>
> conversion present.<br>
><br>
> The code generator can then be made to generate the cast when necessary,<br>
> since it will pass syntax checking.<br>
><br>
> I think I am going to implement it as a compatibility option in the<br>
> compiler that you can turn on or off, depending on if you want the linden<br>
> compilers more strict type checking behavior.<br>
><br>
> I should also probably make order of evaluation correction on binary<br>
> operations something you can disable if needed, since I can see that<br>
> causing compatibility problems somewhere too.<br>
><br>
> Side Note:  I have not tested on Mac yet, but I plan to do so 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>> wrote:<br>
><br>
>> Hello Eric,<br>
>><br>
>> Very useful, thankyou.<br>
>><br>
>> Caveat<br>
>> XEngine appears to cast library function parameters to the relevant type,<br>
>> though I can see this handy for novice scriptwriters it does encourage some<br>
>> less than elegant techniques<br>
>><br>
>> Some popular scripts freely available to OpenSim use this feature:<br>
>> For instance:<br>
>> llListFindList takes 2 parameters of the type List, when in fact the<br>
>> existing compiler permits any type (as far as we have tested).<br>
>><br>
>> example... integer  bah = llListFindList( blah1, llList2String(blah2,<br>
>> blah3)); // compiles and kind of works.<br>
>><br>
>> This of course fails when compiled with LSLcc, the explanation 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 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 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 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 build it<br>
>>> without any problems.<br>
>>><br>
>>> I'm going to be pushing the changes I made to the .csproj files shortly,<br>
>>>  I will probably rename "MonoDevelop-LibLSLCC.sln" to something like<br>
>>> "LibLSLCC-No-Editor.sln" and update the build instructions in the<br>
>>> README.md to specify that solution as the solution to use for building the<br>
>>> library on Mono.<br>
>>><br>
>>><br>
>>> I have not tested that the editor build is working with anything other<br>
>>> than vs2015,  but I will test with the prior versions vs2012+ to see what<br>
>>> all<br>
>>> works, then put some info in the README.md about what IDE's the 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 <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> Thanks for letting me know about this problem Jak.   (See the bottom for<br>
>>>> TLDR :P)<br>
>>>><br>
>>>><br>
>>>> I am using vs2015 and WiX 3.10.1, it does indeed seem to be a problem<br>
>>>> with vs2010 C#.<br>
>>>><br>
>>>> I was unable to find an updated download for vs2010 C# to test with,<br>
>>>> only an SP1 ISO I found on stackoverflow:<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 attempt to 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 my build.<br>
>>>><br>
>>>> I cannot get it to update from SP1, I am unsure if updates are still<br>
>>>> available to download for vs2010.<br>
>>>><br>
>>>> When I try to update, it just directs me to use windows update 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 building<br>
>>>> against .NET 4.5.<br>
>>>><br>
>>>> I downgraded LibraryDataScrapingTools to .NET 4.0  and re-installed the<br>
>>>> 'System.Data.Sqlite.Core' package from nuget using vs2015 in order to make<br>
>>>> it load in vs2010.<br>
>>>> I then made some code changes to make it compatible with .NET 4.0.<br>
>>>><br>
>>>> I will be committing the changes to LibraryDataScrapingTools tonight, 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 incompatible at<br>
>>>> the moment due to the .NET framework level they require as well.<br>
>>>><br>
>>>> The code base for LSLCCEditor requires a minimum of .NET 4.5 to 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 made to the<br>
>>>> LibraryDataScrapingTools project.<br>
>>>><br>
>>>> I am not sure if I want to limit the LSLCCEditor part of the project to<br>
>>>> a  .NET 4.0 at the moment, as it is a Windows<br>
>>>> only WPF application, and that sort of compatibility profile is not<br>
>>>> necessary.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I also noticed when installing WiX v3.10.1 on a Virtual Machine with<br>
>>>> vs2010 installed that It does not try to register itself with vs2010 as a<br>
>>>> project type.<br>
>>>> I do not think the latest version of WiX installer framework supports<br>
>>>> vs2010 anymore.<br>
>>>><br>
>>>><br>
>>>> === How I got LibLSLCC, LibraryDataScrapingTools, lslcc_cmd and DemoArea<br>
>>>>  to build.  ===<br>
>>>><br>
>>>><br>
>>>><br>
>>>> After the code changes to LibraryDataScrapingTools and 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 projects.<br>
>>>><br>
>>>> When trying to build these projects I got the message "Error 1 Invalid<br>
>>>> option '5' for /langversion; must be ISO-1, ISO-2, 3 or 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 occurrences of:<br>
>>>><br>
>>>> <LangVersion>5</LangVersion><br>
>>>><br>
>>>><br>
>>>> That particular MSBuild setting is not necessary for vs2015 or Mono to<br>
>>>> build the library anyway, so I am going to remove it and commit the changes.<br>
>>>><br>
>>>> After that, LibLSLCC, LibraryDataScrapingTools, lslcc_cmd and DemoArea<br>
>>>> were all able to build under vs2010.<br>
>>>><br>
>>>> ===<br>
>>>><br>
>>>> That all being said,  I will be adding a vs2010 compatible solution 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 compiler,<br>
>>>> library data scraper and demo project with vs2010.<br>
>>>><br>
>>>><br>
>>>> Unfortunately making LSLCCEditor build in vs2010 would require some non<br>
>>>> trivial code changes, a new method of triggering the WiX installer build,<br>
>>>> and a downgrade from .NET 4.5 to .NET 4.0 for the editor related<br>
>>>> projects.<br>
>>>><br>
>>>> I'm not sure if I want to make these changes to the Editor portion of<br>
>>>> the project just for the sake of being compatible with older versions 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>
>>>> <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 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 VS C# 2010<br>
>>>>> express... but only 3 of the projects will load.  LibraryDataScrapingTools,<br>
>>>>> LSLCCEditor, LSLCCEditor.CompletionUI all say (incompatible) and<br>
>>>>> LSLCCEditorInstaller says (unavailable) even though I have 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 installed VS2013<br>
>>>>> it just dumped everything onto my SSD c: drive and filled it up, with no<br>
>>>>> option to put things on drive D: my large harddrive. It also left a mess<br>
>>>>> behind (more than 50% of itself including MSSQL server stuff) when I tried<br>
>>>>> to uninstall it. VS2015 might be better now in this respect, but knowing MS<br>
>>>>> products probably not! I also found VS2013 to be way, way slower loading up<br>
>>>>> large projects like OpenSimulator than VS2010. So before I take the<br>
>>>>> possibly irreversible path of installing VS2015, is there something 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 stuff I<br>
>>>>> have made..) but for a quite a while now I have been working on<br>
>>>>> a new (BSD Licensed) Compilation/Code Generation framework for LSL,<br>
>>>>> tailored towards usage with OpenSim.  I thought I should 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 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 have<br>
>>>>> integrated into my OpenSim fork on GitHub, it's implemented 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 syntax<br>
>>>>> tree implements full front end syntax checking, dead code detection, the<br>
>>>>> works.<br>
>>>>> It also emits extended warning information that is standard to most<br>
>>>>> compilers now days.<br>
>>>>><br>
>>>>><br>
>>>>> The OpenSim code generator I have written and included with the library<br>
>>>>> drastically improves compatibility with scripts written for SecondLife.<br>
>>>>> Order of evaluation in generated code is correct for LSL (Right to<br>
>>>>> Left) among many other things.<br>
>>>>><br>
>>>>> As an example, all of the encryption scripts you can find on the LSL<br>
>>>>> wiki will compile correctly and execute with correct behavior using my<br>
>>>>> compiler.<br>
>>>>><br>
>>>>><br>
>>>>> The README.md for the project goes into a bit more detail on 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 AvalonEdit)<br>
>>>>> with the project that features code completion and syntax highlighting.<br>
>>>>><br>
>>>>> It can be used to test CSharp code generation for OpenSim by 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 editor<br>
>>>>> installer are not.  There's a separate project file for 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 Script<br>
>>>>> functions.<br>
>>>>><br>
>>>>> Such as the 'IdleTimeout' setting not being honored properly.<br>
>>>>><br>
>>>>> And llParseString2List using culture specific comparisons, 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 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 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 README.md.<br>
>>>>><br>
>>>>><br>
>>>>> ==<br>
>>>>><br>
>>>>> I started working on this sometime early last year when I 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 GitHub.<br>
>>>>> I'm going to continue improving this in my spare time,<br>
>>>>> right now I am doing rolling releases versioned by date anywhere from<br>
>>>>> once every few days to a few times a day.  I am also keeping my 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>
</div></div>>>>>> Opensim-dev mailing listOpensim-dev@opensimulator.orghttp://<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>
<span class="">>>>>><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>
</span>>>> Opensim-dev mailing listOpensim-dev@opensimulator.orghttp://<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>
<div class="HOEnZb"><div class="h5">>>><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>
</div></div></blockquote></div><br></div>