<p dir="ltr">Will start resolving conflicts with the aviation merge shortly, there's quite a few caused by the CSharp attributes I put in the LSL Api </p>
<div class="gmail_quote">On Nov 13, 2015 7:21 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Here's the change, it was easy enough to fix from here.</p>
<p dir="ltr"><a href="https://github.com/EriHoss/OpenSim_With_LibLSLCC/commit/f3a7b9a6c4fdb98c3a5e732b8d2b865de8e49df7" target="_blank">https://github.com/EriHoss/OpenSim_With_LibLSLCC/commit/f3a7b9a6c4fdb98c3a5e732b8d2b865de8e49df7</a></p>
<div class="gmail_quote">On Nov 13, 2015 6:38 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com" target="_blank">eblundell800@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Alright, this is an easy fix.  Since the compiler just reads it from settings, co-op call insertion can be forced to true regardless of what OpenSim.ini says</p>
<p dir="ltr">I am currently out of town for the weekend and have spotty coverage,  I'm out in the middle of nowhere hiking. </p>
<p dir="ltr">I can fix this sunday night when I get back or monday if I have trouble doing it from here.</p>
<p dir="ltr">I only have a cell with me :)</p>
<div class="gmail_quote">On Nov 13, 2015 6:27 PM, "Melanie" <<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
please change that to insert the calls unconditionally. The user can<br>
change the script stop strategy without wanting to recompile. The<br>
calls simply do nothing in preemptive stop mode.<br>
<br>
- Melanie<br>
<br>
On 14/11/2015 01:21, Eric Blundell wrote:<br>
> I have no problem with integration, I'd love to see this put to use.  I am<br>
> causing breaking changes quite often at the moment to the library though.<br>
><br>
> If you would like me to help keep the integrated code up to date with my<br>
> latest I can do this.<br>
><br>
> I am unsure what the mode of operation is for ongoing contributions, just<br>
> let me know.<br>
><br>
> The compiler does inject co-op termination calls where necessary when co-op<br>
> script stop is enabled, the function it uses for this is also templated in<br>
> its configuration.<br>
><br>
> The base class name and such is also drawn from XEngine the way the<br>
> previous compiler was set up.<br>
> On Nov 13, 2015 5:21 PM, "Melanie" <<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> what is your position on core integration for this? It does appear<br>
>> to be vastly superior and should not languish in an out-of-core<br>
>> repository.<br>
>><br>
>> Also, does your compiler inject the cooperative termination calls?<br>
>><br>
>> - Melanie<br>
>><br>
>> On 14/11/2015 00:17, Eric Blundell wrote:<br>
>> > Just an update on this.<br>
>> ><br>
>> > I recently corrected a pretty large issue with modifying operations on<br>
>> > vector/rotation components being erroneously optimized away in certain<br>
>> > cases.<br>
>> ><br>
>> > The expression node property that recursively checks the an expression<br>
>> tree<br>
>> > for expressions with side effects was failing to recognize that result of<br>
>> > the '.'  operator access node could be modified by certain assignment and<br>
>> > postfix/prefix operations.<br>
>> ><br>
>> > Therefore statements like:<br>
>> ><br>
>> > vec.x *= 2; or vec.y++; (ect..)<br>
>> ><br>
>> > Were interpreted as having no side effects.<br>
>> ><br>
>> > I found this problem from the MONO tests Blake pointed out on the wiki.<br>
>> ><br>
>> > ==<br>
>> ><br>
>> > I've since put up a new release, the editor now contains a working config<br>
>> > pane for the compiler in the settings window, and uses a LibLSLCC binary<br>
>> > with the previously mentioned optimization fix.<br>
>> ><br>
>> > The compiler options pane is only partially field validated (need to<br>
>> write<br>
>> > validation stuff for method signatures, class inheritance list, and<br>
>> > constructor signature settings still)<br>
>> ><br>
>> > The OpenSim fork has been updated as well to contain the fix.<br>
>> ><br>
>> > I have also put some work into the experimental branch on my fork that<br>
>> > attempts to improves casts from strings to floats in all runtime types.<br>
>> It<br>
>> > adds formating support for NaN, Infinity (both pos and neg) as well as<br>
>> > preservation and printing of negative signed zeros.  hex string to float<br>
>> > parsing has also been added.<br>
>> ><br>
>> > The changes to the runtime types in the experimental branch have not been<br>
>> > heavily tested yet, but seem to fix most of the formating/cast from<br>
>> string<br>
>> > issues present in the compiler compliance test from the wiki.<br>
>> ><br>
>> > Everything's still overflow checked, so that's still going to stop the<br>
>> > overflow tests from working of course, and quaternions still have<br>
>> > normalization differences (that's not really a correctable thing)<br>
>> > On Nov 9, 2015 5:20 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com" target="_blank">eblundell800@gmail.com</a>> wrote:<br>
>> ><br>
>> >> TIL that that ([0,0] != [0,0])  is (length(left) - length(right)).<br>
>> >>  interesting.<br>
>> >><br>
>> >> On Mon, Nov 9, 2015 at 3:47 PM, Melanie <<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>> wrote:<br>
>> >><br>
>> >>> 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>
>> >>><br>
>> >>> - Melanie<br>
>> >>><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<br>
>> working<br>
>> >>> on<br>
>> >>> > the library,<br>
>> >>> > I forgot where I got them and went looking for the other ones but<br>
>> could<br>
>> >>> 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<br>
>> valid)<br>
>> >>> > results in OpenSim on line 436<br>
>> >>> > The second is on line 471-473 and it is caused by an overflow<br>
>> exception<br>
>> >>> > being thrown<br>
>> >>> > The third is on line 480-482 and it is also caused by an overflow<br>
>> >>> exception.<br>
>> >>> ><br>
>> >>> > The rest of the failures are caused by the Float equality delta<br>
>> tests,<br>
>> >>> and<br>
>> >>> > comparing vectors/rotations cast to strings. (their formatting is<br>
>> >>> slightly<br>
>> >>> > different in opensim)<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > There are several in the second, due to vectors and rotations in<br>
>> >>> 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<br>
>> >>> 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<br>
>> >>> 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<br>
>> >>> types.<br>
>> >>> ><br>
>> >>> > ==<br>
>> >>> ><br>
>> >>> > All benchmark scripts on the page work and produce identical output<br>
>> to<br>
>> >>> > second life.<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > LSL_Library_Call_Test_1 failed due to OpenSim using void for the<br>
>> return<br>
>> >>> > type of llGiveMoney();, and also due to erroneous function<br>
>> parameters in<br>
>> >>> > the script causing exceptions.<br>
>> >>> ><br>
>> >>> > LSL_Library_Call_Test_2 compiles and fails due to erroneous<br>
>> parameters<br>
>> >>> 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<br>
>> 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" target="_blank">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" target="_blank">techplex.engineer@gmail.com</a>><br>
>> 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<br>
>> fail<br>
>> >>> 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 <<br>
>> >>> <a href="mailto:eblundell800@gmail.com" target="_blank">eblundell800@gmail.com</a>><br>
>> >>> > >> wrote:<br>
>> >>> > >><br>
>> >>> > >>> If yall believe that reverse compatibility should be thrown out<br>
>> the<br>
>> >>> > >>> door, it makes everything much simpler.<br>
>> >>> > >>><br>
>> >>> > >>> I was under a preconceived notion for a bit that any sort of<br>
>> 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<br>
>> >>> due to<br>
>> >>> > >>> the, way the expression type evaluation and checking logic is<br>
>> >>> segregated<br>
>> >>> > >>> out in the library.<br>
>> >>> > >>><br>
>> >>> > >>><br>
>> >>> > >>> At the moment I am tidying up some things and updating the build<br>
>> >>> system,<br>
>> >>> > >>> mainly to remove the platform specific binaries from the<br>
>> installer<br>
>> >>> 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<br>
>> for<br>
>> >>> the<br>
>> >>> > >>> compatibility options previously mentioned.<br>
>> >>> > >>><br>
>> >>> > >>><br>
>> >>> > >>><br>
>> >>> > >>><br>
>> >>> > >>> I have experienced a few problems as you mentioned with the<br>
>> default<br>
>> >>> > >>> XEngine compiler, I have put at least one script through it that<br>
>> >>> 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<br>
>> compiler<br>
>> >>> > >>> itself and not in the running code.<br>
>> >>> > >>><br>
>> >>> > >>> Examples of either type of problem (in running code, or<br>
>> 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 <<br>
>> >>> <a href="mailto:zadarkportal@gmail.com" target="_blank">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<br>
>> reintroducing<br>
>> >>> > >>>> Opensim as an entry platform to scripting. Previously we found<br>
>> it<br>
>> >>> > >>>> impossible to support larger class sizes due to the empirical<br>
>> >>> 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<br>
>> >>> this is a<br>
>> >>> > >>>> tall ask, but enormously beneficial to simulator operators<br>
>> managing<br>
>> >>> > >>>> experimental behaviour of users attracted to Opensim. I have not<br>
>> >>> 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<br>
>> >>> 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<br>
>> use.<br>
>> >>> > >>>><br>
>> >>> > >>>> Regards<br>
>> >>> > >>>> Z<br>
>> >>> > >>>><br>
>> >>> > >>>> On 9 November 2015 at 14:20, Melanie <<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>><br>
>> wrote:<br>
>> >>> > >>>><br>
>> >>> > >>>>> Please don't do all these things.<br>
>> >>> > >>>>><br>
>> >>> > >>>>> OpenSim is alpha software and there is no need to make the<br>
>> mistake<br>
>> >>> > >>>>> other projects made and perpetuate bugs in the name of<br>
>> >>> compatibility.<br>
>> >>> > >>>>><br>
>> >>> > >>>>> The cast to list is there because, afaik, in SL the operation<br>
>> >>> list +<br>
>> >>> > >>>>> scalar is legal and means to append an element. It's not meant<br>
>> to<br>
>> >>> > >>>>> allow the other side effects you listed and they should be<br>
>> >>> illegal.<br>
>> >>> > >>>>><br>
>> >>> > >>>>> There isn't a way to do these tests on crossings. That's also<br>
>> not<br>
>> >>> > >>>>> necessary as the better compiler will be used by all in short<br>
>> >>> 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<br>
>> not<br>
>> >>> > >>>>> possible<br>
>> >>> > >>>>> > beforehand while using XEngines compiler,<br>
>> >>> > >>>>> > there is probably not to many people with code that's going<br>
>> to<br>
>> >>> behave<br>
>> >>> > >>>>> > incorrectly with the evaluation order of binary<br>
>> >>> > >>>>> > operations switched.  The scripts that happen to break are<br>
>> doing<br>
>> >>> > >>>>> something<br>
>> >>> > >>>>> > pretty wacky/unnecessary.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > There's not any micro optimizations that I know of relying on<br>
>> >>> the<br>
>> >>> > >>>>> old left<br>
>> >>> > >>>>> > to right evaluation order either.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > ==<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > That being said, there are many things the XEngine default<br>
>> >>> 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<br>
>> default<br>
>> >>> > >>>>> XEngine<br>
>> >>> > >>>>> > compiler's rules for global variable<br>
>> >>> > >>>>> > declaration expression content are very lax in comparison to<br>
>> the<br>
>> >>> > >>>>> secondlife<br>
>> >>> > >>>>> > compiler, and that is just one example.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > LibLSLCC's goal to mimic the secondlife compiler's rules<br>
>> >>> exactly, in<br>
>> >>> > >>>>> its<br>
>> >>> > >>>>> > default configuration.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > From my understanding a script moving to new a region is<br>
>> going<br>
>> >>> to be<br>
>> >>> > >>>>> > recompiled if the destination sim does not allow the script<br>
>> >>> binary<br>
>> >>> > >>>>> > to transfer over and be executed.  This will be true in most<br>
>> >>> 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<br>
>> that<br>
>> >>> > >>>>> LibLSLCC<br>
>> >>> > >>>>> > deems to contain syntax errors.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > I may to have to dig into OpenSim to see how region crossing<br>
>> 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<br>
>> what<br>
>> >>> > >>>>> version of<br>
>> >>> > >>>>> > OpenSim it is running.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > I imagine this would be a requirement to connect a sim to a<br>
>> 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<br>
>> 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<br>
>> >>> fine on<br>
>> >>> > >>>>> both<br>
>> >>> > >>>>> > and has no problem generating code.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > LibraryDataScrapingTools works on OSX 10.11 even with its<br>
>> >>> 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<br>
>> where<br>
>> >>> 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<br>
>> look<br>
>> >>> into<br>
>> >>> > >>>>> it to<br>
>> >>> > >>>>> > deeply as I was using a borrowed computer for a few minutes,<br>
>> >>> > >>>>> > that error prevented both LibraryDataScrapingTools and<br>
>> OpenSim<br>
>> >>> from<br>
>> >>> > >>>>> > starting.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > ==<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > As of now I have added a setting to allow implicit cast of<br>
>> all<br>
>> >>> 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<br>
>> list<br>
>> >>> cast<br>
>> >>> > >>>>> > everywhere as an option,<br>
>> >>> > >>>>> > and maybe add some syntax related compatibility options for<br>
>> >>> global<br>
>> >>> > >>>>> > variables.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > In the long run, if I can figure out how to make the compiler<br>
>> >>> addon<br>
>> >>> > >>>>> aware<br>
>> >>> > >>>>> > of re-compiles due to region<br>
>> >>> > >>>>> > crossing, some syntax in-compatibility will not be a major<br>
>> >>> issue for<br>
>> >>> > >>>>> > scripts that you cannot modify.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > If I could somehow select to re-compile them with the default<br>
>> >>> XEngine<br>
>> >>> > >>>>> > compiler  (if that's what they were originally compiled<br>
>> with),<br>
>> >>> > >>>>> > then they will not be subject to LibLSLCC's stricter syntax<br>
>> >>> checking.<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > ==<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> > I have been working on a settings panel for the editor so I<br>
>> can<br>
>> >>> > >>>>> easily test<br>
>> >>> > >>>>> > different<br>
>> >>> > >>>>> > compiler configurations, and segregating some of the editor<br>
>> >>> 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<br>
>> github,<br>
>> >>> 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" target="_blank">melanie@t-data.com</a>><br>
>> >>> wrote:<br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> >> I would be against making the evaluation order optional. It<br>
>> >>> has long<br>
>> >>> > >>>>> >> been recognized as a bug in XEngine's compiler and people<br>
>> >>> porting<br>
>> >>> > >>>>> >> scripts from SL have been advised to remove evaluation order<br>
>> >>> > >>>>> >> dependent code but not write any code that depends on the<br>
>> wrong<br>
>> >>> > >>>>> >> XEngine eval order. Therefore, if this compiler breaks<br>
>> content<br>
>> >>> that<br>
>> >>> > >>>>> >> content needs to be fixed, not a setting changed for<br>
>> >>> 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<br>
>> >>> validation<br>
>> >>> > >>>>> system<br>
>> >>> > >>>>> >> > just little so the syntax tree can be built with these<br>
>> types<br>
>> >>> of<br>
>> >>> > >>>>> implicit<br>
>> >>> > >>>>> >> > conversion present.<br>
>> >>> > >>>>> >> ><br>
>> >>> > >>>>> >> > The code generator can then be made to generate the cast<br>
>> when<br>
>> >>> > >>>>> necessary,<br>
>> >>> > >>>>> >> > since it will pass syntax checking.<br>
>> >>> > >>>>> >> ><br>
>> >>> > >>>>> >> > I think I am going to implement it as a compatibility<br>
>> option<br>
>> >>> in<br>
>> >>> > >>>>> the<br>
>> >>> > >>>>> >> > compiler that you can turn on or off, depending on if you<br>
>> >>> want<br>
>> >>> > >>>>> the linden<br>
>> >>> > >>>>> >> > compilers more strict type checking behavior.<br>
>> >>> > >>>>> >> ><br>
>> >>> > >>>>> >> > I should also probably make order of evaluation<br>
>> correction on<br>
>> >>> > >>>>> binary<br>
>> >>> > >>>>> >> > operations something you can disable if needed, since I<br>
>> can<br>
>> >>> see<br>
>> >>> > >>>>> that<br>
>> >>> > >>>>> >> > causing compatibility problems somewhere too.<br>
>> >>> > >>>>> >> ><br>
>> >>> > >>>>> >> > Side Note:  I have not tested on Mac yet, but I plan to<br>
>> do so<br>
>> >>> > >>>>> today if I<br>
>> >>> > >>>>> >> > can get time to, sorry.<br>
>> >>> > >>>>> >> > On Nov 7, 2015 7:42 AM, "Zadark Portal" <<br>
>> >>> <a href="mailto:zadarkportal@gmail.com" target="_blank">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<br>
>> the<br>
>> >>> > >>>>> relevant<br>
>> >>> > >>>>> >> type,<br>
>> >>> > >>>>> >> >> though I can see this handy for novice scriptwriters it<br>
>> 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<br>
>> in<br>
>> >>> fact<br>
>> >>> > >>>>> the<br>
>> >>> > >>>>> >> >> existing compiler permits any type (as far as we have<br>
>> >>> 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<br>
>> >>> explanation<br>
>> >>> > >>>>> is clear<br>
>> >>> > >>>>> >> >> and precise so easy to fix (enable compile) with a local<br>
>> >>> cast.<br>
>> >>> > >>>>> >> >><br>
>> >>> > >>>>> >> >> Z<br>
>> >>> > >>>>> >> >><br>
>> >>> > >>>>> >> >><br>
>> >>> > >>>>> >> >> On 5 November 2015 at 12:52, Jak Daniels <<a href="mailto:jak@ateb.co.uk" target="_blank">jak@ateb.co.uk</a><br>
>> ><br>
>> >>> wrote:<br>
>> >>> > >>>>> >> >><br>
>> >>> > >>>>> >> >>> Hi Eric,<br>
>> >>> > >>>>> >> >>><br>
>> >>> > >>>>> >> >>> yes I can confirm now that it does open and compile<br>
>> >>> correctly<br>
>> >>> > >>>>> in VS C#<br>
>> >>> > >>>>> >> >>> 2010 express now. Thank you.<br>
>> >>> > >>>>> >> >>><br>
>> >>> > >>>>> >> >>> I'm now installing VS2015 in a win10 virtual machine so<br>
>> I<br>
>> >>> 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,<br>
>> >>> and<br>
>> >>> > >>>>> add some<br>
>> >>> > >>>>> >> >>> info...<br>
>> >>> > >>>>> >> >>><br>
>> >>> > >>>>> >> >>> After removing the "<LangVersion>5</LangVersion>" stuff<br>
>> >>> 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<br>
>> >>> tree and<br>
>> >>> > >>>>> build<br>
>> >>> > >>>>> >> it<br>
>> >>> > >>>>> >> >>> without any problems.<br>
>> >>> > >>>>> >> >>><br>
>> >>> > >>>>> >> >>> I'm going to be pushing the changes I made to the<br>
>> .csproj<br>
>> >>> files<br>
>> >>> > >>>>> >> shortly,<br>
>> >>> > >>>>> >> >>>  I will probably rename "MonoDevelop-LibLSLCC.sln" to<br>
>> >>> something<br>
>> >>> > >>>>> like<br>
>> >>> > >>>>> >> >>> "LibLSLCC-No-Editor.sln" and update the build<br>
>> instructions<br>
>> >>> in<br>
>> >>> > >>>>> the<br>
>> >>> > >>>>> >> >>> README.md to specify that solution as the solution to<br>
>> use<br>
>> >>> 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<br>
>> >>> vs2012+<br>
>> >>> > >>>>> to see<br>
>> >>> > >>>>> >> what<br>
>> >>> > >>>>> >> >>> all<br>
>> >>> > >>>>> >> >>> works, then put some info in the README.md about what<br>
>> >>> 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" target="_blank">eblundell800@gmail.com</a><br>
>> >>> > >>>>> >> ><br>
>> >>> > >>>>> >> >>> wrote:<br>
>> >>> > >>>>> >> >>><br>
>> >>> > >>>>> >> >>>> Thanks for letting me know about this problem Jak.<br>
>>  (See<br>
>> >>> the<br>
>> >>> > >>>>> bottom<br>
>> >>> > >>>>> >> for<br>
>> >>> > >>>>> >> >>>> TLDR :P)<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I am using vs2015 and WiX 3.10.1, it does indeed seem<br>
>> to<br>
>> >>> be a<br>
>> >>> > >>>>> problem<br>
>> >>> > >>>>> >> >>>> with vs2010 C#.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I was unable to find an updated download for vs2010 C#<br>
>> to<br>
>> >>> test<br>
>> >>> > >>>>> with,<br>
>> >>> > >>>>> >> >>>> only an SP1 ISO I found on stackoverflow:<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>><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<br>
>> not<br>
>> >>> > >>>>> attempt to<br>
>> >>> > >>>>> >> open<br>
>> >>> > >>>>> >> >>>> my solution files at all as it says they are<br>
>> incompatible.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I can however, load the .csproj files for certain<br>
>> >>> projects in<br>
>> >>> > >>>>> my<br>
>> >>> > >>>>> >> build.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I cannot get it to update from SP1, I am unsure if<br>
>> >>> updates are<br>
>> >>> > >>>>> still<br>
>> >>> > >>>>> >> >>>> available to download for vs2010.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> When I try to update, it just directs me to use windows<br>
>> >>> 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:<br>
>> >>> LibLSLCC.csproj,<br>
>> >>> > >>>>> >> >>>> lslcc_cmd.csproj and DemoArea.csproj.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> LibraryDataScrapingTools was incompatible because it<br>
>> 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<br>
>> vs2015<br>
>> >>> in<br>
>> >>> > >>>>> order to<br>
>> >>> > >>>>> >> make<br>
>> >>> > >>>>> >> >>>> it load in vs2010.<br>
>> >>> > >>>>> >> >>>> I then made some code changes to make it compatible<br>
>> with<br>
>> >>> .NET<br>
>> >>> > >>>>> 4.0.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I will be committing the changes to<br>
>> >>> 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<br>
>> require as<br>
>> >>> > >>>>> well.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> The code base for LSLCCEditor requires a minimum of<br>
>> .NET<br>
>> >>> 4.5 to<br>
>> >>> > >>>>> >> compile,<br>
>> >>> > >>>>> >> >>>> and the code changes required to make the editor<br>
>> projects<br>
>> >>> > >>>>> >> >>>> compatible with .NET 4.0 are not as trivial as the<br>
>> >>> changes I<br>
>> >>> > >>>>> made to<br>
>> >>> > >>>>> >> the<br>
>> >>> > >>>>> >> >>>> LibraryDataScrapingTools project.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I am not sure if I want to limit the LSLCCEditor part<br>
>> of<br>
>> >>> 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<br>
>> >>> 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<br>
>> itself<br>
>> >>> with<br>
>> >>> > >>>>> vs2010<br>
>> >>> > >>>>> >> as a<br>
>> >>> > >>>>> >> >>>> project type.<br>
>> >>> > >>>>> >> >>>> I do not think the latest version of WiX installer<br>
>> >>> framework<br>
>> >>> > >>>>> supports<br>
>> >>> > >>>>> >> >>>> vs2010 anymore.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> === How I got LibLSLCC, LibraryDataScrapingTools,<br>
>> >>> 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<br>
>> >>> existing<br>
>> >>> > >>>>> >> projects.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> When trying to build these projects I got the message<br>
>> >>> "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<br>
>> for<br>
>> >>> 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<br>
>> >>> vs2015 or<br>
>> >>> > >>>>> Mono to<br>
>> >>> > >>>>> >> >>>> build the library anyway, so I am going to remove it<br>
>> and<br>
>> >>> > >>>>> commit the<br>
>> >>> > >>>>> >> changes.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> After that, LibLSLCC, LibraryDataScrapingTools,<br>
>> lslcc_cmd<br>
>> >>> 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<br>
>> 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<br>
>> line<br>
>> >>> > >>>>> compiler,<br>
>> >>> > >>>>> >> >>>> library data scraper and demo project with vs2010.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> Unfortunately making LSLCCEditor build in vs2010 would<br>
>> >>> require<br>
>> >>> > >>>>> some<br>
>> >>> > >>>>> >> non<br>
>> >>> > >>>>> >> >>>> trivial code changes, a new method of triggering the<br>
>> WiX<br>
>> >>> > >>>>> installer<br>
>> >>> > >>>>> >> build,<br>
>> >>> > >>>>> >> >>>> and a downgrade from .NET 4.5 to .NET 4.0 for the<br>
>> editor<br>
>> >>> > >>>>> related<br>
>> >>> > >>>>> >> >>>> projects.<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>> I'm not sure if I want to make these changes to the<br>
>> Editor<br>
>> >>> > >>>>> portion of<br>
>> >>> > >>>>> >> >>>> the project just for the sake of being compatible with<br>
>> >>> 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 < <<br>
>> >>> <a href="mailto:jak@ateb.co.uk" target="_blank">jak@ateb.co.uk</a><br>
>> >>> > >>>>> ><br>
>> >>> > >>>>> >> >>>> <a href="mailto:jak@ateb.co.uk" target="_blank">jak@ateb.co.uk</a>> wrote:<br>
>> >>> > >>>>> >> >>>><br>
>> >>> > >>>>> >> >>>>> Hi Eric,<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> Thank you for posting up your work to this group. This<br>
>> >>> 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<br>
>> >>> 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<br>
>> >>> (incompatible)<br>
>> >>> > >>>>> and<br>
>> >>> > >>>>> >> >>>>> LSLCCEditorInstaller says (unavailable) even though I<br>
>> >>> 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<br>
>> >>> filled it<br>
>> >>> > >>>>> up,<br>
>> >>> > >>>>> >> with no<br>
>> >>> > >>>>> >> >>>>> option to put things on drive D: my large harddrive.<br>
>> It<br>
>> >>> also<br>
>> >>> > >>>>> left a<br>
>> >>> > >>>>> >> mess<br>
>> >>> > >>>>> >> >>>>> behind (more than 50% of itself including MSSQL server<br>
>> >>> stuff)<br>
>> >>> > >>>>> when I<br>
>> >>> > >>>>> >> tried<br>
>> >>> > >>>>> >> >>>>> to uninstall it. VS2015 might be better now in this<br>
>> >>> respect,<br>
>> >>> > >>>>> but<br>
>> >>> > >>>>> >> knowing MS<br>
>> >>> > >>>>> >> >>>>> products probably not! I also found VS2013 to be way,<br>
>> way<br>
>> >>> > >>>>> slower<br>
>> >>> > >>>>> >> loading up<br>
>> >>> > >>>>> >> >>>>> large projects like OpenSimulator than VS2010. So<br>
>> before<br>
>> >>> I<br>
>> >>> > >>>>> take the<br>
>> >>> > >>>>> >> >>>>> possibly irreversible path of installing VS2015, is<br>
>> 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<br>
>> >>> sharing<br>
>> >>> > >>>>> stuff I<br>
>> >>> > >>>>> >> >>>>> have made..) but for a quite a while now I have been<br>
>> >>> working<br>
>> >>> > >>>>> on<br>
>> >>> > >>>>> >> >>>>> a new (BSD Licensed) Compilation/Code Generation<br>
>> >>> framework<br>
>> >>> > >>>>> for LSL,<br>
>> >>> > >>>>> >> >>>>> tailored towards usage with OpenSim.  I thought I<br>
>> should<br>
>> >>> > >>>>> share it<br>
>> >>> > >>>>> >> >>>>> at this point of its development.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> This is pretty much a "full" or "true" compiler front<br>
>> >>> end.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> It's built on-top of ANTLR4 and ANTLR4's CSharp<br>
>> target.<br>
>> >>> > >>>>> >> >>>>> ANTLR4 however has been completely abstracted and the<br>
>> >>> 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<br>
>> >>> which I<br>
>> >>> > >>>>> have<br>
>> >>> > >>>>> >> >>>>> integrated into my OpenSim fork on GitHub, it's<br>
>> >>> implemented<br>
>> >>> > >>>>> as an<br>
>> >>> > >>>>> >> >>>>> optional compiler that you can enable in your<br>
>> >>> OpenSim.ini.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> The Code validation step my library performs when<br>
>> >>> building a<br>
>> >>> > >>>>> syntax<br>
>> >>> > >>>>> >> >>>>> tree implements full front end syntax checking, dead<br>
>> code<br>
>> >>> > >>>>> detection,<br>
>> >>> > >>>>> >> the<br>
>> >>> > >>>>> >> >>>>> works.<br>
>> >>> > >>>>> >> >>>>> It also emits extended warning information that is<br>
>> >>> standard<br>
>> >>> > >>>>> to most<br>
>> >>> > >>>>> >> >>>>> compilers now days.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> The OpenSim code generator I have written and included<br>
>> >>> with<br>
>> >>> > >>>>> the<br>
>> >>> > >>>>> >> library<br>
>> >>> > >>>>> >> >>>>> drastically improves compatibility with scripts<br>
>> written<br>
>> >>> for<br>
>> >>> > >>>>> >> SecondLife.<br>
>> >>> > >>>>> >> >>>>> Order of evaluation in generated code is correct for<br>
>> LSL<br>
>> >>> > >>>>> (Right to<br>
>> >>> > >>>>> >> >>>>> Left) among many other things.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> As an example, all of the encryption scripts you can<br>
>> >>> find on<br>
>> >>> > >>>>> the LSL<br>
>> >>> > >>>>> >> >>>>> wiki will compile correctly and execute with correct<br>
>> >>> behavior<br>
>> >>> > >>>>> using<br>
>> >>> > >>>>> >> my<br>
>> >>> > >>>>> >> >>>>> compiler.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> The README.md for the project goes into a bit more<br>
>> >>> 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<br>
>> used<br>
>> >>> > >>>>> AvalonEdit)<br>
>> >>> > >>>>> >> >>>>> with the project that features code completion and<br>
>> syntax<br>
>> >>> > >>>>> >> highlighting.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> It can be used to test CSharp code generation for<br>
>> >>> OpenSim by<br>
>> >>> > >>>>> >> compiling<br>
>> >>> > >>>>> >> >>>>> LSL into C# using LibLSLCC, which can then be uploaded<br>
>> >>> to an<br>
>> >>> > >>>>> >> >>>>> OpenSim server with C# scripting enabled.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> The library itself is cross-platform, but the editor<br>
>> and<br>
>> >>> > >>>>> editor<br>
>> >>> > >>>>> >> >>>>> installer are not.  There's a separate project file<br>
>> 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<br>
>> Runtime<br>
>> >>> > >>>>> Script<br>
>> >>> > >>>>> >> >>>>> functions.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> Such as the 'IdleTimeout' setting not being honored<br>
>> >>> properly.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> And llParseString2List using culture specific<br>
>> >>> comparisons,<br>
>> >>> > >>>>> causing it<br>
>> >>> > >>>>> >> >>>>> to misbehave when comparing Unicode characters on<br>
>> 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<br>
>> >>> library<br>
>> >>> > >>>>> data<br>
>> >>> > >>>>> >> >>>>> that's consumable by its code validator and code<br>
>> >>> generator.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> I have also made some slight changes to<br>
>> >>> IScriptModuleComms and<br>
>> >>> > >>>>> >> >>>>> ScriptModuleCommsModule.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> The old compiler in my fork works as it did before, so<br>
>> >>> 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<br>
>> the<br>
>> >>> > >>>>> README.md.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> ==<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> I started working on this sometime early last year<br>
>> 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<br>
>> >>> 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<br>
>> date<br>
>> >>> > >>>>> anywhere from<br>
>> >>> > >>>>> >> >>>>> once every few days to a few times a day.  I am also<br>
>> >>> keeping<br>
>> >>> > >>>>> my<br>
>> >>> > >>>>> >> OpenSim<br>
>> >>> > >>>>> >> >>>>> fork synced with the latest OpenSim commits.<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> Hopefully this will be useful, any feedback is<br>
>> >>> appreciated :)<br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>><br>
>> >>> > >>>>> >> >>>>> _______________________________________________<br>
>> >>> > >>>>> >> >>>>> Opensim-dev mailing listOpensim-dev<br>
>> >>> @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" target="_blank">Opensim-dev@opensimulator.org</a><br>
>> >>> > >>>>> >> >>>>><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<br>
>> >>> @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" target="_blank">Opensim-dev@opensimulator.org</a><br>
>> >>> > >>>>> >> >>><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" target="_blank">Opensim-dev@opensimulator.org</a><br>
>> >>> > >>>>> >> >><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" target="_blank">Opensim-dev@opensimulator.org</a><br>
>> >>> > >>>>> >> ><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" target="_blank">Opensim-dev@opensimulator.org</a><br>
>> >>> > >>>>> >><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" target="_blank">Opensim-dev@opensimulator.org</a><br>
>> >>> > >>>>> ><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@opensimulator.org" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</blockquote></div>
</blockquote></div>
</blockquote></div>