Well, feel free to share that incomplete list with us so people know which functions you're looking at.
And yes, AuroraSim's LSL_Api.cs list is a lot shorter then the one in WhiteCore because of the recent changes we made to LSL functions. That's why I am kinda amazed that you found "old" LSL functions that aren't in OpenSim yet or not implemented. 2015-05-27 17:53 GMT+02:00 W Smith <[email protected]>: > Fly Man > > I only have a probably incomplete list of LSL functions (25 at them > moment) that are missing from OpenSim. I have no idea how many have been > implemented in Aurora. The only one I looked at in Aurora so far were the > LL json functions, the first on my list. > > You appear to be wrong about needing AA* functions, the code for the LL > Json functions that I got from aurora sim was not from and contained no > references to any AA* functions. You may have an older version or perhaps a > more recent from WhiteCore I have not looked there, I only found out > WhiteCore existed yesterday. > I got a copy from https://github.com/aurora-sim/Aurora-Sim a week or so > ago. > See > https://github.com/aurora-sim/Aurora-Sim/blob/master/Aurora/AuroraDotNetEngine/APIs/LSL_Api.cs > for their implentation. > > The code from Aurora sim compiled in OpenSim merely by adding "using > OpenMetaverse.StructuredData;". No other libraries were added by me, I am > just using the OSD library supplied from the OpensSim git repository. > > The Aurora implementation is plain wrong, its results differ from those of > SL LSL, it requires a number of changes to correct the outputs. Also > changes to cope with OpenSim allowing native c# data types to be added to > an lsl_list, lots of defensive type checking required to avoid casting > errors. > > My original intention was to work down my list of functions and submit > either a patch with an implementation or failing that a patch with the > "plumbing" and a "not implemented" implementation in LSL_Api > > Regards Talun > > -------------------------------------------- > On Wed, 27/5/15, Fly Man <[email protected]> wrote: > > Subject: Re: [Opensim-dev] Harvesting code from forks of Opensim > To: [email protected] > Date: Wednesday, 27 May, 2015, 12:53 > > Talun, > > Let me quote 2 pieces out of your > reply: > > "First of all I > have no interest in extracting anything from the AA* > functions or any other part of Aurora-Sim that is not > required by LSL > functions." > If you are > able to compile a list of the functions that are missing / > lacking in OpenSim and that work in AuroraSim, that would be > a great help. > > But as > I mentioned before, some of the functions you see as LSL > functions are bound in with the implementations for > aaFunctions. > > As > an example, the llJson function you mentioned ties in with > the aa function for it, using a different approach to JSON > as the LibOMV wasn't upgraded back then. The latest > LibOMV has the JSON implementation much easier and better > then the one in AuroraSim. > > "A few parts of the Aurora sim function > are usable (general looping > structure) as is but most require changes to correct the > differences > with SLs version." > > "None will probably be a direct > fit to OpenSim but there will be some degree of > copy/paste" > > My personal conclusion: Talun is > gonna create a list of the LSL functions that are in > AuroraSim which don't exist in OpenSim or are not > implemented correctly and he's gonna donate his time to > rewrite them all so they can be send in as a patch for > OpenSim. > > That sounds like a > good starting point to me > 2015-05-27 3:44 GMT+02:00 > Dahlia Trimble <[email protected]>: > There is a OSD > library which is part of libopenmetaverse. That > implementation is > compatible with the OpenSimulator license and the JSON > implementation in it is > fairly robust and used extensively in OpenSimulator. > "ll*" functions > are usually documented on http://wiki.secondlife.com/wiki/LSL_Portal > and > that site is generally regarded as the canonical > reference. > On Tue, May 26, 2015 at > 6:33 PM, W Smith <[email protected]> > wrote: > I have no > idea how the idea of importing these AA* functions got into > this thread my interest is in implementing LSL. > > > > I was intending implementing some of the 24+ unimplemented > LSL ll* functions that OpenSim lacks. I was going to look > for "inspiration and assistance" in doing this in > the Aurora sim implementations. > > > > None will probably be a direct fit to OpenSim but there will > be some degree of copy/paste > > > > Talun > > > > -------------------------------------------- > > On Wed, 27/5/15, Morgaine <[email protected]> > wrote: > > > > Subject: Re: [Opensim-dev] Harvesting code from forks of > Opensim > > To: [email protected] > > Cc: "Morgaine Dinova" <[email protected]> > > Date: Wednesday, 27 May, 2015, 1:28 > > > > Fly Man writes: > > > and my > > -1 was meant to say "Please do not put things that > no > > one knows about in OpenSim" > > > > +1 for that > > -1. :-) > > > > Your point applies to all FOSS code of > > course, not just Opensim. Undocumented or minimally > > documented code is a liability, not an asset, even if > > it's a million lines of alleged > > "awesomeness". > > > > The D/C ratio is not a perfect metric, > > but when it's near zero then you know that there's > a > > problem. > > > > > > On Wed, May 27, 2015 at > > 1:18 AM, Fly Man <[email protected]> > > wrote: > > Let me answer most > > questions that have been shooting up in my personal > mailbox > > which have to do with Opensim as a project. > > > > I'll start with > > perhaps the most easy part of the discussion: > AuroraSim. > > > > AuroraSim is a derivated > > from OpenSim, forked on the 14th of October 2010 after > Rev > > (RevolutionSmythe) decided that Opensim wasn't > going > > into the way he personally had seen. He decided to fork > the > > Opensim tree and renamed it to AuroraSim. In the years > > following he upgraded parts of the source-code and added > a > > set of new functional code parts knows as the > > aaFunctions. > > > > These > > functions are based on the code that he wrote at that > moment > > for the AuroraSim branch. Remember, this is an OLDER copy > of > > what the current Opensim branch is now. Most of the > > functions in there won't ever work in Opensim > mainly > > because Opensim does not have these older hooks. > > > > In 2013 Rev was done > > with his education and decided to start working which > > brought AuroraSim to a slower moving branch and patches > > weren't applied instantly anymore. The last patch > that > > was applied to the sourcecode was Jan 2014 and the > project > > slowly died. > > > > So, > > currently there's no maintainer of any of the code > that > > was/is in AuroraSim other then what is currently in > that > > GitHub repository. > > > > Now here comes the part which Kevin > > already mentioned: "The fork is called > > WhiteCore" > > > > Indeed, WhiteCore is a fork of > > AuroraSim after I personally saw what was happening to > > AuroraSim. I had been watching the slow pace for a > longer > > period of time and already had found 2 other people that > had > > the same "issue". So in December 2013 > AuroraSim > > was forked and re-based as WhiteCoreSim. > > > > Currently in development with 2 > > other developers, I am 1 of the 3 lead developers that > > actively maintain that "fork" although > it's > > not even close to what the endgoal for it will be. > > > > 1 thing that we > > broke "on purpose" when we changed the name is > the > > aaFunctions because only Rev knows exactly how they are > > meant to work. At the moment there's no other person > who > > knows what exactly the functions are meant to do other > then > > a better way to have NPC's spawn and some basic > > functions that mimic the osFunctions. > > > > Conclusion: There's no developer > > at the moment that can look into Rev's head from a > > distance and ask him how the functions are meant to work > (if > > they still work at all) and my -1 was meant to say > > "Please do not put things that no one knows about > in > > OpenSim" > > > > > > > > 2015-05-27 1:58 GMT+02:00 > > Dahlia Trimble <[email protected]>: > > Just to clarify on > > the slight chance it was missed, I wasn't > suggesting > > anyone "fork off" in any sense of the term. > Many > > forks, both public and private, already exist and I > suspect > > more will come about. My hope is that the community > will > > survuve and even thrive beyond any code fork. > > > > On Tue, > > May 26, 2015 at 4:22 PM, Morgaine <[email protected]> > > wrote: > > Dahlia writes: > > > > > I'd like to see disagreement and forks as a means > to > > drive innovation rather than conflict. > > > > More often than not, > > real project forking into separate projects (not just > > forking in the github sense) implies an inability or lack > of > > desire to find a meeting of minds with technical peers. > > > > If requirements are > > dramatically different then project forking can be a > very > > reasonable way forward, and to the benefit of > everybody. > > But if the requirements are really quite similar then > > forking is more likely an indication of inflexibility > and > > intransigence by one or both parties. The communal > > engineering process has probably failed. > > > > This is a > > technical project, so it's inherently different to > > discussing the merits of cat pictures -- discussions can > be > > objective. A rationally presented suggestion or even > a > > strong criticism presented in good faith is not a reason > for > > telling people to fork off. If that is the response > then > > it's a sign of extreme project ill health. > > > > Negative feedback > > is intrinsic to good engineering, and all good > engineers > > embrace it. That's not theoretical. Without it > a > > project's direction would never change to take into > > consideration the bitter lessons of experience. > > > > Morgaine. > > > > > > On Tue, May 26, 2015 at > > 11:35 PM, Dahlia Trimble <[email protected]> > > wrote: > > Apparently there is still a fair bit of passion > > about this platform and I prefer to see this in a > manner > > where people can use the code in a way they see fit and > to > > (hopefully) contribute back something or pay it forward > in > > other ways as appropriate. I'm not opposed to forks > but > > I'd hope civil discourse can be maintained even > through > > the times when much disagreement looms. I would hope > that > > various forks and branches could benefit from each other > and > > the community as a whole can thereby benefit. I'd > like > > to see disagreement and forks as a means to drive > innovation > > rather than conflict. > > > > On Tue, May 26, 2015 at > > 2:14 PM, Morgaine <[email protected]> > > wrote: > > Good data, thanks Cinder. It doesn't > > look like death to me. > > > > You clearly have some elite query-foo > > skills, can you generate a historical list of commits > per > > month and per year? This is a very strong way of > debunking > > allegations of death! :P > > > > > > On Tue, May 26, > > 2015 at 10:05 PM, Cinder Roxley <[email protected]> > > wrote: > > On May 26, 2015 at 2:59:54 > > PM, Morgaine ([email protected]) > > wrote: I'm just an observer > > on this project, albeit a very long term one, dating back > to > > near the beginning. One thing that long-term observers > are > > well qualified to do is to confirm or to deny the > veracity > > of allegations of long-term trends. > > > > Mike Chase's allegation that > > > > "OpenSim is slowly dieing > > (IMO) from neglect" > > > > is clearly unfounded since commits show > > no sign of stopping. I haven't checked the rate > of > > commits so perhaps Mike has more information in this > > regard. I welcome better > > information.https://www.openhub.net/p/opensimulator/commits/summary-- > > Cinder > > Roxley > > Sent > > with Airmail > > _______________________________________________ > > > > Opensim-dev mailing list > > > > [email protected] > > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > > > > > > > _______________________________________________ > > > > Opensim-dev mailing list > > > > [email protected] > > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > > > > > > > _______________________________________________ > > > > Opensim-dev mailing list > > > > [email protected] > > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > > > > > > > _______________________________________________ > > > > Opensim-dev mailing list > > > > [email protected] > > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > > > > > > > _______________________________________________ > > > > Opensim-dev mailing list > > > > [email protected] > > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > > > > > > > _______________________________________________ > > > > Opensim-dev mailing list > > > > [email protected] > > > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > > > > > > -----Inline Attachment Follows----- > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > > > > -----Inline Attachment Follows----- > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
