[Opensim-dev] My new LSL compiler project
Melanie
melanie at t-data.com
Tue Nov 17 17:06:12 UTC 2015
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 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 <e800 at gmail.com>
> 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" <melanie at t-data.com> 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 wrote:
>>> > Avination*
>>> > On Nov 16, 2015 7:01 PM, "Eric " <e800 at gmail.com>
>>> 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 " <e800 at gmail.com>
>>> 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 " <e800 at gmail.com>
>>> 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" <melanie at t-data.com> 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 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" <melanie at t-data.com> 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 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 " <e800 at gmail.com
>>> >
>>> >>>> wrote:
>>> >>>> >> >
>>> >>>> >> >> TIL that that ([0,0] != [0,0]) is (length(left) -
>>> length(right)).
>>> >>>> >> >> interesting.
>>> >>>> >> >>
>>> >>>> >> >> On Mon, Nov 9, 2015 at 3:47 PM, Melanie <melanie at t-data.com>
>>> >>>> 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 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 <
>>> >>>> >> >>> > nebadon2025 at gmail.com> wrote:
>>> >>>> >> >>> >
>>> >>>> >> >>> > > doesnt LL use their own forked version of mono?
>>> >>>> >> >>> > > On Nov 9, 2015 10:38 AM, "Blake" <
>>> techplex.engineer at gmail.com
>>> >>>> >
>>> >>>> >> 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 <
>>> >>>> >> >>> e800 at gmail.com>
>>> >>>> >> >>> > >> 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 <
>>> >>>> >> >>> zadarkportal at gmail.com>
>>> >>>> >> >>> > >>> 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 <
>>> melanie at t-data.com>
>>> >>>> >> 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 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 <
>>> >>>> melanie at t-data.com>
>>> >>>> >> >>> 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 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" <
>>> >>>> >> >>> zadarkportal at gmail.com>
>>> >>>> >> >>> > >>>>> 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 <
>>> >>>> jak at ateb.co.uk
>>> >>>> >> >
>>> >>>> >> >>> 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 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
>>> <
>>> >>>> >> >>> > >>>>> e800 at gmail.com
>>> >>>> >> >>> > >>>>> >> >
>>> >>>> >> >>> > >>>>> >> >>> 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
>>> < <
>>> >>>> >> >>> jak at ateb.co.uk
>>> >>>> >> >>> > >>>>> >
>>> >>>> >> >>> > >>>>> >> >>>> jak at ateb.co.uk> 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 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
>>> >>>> >> >>> > >>>>> >> >>>>> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>> >> >>>>>
>>> >>>> >> >>> 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
>>> >>>> >> >>> > >>>>> >> >>> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>> >> >>>
>>> >>>> >> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>> >> >>>
>>> >>>> >> >>> > >>>>> >> >>>
>>> >>>> >> >>> > >>>>> >> >>
>>> >>>> >> >>> > >>>>> >> >> _______________________________________________
>>> >>>> >> >>> > >>>>> >> >> Opensim-dev mailing list
>>> >>>> >> >>> > >>>>> >> >> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>> >> >>
>>> >>>> >> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>> >> >>
>>> >>>> >> >>> > >>>>> >> >>
>>> >>>> >> >>> > >>>>> >> >
>>> >>>> >> >>> > >>>>> >> >
>>> >>>> >> >>> > >>>>> >> >
>>> >>>> >> >>> > >>>>> >> > _______________________________________________
>>> >>>> >> >>> > >>>>> >> > Opensim-dev mailing list
>>> >>>> >> >>> > >>>>> >> > Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>> >> >
>>> >>>> >> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>> >> _______________________________________________
>>> >>>> >> >>> > >>>>> >> Opensim-dev mailing list
>>> >>>> >> >>> > >>>>> >> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>> >>
>>> >>>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>> >>
>>> >>>> >> >>> > >>>>> >
>>> >>>> >> >>> > >>>>> >
>>> >>>> >> >>> > >>>>> >
>>> >>>> >> >>> > >>>>> > _______________________________________________
>>> >>>> >> >>> > >>>>> > Opensim-dev mailing list
>>> >>>> >> >>> > >>>>> > Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>> >
>>> >>>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>> _______________________________________________
>>> >>>> >> >>> > >>>>> Opensim-dev mailing list
>>> >>>> >> >>> > >>>>> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>>
>>> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>>
>>> >>>> >> >>> > >>>>
>>> >>>> >> >>> > >>>>
>>> >>>> >> >>> > >>>> _______________________________________________
>>> >>>> >> >>> > >>>> Opensim-dev mailing list
>>> >>>> >> >>> > >>>> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>>
>>> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>>
>>> >>>> >> >>> > >>>>
>>> >>>> >> >>> > >>>
>>> >>>> >> >>> > >>> _______________________________________________
>>> >>>> >> >>> > >>> Opensim-dev mailing list
>>> >>>> >> >>> > >>> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>>
>>> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>>
>>> >>>> >> >>> > >>>
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >> _______________________________________________
>>> >>>> >> >>> > >> Opensim-dev mailing list
>>> >>>> >> >>> > >> Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >>
>>> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > >>
>>> >>>> >> >>> > > _______________________________________________
>>> >>>> >> >>> > > Opensim-dev mailing list
>>> >>>> >> >>> > > Opensim-dev at opensimulator.org
>>> >>>> >> >>> > >
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>> > >
>>> >>>> >> >>> > >
>>> >>>> >> >>> >
>>> >>>> >> >>> >
>>> >>>> >> >>> >
>>> >>>> >> >>> > _______________________________________________
>>> >>>> >> >>> > Opensim-dev mailing list
>>> >>>> >> >>> > Opensim-dev at opensimulator.org
>>> >>>> >> >>> >
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>>
>>> >>>> >> >>> _______________________________________________
>>> >>>> >> >>> Opensim-dev mailing list
>>> >>>> >> >>> Opensim-dev at opensimulator.org
>>> >>>> >> >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >>>
>>> >>>> >> >>
>>> >>>> >> >>
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> >
>>> >>>> >> > _______________________________________________
>>> >>>> >> > Opensim-dev mailing list
>>> >>>> >> > Opensim-dev at opensimulator.org
>>> >>>> >> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >> >
>>> >>>> >>
>>> >>>> >> _______________________________________________
>>> >>>> >> Opensim-dev mailing list
>>> >>>> >> Opensim-dev at opensimulator.org
>>> >>>> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >>
>>> >>>> >
>>> >>>> >
>>> >>>> >
>>> >>>> > _______________________________________________
>>> >>>> > Opensim-dev mailing list
>>> >>>> > Opensim-dev at opensimulator.org
>>> >>>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>> >
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Opensim-dev mailing list
>>> >>>> Opensim-dev at opensimulator.org
>>> >>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >>>>
>>> >>>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Opensim-dev mailing list
>>> > Opensim-dev at opensimulator.org
>>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> >
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
More information about the Opensim-dev
mailing list