[Opensim-dev] Profiling and an API between Opensim components

Tue Dec 9 20:27:30 UTC 2014

Hey,

    I would agree it is a challenge to make module for open sim when the
innards are undocumented and ever in flux.  Took me a while to resolve an
issue that gave no errors, but did not give me any results when we moved
from .7 to .8 code base.    The next best things to an API is put internal
documentation to what a function is used for and maybe a comment or two on
how it it used.

 A case in point(one of the projects that mysteriously broke)  I had a
region module that when a new avatar entered the region , it would check
its agee and then send a group message out to group. I tracked it down to
the call to post the message,  it took probably 3 hours of trial and errors
to get it back working, just by altering the values a little. But it still
does not work like it did before, I just wrote it off to some check that
was added to prevent an avatar from from sending a message to a group they
are not members of.  Might of been the root of the issue I was having but
even wh debug logging turned on I could not get any indication that the it
was failing or even working.   But now it back working at useful level tho.
  I did tho get the bases for the code from one of justins blogs I believe.

  But here is very little documentation to go on.  Or even simple
examples.  But i understand allot of the  reasons why. But one thing to
think about tho, most programmers hate to read other people code to begin
with. And if they find it to hard to understand why it done this way they
will attempt to reinvent the wheel. I find the learning curve for the code
is steep and ever changing.  This is why I stick with a stable version and
not update tell I think it worth the hassles of it.  I just upgrading from
0.8 to 0.8.0.3 ...

But with that said, you guys doing great work.

On Tue, Dec 9, 2014 at 1:49 PM, Mic Bowman <cmickeyb at gmail.com> wrote:

> I will say that i got burned again on interface changes last week (changes
> to the thread watchdog and monitors).
>
> My concern is not that the interface is changing (I expect that since I'm
> tracking master), but that there doesn't seem to be a good way to
> accommodate "old code". Basically, once you make the change to the
> interface, I'm kind of forced to either deal with compatibility across
> multiple versions of my code (which given the challenges of conditional
> compilation in C# really means managing multiple branches of the code that
> track different opensim versions), or just sacrifice any backwards
> compatibility (or move the dispatcher code into core which means that it
> becomes "our" problem to fix it when a change happens). And we're not
> talking about obscure public methods, but thread management.
>
> No, I don't have a suggestion for improving the situation other than to
> preserve old interfaces & mark them deprecated and only remove the
> deprecated methods on major releases.
>
> --mic
>
>
> On Tue, Dec 9, 2014 at 10:41 AM, Justin Clark-Casey <
> jjustincc at googlemail.com> wrote:
>
>> From my perspective, OpenSimulator is a young and complex project that
>> has grown organically, in an area where there is very little previous
>> knowledge to draw upon and better ways to do things are frequently
>> discovered (e.g. the change in service approach between 0.6.9 and 0.7).
>> This has been the case since the project's beginnings and is still very
>> much true today.
>>
>> In such an environment, I think it would be a big mistake to try to
>> arbitrarily freeze or restrain internal change.  It would make it far
>> harder for those of us actively working on core to fix issues and evolve
>> the codebase for long-term sustainability.  In this, I very much agree with
>> the Linux approach [1] where drivers (modules) outside of the core simply
>> have to adapt to internal changes.  Just because a method is made public in
>> C# (which is necessary for projects to call each other) does not make in an
>> API.
>>
>> That said, to take the Linux example further, there are proper agreed
>> upon external facing APIs (POSIX, etc.) that are preserved whenever
>> possible.  I have no objection if someone wants to create and post a
>> document proposing actual API(s) that go through a proper design and
>> criticism process.  Indeed, the reason why it can be difficult for region
>> modules is because of the very large amount of inconsistency and occasional
>> bizarreness of the internal code, something that I would not want to see
>> frozen in place.
>>
>> However, I personally think it is much too early for such API creation
>> and it is not something I would initiate.
>>
>> The current effective QA/testing process is to make a change to master
>> and then get feedback from people using that branch.  As programmer labour
>> is scarce and often unpaid, there is no manpower available for any other
>> approach.
>>
>> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/
>> linux.git/tree/Documentation/stable_api_nonsense.txt
>>
>> On 09/12/14 17:56, Michael Heilmann wrote:
>>
>>> Opensim Developers
>>>
>>> On the MOSES grid we have been attempting to profile and test the
>>> Opensimulator code for quite a bit.  I saw the unit
>>> tests that already exist, also that Opensim has a Jenkins process
>>> running against the repository.  I also saw the
>>> conversation concerning API's and Justin renaming a function.  Has there
>>> been any thought into segregating Opensimulator
>>> components and creating API's for the different components?
>>>
>>> I am working on an After Action Review region module, where user actions
>>> are recorded on command, and later re-enacted
>>> using the NPC module on command.  This is pretty hairy with the number
>>> of classes from different parts of the code I've
>>> instantiated and interfaced with to get some of the behaviour I am
>>> seeking for the module.
>>>
>>> A clear API would make both testing/benchmarking simpler, as well as
>>> module development.  The tight coupling and
>>> functionality crossing multiple namespaces should also become clear as
>>> the API progresses. A clear delineation between
>>> the networking, scripting, and physics components would allow for better
>>> independent testing and development of each
>>> component.  Thoughts?
>>>
>>> While I've breached the subject of instrumenting and testing
>>> Opensimulator, has anyone thought about a testing/QA
>>> process on Opensim?
>>>
>>>
>>
>> --
>> Justin Clark-Casey (justincc)
>> OSVW Consulting
>> http://justincc.org
>> http://twitter.com/justincc
>>
>> _______________________________________________
>> 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/20141209/8fd19daf/attachment-0001.html>