<p dir="ltr">Alright, there is another way I can reflect call information from there.</p>
<p dir="ltr">I can change to converting the CSharp types in the the LSL Api constants/functions to their corresponding LSL type instead of having them attributed.  </p>
<p dir="ltr">The attributes are for reflecting call signatures <br>
and constant types that can be used for syntax checking and overload resolution.  The signature info for the library can be also be generated dynamically using a converter to convert the CSharp types when the methods/fields are reflected upon.<br></p>
<p dir="ltr">However, the attributes themselves do not change interaction with these classes from the outside.</p>
<p dir="ltr">I think place where it would break things for other people would be on merge,  if they had already modified these files themselves and added their own set of function/parameter attributes that are conflicting in the source code.</p>
<p dir="ltr">=</p>
<p dir="ltr">I am using these attributes also on optional module functions and constants, these are there along with the original ScriptConstant and ScriptFunction attributes which have not been altered or removed.</p>
<p dir="ltr">Does that need to be changed as well? </p>
<div class="gmail_quote">On Nov 16, 2015 7:09 PM, "Melanie" <<a href="mailto:melanie@t-data.com">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">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>> 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>> wrote:<br>
><br>
>> Here's the change, it was easy enough to fix from here.<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>> 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 what<br>
>>> OpenSim.ini says<br>
>>><br>
>>> I am currently out of town for the weekend and have spotty coverage,  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 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 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 with<br>
>>>> my<br>
>>>> > latest I can do this.<br>
>>>> ><br>
>>>> > I am unsure what the mode of operation is for ongoing contributions,<br>
>>>> just<br>
>>>> > let me know.<br>
>>>> ><br>
>>>> > The compiler does inject co-op termination calls where necessary 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 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 the<br>
>>>> wiki.<br>
>>>> >> ><br>
>>>> >> > ==<br>
>>>> >> ><br>
>>>> >> > I've since put up a new release, the editor now contains a working<br>
>>>> config<br>
>>>> >> > pane for the compiler in the settings window, and uses a LibLSLCC<br>
>>>> 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<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 well<br>
>>>> as<br>
>>>> >> > preservation and printing of negative signed zeros.  hex string 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 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<br>
>>>> 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">eblundell800@gmail.com</a>><br>
>>>> 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">melanie@t-data.com</a>><br>
>>>> wrote:<br>
>>>> >> >><br>
>>>> >> >>> The [1] != [2,3] test would yield 1 because the c# notion of 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 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<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 (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<br>
>>>> 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<br>
>>>> 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<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 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, 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<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 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" <<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 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 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 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 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 logic<br>
>>>> is<br>
>>>> >> >>> segregated<br>
>>>> >> >>> > >>> out in the library.<br>
>>>> >> >>> > >>><br>
>>>> >> >>> > >>><br>
>>>> >> >>> > >>> At the moment I am tidying up some things and updating 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 the<br>
>>>> >> default<br>
>>>> >> >>> > >>> XEngine compiler, I have put at least one script 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 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">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<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 constructs.<br>
>>>> 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<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 <<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 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 not<br>
>>>> 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<br>
>>>> also<br>
>>>> >> not<br>
>>>> >> >>> > >>>>> necessary as the better compiler will be used by all in<br>
>>>> short<br>
>>>> >> >>> order.<br>
>>>> >> >>> > >>>>> People will fix their scripts and everyone will be 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 hacks<br>
>>>> were<br>
>>>> >> not<br>
>>>> >> >>> > >>>>> possible<br>
>>>> >> >>> > >>>>> > beforehand while using XEngines compiler,<br>
>>>> >> >>> > >>>>> > there is probably not to many people with code that's<br>
>>>> going<br>
>>>> >> to<br>
>>>> >> >>> behave<br>
>>>> >> >>> > >>>>> > incorrectly with the evaluation order of binary<br>
>>>> >> >>> > >>>>> > operations switched.  The scripts that happen to 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 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 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<br>
>>>> script<br>
>>>> >> >>> binary<br>
>>>> >> >>> > >>>>> > to transfer over and be executed.  This will be 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 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 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 LibLSLCC<br>
>>>> works<br>
>>>> >> >>> fine on<br>
>>>> >> >>> > >>>>> both<br>
>>>> >> >>> > >>>>> > and has no problem generating code.<br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> > LibraryDataScrapingTools works on OSX 10.11 even 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 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<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 and<br>
>>>> >> OpenSim<br>
>>>> >> >>> from<br>
>>>> >> >>> > >>>>> > starting.<br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> > ==<br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> > As of now I have added a setting to allow implicit cast<br>
>>>> 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<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 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 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 the<br>
>>>> 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<br>
>>>> syntax<br>
>>>> >> >>> checking.<br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> > ==<br>
>>>> >> >>> > >>>>> ><br>
>>>> >> >>> > >>>>> > I have been working on a settings panel for the 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 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 evaluation<br>
>>>> order<br>
>>>> >> >>> > >>>>> >> dependent code but not write any code that depends on<br>
>>>> 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<br>
>>>> these<br>
>>>> >> types<br>
>>>> >> >>> of<br>
>>>> >> >>> > >>>>> implicit<br>
>>>> >> >>> > >>>>> >> > conversion present.<br>
>>>> >> >>> > >>>>> >> ><br>
>>>> >> >>> > >>>>> >> > The code generator can then be made to generate 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 compatibility<br>
>>>> >> option<br>
>>>> >> >>> in<br>
>>>> >> >>> > >>>>> the<br>
>>>> >> >>> > >>>>> >> > compiler that you can turn on or off, depending 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 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 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 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, the<br>
>>>> >> >>> explanation<br>
>>>> >> >>> > >>>>> is clear<br>
>>>> >> >>> > >>>>> >> >> and precise so easy to fix (enable compile) 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 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 "<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 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 the<br>
>>>> >> .csproj<br>
>>>> >> >>> files<br>
>>>> >> >>> > >>>>> >> shortly,<br>
>>>> >> >>> > >>>>> >> >>>  I will probably rename "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 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 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 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>
>>>> >> >>> > >>>>> <a href="mailto:eblundell800@gmail.com">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<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>
>>>> <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<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 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<br>
>>>> 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<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 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 sure<br>
>>>> 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<br>
>>>> 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<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 a<br>
>>>> 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<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 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 .csproj<br>
>>>> file<br>
>>>> >> for<br>
>>>> >> >>> each<br>
>>>> >> >>> > >>>>> >> >>>> non-building project in a text editor, removing<br>
>>>> the<br>
>>>> >> >>> > >>>>> occurrences of:<br>
>>>> >> >>> > >>>>> >> >>>><br>
>>>> >> >>> > >>>>> >> >>>> <LangVersion>5</LangVersion><br>
>>>> >> >>> > >>>>> >> >>>><br>
>>>> >> >>> > >>>>> >> >>>><br>
>>>> >> >>> > >>>>> >> >>>> That particular MSBuild setting is not necessary<br>
>>>> for<br>
>>>> >> >>> vs2015 or<br>
>>>> >> >>> > >>>>> Mono to<br>
>>>> >> >>> > >>>>> >> >>>> build the library anyway, so I am going to remove<br>
>>>> 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,<br>
>>>> command<br>
>>>> >> line<br>
>>>> >> >>> > >>>>> compiler,<br>
>>>> >> >>> > >>>>> >> >>>> library data scraper and demo project with vs2010.<br>
>>>> >> >>> > >>>>> >> >>>><br>
>>>> >> >>> > >>>>> >> >>>><br>
>>>> >> >>> > >>>>> >> >>>> Unfortunately making LSLCCEditor build in vs2010<br>
>>>> would<br>
>>>> >> >>> require<br>
>>>> >> >>> > >>>>> some<br>
>>>> >> >>> > >>>>> >> non<br>
>>>> >> >>> > >>>>> >> >>>> trivial code changes, a new method of triggering<br>
>>>> 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<br>
>>>> the<br>
>>>> >> Editor<br>
>>>> >> >>> > >>>>> portion of<br>
>>>> >> >>> > >>>>> >> >>>> the project just for the sake of being 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>
>>>> >> >>> <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 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<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 last<br>
>>>> time I<br>
>>>> >> >>> > >>>>> installed<br>
>>>> >> >>> > >>>>> >> VS2013<br>
>>>> >> >>> > >>>>> >> >>>>> it just dumped everything onto my SSD c: 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 MSSQL<br>
>>>> server<br>
>>>> >> >>> stuff)<br>
>>>> >> >>> > >>>>> when I<br>
>>>> >> >>> > >>>>> >> tried<br>
>>>> >> >>> > >>>>> >> >>>>> to uninstall it. VS2015 might be better now in<br>
>>>> this<br>
>>>> >> >>> respect,<br>
>>>> >> >>> > >>>>> but<br>
>>>> >> >>> > >>>>> >> knowing MS<br>
>>>> >> >>> > >>>>> >> >>>>> products probably not! I also found VS2013 to be<br>
>>>> 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,<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 have<br>
>>>> 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<br>
>>>> 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<br>
>>>> and the<br>
>>>> >> >>> library<br>
>>>> >> >>> > >>>>> >> provides<br>
>>>> >> >>> > >>>>> >> >>>>> its own Rich LSL Syntax Tree for users to deal<br>
>>>> with.<br>
>>>> >> >>> > >>>>> >> >>>>><br>
>>>> >> >>> > >>>>> >> >>>>> My library includes an OpenSim code generation<br>
>>>> 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,<br>
>>>> dead<br>
>>>> >> code<br>
>>>> >> >>> > >>>>> detection,<br>
>>>> >> >>> > >>>>> >> the<br>
>>>> >> >>> > >>>>> >> >>>>> works.<br>
>>>> >> >>> > >>>>> >> >>>>> It also emits extended warning information 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 scripts<br>
>>>> >> written<br>
>>>> >> >>> for<br>
>>>> >> >>> > >>>>> >> SecondLife.<br>
>>>> >> >>> > >>>>> >> >>>>> Order of evaluation in generated code is correct<br>
>>>> for<br>
>>>> >> LSL<br>
>>>> >> >>> > >>>>> (Right to<br>
>>>> >> >>> > >>>>> >> >>>>> Left) among many other things.<br>
>>>> >> >>> > >>>>> >> >>>>><br>
>>>> >> >>> > >>>>> >> >>>>> As an example, all of the encryption scripts 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>
>>>> >> >>> > >>>>> >> >>>>> <<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 completion<br>
>>>> 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<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 project<br>
>>>> 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<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>
>>>> >> >>> > >>>>> >> >>>>> <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<br>
>>>> 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<br>
>>>> module<br>
>>>> >> >>> > >>>>> >> >>>>> constants/functions and also to ScriptBaseClass.<br>
>>>> >> >>> > >>>>> >> >>>>> This is so LibLSLCC can de-serialize the classes<br>
>>>> 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<br>
>>>> 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<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, and<br>
>>>> >> >>> > >>>>> >> >>>>> I have only recently moved the code from my Git<br>
>>>> server<br>
>>>> >> >>> up to<br>
>>>> >> >>> > >>>>> GitHub.<br>
>>>> >> >>> > >>>>> >> >>>>> I'm going to continue improving this in my spare<br>
>>>> time,<br>
>>>> >> >>> > >>>>> >> >>>>> right now I am doing rolling releases versioned<br>
>>>> by<br>
>>>> >> date<br>
>>>> >> >>> > >>>>> anywhere from<br>
>>>> >> >>> > >>>>> >> >>>>> once every few days to a few times a day.  I 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 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">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">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>
>>>> >> >>> > > <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>
>>>> >> > _______________________________________________<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>
</blockquote></div>