[Opensim-dev] My new LSL compiler project
Eric
e800 at gmail.com
Tue Nov 17 17:15:23 UTC 2015
Gotcha, I'll make the self contained version the main branch and make any
updates there or off a copy.
Thank you for all your input.
On Tue, Nov 17, 2015 at 11:06 AM, Melanie <melanie at t-data.com> wrote:
> 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
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151117/67b7d89c/attachment-0001.html>
More information about the Opensim-dev
mailing list