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