[Opensim-dev] My new LSL compiler project
Eric
e800 at gmail.com
Mon Nov 9 23:20:47 UTC 2015
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/20151109/3876060d/attachment-0001.html>
More information about the Opensim-dev
mailing list