[Opensim-dev] Harvesting code from forks of Opensim

Wed May 27 15:53:31 UTC 2015

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 <fly.man.opensim at gmail.com> wrote:

 Subject: Re: [Opensim-dev] Harvesting code from forks of Opensim
 To: opensim-dev at opensimulator.org
 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 <dahliatrimble at gmail.com>:
 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 <wanderingcodesmith at yahoo.co.uk>
 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 <morgaine.dinova at googlemail.com>
 wrote:

  Subject: Re: [Opensim-dev] Harvesting code from forks of
 Opensim

  To: opensim-dev at opensimulator.org

  Cc: "Morgaine Dinova" <morgaine.dinova at googlemail.com>

  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 <fly.man.opensim at gmail.com>

  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 <dahliatrimble at gmail.com>:

  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 <morgaine.dinova at googlemail.com>

  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 <dahliatrimble at gmail.com>

  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 <morgaine.dinova at googlemail.com>

  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 <cinder at alchemyviewer.org>

  wrote:

  On May 26, 2015 at 2:59:54

  PM, Morgaine (morgaine.dinova at googlemail.com)

  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

  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

  -----Inline Attachment Follows-----

  _______________________________________________

  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

 -----Inline Attachment Follows-----

 _______________________________________________
 Opensim-dev mailing list
 Opensim-dev at opensimulator.org
 http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev