<div dir="ltr">Gotcha, I'll make the self contained version the main branch and make any updates there or off a copy.<div><br></div><div>Thank you for all your input.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 11:06 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">Since the policy is that the script compiler/engine has to adapt to<br>
the core code rather than adapting the core code for every script<br>
engine/compiler, the one without changes to any of the core files is<br>
the one that has good chances to get in.<br>
<br>
Removing a public API is definitely not acceptable. That would cause<br>
out-of-core modules that use it to break and we know that module<br>
creators often don't follow code changes in a timely fashion,<br>
leading to useful modules lying around in a broken state.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Melanie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 17/11/2015 17:56, Eric Blundell wrote:<br>
> Melanie,<br>
><br>
><br>
> While merging the avination changes into my fork, I reverted all of<br>
> ScriptBaseClass's<br>
> definition to its original state from the OpenSim master.<br>
><br>
> The methods/constants are reflected off it now by mapping the CSharp Types<br>
> in their<br>
> signatures to something LibLSLCC can consume for syntax checking.<br>
><br>
> I have made a new branch named 'no-scriptcomms-change' where the compiler<br>
> is entirely self contained,<br>
> and no changes are necessary to OpenSim's existing framework at all for it<br>
> to function.<br>
><br>
><br>
> The Core/Optional modules in this branch are reverted to their original<br>
> state in the OpenSim master as well.<br>
> LibLSLCC attributes are no longer required for the compiler to reflect<br>
> module methods and constants.<br>
><br>
><br>
> The compiler just uses the same type conversions as it does for<br>
> ScriptBaseClass to derive LibLSLCC signatures for modules.<br>
><br>
> In the case of constants, it uses the 'Type' of the constant value when<br>
> attempting to map types, since<br>
> IScriptModuleComms can only provide the constant's value in object form.<br>
><br>
><br>
> Constants and functions that contain types un-mappable by the LibLSLCC<br>
> compiler are ignored and considered undefined.<br>
><br>
><br>
> The compiler has been setup with mappings for every type currently used in<br>
> ScriptBaseClass, as well as the Core/Optional modules.<br>
><br>
> This includes the basic CSharp built in types, OpenSim's LSL_Type's, and<br>
> OpenMetaverse types.<br>
><br>
><br>
> ==<br>
><br>
><br>
> In my master branch there are still modifications<br>
> to ScriptModuleCommsModule.<br>
><br>
><br>
> The changes are for returning more information about a module constants<br>
> declaration site. (IE, its MemberInfo, which also defines DeclaringType)<br>
><br>
> There is no ability for modules to define a constant without an associated<br>
> class field in this branch, as it removes:<br>
><br>
>     void RegisterConstant(string cname, object value);<br>
><br>
><br>
><br>
> The modifications to the ScriptModuleCommsModule module and its interface<br>
> were made to allow for access to the MemberInfo<br>
> of the constants class field;  Which in-turn allows for finding the<br>
> attributes applied to the constant.<br>
><br>
><br>
> That change may not welcome which is why I have the other branch.<br>
><br>
><br>
> ==<br>
><br>
><br>
> There are no changes/fixes to LSL_Types.* ToString() formatting or string<br>
> parsing in either branch.<br>
> I can experiment with those changes and everything else once I know which<br>
> of the two branches has the best approach.<br>
><br>
><br>
> Also, any changes I made to the LSL function implementations have been<br>
> discarded (llParseString2List)<br>
> because avination fixed them.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Nov 16, 2015 at 7:44 PM, Eric Blundell <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>><br>
> wrote:<br>
><br>
>> Alright, there is another way I can reflect call information from there.<br>
>><br>
>> I can change to converting the CSharp types in the the LSL Api<br>
>> constants/functions to their corresponding LSL type instead of having them<br>
>> attributed.<br>
>><br>
>> The attributes are for reflecting call signatures<br>
>> and constant types that can be used for syntax checking and overload<br>
>> resolution.  The signature info for the library can be also be generated<br>
>> dynamically using a converter to convert the CSharp types when the<br>
>> methods/fields are reflected upon.<br>
>><br>
>> However, the attributes themselves do not change interaction with these<br>
>> classes from the outside.<br>
>><br>
>> I think place where it would break things for other people would be on<br>
>> merge,  if they had already modified these files themselves and added their<br>
>> own set of function/parameter attributes that are conflicting in the source<br>
>> code.<br>
>><br>
>> =<br>
>><br>
>> I am using these attributes also on optional module functions and<br>
>> constants, these are there along with the original ScriptConstant and<br>
>> ScriptFunction attributes which have not been altered or removed.<br>
>><br>
>> Does that need to be changed as well?<br>
>> On Nov 16, 2015 7:09 PM, "Melanie" <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>><br>
>>> You can NOT modify the LSL API. For the purposes of script engine<br>
>>> development, the LSL_Api files are to be considered frozen.<br>
>>><br>
>>> The LSL API serves several script engines, some not in core, so<br>
>>> modifications that would only benefit one engine, or that would<br>
>>> break others, can't be permitted.<br>
>>><br>
>>> - Melanie<br>
>>><br>
>>> On 17/11/2015 02:01, Eric Blundell wrote:<br>
>>> > Avination*<br>
>>> > On Nov 16, 2015 7:01 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>><br>
>>> wrote:<br>
>>> ><br>
>>> > Will start resolving conflicts with the aviation merge shortly, there's<br>
>>> > quite a few caused by the CSharp attributes I put in the LSL Api<br>
>>> > On Nov 13, 2015 7:21 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>><br>
>>> wrote:<br>
>>> ><br>
>>> >> Here's the change, it was easy enough to fix from here.<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> <a href="https://github.com/EriHoss/OpenSim_With_LibLSLCC/commit/f3a7b9a6c4fdb98c3a5e732b8d2b865de8e49df7" rel="noreferrer" target="_blank">https://github.com/EriHoss/OpenSim_With_LibLSLCC/commit/f3a7b9a6c4fdb98c3a5e732b8d2b865de8e49df7</a><br>
>>> >> On Nov 13, 2015 6:38 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a>><br>
>>> wrote:<br>
>>> >><br>
>>> >>> Alright, this is an easy fix.  Since the compiler just reads it from<br>
>>> >>> settings, co-op call insertion can be forced to true regardless of<br>
>>> what<br>
>>> >>> OpenSim.ini says<br>
>>> >>><br>
>>> >>> I am currently out of town for the weekend and have spotty coverage,<br>
>>> I'm<br>
>>> >>> out in the middle of nowhere hiking.<br>
>>> >>><br>
>>> >>> I can fix this sunday night when I get back or monday if I have<br>
>>> trouble<br>
>>> >>> doing it from here.<br>
>>> >>><br>
>>> >>> I only have a cell with me :)<br>
>>> >>> On Nov 13, 2015 6:27 PM, "Melanie" <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>>> >>><br>
>>> >>>> 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<br>
>>> use.<br>
>>> >>>> I am<br>
>>> >>>> > causing breaking changes quite often at the moment to the library<br>
>>> >>>> though.<br>
>>> >>>> ><br>
>>> >>>> > If you would like me to help keep the integrated code up to date<br>
>>> with<br>
>>> >>>> my<br>
>>> >>>> > latest I can do this.<br>
>>> >>>> ><br>
>>> >>>> > I am unsure what the mode of operation is for ongoing<br>
>>> contributions,<br>
>>> >>>> just<br>
>>> >>>> > let me know.<br>
>>> >>>> ><br>
>>> >>>> > The compiler does inject co-op termination calls where necessary<br>
>>> when<br>
>>> >>>> co-op<br>
>>> >>>> > script stop is enabled, the function it uses for this is also<br>
>>> >>>> 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">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<br>
>>> operations<br>
>>> >>>> on<br>
>>> >>>> >> > vector/rotation components being erroneously optimized away in<br>
>>> >>>> certain<br>
>>> >>>> >> > cases.<br>
>>> >>>> >> ><br>
>>> >>>> >> > The expression node property that recursively checks the an<br>
>>> >>>> expression<br>
>>> >>>> >> tree<br>
>>> >>>> >> > for expressions with side effects was failing to recognize that<br>
>>> >>>> result of<br>
>>> >>>> >> > the '.'  operator access node could be modified by certain<br>
>>> >>>> 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<br>
>>> the<br>
>>> >>>> wiki.<br>
>>> >>>> >> ><br>
>>> >>>> >> > ==<br>
>>> >>>> >> ><br>
>>> >>>> >> > I've since put up a new release, the editor now contains a<br>
>>> working<br>
>>> >>>> config<br>
>>> >>>> >> > pane for the compiler in the settings window, and uses a<br>
>>> LibLSLCC<br>
>>> >>>> binary<br>
>>> >>>> >> > with the previously mentioned optimization fix.<br>
>>> >>>> >> ><br>
>>> >>>> >> > The compiler options pane is only partially field validated<br>
>>> (need to<br>
>>> >>>> >> write<br>
>>> >>>> >> > validation stuff for method signatures, class inheritance list,<br>
>>> 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<br>
>>> fork<br>
>>> >>>> that<br>
>>> >>>> >> > attempts to improves casts from strings to floats in all runtime<br>
>>> >>>> types.<br>
>>> >>>> >> It<br>
>>> >>>> >> > adds formating support for NaN, Infinity (both pos and neg) as<br>
>>> well<br>
>>> >>>> as<br>
>>> >>>> >> > preservation and printing of negative signed zeros.  hex string<br>
>>> to<br>
>>> >>>> float<br>
>>> >>>> >> > parsing has also been added.<br>
>>> >>>> >> ><br>
>>> >>>> >> > The changes to the runtime types in the experimental branch have<br>
>>> >>>> not been<br>
>>> >>>> >> > heavily tested yet, but seem to fix most of the formating/cast<br>
>>> 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<br>
>>> stop<br>
>>> >>>> the<br>
>>> >>>> >> > overflow tests from working of course, and quaternions still<br>
>>> have<br>
>>> >>>> >> > normalization differences (that's not really a correctable<br>
>>> thing)<br>
>>> >>>> >> > On Nov 9, 2015 5:20 PM, "Eric Blundell" <<a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a><br>
>>> ><br>
>>> >>>> wrote:<br>
>>> >>>> >> ><br>
>>> >>>> >> >> TIL that that ([0,0] != [0,0])  is (length(left) -<br>
>>> length(right)).<br>
>>> >>>> >> >>  interesting.<br>
>>> >>>> >> >><br>
>>> >>>> >> >> On Mon, Nov 9, 2015 at 3:47 PM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>><br>
>>> >>>> wrote:<br>
>>> >>>> >> >><br>
>>> >>>> >> >>> The [1] != [2,3] test would yield 1 because the c# notion of<br>
>>> true<br>
>>> >>>> is<br>
>>> >>>> >> >>> 1, not -1.<br>
>>> >>>> >> >>><br>
>>> >>>> >> >>> This can't be fixed because it's a Mono thing. A compiler cold<br>
>>> >>>> work<br>
>>> >>>> >> >>> around it by identifying expressions yielding a boolean value<br>
>>> 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<br>
>>> started<br>
>>> >>>> >> working<br>
>>> >>>> >> >>> on<br>
>>> >>>> >> >>> > the library,<br>
>>> >>>> >> >>> > I forgot where I got them and went looking for the other<br>
>>> ones<br>
>>> >>>> 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<br>
>>> (but<br>
>>> >>>> >> valid)<br>
>>> >>>> >> >>> > results in OpenSim on line 436<br>
>>> >>>> >> >>> > The second is on line 471-473 and it is caused by an<br>
>>> overflow<br>
>>> >>>> >> exception<br>
>>> >>>> >> >>> > being thrown<br>
>>> >>>> >> >>> > The third is on line 480-482 and it is also caused by an<br>
>>> >>>> overflow<br>
>>> >>>> >> >>> exception.<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > The rest of the failures are caused by the Float equality<br>
>>> delta<br>
>>> >>>> >> tests,<br>
>>> >>>> >> >>> and<br>
>>> >>>> >> >>> > comparing vectors/rotations cast to strings. (their<br>
>>> formatting<br>
>>> >>>> is<br>
>>> >>>> >> >>> slightly<br>
>>> >>>> >> >>> > different in opensim)<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > There are several in the second, due to vectors and<br>
>>> rotations in<br>
>>> >>>> >> >>> OpenSims<br>
>>> >>>> >> >>> > runtime converting into strings with spaces after the<br>
>>> commas.<br>
>>> >>>> >> >>> > In secondlife there are no spaces in the list of components<br>
>>> >>>> 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<br>
>>> 224<br>
>>> >>>> of<br>
>>> >>>> >> >>> > LSL_Language_Test_2 which is a runtime related thing I am<br>
>>> >>>> curious to<br>
>>> >>>> >> >>> > investigate.<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > I am unsure if I should improve the actual runtime types,<br>
>>> or fix<br>
>>> >>>> >> >>> > differences generating workaround code.<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > I am inclined to believe that the quaternion runtime type<br>
>>> 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<br>
>>> >>>> existing<br>
>>> >>>> >> >>> types.<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > ==<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > All benchmark scripts on the page work and produce identical<br>
>>> >>>> output<br>
>>> >>>> >> to<br>
>>> >>>> >> >>> > second life.<br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> ><br>
>>> >>>> >> >>> > LSL_Library_Call_Test_1 failed due to OpenSim using void<br>
>>> 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<br>
>>> >>>> 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">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" <<br>
>>> <a href="mailto:techplex.engineer@gmail.com">techplex.engineer@gmail.com</a><br>
>>> >>>> ><br>
>>> >>>> >> wrote:<br>
>>> >>>> >> >>> > ><br>
>>> >>>> >> >>> > >> Eric,<br>
>>> >>>> >> >>> > >><br>
>>> >>>> >> >>> > >> Have you seen the Mono test scripts that SL used when<br>
>>> they<br>
>>> >>>> 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<br>
>>> the<br>
>>> >>>> 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">eblundell800@gmail.com</a>><br>
>>> >>>> >> >>> > >> wrote:<br>
>>> >>>> >> >>> > >><br>
>>> >>>> >> >>> > >>> If yall believe that reverse compatibility should be<br>
>>> thrown<br>
>>> >>>> out<br>
>>> >>>> >> the<br>
>>> >>>> >> >>> > >>> door, it makes everything much simpler.<br>
>>> >>>> >> >>> > >>><br>
>>> >>>> >> >>> > >>> I was under a preconceived notion for a bit that any<br>
>>> 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<br>
>>> >>>> reverse<br>
>>> >>>> >> >>> due to<br>
>>> >>>> >> >>> > >>> the, way the expression type evaluation and checking<br>
>>> logic<br>
>>> >>>> is<br>
>>> >>>> >> >>> segregated<br>
>>> >>>> >> >>> > >>> out in the library.<br>
>>> >>>> >> >>> > >>><br>
>>> >>>> >> >>> > >>><br>
>>> >>>> >> >>> > >>> At the moment I am tidying up some things and updating<br>
>>> the<br>
>>> >>>> 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<br>
>>> >>>> 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<br>
>>> the<br>
>>> >>>> >> default<br>
>>> >>>> >> >>> > >>> XEngine compiler, I have put at least one script<br>
>>> through it<br>
>>> >>>> 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<br>
>>> 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<br>
>>> 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">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<br>
>>> we<br>
>>> >>>> found<br>
>>> >>>> >> it<br>
>>> >>>> >> >>> > >>>> impossible to support larger class sizes due to the<br>
>>> >>>> empirical<br>
>>> >>>> >> >>> nature of<br>
>>> >>>> >> >>> > >>>> novices producing non deterministic behaviours.<br>
>>> >>>> >> >>> > >>>><br>
>>> >>>> >> >>> > >>>> If when considering further developments may I suggest<br>
>>> >>>> trapping<br>
>>> >>>> >> >>> > >>>> potentially dangerous (Opensim crash) scripted<br>
>>> constructs.<br>
>>> >>>> Maybe<br>
>>> >>>> >> >>> this is a<br>
>>> >>>> >> >>> > >>>> tall ask, but enormously beneficial to simulator<br>
>>> operators<br>
>>> >>>> >> managing<br>
>>> >>>> >> >>> > >>>> experimental behaviour of users attracted to Opensim. I<br>
>>> >>>> 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<br>
>>> >>>> for this<br>
>>> >>>> >> >>> > >>>> contribution with regards to core we will continue make<br>
>>> >>>> full<br>
>>> >>>> >> use.<br>
>>> >>>> >> >>> > >>>><br>
>>> >>>> >> >>> > >>>> Regards<br>
>>> >>>> >> >>> > >>>> Z<br>
>>> >>>> >> >>> > >>>><br>
>>> >>>> >> >>> > >>>> On 9 November 2015 at 14:20, Melanie <<br>
>>> <a href="mailto:melanie@t-data.com">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<br>
>>> 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<br>
>>> >>>> operation<br>
>>> >>>> >> >>> list +<br>
>>> >>>> >> >>> > >>>>> scalar is legal and means to append an element. It's<br>
>>> not<br>
>>> >>>> meant<br>
>>> >>>> >> to<br>
>>> >>>> >> >>> > >>>>> allow the other side effects you listed and they<br>
>>> should be<br>
>>> >>>> >> >>> illegal.<br>
>>> >>>> >> >>> > >>>>><br>
>>> >>>> >> >>> > >>>>> There isn't a way to do these tests on crossings.<br>
>>> That's<br>
>>> >>>> also<br>
>>> >>>> >> not<br>
>>> >>>> >> >>> > >>>>> necessary as the better compiler will be used by all<br>
>>> in<br>
>>> >>>> short<br>
>>> >>>> >> >>> order.<br>
>>> >>>> >> >>> > >>>>> People will fix their scripts and everyone will be<br>
>>> happy<br>
>>> >>>> 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<br>
>>> hacks<br>
>>> >>>> were<br>
>>> >>>> >> not<br>
>>> >>>> >> >>> > >>>>> possible<br>
>>> >>>> >> >>> > >>>>> > beforehand while using XEngines compiler,<br>
>>> >>>> >> >>> > >>>>> > there is probably not to many people with code<br>
>>> that's<br>
>>> >>>> going<br>
>>> >>>> >> to<br>
>>> >>>> >> >>> behave<br>
>>> >>>> >> >>> > >>>>> > incorrectly with the evaluation order of binary<br>
>>> >>>> >> >>> > >>>>> > operations switched.  The scripts that happen to<br>
>>> break<br>
>>> >>>> are<br>
>>> >>>> >> doing<br>
>>> >>>> >> >>> > >>>>> something<br>
>>> >>>> >> >>> > >>>>> > pretty wacky/unnecessary.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > There's not any micro optimizations that I know of<br>
>>> >>>> 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<br>
>>> >>>> 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<br>
>>> general the<br>
>>> >>>> >> default<br>
>>> >>>> >> >>> > >>>>> XEngine<br>
>>> >>>> >> >>> > >>>>> > compiler's rules for global variable<br>
>>> >>>> >> >>> > >>>>> > declaration expression content are very lax in<br>
>>> >>>> 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<br>
>>> rules<br>
>>> >>>> >> >>> exactly, in<br>
>>> >>>> >> >>> > >>>>> its<br>
>>> >>>> >> >>> > >>>>> > default configuration.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > From my understanding a script moving to new a<br>
>>> region is<br>
>>> >>>> >> going<br>
>>> >>>> >> >>> to be<br>
>>> >>>> >> >>> > >>>>> > recompiled if the destination sim does not allow the<br>
>>> >>>> script<br>
>>> >>>> >> >>> binary<br>
>>> >>>> >> >>> > >>>>> > to transfer over and be executed.  This will be<br>
>>> true in<br>
>>> >>>> most<br>
>>> >>>> >> >>> cases<br>
>>> >>>> >> >>> > >>>>> because<br>
>>> >>>> >> >>> > >>>>> > the default settings disallow it, and it's unsafe to<br>
>>> >>>> enable.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > This would cause a problem for scripts from another<br>
>>> >>>> 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<br>
>>> >>>> crossing<br>
>>> >>>> >> for<br>
>>> >>>> >> >>> > >>>>> scripts<br>
>>> >>>> >> >>> > >>>>> > work; to see if I have to make the re-compile<br>
>>> sensitive<br>
>>> >>>> >> >>> > >>>>> >  to which compiler was used on the other sim,<br>
>>> >>>> regardless of<br>
>>> >>>> >> what<br>
>>> >>>> >> >>> > >>>>> version of<br>
>>> >>>> >> >>> > >>>>> > OpenSim it is running.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > I imagine this would be a requirement to connect a<br>
>>> sim<br>
>>> >>>> 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<br>
>>> >>>> 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<br>
>>> LibLSLCC<br>
>>> >>>> works<br>
>>> >>>> >> >>> fine on<br>
>>> >>>> >> >>> > >>>>> both<br>
>>> >>>> >> >>> > >>>>> > and has no problem generating code.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > LibraryDataScrapingTools works on OSX 10.11 even<br>
>>> with<br>
>>> >>>> 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<br>
>>> 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<br>
>>> did<br>
>>> >>>> not<br>
>>> >>>> >> look<br>
>>> >>>> >> >>> into<br>
>>> >>>> >> >>> > >>>>> it to<br>
>>> >>>> >> >>> > >>>>> > deeply as I was using a borrowed computer for a few<br>
>>> >>>> minutes,<br>
>>> >>>> >> >>> > >>>>> > that error prevented both LibraryDataScrapingTools<br>
>>> and<br>
>>> >>>> >> OpenSim<br>
>>> >>>> >> >>> from<br>
>>> >>>> >> >>> > >>>>> > starting.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > ==<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > As of now I have added a setting to allow implicit<br>
>>> cast<br>
>>> >>>> of<br>
>>> >>>> >> all<br>
>>> >>>> >> >>> types<br>
>>> >>>> >> >>> > >>>>> into<br>
>>> >>>> >> >>> > >>>>> > list within a function<br>
>>> >>>> >> >>> > >>>>> > calls parameter expressions, as Zadark had<br>
>>> mentioned.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > As it turns out, all of OpenSim's C# runtime types<br>
>>> >>>> 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<br>
>>> this<br>
>>> >>>> too:<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > list a = "";<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > list b = <0,0,0>;<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > I will probably change the setting to just allow<br>
>>> >>>> implicit<br>
>>> >>>> >> list<br>
>>> >>>> >> >>> cast<br>
>>> >>>> >> >>> > >>>>> > everywhere as an option,<br>
>>> >>>> >> >>> > >>>>> > and maybe add some syntax related compatibility<br>
>>> options<br>
>>> >>>> for<br>
>>> >>>> >> >>> global<br>
>>> >>>> >> >>> > >>>>> > variables.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > In the long run, if I can figure out how to make the<br>
>>> >>>> compiler<br>
>>> >>>> >> >>> addon<br>
>>> >>>> >> >>> > >>>>> aware<br>
>>> >>>> >> >>> > >>>>> > of re-compiles due to region<br>
>>> >>>> >> >>> > >>>>> > crossing, some syntax in-compatibility will not be a<br>
>>> >>>> major<br>
>>> >>>> >> >>> issue for<br>
>>> >>>> >> >>> > >>>>> > scripts that you cannot modify.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > If I could somehow select to re-compile them with<br>
>>> the<br>
>>> >>>> default<br>
>>> >>>> >> >>> XEngine<br>
>>> >>>> >> >>> > >>>>> > compiler  (if that's what they were originally<br>
>>> compiled<br>
>>> >>>> >> with),<br>
>>> >>>> >> >>> > >>>>> > then they will not be subject to LibLSLCC's stricter<br>
>>> >>>> syntax<br>
>>> >>>> >> >>> checking.<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > ==<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> > I have been working on a settings panel for the<br>
>>> editor<br>
>>> >>>> so I<br>
>>> >>>> >> can<br>
>>> >>>> >> >>> > >>>>> easily test<br>
>>> >>>> >> >>> > >>>>> > different<br>
>>> >>>> >> >>> > >>>>> > compiler configurations, and segregating some of the<br>
>>> >>>> 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<br>
>>> 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 <<br>
>>> >>>> <a href="mailto:melanie@t-data.com">melanie@t-data.com</a>><br>
>>> >>>> >> >>> wrote:<br>
>>> >>>> >> >>> > >>>>> ><br>
>>> >>>> >> >>> > >>>>> >> I would be against making the evaluation order<br>
>>> >>>> optional. It<br>
>>> >>>> >> >>> has long<br>
>>> >>>> >> >>> > >>>>> >> been recognized as a bug in XEngine's compiler and<br>
>>> >>>> people<br>
>>> >>>> >> >>> porting<br>
>>> >>>> >> >>> > >>>>> >> scripts from SL have been advised to remove<br>
>>> evaluation<br>
>>> >>>> order<br>
>>> >>>> >> >>> > >>>>> >> dependent code but not write any code that depends<br>
>>> on<br>
>>> >>>> the<br>
>>> >>>> >> wrong<br>
>>> >>>> >> >>> > >>>>> >> XEngine eval order. Therefore, if this compiler<br>
>>> breaks<br>
>>> >>>> >> content<br>
>>> >>>> >> >>> that<br>
>>> >>>> >> >>> > >>>>> >> content needs to be fixed, not a setting changed<br>
>>> 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<br>
>>> type<br>
>>> >>>> >> >>> validation<br>
>>> >>>> >> >>> > >>>>> system<br>
>>> >>>> >> >>> > >>>>> >> > just little so the syntax tree can be built with<br>
>>> >>>> these<br>
>>> >>>> >> types<br>
>>> >>>> >> >>> of<br>
>>> >>>> >> >>> > >>>>> implicit<br>
>>> >>>> >> >>> > >>>>> >> > conversion present.<br>
>>> >>>> >> >>> > >>>>> >> ><br>
>>> >>>> >> >>> > >>>>> >> > The code generator can then be made to generate<br>
>>> the<br>
>>> >>>> cast<br>
>>> >>>> >> when<br>
>>> >>>> >> >>> > >>>>> necessary,<br>
>>> >>>> >> >>> > >>>>> >> > since it will pass syntax checking.<br>
>>> >>>> >> >>> > >>>>> >> ><br>
>>> >>>> >> >>> > >>>>> >> > I think I am going to implement it as a<br>
>>> compatibility<br>
>>> >>>> >> option<br>
>>> >>>> >> >>> in<br>
>>> >>>> >> >>> > >>>>> the<br>
>>> >>>> >> >>> > >>>>> >> > compiler that you can turn on or off, depending<br>
>>> on<br>
>>> >>>> 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,<br>
>>> >>>> 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<br>
>>> plan<br>
>>> >>>> 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">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<br>
>>> parameters<br>
>>> >>>> to<br>
>>> >>>> >> the<br>
>>> >>>> >> >>> > >>>>> relevant<br>
>>> >>>> >> >>> > >>>>> >> type,<br>
>>> >>>> >> >>> > >>>>> >> >> though I can see this handy for novice<br>
>>> >>>> scriptwriters it<br>
>>> >>>> >> does<br>
>>> >>>> >> >>> > >>>>> encourage<br>
>>> >>>> >> >>> > >>>>> >> some<br>
>>> >>>> >> >>> > >>>>> >> >> less than elegant techniques<br>
>>> >>>> >> >>> > >>>>> >> >><br>
>>> >>>> >> >>> > >>>>> >> >> Some popular scripts freely available to OpenSim<br>
>>> >>>> use this<br>
>>> >>>> >> >>> > >>>>> feature:<br>
>>> >>>> >> >>> > >>>>> >> >> For instance:<br>
>>> >>>> >> >>> > >>>>> >> >> llListFindList takes 2 parameters of the type<br>
>>> List,<br>
>>> >>>> when<br>
>>> >>>> >> in<br>
>>> >>>> >> >>> fact<br>
>>> >>>> >> >>> > >>>>> the<br>
>>> >>>> >> >>> > >>>>> >> >> existing compiler permits any type (as far as we<br>
>>> >>>> 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,<br>
>>> the<br>
>>> >>>> >> >>> explanation<br>
>>> >>>> >> >>> > >>>>> is clear<br>
>>> >>>> >> >>> > >>>>> >> >> and precise so easy to fix (enable compile)<br>
>>> with a<br>
>>> >>>> local<br>
>>> >>>> >> >>> cast.<br>
>>> >>>> >> >>> > >>>>> >> >><br>
>>> >>>> >> >>> > >>>>> >> >> Z<br>
>>> >>>> >> >>> > >>>>> >> >><br>
>>> >>>> >> >>> > >>>>> >> >><br>
>>> >>>> >> >>> > >>>>> >> >> On 5 November 2015 at 12:52, Jak Daniels <<br>
>>> >>>> <a href="mailto:jak@ateb.co.uk">jak@ateb.co.uk</a><br>
>>> >>>> >> ><br>
>>> >>>> >> >>> wrote:<br>
>>> >>>> >> >>> > >>>>> >> >><br>
>>> >>>> >> >>> > >>>>> >> >>> Hi Eric,<br>
>>> >>>> >> >>> > >>>>> >> >>><br>
>>> >>>> >> >>> > >>>>> >> >>> yes I can confirm now that it does open and<br>
>>> compile<br>
>>> >>>> >> >>> correctly<br>
>>> >>>> >> >>> > >>>>> in VS C#<br>
>>> >>>> >> >>> > >>>>> >> >>> 2010 express now. Thank you.<br>
>>> >>>> >> >>> > >>>>> >> >>><br>
>>> >>>> >> >>> > >>>>> >> >>> I'm now installing VS2015 in a win10 virtual<br>
>>> >>>> machine so<br>
>>> >>>> >> I<br>
>>> >>>> >> >>> don't<br>
>>> >>>> >> >>> > >>>>> clobber<br>
>>> >>>> >> >>> > >>>>> >> >>> my SSD, so I can compile and play with the LSL<br>
>>> >>>> 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<br>
>>> >>>> message,<br>
>>> >>>> >> >>> and<br>
>>> >>>> >> >>> > >>>>> add some<br>
>>> >>>> >> >>> > >>>>> >> >>> info...<br>
>>> >>>> >> >>> > >>>>> >> >>><br>
>>> >>>> >> >>> > >>>>> >> >>> After removing the<br>
>>> "<LangVersion>5</LangVersion>"<br>
>>> >>>> stuff<br>
>>> >>>> >> >>> from the<br>
>>> >>>> >> >>> > >>>>> >> >>> non-editor related .csproj files,<br>
>>> >>>> >> >>> > >>>>> >> >>><br>
>>> >>>> >> >>> > >>>>> >> >>> I found that VS2010 is actually able to open<br>
>>> the<br>
>>> >>>> >> >>> > >>>>> >> >>> "MonoDevelop-LibLSLCC.sln" solution file in the<br>
>>> >>>> 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<br>
>>> the<br>
>>> >>>> >> .csproj<br>
>>> >>>> >> >>> files<br>
>>> >>>> >> >>> > >>>>> >> shortly,<br>
>>> >>>> >> >>> > >>>>> >> >>>  I will probably rename<br>
>>> "MonoDevelop-LibLSLCC.sln"<br>
>>> >>>> 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<br>
>>> solution<br>
>>> >>>> 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<br>
>>> working<br>
>>> >>>> with<br>
>>> >>>> >> >>> > >>>>> anything other<br>
>>> >>>> >> >>> > >>>>> >> >>> than vs2015,  but I will test with the prior<br>
>>> >>>> versions<br>
>>> >>>> >> >>> vs2012+<br>
>>> >>>> >> >>> > >>>>> to see<br>
>>> >>>> >> >>> > >>>>> >> what<br>
>>> >>>> >> >>> > >>>>> >> >>> all<br>
>>> >>>> >> >>> > >>>>> >> >>> works, then put some info in the README.md<br>
>>> about<br>
>>> >>>> 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>
>>> <<br>
>>> >>>> >> >>> > >>>>> <a href="mailto:eblundell800@gmail.com">eblundell800@gmail.com</a><br>
>>> >>>> >> >>> > >>>>> >> ><br>
>>> >>>> >> >>> > >>>>> >> >>> wrote:<br>
>>> >>>> >> >>> > >>>>> >> >>><br>
>>> >>>> >> >>> > >>>>> >> >>>> Thanks for letting me know about this problem<br>
>>> 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<br>
>>> indeed<br>
>>> >>>> seem<br>
>>> >>>> >> to<br>
>>> >>>> >> >>> be a<br>
>>> >>>> >> >>> > >>>>> problem<br>
>>> >>>> >> >>> > >>>>> >> >>>> with vs2010 C#.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I was unable to find an updated download for<br>
>>> >>>> vs2010 C#<br>
>>> >>>> >> to<br>
>>> >>>> >> >>> test<br>
>>> >>>> >> >>> > >>>>> with,<br>
>>> >>>> >> >>> > >>>>> >> >>>> only an SP1 ISO I found on stackoverflow:<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><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<br>
>>> version<br>
>>> >>>> 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<br>
>>> certain<br>
>>> >>>> >> >>> projects in<br>
>>> >>>> >> >>> > >>>>> my<br>
>>> >>>> >> >>> > >>>>> >> build.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I cannot get it to update from SP1, I am<br>
>>> 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<br>
>>> use<br>
>>> >>>> windows<br>
>>> >>>> >> >>> update<br>
>>> >>>> >> >>> > >>>>> which<br>
>>> >>>> >> >>> > >>>>> >> >>>> does not seem to find any updates related to<br>
>>> 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<br>
>>> because<br>
>>> >>>> it<br>
>>> >>>> >> was<br>
>>> >>>> >> >>> > >>>>> building<br>
>>> >>>> >> >>> > >>>>> >> >>>> against .NET 4.5.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I downgraded LibraryDataScrapingTools to .NET<br>
>>> >>>> 4.0  and<br>
>>> >>>> >> >>> > >>>>> re-installed<br>
>>> >>>> >> >>> > >>>>> >> the<br>
>>> >>>> >> >>> > >>>>> >> >>>> 'System.Data.Sqlite.Core' package from nuget<br>
>>> 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<br>
>>> >>>> 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<br>
>>> >>>> compatible.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> The LSLCCEditor related projects I am pretty<br>
>>> sure<br>
>>> >>>> are<br>
>>> >>>> >> >>> > >>>>> incompatible at<br>
>>> >>>> >> >>> > >>>>> >> >>>> the moment due to the .NET framework level<br>
>>> they<br>
>>> >>>> >> require as<br>
>>> >>>> >> >>> > >>>>> well.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> The code base for LSLCCEditor requires a<br>
>>> minimum<br>
>>> >>>> of<br>
>>> >>>> >> .NET<br>
>>> >>>> >> >>> 4.5 to<br>
>>> >>>> >> >>> > >>>>> >> compile,<br>
>>> >>>> >> >>> > >>>>> >> >>>> and the code changes required to make the<br>
>>> editor<br>
>>> >>>> >> projects<br>
>>> >>>> >> >>> > >>>>> >> >>>> compatible with .NET 4.0 are not as trivial<br>
>>> 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<br>
>>> LSLCCEditor<br>
>>> >>>> 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<br>
>>> >>>> compatibility<br>
>>> >>>> >> >>> profile<br>
>>> >>>> >> >>> > >>>>> is not<br>
>>> >>>> >> >>> > >>>>> >> >>>> necessary.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I also noticed when installing WiX v3.10.1 on<br>
>>> a<br>
>>> >>>> Virtual<br>
>>> >>>> >> >>> > >>>>> Machine with<br>
>>> >>>> >> >>> > >>>>> >> >>>> vs2010 installed that It does not try to<br>
>>> register<br>
>>> >>>> >> itself<br>
>>> >>>> >> >>> with<br>
>>> >>>> >> >>> > >>>>> vs2010<br>
>>> >>>> >> >>> > >>>>> >> as a<br>
>>> >>>> >> >>> > >>>>> >> >>>> project type.<br>
>>> >>>> >> >>> > >>>>> >> >>>> I do not think the latest version of WiX<br>
>>> installer<br>
>>> >>>> >> >>> framework<br>
>>> >>>> >> >>> > >>>>> supports<br>
>>> >>>> >> >>> > >>>>> >> >>>> vs2010 anymore.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> === How I got LibLSLCC,<br>
>>> LibraryDataScrapingTools,<br>
>>> >>>> >> >>> lslcc_cmd and<br>
>>> >>>> >> >>> > >>>>> >> DemoArea<br>
>>> >>>> >> >>> > >>>>> >> >>>>  to build.  ===<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> After the code changes to<br>
>>> >>>> LibraryDataScrapingTools and<br>
>>> >>>> >> >>> > >>>>> downgrading the<br>
>>> >>>> >> >>> > >>>>> >> >>>> .NET Framework level...<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I created a new vs2010 project and added<br>
>>> >>>> (LibLSLCC,<br>
>>> >>>> >> >>> > >>>>> >> >>>> LibraryDataScrapingTools, lslcc_cmd and<br>
>>> DemoArea)<br>
>>> >>>> as<br>
>>> >>>> >> >>> existing<br>
>>> >>>> >> >>> > >>>>> >> projects.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> When trying to build these projects I got the<br>
>>> >>>> message<br>
>>> >>>> >> >>> "Error 1<br>
>>> >>>> >> >>> > >>>>> Invalid<br>
>>> >>>> >> >>> > >>>>> >> >>>> option '5' for /langversion; must be ISO-1,<br>
>>> >>>> ISO-2, 3 or<br>
>>> >>>> >> >>> > >>>>> Default"<br>
>>> >>>> >> >>> > >>>>> >> >>>> for all of the projects except 'DemoArea'<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I resolved this by manually editing the<br>
>>> .csproj<br>
>>> >>>> file<br>
>>> >>>> >> for<br>
>>> >>>> >> >>> each<br>
>>> >>>> >> >>> > >>>>> >> >>>> non-building project in a text editor,<br>
>>> removing<br>
>>> >>>> the<br>
>>> >>>> >> >>> > >>>>> occurrences of:<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> <LangVersion>5</LangVersion><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> That particular MSBuild setting is not<br>
>>> necessary<br>
>>> >>>> for<br>
>>> >>>> >> >>> vs2015 or<br>
>>> >>>> >> >>> > >>>>> Mono to<br>
>>> >>>> >> >>> > >>>>> >> >>>> build the library anyway, so I am going to<br>
>>> remove<br>
>>> >>>> it<br>
>>> >>>> >> and<br>
>>> >>>> >> >>> > >>>>> commit the<br>
>>> >>>> >> >>> > >>>>> >> changes.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> After that, LibLSLCC,<br>
>>> 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<br>
>>> 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,<br>
>>> >>>> command<br>
>>> >>>> >> line<br>
>>> >>>> >> >>> > >>>>> compiler,<br>
>>> >>>> >> >>> > >>>>> >> >>>> library data scraper and demo project with<br>
>>> vs2010.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> Unfortunately making LSLCCEditor build in<br>
>>> vs2010<br>
>>> >>>> would<br>
>>> >>>> >> >>> require<br>
>>> >>>> >> >>> > >>>>> some<br>
>>> >>>> >> >>> > >>>>> >> non<br>
>>> >>>> >> >>> > >>>>> >> >>>> trivial code changes, a new method of<br>
>>> triggering<br>
>>> >>>> the<br>
>>> >>>> >> WiX<br>
>>> >>>> >> >>> > >>>>> installer<br>
>>> >>>> >> >>> > >>>>> >> build,<br>
>>> >>>> >> >>> > >>>>> >> >>>> and a downgrade from .NET 4.5 to .NET 4.0 for<br>
>>> the<br>
>>> >>>> >> editor<br>
>>> >>>> >> >>> > >>>>> related<br>
>>> >>>> >> >>> > >>>>> >> >>>> projects.<br>
>>> >>>> >> >>> > >>>>> >> >>>><br>
>>> >>>> >> >>> > >>>>> >> >>>> I'm not sure if I want to make these changes<br>
>>> to<br>
>>> >>>> the<br>
>>> >>>> >> Editor<br>
>>> >>>> >> >>> > >>>>> portion of<br>
>>> >>>> >> >>> > >>>>> >> >>>> the project just for the sake of being<br>
>>> compatible<br>
>>> >>>> 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>
>>> < <<br>
>>> >>>> >> >>> <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<br>
>>> >>>> group. This<br>
>>> >>>> >> >>> all<br>
>>> >>>> >> >>> > >>>>> looks very<br>
>>> >>>> >> >>> > >>>>> >> >>>>> promising, and I was intrigued to give it a<br>
>>> try.<br>
>>> >>>> >> >>> > >>>>> >> >>>>> I checked out the source from github and I<br>
>>> tried<br>
>>> >>>> >> >>> building in<br>
>>> >>>> >> >>> > >>>>> VS C#<br>
>>> >>>> >> >>> > >>>>> >> 2010<br>
>>> >>>> >> >>> > >>>>> >> >>>>> express... but only 3 of the projects will<br>
>>> load.<br>
>>> >>>> >> >>> > >>>>> >> LibraryDataScrapingTools,<br>
>>> >>>> >> >>> > >>>>> >> >>>>> LSLCCEditor, LSLCCEditor.CompletionUI all say<br>
>>> >>>> >> >>> (incompatible)<br>
>>> >>>> >> >>> > >>>>> and<br>
>>> >>>> >> >>> > >>>>> >> >>>>> LSLCCEditorInstaller says (unavailable) even<br>
>>> >>>> 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<br>
>>> last<br>
>>> >>>> time I<br>
>>> >>>> >> >>> > >>>>> installed<br>
>>> >>>> >> >>> > >>>>> >> VS2013<br>
>>> >>>> >> >>> > >>>>> >> >>>>> it just dumped everything onto my SSD c:<br>
>>> drive<br>
>>> >>>> and<br>
>>> >>>> >> >>> filled it<br>
>>> >>>> >> >>> > >>>>> up,<br>
>>> >>>> >> >>> > >>>>> >> with no<br>
>>> >>>> >> >>> > >>>>> >> >>>>> option to put things on drive D: my large<br>
>>> >>>> harddrive.<br>
>>> >>>> >> It<br>
>>> >>>> >> >>> also<br>
>>> >>>> >> >>> > >>>>> left a<br>
>>> >>>> >> >>> > >>>>> >> mess<br>
>>> >>>> >> >>> > >>>>> >> >>>>> behind (more than 50% of itself including<br>
>>> MSSQL<br>
>>> >>>> server<br>
>>> >>>> >> >>> stuff)<br>
>>> >>>> >> >>> > >>>>> when I<br>
>>> >>>> >> >>> > >>>>> >> tried<br>
>>> >>>> >> >>> > >>>>> >> >>>>> to uninstall it. VS2015 might be better now<br>
>>> in<br>
>>> >>>> this<br>
>>> >>>> >> >>> respect,<br>
>>> >>>> >> >>> > >>>>> but<br>
>>> >>>> >> >>> > >>>>> >> knowing MS<br>
>>> >>>> >> >>> > >>>>> >> >>>>> products probably not! I also found VS2013<br>
>>> to be<br>
>>> >>>> way,<br>
>>> >>>> >> way<br>
>>> >>>> >> >>> > >>>>> slower<br>
>>> >>>> >> >>> > >>>>> >> loading up<br>
>>> >>>> >> >>> > >>>>> >> >>>>> large projects like OpenSimulator than<br>
>>> VS2010. So<br>
>>> >>>> >> before<br>
>>> >>>> >> >>> I<br>
>>> >>>> >> >>> > >>>>> take the<br>
>>> >>>> >> >>> > >>>>> >> >>>>> possibly irreversible path of installing<br>
>>> VS2015,<br>
>>> >>>> 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<br>
>>> >>>> at-least<br>
>>> >>>> >> >>> sharing<br>
>>> >>>> >> >>> > >>>>> stuff I<br>
>>> >>>> >> >>> > >>>>> >> >>>>> have made..) but for a quite a while now I<br>
>>> have<br>
>>> >>>> been<br>
>>> >>>> >> >>> working<br>
>>> >>>> >> >>> > >>>>> on<br>
>>> >>>> >> >>> > >>>>> >> >>>>> a new (BSD Licensed) Compilation/Code<br>
>>> Generation<br>
>>> >>>> >> >>> framework<br>
>>> >>>> >> >>> > >>>>> for LSL,<br>
>>> >>>> >> >>> > >>>>> >> >>>>> tailored towards usage with OpenSim.  I<br>
>>> 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"<br>
>>> compiler<br>
>>> >>>> front<br>
>>> >>>> >> >>> end.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> It's built on-top of ANTLR4 and ANTLR4's<br>
>>> CSharp<br>
>>> >>>> >> target.<br>
>>> >>>> >> >>> > >>>>> >> >>>>> ANTLR4 however has been completely abstracted<br>
>>> >>>> and the<br>
>>> >>>> >> >>> library<br>
>>> >>>> >> >>> > >>>>> >> provides<br>
>>> >>>> >> >>> > >>>>> >> >>>>> its own Rich LSL Syntax Tree for users to<br>
>>> deal<br>
>>> >>>> with.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> My library includes an OpenSim code<br>
>>> generation<br>
>>> >>>> target<br>
>>> >>>> >> >>> which I<br>
>>> >>>> >> >>> > >>>>> have<br>
>>> >>>> >> >>> > >>>>> >> >>>>> integrated into my OpenSim fork on GitHub,<br>
>>> 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<br>
>>> when<br>
>>> >>>> >> >>> building a<br>
>>> >>>> >> >>> > >>>>> syntax<br>
>>> >>>> >> >>> > >>>>> >> >>>>> tree implements full front end syntax<br>
>>> checking,<br>
>>> >>>> dead<br>
>>> >>>> >> code<br>
>>> >>>> >> >>> > >>>>> detection,<br>
>>> >>>> >> >>> > >>>>> >> the<br>
</div></div><div class="HOEnZb"><div class="h5">>>> >>>> >> >>> > >>>>> >> >>>>> works.<br>
>>> >>>> >> >>> > >>>>> >> >>>>> It also emits extended warning information<br>
>>> that<br>
>>> >>>> is<br>
>>> >>>> >> >>> standard<br>
>>> >>>> >> >>> > >>>>> to most<br>
>>> >>>> >> >>> > >>>>> >> >>>>> compilers now days.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> The OpenSim code generator I have written and<br>
>>> >>>> included<br>
>>> >>>> >> >>> with<br>
>>> >>>> >> >>> > >>>>> the<br>
>>> >>>> >> >>> > >>>>> >> library<br>
>>> >>>> >> >>> > >>>>> >> >>>>> drastically improves compatibility with<br>
>>> scripts<br>
>>> >>>> >> written<br>
>>> >>>> >> >>> for<br>
>>> >>>> >> >>> > >>>>> >> SecondLife.<br>
>>> >>>> >> >>> > >>>>> >> >>>>> Order of evaluation in generated code is<br>
>>> correct<br>
>>> >>>> for<br>
>>> >>>> >> LSL<br>
>>> >>>> >> >>> > >>>>> (Right to<br>
>>> >>>> >> >>> > >>>>> >> >>>>> Left) among many other things.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> As an example, all of the encryption scripts<br>
>>> you<br>
>>> >>>> can<br>
>>> >>>> >> >>> find on<br>
>>> >>>> >> >>> > >>>>> the LSL<br>
>>> >>>> >> >>> > >>>>> >> >>>>> wiki will compile correctly and execute with<br>
>>> >>>> correct<br>
>>> >>>> >> >>> behavior<br>
>>> >>>> >> >>> > >>>>> using<br>
>>> >>>> >> >>> > >>>>> >> my<br>
>>> >>>> >> >>> > >>>>> >> >>>>> compiler.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> The README.md for the project goes into a bit<br>
>>> >>>> more<br>
>>> >>>> >> >>> detail on<br>
>>> >>>> >> >>> > >>>>> what all<br>
>>> >>>> >> >>> > >>>>> >> >>>>> the library can do.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> My library LibLSLCC is on GitHub here:<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
</div></div><div class="HOEnZb"><div class="h5">>>> >>>> >> >>> > >>>>> >> >>>>> <<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<br>
>>> >>>> Only, I<br>
>>> >>>> >> used<br>
>>> >>>> >> >>> > >>>>> AvalonEdit)<br>
>>> >>>> >> >>> > >>>>> >> >>>>> with the project that features code<br>
>>> completion<br>
>>> >>>> and<br>
>>> >>>> >> syntax<br>
>>> >>>> >> >>> > >>>>> >> highlighting.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> It can be used to test CSharp code<br>
>>> generation for<br>
>>> >>>> >> >>> OpenSim by<br>
>>> >>>> >> >>> > >>>>> >> compiling<br>
>>> >>>> >> >>> > >>>>> >> >>>>> LSL into C# using LibLSLCC, which can then be<br>
>>> >>>> uploaded<br>
>>> >>>> >> >>> to an<br>
>>> >>>> >> >>> > >>>>> >> >>>>> OpenSim server with C# scripting enabled.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> The library itself is cross-platform, but the<br>
>>> >>>> editor<br>
>>> >>>> >> and<br>
>>> >>>> >> >>> > >>>>> editor<br>
>>> >>>> >> >>> > >>>>> >> >>>>> installer are not.  There's a separate<br>
>>> project<br>
>>> >>>> file<br>
</div></div><span class="im HOEnZb">>>> >>>> >> for<br>
>>> >>>> >> >>> > >>>>> building the<br>
>>> >>>> >> >>> > >>>>> >> >>>>> library on<br>
</span><div class="HOEnZb"><div class="h5">>>> >>>> >> >>> > >>>>> >> >>>>> mono with monodevelop/xbuild.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> ===<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> The OpenSim fork that integrates my compiler<br>
>>> is<br>
>>> >>>> here:<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> <<br>
>>> >>>> <a href="https://github.com/EriHoss/OpenSim_With_LibLSLCC" rel="noreferrer" target="_blank">https://github.com/EriHoss/OpenSim_With_LibLSLCC</a>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><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<br>
>>> and<br>
>>> >>>> >> Runtime<br>
>>> >>>> >> >>> > >>>>> Script<br>
>>> >>>> >> >>> > >>>>> >> >>>>> functions.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> Such as the 'IdleTimeout' setting not being<br>
>>> >>>> honored<br>
>>> >>>> >> >>> properly.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> And llParseString2List using culture specific<br>
>>> >>>> >> >>> comparisons,<br>
>>> >>>> >> >>> > >>>>> causing it<br>
>>> >>>> >> >>> > >>>>> >> >>>>> to misbehave when comparing Unicode<br>
>>> characters on<br>
>>> >>>> >> Mono.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> I have added new attributes to OpenSim's<br>
>>> script<br>
>>> >>>> module<br>
>>> >>>> >> >>> > >>>>> >> >>>>> constants/functions and also to<br>
>>> ScriptBaseClass.<br>
>>> >>>> >> >>> > >>>>> >> >>>>> This is so LibLSLCC can de-serialize the<br>
>>> classes<br>
>>> >>>> into<br>
>>> >>>> >> >>> library<br>
>>> >>>> >> >>> > >>>>> data<br>
>>> >>>> >> >>> > >>>>> >> >>>>> that's consumable by its code validator and<br>
>>> 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<br>
>>> >>>> before, so<br>
>>> >>>> >> >>> you<br>
>>> >>>> >> >>> > >>>>> can switch<br>
>>> >>>> >> >>> > >>>>> >> >>>>> back and forth from LibLSLCC to the old<br>
>>> compiler<br>
>>> >>>> >> >>> > >>>>> >> >>>>> if you want without any problems.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> There are more details on the changes I have<br>
>>> >>>> made in<br>
>>> >>>> >> the<br>
>>> >>>> >> >>> > >>>>> README.md.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> ==<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> I started working on this sometime early last<br>
>>> >>>> year<br>
>>> >>>> >> when I<br>
>>> >>>> >> >>> > >>>>> broke my<br>
>>> >>>> >> >>> > >>>>> >> >>>>> wrist and was unable to do much for a while,<br>
>>> and<br>
>>> >>>> >> >>> > >>>>> >> >>>>> I have only recently moved the code from my<br>
>>> Git<br>
>>> >>>> server<br>
>>> >>>> >> >>> up to<br>
>>> >>>> >> >>> > >>>>> GitHub.<br>
>>> >>>> >> >>> > >>>>> >> >>>>> I'm going to continue improving this in my<br>
>>> spare<br>
>>> >>>> time,<br>
>>> >>>> >> >>> > >>>>> >> >>>>> right now I am doing rolling releases<br>
>>> versioned<br>
>>> >>>> by<br>
>>> >>>> >> date<br>
>>> >>>> >> >>> > >>>>> anywhere from<br>
>>> >>>> >> >>> > >>>>> >> >>>>> once every few days to a few times a day.  I<br>
>>> am<br>
>>> >>>> also<br>
>>> >>>> >> >>> keeping<br>
>>> >>>> >> >>> > >>>>> my<br>
>>> >>>> >> >>> > >>>>> >> OpenSim<br>
>>> >>>> >> >>> > >>>>> >> >>>>> fork synced with the latest OpenSim commits.<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>> Hopefully this will be useful, any feedback<br>
>>> is<br>
>>> >>>> >> >>> appreciated :)<br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> >>>> >> >>> > >>>>> >> >>>>><br>
>>> _______________________________________________<br>
>>> >>>> >> >>> > >>>>> >> >>>>> Opensim-dev mailing listOpensim-dev<br>
>>> >>>> >> >>> @opensimulator.orghttp://<br>
>>> >>>> >> >>> > >>>>> >><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>
>>> _______________________________________________<br>
>>> >>>> >> >>> > >>>>> >> >>>>> Opensim-dev mailing list<br>
>>> >>>> >> >>> > >>>>> >> >>>>> <a href="mailto:Opensim-dev@opensimulator.org">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>
>>> >>>> >> >>> > >>>>> >><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>
>>> >>>> >> >>> > >>>>> >> >>><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>
>>> >>>> >> >>> > >>>>> >> >><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>
>>> >>>> >> >>> > >>>>> >> ><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>
>>> >>>> >> >>> > >>>>> >><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>
>>> >>>> >> >>> > >>>>> ><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>
>>> >>>> >> >>> > >>>>><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>
>>> >>>> >> >>> > >>>><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>
>>> >>>> >> >>> > >>><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>
>>> >>>> >> >>> > >><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>
>>> >>>> >> >>> > ><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>
>>> >>>> >> >>> ><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>
>>> >>>> >> >>><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>
>>> >>>> >> _______________________________________________<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>
>>> >>>><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>
>>><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>