[Opensim-dev] My new LSL compiler project

Fri Nov 13 23:19:23 UTC 2015

Also excuse the typos. (phone, sorry)
On Nov 13, 2015 5:17 PM, "Eric " <e800 at gmail.com> 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
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151113/cc76eb1b/attachment-0001.html>