[Opensim-dev] RecentLibSL Update and Testing.

[Teravus Ovares]

After doing some more significant testing on Windows,

Here are a few things that I noticed.

1. The core functionality still works (outside of a packet null error which
I'm fixing)
Uploading/persistant inventory..  physics..  moving..  border crossing,
etc..

2. All previous assets no longer match up with the current assets. (the
.ToString() explosion)
So, essentially, it appears at least on windows, the major issue is for
people with content.
(dropping the tables, and letting it start from scratch seems to be the
ticket.)

However, I've heard of some more insidious issues for Linux;
--------
*melanie:* from r1478 to r1479, jh decided libsl must work on asmartphone
and in making that possible, broke it for linux,a nd good
http://bug.opensecondlife.org/view.php?id=55
 http://bug.opensecondlife.org/view.php?id=51
------

I'm not sure if this affects us at this moment, (my guess based on Nebadon's
tests is it very well could)
I suppose it's time to fire up that Linux box and try it

Best Regards

Teravus

On 12/20/07, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
>
> Teravus Ovares wrote:
> > Well, alternatively, you could strip out the hyphens where needed.
> >
> > ToString.Replace FTW!!!111!!1!1!!11!1!!One
> Or on the lines of Johan's 3. (and 1.) below, perhaps we should use the
> non overriden LLUUID.GetBytes() and convert this back to an unhyphenated
> hex string with a simple utility method.  To get off ToString() (a point
> about which I completely agree with Stefan) we could also have a utility
> method to produce the hyphenated version.
>
> Changing the underlying representations in the database at this stage
> (though it might well be necessary at some point) would cause a
> significant amount of upheaval for grid maintainers.  I know this is
> alpha code, but if we were to do this it would be  nice to provide a
> migration path, even if this is just some sql file which directly
> manipulates grid mysql).  We might also want to signal our intention to
> change database representations in advance in order to give grid
> operators some time to prepare.
>
> --
> justincc
> >
> >
> > On 12/20/07, *Justin Clark-Casey* <jjustincc at googlemail.com
> > <mailto:jjustincc at googlemail.com>> wrote:
> >
> >     Johan Berntsson wrote:
> >     > This problem is not caused by my work, but of changes in later
> >     versions
> >     > of LibSL. It has changed from using ToString (unhyphenated) and
> >     > ToStringHyphenated(), to only using ToString() (hyphenated).
> >     This means
> >     > that there is no way of getting an unhyphenated string from libSL
> >     > anymore. I changed all instances of  ToStringHyphenated() in
> >     OpenSim to
> >     > ToString(), but I didn't realize that there would be a problem
> with
> >     > plain ToString() calls.
> >     >
> >     > The basic problem is that we are relying on a libSL behaviour
> >     that is
> >     > outside our control, and has changed. If we want to keep up to
> >     date with
> >     > libSL I suggest that the problem is solved.
> >     >
> >     > Possible solutions:
> >     > 1. Identify the problematic ToString() calls and use a utility
> >     function
> >     > (Util.ConvertToUnhyphentated) to fix them like before.
> >     > 2. Write scripts to update the current databases to use hyphenated
> >     > GUID:s
> >     > 3. Change the code not to use ToString at all.
> >     >
> >     > I prefer option 3, and to be compatible it could output
> >     unhyphenated
> >     > GUIDs. At least this means that we won't have problems every
> >     time libSL
> >     > is refactored (and ToString is meant as a debug tool, not as a
> >     provider
> >     > of keys to a database)
> >     >
> >     Is there any chance that, if asked, the LibSL folks would add extra
> >     methods such as
> >
> >     ToGuidString()
> >     ToGuidHyphenatedString()
> >
> >     ?  We would still be relying on LibSL but with explicitly named and
> >     purposed methods such as these rather than ToString(), I would hope
> >     no-notice refactoring would be much less likely.
> >
> >     If necessary, we could then migrate to our own methods at our
> leisure
> >     (after patching all the string calls to use these two methods).
> >
> >     Even if they won't do this, we could patch their code in the
> meantime
> >     for these methods (I doubt that would be very complicated) if
> >     migrating
> >     now would be considerable and destablizing work (in light of 0.5).
> >
> >     Regards,
> >
> >     --
> >     justincc
> >     _______________________________________________
> >     Opensim-dev mailing list
> >     Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
> >     https://lists.berlios.de/mailman/listinfo/opensim-dev
> >     <https://lists.berlios.de/mailman/listinfo/opensim-dev>
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071220/b5fe83ce/attachment-0001.html>