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
