[Opensim-dev] My new LSL compiler project

Sat Nov 14 01:21:30 UTC 2015

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20151113/6fe8db31/attachment-0001.html>