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