[Opensim-dev] My new LSL compiler project
Melanie
melanie at t-data.com
Tue Nov 17 01:09:38 UTC 2015
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
>
More information about the Opensim-dev
mailing list