Re: [opensource-dev] saved logins

[Henri Beauchamp]

On Mon, 3 Jan 2011 15:22:02 -0800, Philippe (Merov) Bossut wrote:

> Hi,
> 
> On Wed, Dec 29, 2010 at 2:46 PM, Lance Corrimal
> wrote:
> 
> > Am Mittwoch, 29. Dezember 2010 schrieb Aleric Inglewood:
> > > https://jira.secondlife.com/browse/SNOW-129
> >
> > that is one of the main things that are holding me back from going
> > live with dolphin viewer 2.x, the missing saved logins dropdown...
> 
> That was proposed as a port to Snowstorm:
> https://jira.secondlife.com/browse/SNOW-670
> 
> IIRC, OpenSim users didn't like some of the aspects of that implementation.
> An alternative proposal fixing those issues would be welcome.

The problem with Snowglobe's implementation is that it saves the login
info using the grid index number in the grids list, number which changes
for OpenSim grids as soon as you change the grids list, resulting in
messed up saved login info.

I fixed this issue in the Cool VL Viewer v1.25 (which is based off
Snowglobe v1.5), simply by using the grid name instead of the grid
index number...

This fix is part of the patch (for SG 1.5) available here:
http://sldev.free.fr/patches/12500/slviewer-0-v12500-MoreGridsDynamic_v7.patch.bz2

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] New web search: how to get search_token or auth_token in v1 viewers ?

[Henri Beauchamp]

Greetings,

I backported the new web search to the Cool VL Viewer (Snowglobe v1.5
code base), however, I'm left a bit puzzled on how viewer 2 retrieves
the necessary authentication tokens (either earch_token or auth_token)...

Looking at (grepping) the code, I see no mention of these in
lllogininstance.cpp (if these options are like others, there
should be requested_options.append("search_token") and
requested_options.append("auth_token") calls in there...).

I tried to request these options in my backport, but both
getResponse("search_token") and getResponse("auth_token") keep
returning empty strings...

The net result is that I can only search for PG stuff...

Any clue as to how to retreive these tokens, or are the corresponding
options not yet implemented on the login server side ?

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New web search: how to get search_token or auth_token in v1 viewers ?

[Henri Beauchamp]

On Thu, 26 May 2011 13:59:50 -0700, Joshua Bell wrote:

> On Thu, May 26, 2011 at 12:41 PM, Henri Beauchamp  wrote:
> .../...
> > I tried to request these options in my backport, but both
> > getResponse("search_token") and getResponse("auth_token") keep
> > returning empty strings...
> 
> That's odd. Can you dump out the full XMLRPC response to verify that
> search_token isn't present and that it's not some other part of the viewer
> plumbing that's eating the value? I'm seeing it when doing some raw XMLRPC
> tests against the login service.

Well, yes, it was indeed here, but it has to be retreived from llstartup.cpp
(the results are probably discarded later on), and not in the search floater
class...

The token (a 384 characters string) is now properly passed, but I'm still
not allowed to search for Mature and Adult stuff (while it works when the
same query string is used in my main browser)... A bug in my port (I don't
see where since same URL is used in both the viewer and the browser and yet
give different results...), or in the web server for the search engine ?...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New web search: how to get search_token or auth_token in v1 viewers ?

[Henri Beauchamp]

On Thu, 26 May 2011 18:06:00 -0700, CG Linden wrote:

> On Thu, May 26, 2011 at 5:10 PM, Henri Beauchamp  wrote:
> 
> .../...
> > The token (a 384 characters string) is now properly passed, but I'm still
> > not allowed to search for Mature and Adult stuff (while it works when the
> > same query string is used in my main browser)... A bug in my port (I don't
> > see where since same URL is used in both the viewer and the browser and yet
> > give different results...), or in the web server for the search engine ?...
>
> Yes, there is an edge case when people have never set their maturity
> preferences. Simply change them in the viewer, then change them back, and
> that will fix it for now.

It worked (after I set my preferred maturity to General then back to
A+M+G; it didn't work when I tried to set to M+G then back to A+M+G),
thanks ! :-)

However, I found another bug in the new search... the maturity rating
parameter (r=13 or r=21 or r=42) passed in the search URL seems to be
completely ignored, that is, if I want only the G results for a given
search (I kept maturity selection checkboxes in the search panel for
this purpose) while my global maturity preference is set to G+M+A,
I'm still presented with all results, including M and A ones...
Also, given what I can see of the viewer-search v2 code and of the
values passed for this rating parameter (13/21/42), it doesn't seem
designed to allow searching only for M or only for A, or only for
M+A stuff, like it was possible to do with the old web (and also with
the oldest non-web) search.
These are *serious* shortcomings and a net loss in features when
compared to what we could do with search till now... I do hope these
shortocmings will be fixed !

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New web search: how to get search_token or auth_token in v1 viewers ?

[Henri Beauchamp]

On Fri, 27 May 2011 14:08:04 -0400, Oz Linden (Scott Lawrence) wrote:

> The new search backend was originally designed to be inclusive:
>  G, G+M, or G+M+A - like the viewer.

Err... you mean v2 viewer, right ?... Because v1.23 and Snowglobe v1
always could do this in search.

> However, we are changing that now and we will have the backend
> support for searching just M or just A and any combination soon.

Excellent ! :-)

However, I'm still hoping that LL didn't took the decision to just
shut down the old seach engine API: it still gives the best (most
relevant) results for simple searches (one or two words, and also
(and especially) for exact matches) and, most important (if we
consider that, after all (and after 4 years... :-P), revelancy for
the new web search *can* be improved and brought back to what it
was in the non-web search), the old search allows to display the
results in a WAY more compact and efficient way, allowing
to keep the search floater at a minimum size (to avoid blocking
the 3D view: something viewer 2 lamentably fails to preserve in
*all* and *every* aspect of its UI) while easily browsing through
the results faster than any heavily scripted web search will ever
be able to achieve...

The proper solution would probably be to implement a bridge
between the new search database and the old search API... It
would also preserve full compatibility with older viewers that
don't have a proper backport.

> Outstanding job back-porting so quickly, Henri.

That was an easy port: one afternoon, most of the time spent
figuring out why that damned search_token parameter was not
showing up where it should have, and also some time spent
backporting the whole llplugin+SLPlugin+media_plugin stuff
from v2.6, since SG v1.5 plugin system could not properly
handle the new search engine (it gave HTTP requests stalls,
was utterly slow and probably had trouble with the scripting).

The Cool VL Viewer v1.26.0.4 was released earlier today with
the new web search support (along with the old web search and
old non-web search).

I do not provide any more individual (stand-alone) patches for
the features I implement in v1.26 since it is now a true fork
of SG v1.5 (done in anticipation for Mesh support), but there's
a diff between v1.26.0.3 and v1.26.0.4 that pretty much only
deals with the new web search implementation:
http://sldev.free.fr/patches/CoolVLViewer-v12603-to-v12604.diff.bz2

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Search project viewer

[Henri Beauchamp]

On Sun, 29 May 2011 20:58:02 -0400, Jonathan Welch wrote:

> In case you have not caught the message yet a project viewer with the
> new search recently came out:
> http://wiki.secondlife.com/wiki/Search_Project_Viewer_FAQ
> 
> There is mention of V1 All and Group search being turned off once it
> goes to full release.

Which is EXTREMELY unfortunate and, once again, a HUGE mistake from LL...

Instead of being committed to *improve* user experience, LL seems
committed to *ruin* it...
The old search was WAY more efficient at the job of displaying results
and browsing through them, allowing to keep a compact search floater
that preserved screen estate for the 3D world. It also allowed to
sort the results by name, or by number of members (for the group
search), both *instantly* and with a single click of the mouse (and
without having to relaunch a query: less load for the servers !).
It also gave a larger version of the associated texture for the
"All" search, and a clear, synthetic layout of the group charter,
members, fees, etc for the "Groups" search...

Add to the above arguments the fact that LOADS of SL residents are
still using the v1.23 and Snowglobe v1.4/1.5 viewers and would
rather give up on SL than letting LL ram viewer 2 down their throat,
and you get the picture...

The REALLY sad thing, it that it would not even take half a work
day for a decent coder to write the server side glue code that would
allow to keep the backward compatibility (using the same query method
as the one used for the old search, but instead querying the new
search database).

Mind you, software companies such as MicroSoft *did* understood,
*unlike LL*, that backward compatibility is a *MUST*: what do you
think would have happened if the Windows 95 users would suddenly
be forced to trash all their software and relearn to use an UI
rewritten from scratch ?... Fact is that today, even in Windows 7,
you can still run Windows 95 programs and revert the UI and skin
to what it was in Windows 95 !
I'd LOVE to see LL learn that lesson from MicroSoft... FAST !
Because if they don't, they will see more and more old-timers
(those residents who actually BUILT SL !) leave for greener
pastures.
It would be about time that LL paid more attention to their
*serious*, *committed*, *building*, *paying* user base and stop
imposing things on them they obviously *massively* reject !

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New web search: how to get search_token or auth_token in v1 viewers ?

[Henri Beauchamp]

On Fri, 27 May 2011 14:08:04 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2011-05-27 3:36, Henri Beauchamp wrote:
>
> > However, I found another bug in the new search... the maturity rating
> > parameter (r=13 or r=21 or r=42) passed in the search URL seems to be
> > completely ignored, that is, if I want only the G results for a given
> > search (I kept maturity selection checkboxes in the search panel for
> > this purpose) while my global maturity preference is set to G+M+A,
> > I'm still presented with all results, including M and A ones...
> > Also, given what I can see of the viewer-search v2 code and of the
> > values passed for this rating parameter (13/21/42), it doesn't seem
> > designed to allow searching only for M or only for A, or only for
> > M+A stuff, like it was possible to do with the old web (and also with
> > the oldest non-web) search.
> 
> The new search backend was originally designed to be inclusive:  G, G+M, 
> or G+M+A - like the viewer.  However, we are changing that now and we 
> will have the backend support for searching just M or just A and any 
> combination soon.

I can now see the three maturity checkboxes in the search page results.
However the "r" (rating) parameter in the search URL
(http://search-beta.secondlife.com/viewer/[CATEGORY]/?q=[QUERY]&p=[AUTH_TOKEN]&r=[MATURITY]...)
is still completely ignored (when I pass, 21 for M, for example, the
checkboxes in the search results page are not modified to match and the
search results are not updated to show only M results either), and
the only valid (if to believe viewer sources) values for this parameter
(13 xor 21 xor 42) do not allow to pass combined maturity queries (G+M,
M+A, G+M+A, etc).

Could we get a "m" (maturity) parameter in the search URL that would
actually be taken into account (automatically updating the checkboxes
in the web page) and would allow to combine maturity flags (such as what
is done for the current/old web search) ?
The advantage of such a parameter is that the viewer can remember the
preferred maturity for the user's searches over sessions and pass the
right parameter value on opening the search floater, unlike the new
web-based maturity check boxes (which are always reset to G+M+A (or G+M
if you are not adult-verified) at the next viewer session).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] New Mesh servers made incompatible with v2 Mesh viewers ???

[Henri Beauchamp]

Greetings,

I'm putting the finishing touch to the first alpha release of the
Cool VL Viewer v1.26.1, which is a v1 UI viewer with Mesh rendering
support.

I finally got everything to compile and run fine (basically, I ported
the whole v2.6-mesh renderer, and of course all the mesh code), but it
fails to render meshes: the mesh objects stay as oblong prims, the
mesh repository doesn't fetch any mesh data from the network, and I get
plenty of "createNewParameterEntry: Unknown param type #96" messages in
the log file...

I checked and rechecked my backport against v2.6-mesh and v2.7.4, and
after a few hours, I was sure I didn't miss anything. So, I launched
the last official mesh viewer I donwloaded (v2.7.2), and it happens that
it shows the exact same symptoms !!!

I'm now wondering if the new Mesh servers implementation was not made
incompatible with pre-v3 viewers.

If the answer is yes, please tell me before I loose some more hours
searching through megabytes of diffs to find out what changed.

A pointer to what should be modified to be able to fetch mesh data
again would also be nice !

Thanks in advance,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New Mesh servers made incompatible with v2 Mesh viewers ???

[Henri Beauchamp]

Thanks, folks !

I indeed found the changes: one in llprimitve.h, as pointed to by Armin
(new PARAMS_MESH type) and another in llviewerobject.cpp (where
unpackParameterEntry() translates PARAMS_MESH into PARAMS_SCULPT to
process the latter like it was in older mesh viewers)...

Now, the mesh data download starts... and causes a dead lock, lol !
Looks like I'll have to backport the latest versions of llcurl,
llthread, llapr & Co (though, they were already v2.6 backports)...

At least, I'm making progresses again ! ;-)

Back to browsing the diffs, this time with v3.0 as a reference...

Henri.


On Wed, 24 Aug 2011 21:07:32 +0100, Robin Cornelius wrote:

> On Wed, Aug 24, 2011 at 9:01 PM, Henri Beauchamp  wrote:
> > Greetings,
>
> > If the answer is yes, please tell me before I loose some more hours
> > searching through megabytes of diffs to find out what changed.
> >
> > A pointer to what should be modified to be able to fetch mesh data
> > again would also be nice !
> 
> There were two major changes to mesh since the first release on Aditi
> of it. One was the original mesh asset was being sent as a sculpt with
> a sub type of mesh and then the sculptID was being used as the UUID
> for the mesh asset which would then be fetched. The problem here was
> non mesh viewers would try to show a sculpt and use the UUID as a
> texture and some crashed because of this.
> 
> The second change was the names of lod/physics info inside the mesh
> asset LLSD was tweaked around, i can't recall the exact change but it
> was something trivial like "high_lod" became "highest_lod"
> 
> Hope that gets you going in the right direction and saves some dfiffing
> 
> Robin

On Wed, 24 Aug 2011 23:32:07 +0200, Armin Weatherwax wrote:

> > I checked and rechecked my backport against v2.6-mesh and v2.7.4, and
> > after a few hours, I was sure I didn't miss anything. So, I launched
> > the last official mesh viewer I donwloaded (v2.7.2), and it happens that
> > it shows the exact same symptoms !!!
> I saw the syptoms you describe some time ago in Kokua with v2.7.3 merged, 
> bisected mesh-development and found 2 commits which fixed the issue for 
> viewing meshes, no idea about physics though:
> 
> 19640:02eb9a481f49
> Don Kjer 
> Mon Jul 18 18:57:40 2011 -0700
> Changed mesh param type to not conflict with one in-use on server
> 
> 19639:9cea44ebea3b
> Don Kjer 
> Mon Jul 18 18:50:57 2011 -0700
> Adding support for viewer reading mesh params from an alternative param type.
> 
> Hope that helps.
> Armin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New Mesh servers made incompatible with v2 Mesh viewers ???

[Henri Beauchamp]

On Thu, 25 Aug 2011 10:45:54 +0200, Lance Corrimal wrote:

> 
> > Back to browsing the diffs, this time with v3.0 as a reference...
> 
> where the *beep* did you find good 3.0 sources? viever-release is 
> still 2.8.3, viewer-beta doesn't compile, and viewer-development is 
> too volatile for my taste to base a TPV on...

I don't care if the v3.0 sources compile or not... I just look at
what code is needed for Mesh in the Cool VL Viewer and backport it.

And I just did it !

http://sldev.free.fr/forum/viewtopic.php?f=5&t=540

The Cool VL Viewer v1.26.1.0 is going to be released really soon ! ;-)

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1567 Mute button for llDialog popup

[Henri Beauchamp]

On Mon, 22 Aug 2011 16:43:22 -, Jonathan Yap wrote:

> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/449/
> ---
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Add a block button to popups from llDialog calls. Clicking on the Block
> button adds the object to the block list.  The type of block is Object.

There is an issue with the way this is implemented: existing scripts
using a "Mute" button in their own menu get this button interpreted
as a viewer-side block action request from the user.
Note that this is also an issue with llDialog()s using "Ignore" as a
button, but the latter has been documented like forever on the LSL
portal, thus not being a real issue, while this new blocking feature
breaks *existing* contents.

The reason why client side buttons and script side llDialog() buttons
get mixed up is that the buttons in the script menus got the same
internal "name" as the "text" they are set for, and since UI dialogs
are all referred by their "name" field in the viewer UI, the first
matching "name" in a list of buttons is used to trigger the
corresponding action (here, block by object UUID for any "Mute"
button in the dialog).

The fix is simple (and also fixes the "Ignore" button issue): you
just have to use a "name" field for the client side buttons ("Ignore"
and "Block") that scripts are unlikely to ever use.

For the Cool VL Viewer (v1.26.0.19 and v1.26.1.6, to be released
this week), I use "client_side_mute" and "client_side_ignore" as
the "Block" and "Ignore" button names in the notification menu
definition (in notifications.xml). For v3, this would read as:

  
[NAME]'s '[TITLE]'
[MESSAGE]

  
  

  

  
group
[GROUPNAME]'s '[TITLE]'
[MESSAGE]

  
  

  

"client_side_mute" and client_side_ignore" are unlikely to be ever used
in llDialog() calls, but you could use even more obscure names if you want.

There is no other code to change for making this work properly, and you can
test it with this simple script:

default {
state_entry() {
llListen(-1, "", NULL_KEY, "");
}

touch_start(integer total_number) {
llDialog(llDetectedKey(0), "Test", [ "Ignore", "Mute", "OK" ], -1);
}

listen(integer chan, string name, key id, string message) {
llSetText(message, <1.0, 1.0, 1.0>, 1.0);
}
}

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

Greetings,

I noticed that all the viewers using tcmalloc (mesh viewers under Linux
and Windows, since those use SSE2 and must gain memory-aligned malloc()
and new() calls that their standard library does not provide) suffer
from a serious problem: they never release memory back to the system,
meaning that after visiting a crowded place and caming around a lot,
the viewer can occupy 2.5Gb of memory, and even after you TP out to a
skybox with almost no objects/textures and no avatar around, the viewer
retains the full amount of alloctaed memory for itself.

Worst, should you manage to keep the viewer from crashing during a full
hour or so, its allocated memory will get so badly fragmented that it
starts crawling down and finally crashes, even in quiet sims.

Bao Linden recently worked on private memory pools to work around these
issues, but so far and despite his hard work, the result is less than 
satisfactory: the memory is still never released to the system, and the
viewers using private memory pools crash every few minutes after issuing
a warning:
"LLPluginProcessParent::poll: apr_pollset_poll failed with status 4

Well, be happy since I found an easy work around for these problems
while working on the Cool VL Viewer v1.26.1 (the mesh branch).

tcmalloc is actually supposed to release back to the system the memory
freed by the application using it, but it does so only after a certain
number of memory blocks have been freed. There is an environment
variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate"
at which tcmalloc will release the freed blocks back to the system.
In fact, this is not really a rate, but a divisor (the number of freed
blocks is divided by the rate number (when != 0: a 0 rate means "never
release memory"), and compared to a threshold. If the number is below
the threshold, the freed blocks are released.
The documentation for tcmalloc says that "Reasonable rates are in the
range [0,10]", but even with a rate of 10, you never get the viewer to
release more than a couple hundreds megabytes for 2+Gb of allocated
memory. It occurred to me that the algorithm tcmalloc uses is simply
crippled !

The good news, is that if you pass an "unreasonnable" rate, tcmalloc
will finally release memory (the more "unreasonnable" and the more
memory is released). With a rate of 1 (yes, ten thousands), you
get the viewer to release everything when it doesn't need it any more,
which matches the behaviour of tcmalloc-less viewers.

Since the Windows builds don't use a wrapper script to launch the
viewer, it is however best to hardcode this new rate as the default
one in tcmalloc istelf. This is what I did for the Cool VL Viewer
and it works like a charm. There is only one line to change in
tcmalloc source, in src/page_heap.cc:
DEFINE_double(tcmalloc_release_rate,
EnvToDouble("TCMALLOC_RELEASE_RATE", 1.0),<--- HERE
"Rate at which we release unused memory to the system.  "
"Zero means we never release memory back to the system.  "
"Increase this flag to return memory faster; decrease it "
"to return memory slower.  Reasonable rates are in the "
"range [0,10]");

Now, the viewer runs rock stable (just like the non-mesh, tcmalloc-less
version) and uses very reasonnable amounts of memory. It also doesn't
suffer from memory fragmentation any more since it is transparently
taken care of by the OS (via the page table and the PMMU of the CPU,
something neither tcmalloc nor Bao's private memory pool can do since
these are userspace code).

For what it is worth...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:

> Setting this as described for me made the client (on Linux) so slow as 
> to be unuseable.  I am seeing occasional crashesas well and tried this 
> as a workaround.

I can tell you the slow down is *certainly* not coming from this fix:
I conducted many tests here (have been using this fix for over a week
now), and can tell there is absolutely no speed difference with the
fix and without the fix...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 2 Oct 2011 01:12:40 -0400, Zabb65 wrote:

> It is not desirable to let the default allocation engine run under
> Linux, and possibly Mac. glibc has an incredibly slow allocator for
> small objects, and tcmalloc was implemented to remedy these
> situations(This is what I heard, but have not confirmed.) Inventory
> and a few other items create massive numbers of very small heap
> objects.

This would be true only if the viewer was to perform dozens of
thousands of allocations *every* second, which is *not* the case,
plus the speed difference is not that large (we are speaking of
microseconds per allocation here), especially when tcmalloc finds
itself with a fragmented allocated virtual memory pool and must
perform garbage collection as a result: the overhead is then huge,
when the system malloc() simply *transparently* benefits from the
OS ability of allocating continuous blocks of virtual memory out
of fragmented physical memory via the page table and doesn't need
any garbage collection.

It becomes even worst with private memory pools of v3 that add
yet another layer of code around memory allocations, slowing
things down more.

Finally, when tcmalloc doesn't release enough memory you find
youself with a huge process in memory that may result in your
system starting to swap... And instead of microseconds penalties,
we are now speaking of seconds !

> Setting a much lower value(1000) that only returns memory
> occasionally is much more desirable on this platform.

The problem is then that not *all* memory get released (the
tcmalloc algorithm is crippled), and tcmalloc will still get
its non-released pool fragmented over time.

> You can do this
> without recompiling tcmalloc as well by passing an environment
> variable, which is the desired method.

I know and told it: please re-read my message !
However, it doesn't work for Windows (unless you create a complicated
shortcut with cmd.exe and accept having a command window staying open
together with the viewer after launching the latter with that
shortcut), thus why hardcoding the value is best (it's a private library
for use by the viewer only anyway: it's not like it it was to be
installed system-wide).

> Please note that it is listed
> as a caveat on the tcmalloc page that it very clearly does not return
> memory to the system(I assume this is outdated, or reflects the
> default value)

No, you probably saw an outdated doc. See:
http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html
and scroll down to the "Releasing Memory Back to the System" section.

> Windows doesn't really have a need for tcmalloc from what I can see.

I so think it does for mesh viewers, for aligned allocations.
MacOS-X doesn't need it.

> If LL compiles using visual studio 2010, the C runtime uses the low
> fragmentation heap allocator. The low fragmentation allocator is fast
> enough to satisfy even large numbers of small objects, and keep heap
> fragmentation to very small percentages. Working "against" the heap
> manager on windows by rolling your own is generally not advised unless
> there are extraordinary needs or requirements, and even then, it is
> far easier to cause more problems then you fix.

Really, the only true motivation behind the use of tcmalloc in mesh
viewers (it was not use for non-mesh viewers) is to provide aligned
allocations. Without it, and the way the mesh viewer code is written,
the viewer simply crashes as soon as it tries to perform an SSE2
operation on an unaligned structure.

I tried with and without tcmalloc in the non-mesh branch of the
Cool VL Viewer (v1.26.0): there is no speed difference at all, but
the viewer does use more memory with tcmalloc (even with the force-
release trick). I got rid of it in newest v1.26.0 versions since
it's not worth bothering with it for non-SSE2 llmath viewers.

> Is tcmalloc really providing aligned allocations? I only found
> documentation that it would enforced specific amounts of space between
> items, not that they were guaranteed to be aligned to an X byte
> boundary. (Maybe this is what the spacing guarantees, but I am
> unsure.)

Yes, it does (see above).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 2 Oct 2011 08:39:06 +0200, Lance Corrimal wrote:

> second, two issues:
> 
> 1. viever_manifest.py needs to be edited to reflect the fact that 
> libtcmalloc.so now has the version 0.2.2 and not 0.1.0 :)

Yes, unless you recompile v1.7.

> 2. 3p-google-perftools does not build under VS2010 EXPRESS since the 
> build script relies on devenv.com :/

Yep, it tries to include *NIX headers..

> 1. is simple enough but what do i do about 2?

Simply recover the v1.7 version of 3p-google-perftools: it compiles
fine here (under VS2005).

Henri
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 2 Oct 2011 16:39:49 +0200, Carlo Wood wrote:

> On Sun, 2 Oct 2011 10:20:47 +0200
> Henri Beauchamp  wrote:
> 
> > Really, the only true motivation behind the use of tcmalloc in mesh
> > viewers (it was not use for non-mesh viewers) is to provide aligned
> > allocations. Without it, and the way the mesh viewer code is written,
> > the viewer simply crashes as soon as it tries to perform an SSE2
> > operation on an unaligned structure.
> 
> Use _mm_malloc, if that doesn't exist use posix_memalign
> and if that also doesn't exist, just use malloc.
> That will work (for sse2 alignment).

Insufficient for the current way the mesh viewers code is written:
you also need all classes (and their members) used with SSE2
operations to be aligned, else you get crashes. This means that
the C++ "new" call is also impacted.

If you're not convinced, try by yourself by compiling the mesh viewer
without tcmalloc under Linux or Windows, and admire the segfaults as
soon as it starts rezzing anything.

Also, this is why LL didn't use tcmalloc for MacOS-X builds, since
that OS got natively aligned memory allocations.

> tcmalloc is to get speed from not having to lock
> threads when they allocate memory: they each have
> their own pool. I never saw any evidence that the
> main thread is waiting considerable long times
> (ie > 10 usec) on a lock in malloc because other
> threads are trying to alloc/free memory, so I don't
> see the need for tcmalloc in the viewer. I think
> LL fell in love with it for their server, but the
> decision to use it for the viewer is wrong. 

They introduced tcmalloc use *only* because of the mesh code
(tcmalloc was not in use before the mesh branch appeared),
but I agree that its use in the viewer, beside the memory
alignment issue is an overkill and certainly not necessary.

I'd rather see a simpler memory allocator used than tcmalloc...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 02 Oct 2011 10:12:57 -0400, Mike Chase wrote:

> On 10/02/2011 03:48 AM, Henri Beauchamp wrote:
> > On Sun, 02 Oct 2011 00:23:36 -0400, Mike Chase wrote:
> >
> >> Setting this as described for me made the client (on Linux) so slow as
> >> to be unuseable.  I am seeing occasional crashesas well and tried this
> >> as a workaround.
> > I can tell you the slow down is *certainly* not coming from this fix:
> > I conducted many tests here (have been using this fix for over a week
> > now), and can tell there is absolutely no speed difference with the
> > fix and without the fix...
> I'm pretty sure it is. No code changes, I simply set the environment 
> variable and restarted. removing the environment variable again returned 
> things to previous behaviour. This is running a 3.0.6 dev viewer on 
> Fedora Linux (F15) x86-64.

Try harder... with multiple sessions (sometimes, you can log in a skybox
and get 150fps, then relog with the same viewer, in the same skybox and
with the same environment and get only 140fps...). Also, use the FPS
reports issued each minute in the debug console (waiting for it to
stabilize, which can take 3 minutes or so) and make sure the viewer
window stays active (with focus) during the whole measurement period.

I can asssure you I saw 0% difference (and I *did* test *hard* to make
sure during now over 10 days).

BTW, the Cool VL Viewer v1.26.1 (mesh branch) is now 5-7% faster than
Snowglobe v1.5 it is (well, *was*) based on.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Mesh viewers and tcmalloc issues

[Henri Beauchamp]

On Sun, 02 Oct 2011 10:20:58 -0400, Mike Chase wrote:

> One more note.  I have 16gb of memory on this system so the large heap 
> really isnt a problem per-se.

It is, because you will not be able to get more than 3Gb of virtual
memory per process, and when this virtual space gets fragmented (which
*does* happen during "long" sessions with tcmalloc and its default
release rate), your viewer will crash trying to allocate the next
unfragmented space that won't fit its currently allocated but
fragmented pool.

> I still see occasional exits (with no crashdump so I can't
> easily say what exactly is happening).

That's exactly what happens when your process tries to use over
3G of memory... Run the viewer under gdb, wait for it to crash
and do a backtrace to get the stack trace and see how it crashes
during a tcmalloc call for allocating memory...

> RSS on my system is 1 so I'm not coming even close to that.

You'll still be stuck with the 3Gb limit per process, thanks to
Intel's insane addressing modes and poor intsruction set design...
If only IBM had chosen Motorola's 680x0 line of CPUs back in
the days when they opted for the 8086, the PCs would have had
32bits OSes with flat memory models from the very start, without
weird stuff such as paging, PAE and whatnot !...
Today, we are still paying the price of the poor design of the
x86 CPUs...

> Henri, I'm not saying your wrong (though setting a param outside
> the specified operational range for the library doesn't feel like
> a *fix* to me).

The tcmalloc algorithm for releasing memory is crippled, period.
And as I wrote, this is a *workaround* (I never wrote is was a
*fix* !). The true fix would be to fix tcmalloc itself, or better,
to do without tcmalloc !

> I do believe more testing is needed.

Feel free to test harder, but I made my mind on it, and the
Cool VL Viewer is already benefitting from my findings. You
are of course free to ignore them (I also wrote in my first
message: "For what it is worth...", so it's up to you, really).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] how to read minidumps

[Henri Beauchamp]

On Tue, 4 Oct 2011 12:23:51 +0200, Thickbrick Sleaford wrote:

> On Tuesday 04 October 2011 09:31:00 Lance Corrimal wrote:
> > hi,
> > 
> > I'm pretty sure noone at LL is interested in the minidumps from my
> > TPV, so I'll have to read them myself... how do i do that?
> 
> At least on the Linux side, breakpad provides minidump_stackwalk,
> which takes a minidump file and a symbols file and produces a stack
> trace. That executable is not provided with the linden-packaged
> breakpad though. You will also need to make sure the symbols file
> you are using is from the same build that produced the minidump.

We've got a saying for this kind of silliness, in France:
"Pourquoi faire simple quand on peut faire compliqué ?"
("Why doing it the simple way when you can find a complex way to
do it ?")

I guess the stack_trace.log file what just too simple in LL's view...
* rolls eyes and shakes head, sighing deeply *

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] how to read minidumps

[Henri Beauchamp]

On Tue, 4 Oct 2011 21:40:49 +0100, Nexii Malthus wrote:

> You can read the google breakpad generated dumps straight into visual
> studio.

Excepted that I develop under Linux and that the stack_trace.log file
doesn't need any thrid party program neither any symbols table to tell
you excatly what went wrong at the first glance...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

On Fri, 06 Jan 2012 16:15:58 -0500, Oz Linden (Scott Lawrence) wrote:

> We're going to deploying changes to the inventory backend soon that 
> improve robustness and performance, but in testing those changes we 
> found that existing viewers relied on certain things being strictly 
> ordered.  With the new backend, that assumption does not always hold true.
> 
> Changeset d327dcc8ae51 
>  
> from viewer-development implements the viewer change needed to avoid 
> race conditions.  It should be straightforward to apply to any viewer, 
> and is safe to release before the changes are deployed (it is compatible 
> with the services as they are now).
> 
> You are strongly urged to port this patch and get it deployed.

How urgent is it ?... Do we have days or weeks ?  Will there be any
testing ground available (e.g. on the beta grid or in some sandbox
on the main grid) ?...

"You are strongly urged" to provide more accurate details... ;-P

Thank you in advance.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

On Sat, 7 Jan 2012 23:41:17 + (GMT), Hitomi Tiponi wrote:

> Will a patch be provided for Viewer 1,

Here is a patch that should apply to v1 viewers (you may perhaps get
rejects due to spacing changes, but they should be dead easy to work
around).

Note that by lack of any testing ground, I could not test the new
capability-based code path, but the old code path still works with
this patch applied.

Henri.


slviewer-v1-copy_and_wear.patch
Description: Binary data
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

Oops...

There was a bug in the patch I sent for v1 viewers (I forgot to replace
mFolderAdded(FALSE) with mFolderAdded(folder_added) in the constructor
of LLInventoryCopyAndWearObserver).

Attached to this email is the fixed patch.

Henri.


slviewer-v1-copy_and_wear_v2.patch
Description: Binary data
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

On Fri, 27 Jan 2012 16:57:20 -0500, Oz Linden (Scott Lawrence) wrote:

> Sorry for the delay letting you know - the inventory service on Aditi is 
> running the version this is needed for, so if you want to test a port, 
> do it there.

The feature also depends on a sim capability, and as far as I could see
(and in the sim I tested the feature in), that capability is not yet
implemented/advertized... Could you please tell us which sims advertize
the new "CreateInventoryCategory" capability on Aditi ?

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

Greetings,

Sorry for my late reply, but I have been busy backporting multiple
clothing layers to the Cool VL Viewer this last couple of weeks
(released today in Cool VL Viewer v1.26.3.4)...

On Mon, 6 Feb 2012 11:13:31 -0800, Jenn Leech wrote:

> I should add that we are also testing inventory routing changes on those
> sims on aditi as well. Items which are *newly* sent to your inventory
> should show up in the Received Items folder (e.g. someone gives you an
> item, you purchase an item etc. - these will show up in this new system
> folder).

And that's why it currently fails with the patch as provided by Oz for
v2/3 and backported by me to v1. Here is an example of the log I get in
the CG Test 8 region when hitting the "Copy And Wear" button of the
"Objects Contents" floater on a prim (named "Copy And Wear Test"
containing the items copied from the "Boy Next Door" stock (library)
avatar:

- On the first try, a new "Received Items" folder is created at the
root of the inventory, but nothing appears in it (luckily, the items
are copy-ok and therefore not gone from the container prim).

- On the second try (i.e. after "Received Items" was created), I get:

2012-02-09T18:28:47Z DEBUG: createNewCategory: Using the 
CreateInventoryCategory capability.
2012-02-09T18:28:48Z WARNING: accountForUpdate: No accounting for: 'Received 
Items' version: 5
2012-02-09T18:28:48Z WARNING: changed: 
gInventory.getCategory(f55dae61-cfe8-e6b6-5429-bfb973639ea9) was NULL
2012-02-09T18:28:48Z WARNING: changed: 
gInventory.getCategory(7371ea0b-2f57-ab08-02cb-031378564b83) was NULL
2012-02-09T18:28:48Z WARNING: changed: 
gInventory.getCategory(775690a1-f412-69c3-fafe-2e4698af15d9) was NULL
2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'Copy And Wear Test' 2 
with 1 descendents.
.../... (repeated for each item)
2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: 
----
2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'My Inventory' 902 
with 18 descendents.
2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received 
Items' version: 5
2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: 
76ac463f-ca9b-608b-b5f7-80d1cb519463
2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received 
Items' version: -1
.../... (repeated for each item)

The items then do appear in a sub-folder of "Received Items", but they
are not worn.

> We plan to announce a public beta for testing these behavior changes in the
> next couple of weeks and have been performing primarily internal testing so
> far.

What we'd need now is the viewer side code dealing with the "Received
Items" folder (obviously, it's a new system folder... another of
these stupid folders that will crowd the root of our inventory).

But I think it's a BAD IDEA to FORCE things to go into a specific folder
from the server side (it should be the viewer to decide where it puts the
received inventory: either at the root, like v1 always did, or in Received
Items" if it exists or if the user configured their viewer to do this):
the v3 viewer may perfectly reparent a folder received at the root of the
inventory to "Received Items" folder, while a v1 viewer (or a user
having deleted the "Received Items" folder because they don't want it)
will not be able to deal with reparenting from a non-existent folder to
its root folder (and the received items may be lost, which would cause
definitive inventory loss for no-copy items...).

Please, reconsider this IMO crippled protocol...

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote:

> Henri, that protocol is not subject to change at this very late date.

LOL !... You are kidding me, right ?... What's the use to ask for
feedback if everything is already settled ?... That got to be a
(very bad) joke !!!

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

On Sat, 11 Feb 2012 01:29:43 +1100, Tateru Nino wrote:

> On 10/02/2012 6:14 AM, Henri Beauchamp wrote:
> > On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote:
> >
> >> Henri, that protocol is not subject to change at this very late date.
> > LOL !... You are kidding me, right ?... What's the use to ask for
> > feedback if everything is already settled ?... That got to be a
> > (very bad) joke !!!
> A small correction: The Lab never asked for feedback, as far as I can
> tell. What was said was (essentially), "We're changing these things,
> here's what can go wrong, this is the patch you should apply."
> 
> I don't recall anyone asking for feedback.

Excepted that the patch is incomplete/non-functional and that
feedback *is* requested on the Wiki page for Aditi inventory
test region...
See: https://wiki.secondlife.com/wiki/InventoryBetaTest#Details

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Patch you should integrate

[Henri Beauchamp]

On Sat, 11 Feb 2012 05:21:03 +1100, Tateru Nino wrote:

> On 11/02/2012 3:26 AM, Henri Beauchamp wrote:
> > On Sat, 11 Feb 2012 01:29:43 +1100, Tateru Nino wrote:
> >
> >> On 10/02/2012 6:14 AM, Henri Beauchamp wrote:
> >>> On Thu, 09 Feb 2012 14:11:30 -0500, Oz Linden (Scott Lawrence) wrote:
> >>>
> >>>> Henri, that protocol is not subject to change at this very late date.
> >>> LOL !... You are kidding me, right ?... What's the use to ask for
> >>> feedback if everything is already settled ?... That got to be a
> >>> (very bad) joke !!!
> >> A small correction: The Lab never asked for feedback, as far as I can
> >> tell. What was said was (essentially), "We're changing these things,
> >> here's what can go wrong, this is the patch you should apply."
> >>
> >> I don't recall anyone asking for feedback.
> > Excepted that the patch is incomplete/non-functional and that
> > feedback *is* requested on the Wiki page for Aditi inventory
> > test region...
> > See: https://wiki.secondlife.com/wiki/InventoryBetaTest#Details
> >
> > Henri.
> Only insofar as to whether it functions or fails to function for the
> test criteria, as far as I can see.

OK... So let's be anal...

Quoting the Wiki ("***" highlightings are mine):

"Why: To help make Inventory more reliable and faster
 How: ***However*** you can."

and:

"Testing will be as simple as rezzing objects and transferring them
between yourselves and others ***by any method you can imagine***."

and finally:

"File JIRAs for any issues you find ..."

If it's not a request for feedback, then I don't know what it is..

Granted, I didn't file a JIRA, but since the patch was posted here...

Now, if feedback and contributions are not welcome by LL, they could
as well close this list and close the sources of their viewer...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] webkit for linux builds too old?

[Henri Beauchamp]

On Sat, 18 Feb 2012 09:30:24 +0100, Lance Corrimal wrote:

> Hi,
> 
> I get "webkit too old" log file entries on linux a lot...
> 
> Is there a special reason why the linux builds use webkit 4.6 while mac and 
> windows use 4.7.1?

Probably because LL didn't figure out the changes to how the new
qtwebkit must be packaged and linked now (with jscore that has
to be added)...

You could use the version I compiled for the Cool VL Viewer:
http://sldev.free.fr/libraries/llqtwebkit-linux-qt4.7.1-20110813.tar.bz2
with MD5 hash: 1baafd063d69cc7ae4a54de43debb790

You will also need to change indra/cmake/WebKitLibPlugin.cmake to
remove qgif, qjpeg and jpeg from WEBKIT_PLUGIN_LIBRARIES and to add
jscore to it. It would then read:

.../...
elseif (LINUX)
set(WEBKIT_PLUGIN_LIBRARIES ${LLQTWEBKIT_LIBRARY} ${QT_LIBRARIES} 
${QT_PLUGIN_LIBRARIES})
set(WEBKIT_PLUGIN_LIBRARIES
llqtwebkit
#qico
#qpng
#qtiff
#qsvg
#QtSvg
QtWebKit
QtOpenGL
QtNetwork
QtGui
QtCore
jscore
#   qgif
#   qjpeg
#   jpeg
fontconfig
X11
Xrender
GL

#sqlite3
#Xi
#SM
)
endif (WINDOWS)
.../...


Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] webkit for linux builds too old?

[Henri Beauchamp]

On Sat, 18 Feb 2012 17:41:30 +0100, Sythos wrote:

> i got another kind of problems, autobuild wrongly detect flags from
> host OS, i've added by hand ni makefile "--no-avx --no-sse4.1
> --no-sse4.2" and forced the cpu/arch, for a reason not clear (to me)
> autobuild create binaries with SSE4 and AVX registry optimization
> (probed CPU but not arch/OS)
> 
> compiling on linux as is from hg don't produce a usable package on my
> system

I don't use autobuild... I built it manually on a Mandriva 2007.1
system (which uses glibc v2.4, so it's compatible with LL's own prebuilt
binaries).

The instruction given in the REAMDE-linux.txt file, should be ammended
to read:

1) BUILDING Qt FOR LINUX LLQTWEBKIT
---

Acquire the Qt 4.7.1 source with our patches
 * Download the source:
hg clone https://bitbucket.org/lindenlab/3p-qt
 * This may take some as the archive contains a lot of files
 * You should now have a directory ~/3p-qt/qt-everywhere-opensource-src-4.7.1
 * Open a terminal window and cd to ~/3p-qt/qt-everywhere-opensource-src-4.7.1 
directory
 * run the following commands (we'll use the QTDIR variable in later steps) 
export QTDIR=`pwd`
export PATH=$QTDIR/bin:$PATH
export MAKEFLAGS="-j6"
export CFLAGS="-m32 -fno-stack-protector"
export CXXFLAGS="-m32 -fno-stack-protector -DQT_NO_INOTIFY"
export LDFLAGS="-m32 -fno-stack-protector"
export 
OPENSSL_LIBS="-L`pwd`/../OpenSSL/libraries/i686-linux/lib_release_client -lssl 
-lcrypto"

Configure the Build
$ ./configure -v -platform linux-g++-32 -fontconfig -fast -no-qt3support 
-static -release -no-xmlpatterns -no-phonon -openssl-linked -no-3dnow -no-sse 
-no-sse2 -no-sse3 -no-ssse3 -no-sse4.1 -no-sse4.2 -no-gtkstyle -no-xinput 
-no-sm -buildkey LL$(date +%s) -no-sql-sqlite -no-scripttools -no-cups -no-dbus 
-qt-libmng -no-glib -qt-gif -qt-libjpeg -qt-libtiff -qt-zlib -qt-libpng -opengl 
desktop -no-xkb -xrender -svg -no-pch -webkit -multimedia -javascript-jit 
-opensource -nomake examples -nomake demos -nomake docs -nomake translations 
-nomake tools

* Accept the license, if you do.

* Wait a few minutes while it churns and bootstraps.

* Build Qt:
$ make -j6

* Wait ages for it to build.

* You're done, but if you want to go on to build llqtwebkit on this machine, 
you'd really better do...

$ sudo make install

2) BUILDING LLQTWEBKIT
--

* set up environment vars - change '4.7.1' as appropriate for your Qt version.
$ export QTDIR=/usr/local/Trolltech/Qt-4.7.1
$ export PATH=$QTDIR/bin:$PATH

* configure llqtwebkit
$ qmake CONFIG-=debug

* Are you making a build for redistribution to other people and you are not 
specifically on Ubuntu Dapper?  Then please hack the resulting Makefile and add 
'-fno-stack-protector' to CXXFLAGS and CFLAGS.  This is important!  Otherwise 
your resulting lib will not be usable at runtime on many machines.

* build it
$ make

3) THE BITS THAT THE VIEWER BUILD NEEDS
---

* From Qt:
 lib/*.a
 plugins/imageformats/*.a
 
3p-qt/qt-everywhere-opensource-src-4.7.1/src/3rdparty/webkit/JavaScriptCore/release/libjscore.a

* From LLQtWebKit:
 libllqtwebkit.a
 llqtwebkit.h


Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] ObjectCategory

[Henri Beauchamp]

On Sat, 18 Feb 2012 22:37:49 +0100, Oz Linden (Scott Lawrence) wrote:
 
> Does anyone know of any current use of the ObjectCategory message or
> the Category information it carries?

It is used in LLSelectMgr::selectionSetObjectCategory(), but this
function doesn't seem to be used anywhere in the viewer code...

I would say that it would allow to set the category (inventory folder)
to which the object is to be "derezzed" (this is normally set on
rezzing for objects dragged from the inventory and dropped into the
sim, so that when "Taking" the object back, it reappears in the
inventory folder from which it was rezzed).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Viewer Policy Changes

[Henri Beauchamp]

Here is my take on this matter:

http://sldev.free.fr/forum/viewtopic.php?f=5&t=741&p=3259#p3259

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs

[Henri Beauchamp]

On Tue, 10 Apr 2012 09:01:24 -0400, Oz Linden (Scott Lawrence) wrote:

> I'd like to get a tutorial on how the AOs built into viewers work - what 
> inputs do they use, and how do they set the animations they set.
> 
> Would someone who's got deep know-how on this either write up one for me 
> (or point me to one if it exists), or make some time to go over it with 
> me interactively?

It would be better implementing a server-side AO (with the viewer only
transmitting the replacement animation UUIDs to the server, for example
via a capability), because the current viewer-side AOs simply duplicate
what scripted AOs are doing (so they are not really better regarding
animations priority conflicts, etc) but lack the capability offered by
(good) scripted AOs to be auto-switched on and off via the Lockmeister
"booton"/"bootoff" commands which allow for cooperation between AOs and
with device you sit onto and that want to play their own anim instead of
the AO's.

I really hope a proper server side AO feature is to be implemented...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs

[Henri Beauchamp]

On Fri, 13 Apr 2012 12:16:03 -0400, Oz Linden (Scott Lawrence) wrote:

> Ok... so those are nice opinions to have, but you're not succeeding in 
> educating me... what is it that makes these better or worse?
> 
> What do they do or not do that differentiates one from another?

Again, the viewer side AOs are in fact mimicking exactly what scripted
AOs (and most specifically Francis Chung's "Franimation Overrider") do.

The scripted AOs got two main flaws (which are in fact the result of
the same lack in the scripted event support): they are often too slow
to change the overriding animation in time to avoid seeing the
overridden animation playing for a second or so before the overriding
anim is started.
As a result of trying to mitigate this issue, AOs all too often tax the
sim servers by using a very high rate timer that checks the currently
playing anim every frame (llSetTimerEvent(0.02); or less) so to detect
the start of the default animation to be overridden and to start the
corresponding overiding animation as fast as possible.

While it is possible to script relatively "low lag" AOs, especially by
using the control() event and detecting key presses that cause the
walk/turn/run/fly anim changes and then using a lower frequency timer
to catch the rest of the animation changes (e.g. when "falling"), they
are still more laggy (seen from the server side) than a viewer-side AO.

These flaws are due to the lack of a change() event for animation
changes (time to implement CHANGED_ANIMATION, perhaps ?...) in LSL: if
such an event existed, then the scripted AOs could become just as fast
as viewer-side AOs if not faster (see below about the "ping" problem)
and would not cause any measurable lag (since the high frequency
timer() would then become useless and would be removed).

Viewer side AOs simply watch the animation changes as sent by the
sim server and, when a default animation (ANIM_AGENT_*) is triggered,
the viewer watches its AO table to see if a custom animation should
replace the default one, and in the affirmative, sends stop default
anim/start overriding anim orders to the server. Note that while there
is no lag involved doing so from the server side, the user may still
experience a delay (assimilated to "lag" from their point of view)
if their ping with the sim server is high (a 250ms ping will then
typically result in a half second delay before the default anim gets
overridden as seen by the user in their viewer, thus not providing a
better experience than a scripted AO).

As mentionned in other messages in this thread, there is also the
problem that the viewer side AOs are currently poorly implemented and
lack region change/TP checks, etc, causing the animation overriding
to fail in some cases, when scripted AOs are not affected (not hard
to fix however... Just a matter or re-coding them properly).

Another, much worst issue with viewer side AOs, is that, like I
explained in my previous message in this thread, they lack a way to
be disabled automatically by scripts.
Let me explain this issue more in details: while AOs are great, they
can be a nuisance when interacting with certain scripted objects which
want to play their own animation on your avatar. This is especially
the case for "seats" (in the largest extent of the term: i.e. any
object you "sit" your avatar onto) that usually provide their own sit
anim; these objects stop the default sit anim (llStopAnimation("sit"))
then start their own anim. If your AO is configured to override the
default sit anim, then the overriding anim will also override the
scripted seat object's anim.
In order to solve this problem, the Lockmeister protocol
(https://wiki.secondlife.com/wiki/LSL_Protocol/LockMeister_System#Special_Commands)
was extended with "bootoff" and "booton" commands ("boot", because
the first AOs were in fact used in scripted shoes/boots) allowing to
(respectively) turn off and turn back on the compatible AOs
automatically.
The seat then just has to send a "bootoff" commmand when your avatar
sits down on it, then a "booton" command when the avatar stands up,
and your AO gets automatically turned off and back on so that the
seat's anim is not overridden.

Note that there are other cases than just seats (for example when
wearing two AOs or, for BDSM folks, when scripted cuffs are used
and must be able to override an AO in some cases and especially
when the avatar is fully chained/bound).

The problem with viewer-side AOs is that since a viewer can't listen
to a private channel, it can't intercept the "booton"/"bootoff"
commands sent by Lockmeister-compatible devices. Of course, you could
use a "bridge" (an object with a script that listens to the
Lockmeister channel and relays the boot* commands to the viewer via
a special llOwnerSay(), à la Restrained Love), but it's IMHO quite
dirty.

Also, not all seats/scripted-devices-with-built-in-anims use Lockmeister
and this results in having to manually disable the AO in some cases.


I think the above 

Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs

[Henri Beauchamp]

On Fri, 13 Apr 2012 16:05:05 -0700, Kadah wrote:

> On 4/13/2012 1:10 PM, Henri Beauchamp wrote:
> > Again, the viewer side AOs are in fact mimicking exactly what
> > scripted AOs (and most specifically Francis Chung's "Franimation
> > Overrider") do.
> 
> I believe FS's was designed to mimic the ZHAO II hud, it even uses its
> config notecards. "Franimation Overrider" is a new one to me.

Francis Chung's "Franimation Overrider" existed long before the ZHAO
HUD, and in fact, at the end of the documentation for the latter you
can read: "Based on Francis Chung's Franimation Overrider v1.8"

Let's not overlook the contribution of the original authors (I hate
it enough when it happens to my contributions to not let it happen
to others'...).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs

[Henri Beauchamp]

On Sat, 14 Apr 2012 15:59:47 +1000, Tateru Nino wrote:

> That's because the AOs in TPVs are necessarily incomplete - because they
> cannot integrate with the server-side. If Linden Lab *were* considering
> just dropping similar functionality into the viewer without additional
> server-side integration, I'd consider that to only be half a job.
> 
> ie: If Linden Lab basically copied what the TPVs do for the official
> viewer then creators would once again likely wind up in the position of
> telling customers "No, you can't use the builtin thingy. You have to use
> the scripted thingy instead, or it won't work properly. Why? Well, it's
> kind of complicated to explain..." That's a point of friction that users
> don't need.

Fully seconded, and that's the very reason behind my first message in this
thread.

Henri
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] master_message_template.msg

[Henri Beauchamp]

Greetings,

Could someone at the Lab update the master_message_template.msg, please
(http://secondlife.com/app/message_template/master_message_template.msg)
It has not been updated in ages (probably over a year)...

There are at least ObjectFlagUpdate and ScriptDialog each missing one
extra data block, and keeping this template up to date is a good way
for TPV developers to spot new features that they should backport.

Many thanks in advance !

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] master_message_template.msg

[Henri Beauchamp]

On Thu, 19 Apr 2012 11:50:26 +0200, Lance Corrimal wrote:

> Am Donnerstag, 19. April 2012, 10:10:55 schrieb Henri Beauchamp:
> 
> > Could someone at the Lab update the master_message_template.msg, please
> > (http://secondlife.com/app/message_template/master_message_template.msg)
> > It has not been updated in ages (probably over a year)...
> 
> 
> isn't the current message template on bitbucket?
> https://bitbucket.org/lindenlab/master-message-
> template/raw/tip/message_template.msg

This is not the version which is checked against while compiling...
In any case, if an up to date version exists, then it's just a matter of
creating a symbolic link to it on the webserver...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] master_message_template.msg

[Henri Beauchamp]

On Sun, 22 Apr 2012 21:06:12 +0200, Nicky D. wrote:

> On Thu, Apr 19, 2012 at 12:04 PM, Henri Beauchamp  wrote:
> > On Thu, 19 Apr 2012 11:50:26 +0200, Lance Corrimal wrote:
> >
> >> Am Donnerstag, 19. April 2012, 10:10:55 schrieb Henri Beauchamp:
> >>
> >> > Could someone at the Lab update the master_message_template.msg, please
> >> > (http://secondlife.com/app/message_template/master_message_template.msg)
> >> > It has not been updated in ages (probably over a year)...
> >>
> >> isn't the current message template on bitbucket?
> >> https://bitbucket.org/lindenlab/master-message-
> >> template/raw/tip/message_template.msg
> >
> > This is not the version which is checked against while compiling...
> 
> Lance is correct. That was changed a good while ago:
> https://bitbucket.org/lindenlab/viewer-release/changeset/92aff170d95e

You are right... Since the Cool VL Viewer is still using the Snowglobe
build scripts, it was using the "legacy" master template URI, but even
when replacing the legacy URI with the new one
(http://bitbucket.org/lindenlab/master-message-template/raw/tip/message_template.msg)
I get "in message ObjectFlagUpdate: has 1 extra blocks", which
corresponds to the "ExtraPhysics" block introduced for the Havoc
update and the new object physics parameters.

So, even the new master template needs updating...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Need help diagnosing a Linux viewer launch failure

[Henri Beauchamp]

On Tue, 26 Jun 2012 06:24:42 -0400, Oz Linden (Scott Lawrence) wrote:

> My Linux box is unavailable at the moment... if you have one and can 
> take a moment to tell me why this beta candidate build fails on startup 
> I'd appreciate it
> 
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-beta-review/rev/260601/arch/Linux/installer/SecondLife-i686-3.3.4.260601.tar.bz2

Launching and working fine under Mandriva 2010.2 and Mandriva 2009.0.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote:

> On Fri, 27 Jul 2012 16:59:18 -0400
> holydoughnuts  wrote:
> 
> The implementation that I wrote for Singularity (not yet in the
> the official release) is more on the side of "blazing fast" :p.
> The bottleneck is entirely server-side, but I've seen download
> speeds of 1 MB/s non-stop till all textures were there.

With just a few tweakings to the texture fetcher (and in particular
a setting that permits up to 32 concurrent HTTP fetches), I get much
more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the
10MB/s+ range while rezzing in heavily textured areas and the rezzing
time is pretty low... This has been so for many months (well over
a year actually) already.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Compilation issues under MSVC2010: Windows guru help *badly* needed !

[Henri Beauchamp]

Greetings, folks !

I just ran into a problem that lets me quite clueless: I recently migrated
the Cool VL Viewer build system from VS2005 to VS2010 and succeeded, two
weeks ago, to compile v1.26.5.0 under VS2010.

This week, I was about to make two new releases (v1.26.4.23 which is basically
the same as v1.26.5.0 with just a few things added) and v1.26.5.1 which is the
firts release with the v3.3.4 renderer backported (working just fine under
Linux).

But then I came around an issue dealing with Windows headers inclusion that
I just can't figure out. When compiling (either v1.26.4.23 or v1.26.5.1),
VS2010 fails for the llwindow library, with the following error (sources
path edited to linden\ for clarity):

llwindow.cpp
linden\indra\llwindow\llwindowwin32.h(45): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(45): error C2143: syntax error : missing 
',' before '&'
linden\indra\llwindow\llwindowwin32.h(146): error C2061: syntax error : 
identifier 'COMPOSITIONFORM'
linden\indra\llwindow\llwindowwin32.h(147): error C2061: syntax error : 
identifier 'CANDIDATEFORM'
linden\indra\llwindow\llwindowwin32.h(148): error C2061: syntax error : 
identifier 'IMECHARPOSITION'
linden\indra\llwindow\llwindowwin32.h(150): error C2061: syntax error : 
identifier 'RECONVERTSTRING'
linden\indra\llwindow\llwindowwin32.h(177): error C2146: syntax error : missing 
';' before identifier 'mWndProc'
linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(237): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(237): error C2143: syntax error : missing 
',' before '&'

COMPOSITIONFORM & Co pertain to Imm.h and the errors around lines 45 and 177+
are related to undefined MSG and WNDPROC types (that seem ro pertain to
WinUser.h).

The weird thing is that I didn't change a single thing in v1.4.26.23 in
llwindows/, neither in the cmake files when compared to v1.26.5.0 that
(still) compiles just fine !!!

I checked the Windows headers inclusion and they seem just fine, with,
in llwindowwin32.h:


#ifndef LL_LLWINDOWWIN32_H
#define LL_LLWINDOWWIN32_H

// Limit Windows API to small and manageable set.
#define WIN32_LEAN_AND_MEAN
#include 
#include 

.../...


Adding #include  after #include  in llwindowwin32.h
allows to get rid of the undefined COMPOSITIONFORM ... RECONVERTSTRING
types, but adding #include  doesn't solve the issue with
MSG and WNDPROC not being defined, even if I use:


#ifndef LL_LLWINDOWWIN32_H
#define LL_LLWINDOWWIN32_H

// Limit Windows API to small and manageable set.
#define WIN32_LEAN_AND_MEAN
#include 
#include 
#include 
#undef NOUSER
#undef NOMSG
#undef _WINUSER_
#include 


I always get:

llwindow.cpp
linden\indra\llwindow\llwindowwin32.h(50): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(50): error C2143: syntax error : missing 
',' before '&'
linden\indra\llwindow\llwindowwin32.h(182): error C2146: syntax error : missing 
';' before identifier 'mWndProc'
linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(242): error C4430: missing type specifier 
- int assumed. Note: C++ does not support default-int
linden\indra\llwindow\llwindowwin32.h(242): error C2143: syntax error : missing 
',' before '&'

What is totally flabbergasting is that between v1.26.5.0 (which compiles
fine) and v1.26.4.23, the diff is only 300Kb and NOTHING in it touches
the cmake files neither the llwindow/ files !!!
Plus, llwindowwin32.cpp (which also needs and includes llwindowwin32.h)
compiles just fine, unlike llwindow.cpp (and yes, I also tried to add
the same Windows includes in the latter than in the former, to no avail).

Finally, I tried on two different build systems (a WinXP SP3 virtual
machine and a genuine (non emulated) Windows 7 Ultimate system), to no
avail (not a build system issue, apparenetly, especially since v1.26.5.0
still compiles just fine).

Any clue of what is going wrong with this sh*tty VS2010 ?

Many thanks in advance !

Henri.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] [SOLVED] Re: Compilation issues under MSVC2010: Windows guru help *badly* needed !

[Henri Beauchamp]

Problem solved !...

Man, what a sh*tty, Mickey Mouse OS Windoze (or "Windaube", in French,
for puns amateurs) can be ... Its UTTER stupidity and hackiness
NEVER cease to amaze me !

The reasons for all my troubles were that:

- windows.h contains a "#pragam once" directive (instead of standard,
  robust and flawless #ifndef _HEADER_NAME_ / #define _HEADER_NAME_ /
  ... header here ... / #endif guards), which means that the
  pre-processor will *never* even *try* to include twice that header
  in nested header invocations.

- Somehow (but I didn't yet figured out it all: to be frank, at this
  point I don't really care any more...), #define WIN32_LEAN_AND_MEAN
  leads the pre-processor to only include the sub-headers (included
  from windows.h) that contain definitions used in the file calling
  the "#include " (and beacuse of the #pragma once, if
  another, nested file includes this file and contains other
  definitions requiring sub-headers that have been skipped the first
  time, it is f*cked up !).

- In v1.26.4.23 and v1.26.5.1 I added support for private memory pools,
  but in a more complete way than in LL's viewer (i.e. proper memory
  usage functions where added for Linux and MacOS-X in llsys.cpp to be
  used by the private pools manager in llmemory.cpp), and this lead me
  to add an '#include "sys.h"' into llmemory.h. And... llsys.h itself
  already contains an #include ...

- In llwindow.cpp, the headers where included as follow:
  
  #include "linden_common.h"
  #include "llwindowheadless.h"

  #if LL_MESA_HEADLESS
  #include "llwindowmesaheadless.h"
  #elif LL_SDL
  #include "llwindowsdl.h"
  #elif LL_WINDOWS
  #include "llwindowwin32.h"<-- With the problem arising here
  #elif LL_DARWIN
  #include "llwindowmacosx.h"
  #endif

  ...and it comes out that llwindowheadless.h was itself including
  llmemory.h, which was including (due to my modifications) sys.h,
  which was including windows.h. Then when llwindowwin32.h was
  trying to include windows.h in its turn (or winuser.h, after I
  tried adding it to solve the issue), it failed because of the
  combined effect of #pragma once and #define WIN32_LEAN_AND_MEAN.

The solution was to reorder the includes in llwindow.cpp to read:

  #include "linden_common.h"

  #if LL_MESA_HEADLESS
  #include "llwindowmesaheadless.h"
  #elif LL_SDL
  #include "llwindowsdl.h"
  #elif LL_WINDOWS
  #include "llwindowwin32.h"
  #elif LL_DARWIN
  #include "llwindowmacosx.h"
  #endif

  // SHITTY MSVC INCLUDE ISSUES WARNING:
  // include llwindowheadless.h* AFTER* llwindowwin32.h, else bad
  // things happen at compilation time !
  #include "llwindowheadless.h"

Note that I'm still lucky that llwindowheadless.h doesn't need
definitions from sub-includes of windows.h that are skipped by
the latter when it is included by llwindowwin32.h (if you still
can follow all the indirections in this reasonning, lol !)...

To prevent such issues in the future, I suggest that the viewer
sources are ammended so that #include  is *NEVER*
done from header files, but only from the *.cpp files using
headers files that require windows.h's inclusion; this may
lead to have to manually add a few includes (windows.h
sub-includes) in the *.cpp files (that might be skipped by
windows.h because of the #define WIN32_LEAN_AND_MEAN if some
definitions are used in the *.h file and not in the *.cpp
file), but at least those includes won't be impacted in case of
nesting by the "#pragma once" that hit me hard here, since even:
  #undef NOUSER
  #undef NOMSG
  #undef _WINUSER_
  #include 
could not get past it and prevented the needed winuser.h
definitions to be included at all !...

I can't provide a patch, since LL won't use it (not having given up
my privacy to fill up their stupid "contribution agreement" form and
stuff...), but you may consider this info as LGPL (or anything
fancying you) and produce the patch yourself.

Henri.


On Sun, 29 Jul 2012 10:40:02 +0200, I wrote:

> Greetings, folks !
> 
> I just ran into a problem that lets me quite clueless: I recently migrated
> the Cool VL Viewer build system from VS2005 to VS2010 and succeeded, two
> weeks ago, to compile v1.26.5.0 under VS2010.
> 
> This week, I was about to make two new releases (v1.26.4.23 which is basically
> the same as v1.26.5.0 with just a few things added) and v1.26.5.1 which is the
> firts release with the v3.3.4 renderer backported (working just fine under
> Linux).
> 
> But then I came around an issue dealing with Windows headers inclusion that
> I just can't figure out. When compiling (either v1.26.4.23 or v1.26.5.1),
> VS2010 fails for the llwindow library, with the following error (sources
> path edited to linden\ for clarity):
> 
> llwindow.cpp
> linden\indra\llwindow\llwindowwin32.h(45): error C4430: missing type 
> specifier - int assumed. Note: C++ does not support default-int
> linden\indra\llwindow\llwindowwin32.h(45): error C2143: syntax error : 
> missing ',' before '&'
> linden\indra\

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

I would agree with you if all decent HTTP servers (Apache, but not
only), didn't have their own throttling algorithms are weren't able
to just drop the excess of connections when they run out of sockets.
But they do have such throttling mechanisms, so it's no issue at all
and in fact, 32 is the max number of connection per IP an Apache
server would accept by default (the admin can of course change this
setting: it's not uncommon to encounter websites configured for up
to 64 connections per IP).

FYI, early HTTP fetches code was allowing up to 32 connections already,
then it was lowered to 8, then raised back up to 16, and I since lost
track of what maximum is currently hardcoded in LL's viewer...

That's why I made it a configurable setting: if you start seeing
timeouts or "busy" replies from the server in your viewer log, then
you can still lower the setting. The default in the Cool VL Viewer
is 16, but I have always used 32 myself and never came accross any
issue, including in over-crowded sims (and I can enjoy a very fast
rezzing experience): of course, you could argue that this is because
everyone else in the sim is limited to 8 connections... And you
could be right (hard to say: only LL could...).

As for keeping only two persistent connections, this can seem a
good idea, but on the viewer side it means that the free cores
(on a quad core CPU, only one is always used at 100% for rendering,
the three others are only (partially) used while decoding textures
and for other threads, suchs as fetching/caching) are just sitting
there, doing nothing as they wait for a texture to be downloaded
from your only two "pipes"... and what happens when a connection
stalls and timeouts ?... You loose half your bandwitdh (instead
of only 1/32th) !...

I would therefore recommend a higher number of persistent
connections (16 sounds good and 8 an absolute minimum); alas such
connections are precisely very limited (usually 4 per IP) in
standard HTTP server configurations (they are considered costy,
precisely because they are persistent while the traffic is only
sporadic on normal web servers).
This means that the grid's (SL and OpenSIM) texture HTTP servers
would have to be configured specially to allow a higher limit per
IP...

On Sun, 29 Jul 2012 15:59:38 +0200, Carlo Wood wrote:

> On Sun, 29 Jul 2012 10:07:18 +0200
> Henri Beauchamp  wrote:
> 
> > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote:
> > 
> > > On Fri, 27 Jul 2012 16:59:18 -0400
> > > holydoughnuts  wrote:
> > > 
> > > The implementation that I wrote for Singularity (not yet in the
> > > the official release) is more on the side of "blazing fast" :p.
> > > The bottleneck is entirely server-side, but I've seen download
> > > speeds of 1 MB/s non-stop till all textures were there.
> > 
> > With just a few tweakings to the texture fetcher (and in particular
> > a setting that permits up to 32 concurrent HTTP fetches), I get much
> > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the
> > 10MB/s+ range while rezzing in heavily textured areas and the rezzing
> > time is pretty low... This has been so for many months (well over
> > a year actually) already.
> 
> I agree that that would be an advantage for the user; but it's not
> clear to me if it is allowed (or will be in the near future) to
> have 32 concurrent fetches.
> 
> The rationale that it SHOULD be allowed is that the user will
> download those textures anyway; so, you might as well allow
> them to get it quickly, in a short time: this has no influence
> on the average number of open file descriptors on the server.
> 
> I understand that LL is afraid that once viewers can keep sockets
> open (for reuse) that the servers run out of filedescriptors. Of course,
> this is all to true. Therefore I propose to set a limit on the
> maximum number of UNUSED filedescriptors. However, there should be
> no limit or a much higher limit, on the number of connections that
> are actually in use. The question is then: when is a filedescriptor
> "unused"? Well, I'd say that for the sake of re-use, it can be
> considered unused if there hasn't been a new request for it for
> -say- a second.  It's probably best to define multiple stages,
> that is:
> * Allow a maximum of 32 connections.
> * Allow up to 32 connections that are unused for 1 second.
> * Allow up to 8 connections that are unused for 10 seconds.
> * Allow up to 2 connections that are unused for 1 minute.
> * Allow 1 connection to be unused for 20 minutes (or whenever
> one leaves a region and it can be determined that this server
> won't be needed or used anymore).
> 
> Of course this means that upon teleport to a new re

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2012-07-29 04:07 , Henri Beauchamp wrote:
> > With just a few tweakings to the texture fetcher (and in particular
> > a setting that permits up to 32 concurrent HTTP fetches),
> 
> Caution... once we begin supporting persistent connections and pipelined 
> requests on the server side (we're working on it), opening that many 
> connections will very likely be considered abuse of the service.  
> Allowing a single server to have that many potentially long-lived 
> connections to the same server would starve the file descriptor pool 
> very quickly at the server end, adversely affecting other users.

Don't put word in my mouths, that I never pronounced... I was not speaking
about *persistent* connections. The current HTTP fetches are not persistent
connections, and that's why 32 simultaneous requests are not really an issue
(and it was actually the limit in Snowglobe v1.5, thus why I kept it in the
Cool VL Viewer, but made it configurable (and defaulting to 16), when I
noticed that the v2 viewers changed that limit down to 8 then up to 16 and
then to whatever number it is now hardcoded with).

> HTTP itself recommends that clients not maintain more than 2 connections 
> to the same service [1].  I don't know exactly what limit we will decide 
> is reasonable (I expect that 2 will be ok, but don't know whether or not 
> some larger number will be also).

I bet 2 persistent connections will not be as performant as 16 (or even
only 8) transient ones... Especially for oversea users, when links go
through a load of routers before the viewer can actually communicate with
LL's servers (and I have seen numerous times buggy/badly configured routers
dropping "persistent" connections).
Not to mention the underusage of the additional CPU cores for image decode
and caching threads (that will have to wait each time and will, at best,
process 2 images before the next 'bunch' (if 2 is already a 'bunch')
arrives).

> Please bear this in mind as you think about your designs.

Please, don't underestimate my thinking capacity... I also think I proved
numerous times with the Cool VL Viewer that I was very careful and quite
reasonnable (refusing to implement things that could overload servers:
I can give you half a dozen of examples if you want).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] ok this may sound dumb but what is the llphysicsextention package

[Henri Beauchamp]

On Tue, 07 Aug 2012 16:45:03 -0700, Oz Linden (Scott Lawrence) wrote:

> On 2012-08-07 16:09 , Angel Dreams wrote:
> > its something i saw i never seen that package before is it new or 
> > something?
> 
> It is the wrapper around the Havok functionality in the viewer.  It 
> replaces (and incorporates) llconvexdecomposition.
   ^^
Which is unfortunate... because Open Source viewers all use HACD to
replace the closed source llconvexdecomposition.

I'd suggest that the HAVOC stub is kept separate from the
llconvexdecomposition stub.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] ok this may sound dumb but what is the llphysicsextention package

[Henri Beauchamp]

On Wed, 8 Aug 2012 10:27:18 -0700, Nyx Linden wrote:

> We use Havok libraries as our implementation of llconvexdecomposition.
> The interface to llconvexdecomposition has not changed, only the packaging
> of it, as we needed to add more havok functionality to the viewer for
> pathfinding.
> 
> You should be able to tie in HACD to llphysicsextensions and leave the rest
> stubbed out with minimal effort. If anyone has difficulty with porting to
> the new structure do let us know, and we'll help how we can.

If the efforts are so minimal, what about doing it
yourself ?... :-P

I mean, why keeping the llconvexdecomposition stub at all when HACD is
available and used by all OpenSource viewers based off LL's v3 ?...

LL could even drop Havok for mesh convex decomposition: HACD actually
provides much simpler (from the users' point of view) and no less
cost-effective decomps than Havok's, and it lowers the number of
steps necessary to upload a mesh.

> Separating out the two parts would just result in havok libraries that
> are shared between convex decomposition and the pathfinding
> functionality being linked in twice for the main viewer.

And gluing them together causes issues for people using HACD (i.e. all
existing TPVs)... Not that I care much myself since I don't use LL's v3
repository and build system, but others will appreciate your "minimal
efforts" to keep things easy to cope with... ;-)

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Regressions in the latest v3.4.1 development viewer

[Henri Beauchamp]

Greetings.

Just two pointers to JIRAs I just created, pointing out regresssions I
found while backporting v3.4.1 code to the Cool VL Viewer:

https://jira.secondlife.com/browse/VWR-29581
https://jira.secondlife.com/browse/VWR-29582

I didn't bother trying to find fixes (no time for that): for now, I
just rejected the changes for the Cool VL Viewer and kept the old code
that works well enough.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Mercurial repository webpage layout

[Henri Beauchamp]

Greetings,

The layout of LL's mercurial repository (http://hg.secondlife.com/)
recently changed, and for the worst... The old layout allowed to see
with a single glance what/when things last changed in each repository
(the list on the right gave the last change's date), while now you
must click on *each* repository link in the short list to open the
commits page and see whether anything changed or not (the "recent
activity" on the left not reflecting commits activity at all).

Could this annoying layout be reverted back to the good old one,
please ?...

Every minute lost browsing pages for nothing is not spend coding and
is lost time...

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Contributing to the JIRA is *obviously* a wating of my time

[Henri Beauchamp]

For what it's worth:

Alexa closed a legit and unresolved issue for the Nth time...

I'm giving up with the JIRA !!!  This was my last contribution to it.

Henri.

Begin forwarded message:

Date: Wed, 29 Aug 2012 08:15:41 -0700 (PDT)
From: "Alexa Linden (Closed) (JIRA)" 
To: sl...@free.fr
Subject: [JIRA] (VWR-29581) Primitives not rebuilt after hitting CTRL Z to 
cancel a translation or rotation in Build/Edit mode

 [ 
https://jira.secondlife.com/browse/VWR-29581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexa Linden closed VWR-29581.
--

Resolution: Duplicate

> Primitives not rebuilt after hitting CTRL Z to cancel a translation or 
> rotation in Build/Edit mode
> --
>
> Key: VWR-29581
> URL: https://jira.secondlife.com/browse/VWR-29581
> Project: 1. Second Life Viewer - VWR
>  Issue Type: Bug
>  Components: Rendering
>Affects Versions: Open Development Candidates
> Environment: Viewer development v3.4.1, any OS, any graphics card & 
> driver.
> Second Life 3.4.1 (263582) Aug 16 2012 14:08:54 (Second Life Development)
> Release Notes
> You are at 462886.0, 304780.0, 835.1 in Hunburgh located at 
> sim9683.agni.lindenlab.com (216.82.45.17:13004)
> Second Life RC Magnum 12.08.17.263676
> Release Notes
> CPU: Intel(R) Core(TM)2 Quad CPUQ6600  @ 2.40GHz (3402.06 MHz)
> Memory: 8114 MB
> OS Version: Linux 3.4.8 #1 SMP Mon Aug 13 01:21:09 CEST 2012 i686
> Graphics Card Vendor: NVIDIA Corporation
> Graphics Card: GeForce GTX 460/PCIe/SSE2
> OpenGL Version: 4.2.0 NVIDIA 304.32
> libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
> J2C Decoder Version: KDU v6.4.1
> Audio Driver Version: FMOD version 3.75
> Qt Webkit Version: 4.7.1 (version number hard-coded)
> Voice Server Version: Not Connected
> Built with GCC version 40103
> Packets Lost: 0/4775 (0.0%)
>Reporter: Henri Beauchamp
>Priority: Major
>  Labels: rendering, viewer
> Attachments: idleUpdate_patch.txt, NoRebuildAfterCtrlZ.png, 
> StillKOIn3.4.1.263920.png
>
>
> With the newest viewer development, when you move or rotate a primitive in 
> Edit mode and hit CTRL Z to cancel that translation/rotation, the render 
> pipeline doesn't rebuild the primitive, resulting in not seeing the primitive 
> position/rotation changing properly while its selection outline does change.
> See the attached screen shot for an example of what happen after cancelling a 
> translation with CTRL Z.
> The code changes responsible for this issue are attached as a patch 
> (reverting that patch cures the issue). They are related to how iddleUpfate() 
> calls are now dealt with. Please, Note that the patch was created from the 
> Cool VL Viewer sources and may not apply cleanly to LL's viewer due to 
> spacing/formatting changes and additional code for LLVOTextBubble and 
> LLVOCloud classes that don't exist any more in LL's viewer (but the code 
> changes are compatible with LL's viewer).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.secondlife.com/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] accidental commits...

[Henri Beauchamp]

On Thu, 06 Sep 2012 17:30:10 -0400, Oz Linden (Scott Lawrence) wrote:

> We had an accidental push to viewer-development (steps have been taken 
> to avoid a repeat).
> 
> The correct tip as of when I'm writing this is 24758:63088c18a73c
> 
> Sorry about that...
> 
> For the conspiracy-minded, this had nothing whatever to do with todays 
> Jira changes, and all those commits will be coming back when they've 
> been properly tested.

No need to invoke a conspiracy: LL simply *never* understood what
"Open Source" actually means... The new JIRA fiasco is just another
proof.

'nuff said.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Fri, 27 Jul 2012 13:46:22 -0400, Oz Linden (Scott Lawrence) wrote:

>  The start of a unified approach to HTTP-based communications
>  between the viewer and grid services with a goal of achieving
>  reliability, consistency and a better overall experience on
>  the grid.
> 
> Project Viewer for testing is here:
> 
> http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP
> 
> Especially if you have had problems when you enable the use of HTTP, we 
> would very much appreciate your giving this a try.  We know that it does 
> not yet solve all the problems, but we think that it solves some and 
> provides the first steps needed for solving some more in the future.

I backported the new HTTP library to the Cool VL Viewer v1.26.5.14
(experimental branch) and made it so that it can be switched on/off
(the old HTTP texture fetching code being used when the new library
is off) to ease comparisions (even though once toggled, the viewer
must still be restarted so that the change takes effect).

So far, I didn't see much difference with what I was achieving with
the Cool VL Viewer's (slightly) ammended texture fetcher code, but of
course, this is on "standard" servers.

Is there any server running the corresponding improved HTTP code on
Aditi ?

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Mon, 22 Oct 2012 09:57:40 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2012-10-20 11:14 , Henri Beauchamp wrote:
> > Is there any server running the corresponding improved HTTP code on
> > Aditi ?
> 
> Not yet.  When there is, we'll post a note on this list.

OK, thanks.

> As Tankmaster said, our ambition at this point is that the server side 
> will be compatible with all existing viewers HTTP usage.   The new 
> version will have different enforcement of fairness heuristics to 
> attempt to prevent viewers from monopolizing server side resources; it's 
> possible that this will cause problems for viewers that have overly 
> aggressive use of multiple connections

In the current implementation, the new HTTP core can be configured to
spawn from 12 to up to 256 (!) simultaneous connections... The texture
fetcher code however never queues more than 40 requests at once, thus
limiting the potential damages, but you might want to have a look at
that and provide safer bounds before the new HTTP core gets used for
more services in the viewer...
My backports allows from 8 to 32 simultaneous connections, with 12 as
the default (i.e. same default as in viewer-http).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Tue, 23 Oct 2012 00:01:29 -0400, Monty Brandenberg wrote:

> On 10/22/2012 6:28 PM, Henri Beauchamp wrote:
> 
> > In the current implementation, the new HTTP core can be configured to
> > spawn from 12 to up to 256 (!) simultaneous connections... The texture
> > fetcher code however never queues more than 40 requests at once, thus
> > limiting the potential damages, but you might want to have a look at
> > that and provide safer bounds before the new HTTP core gets used for
> > more services in the viewer...
> 
> No, the current HTTP code allows up to 12 concurrent connections with
> a shipping default of 8.  A debug control is available to *reduce* not
> increase the concurrency.

>From indra/llcorehttp/_httpinternal.h:

// Limits on connection counts
const int HTTP_CONNECTION_LIMIT_DEFAULT = 8;
const int HTTP_CONNECTION_LIMIT_MIN = 1;
const int HTTP_CONNECTION_LIMIT_MAX = 256;

So, yes you are right that the default is 8, but the maximum is 256,
like I reported.

Now, looking closer, there are two different limits. From
indra/llcorehttp/httprequest.h:

enum EClassPolicy
{
/// Limits the number of connections used for the class.
CP_CONNECTION_LIMIT,

/// Limits the number of connections used for a single
/// literal address/port pair within the class.
CP_PER_HOST_CONNECTION_LIMIT,

/// Suitable requests are allowed to pipeline on their
/// connections when they ask for it.
CP_ENABLE_PIPELINING
};

And in fact, llappcorehttp.cpp only touches CP_CONNECTION_LIMIT, so
CP_PER_HOST_CONNECTION_LIMIT is kept at its default (8) whatever the
TextureFetchConcurrency debug setting value, meaning the viewer never
opens more than 8 simultaneous connections per HTTP server.

I therefore think that, as it is used right now TextureFetchConcurrency
is not really useful (there's already a hard-coded limit of 40 in
lltexturefetch.cpp for the max number of simultaenously queued texture
fetching requests: perhaps this number should be affected by
TextureFetchConcurrency instead ?), and in fact, the CP_CONNECTION_LIMIT
will need to be much greater than 8 or 12, once the new HTTP core is used
for connecting to other servers than just texture servers (mesh,
capabilities, etc).
On the other hand, I agree that CP_PER_HOST_CONNECTION_LIMIT should be
kept below a reasonnable maximum value (8 sounds good for pipelining
requests, but non-pipelining ones could probably allow up to 32 which
is the default for per-host connections in most HTTP servers).

> I'm interested in having available a control
> more refined than HTTP Textures on/off for people who have chronic
> connectivity problems.  My hope is that knocking back concurrency will
> prevent certain routers from falling over.  But other consumers, like
> mesh fetch, may completely swamp any improvement that control might
> offer.

Unless the router is buggy, it shouldn't be impacted by the number of
open sockets (at least not under 60K sockets)... Some protocols, such
as torrent can use hundreds or even thousands of sockets at once.

The true limit is server side.

> > My backports allows from 8 to 32 simultaneous connections, with 12 as
> > the default (i.e. same default as in viewer-http).
> 
> You're running 50% hotter than I am.  Stop eating all the sockets!  :-)

In fact no, because I didn't touch CP_PER_HOST_CONNECTION_LIMIT... ;-P

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Tue, 23 Oct 2012 11:05:38 -0700, Dahlia Trimble wrote:

> Would this excerpt from RFC2616 (section 8.2) be relevent?  Perhaps some
> routers and other infrastructure assume this as design criteria:
> 
> "  Clients that use persistent connections SHOULD limit the number of
>simultaneous connections that they maintain to a given server. A
>single-user client SHOULD NOT maintain more than 2 connections with
>any server or proxy. A proxy SHOULD use up to 2*N connections to
>another server or proxy, where N is the number of simultaneously
>active users. These guidelines are intended to improve HTTP response
>times and avoid congestion. "

This is true for web servers, but in fact current browsers don't use
persistent connections excepted in very specific cases (streaming media,
for example).
When your browser fetches the HTML page and associated images from a web
server, it uses non-persistent connections, and the default number of
simultaneous such connections per client is well above 2 (8 to 16, most
of the time, and 32 is not unheard of).

The problem here is that texture servers are *not* web servers, even if
they use HTTP. If LL is going to migrate to HTTP servers and viewer
using persistent connections, then 2 per viewer will definitely not be
enough (what happens when one connection stalls, for example ?... all
the queued texture requests in it then get delayed by 30 or 60 seconds
(i.e. the timeout for failed/stalled connections)... No good).
If the texture servers mainly accept persistent connections (there will
still be some legacy viewers using non-persistent ones during the
transition period), then they can restrict the number of non-persistent
conection per viewer to increase the number of persistent ones.

In any case, the server can always be configured to refuse new
connections from any given client once the maximum the admin chose for
his server is reached (i.e. you can configure your HTTP server to
accept, say, 8 non-persistent connections and 8 persistent ones per
client (=viewer)).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New HTTP Library & Project Viewer

[Henri Beauchamp]

On Tue, 23 Oct 2012 10:28:37 -0400, Monty Brandenberg wrote:

> Here's a chart I keep forwarding:
> http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn
> Not officially endorsed by Linden, etc., but a useful measure of
> one metric that is likely to predict problems.  At the bottom of
> that chart you'll find members of router families that are both
> very common and very often a source of problems in SL.

Very interesting chart... And quite frigthening too, seeing all the
so-called "routers" that can't even handle 1K connections !

This said, such routers would also stall on torrent downloads.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-540: Math updates by Moon Metty. Reviewed by Chieron Tenk.

[Henri Beauchamp]

On Wed, 24 Oct 2012 07:22:27 -, MartinRJ Fayray wrote:

> This addresses bug BUG-540.
> https://jira.secondlife.com/browse/BUG-540
> .../...
> Testing
> ---
> 
> Please go to https://jira.secondlife.com/browse/BUG-540

"Permission Violation"

Gotta love the crippled JIRA... :-(

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Linux boost shared libraries

[Henri Beauchamp]

On Sun, 9 Dec 2012 18:32:18 -0800 (PST), Nicky Perian wrote:

> What is the reason for the switch to boost shared libraries?
> 
> The other platforms seem to perform without issue using boost static 
> libraries. 

Apart from adding 20Mb of shared libraries (boost regexp) to the viewer
package ?... There's strictly no good reason !

I vote for getting back to static libraries (the few regex functions that
get statically linked only take a few kilobytes in the viewer binary, when
the boost regex shared lib is enormous and 99% of it is usless to the
viewer !)

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Linux boost shared libraries

[Henri Beauchamp]

On Mon, 10 Dec 2012 16:25:37 -0800 (PST), Nicky Perian wrote:

> At the sldev meeting earlier it was stated that unicode processing with boost
> regex was problematic unless a shared boost lib was included. Here:
> http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/unicode.html
> it appears that the static lib compiled/linked with ICU is unicode aware.

Yes, it is if the boost library was built on a system with ICU installed. Here 
is
the relevant info for how to build boost::regex with Unicode support:

http://www.boost.org/doc/libs/1_52_0/libs/regex/doc/html/boost_regex/install.html#boost_regex.install.building_with_unicode_and_icu_support

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Linux boost shared libraries

[Henri Beauchamp]

On Tue, 11 Dec 2012 13:02:51 -0500, Monty Brandenberg wrote:

> filed:  https://jira.secondlife.com/browse/BUG-1056

"Permission Violation"

The JIRA became useless to developers and users alike...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Upcoming server side avatar baking

[Henri Beauchamp]

On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote:

> For any of you developing viewers that are not in the TPV Directory and 
> so didn't get the notice there
> 
> We have now made available the code for our upcoming server side baking 
> changes - you will need to update to be compatible with this in order 
> for users to see avatars correctly once the server side change is rolled 
> out to the main grid (some time > 8 weeks from now, but no date has been 
> set yet).
> 
> See 
> https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance 
> for information on this new code, and watch it for updates.

Alas, the said repository doesn't match any of viewer-release, viewer-beta
or viewer-development code, making it impossible to get a clean diff of
the actual, related, relevant changes.

The diff I get against any of the three public branches of the viewer is
over 2Mb big and contains changes to the UI, the path finding tools, the
renderer (llrender and pipeline), the vfs, and many more cruft that seems
(but it's hard to be 100% sure for everything without carefully studying
the code) totally unrelated with the server side baking changes.

Could you please provide a repository which is the copy of the one that
was used to implement server side baking changes but that would be clean
of those changes (this way, we could create a clean diff containing only
the relevant changes, which would help immensely and prevent long trial
and error sessions figuring out what is needed or not) ?

I also deeply regret that you took the hard-coded approach (making the
baking code rely on a hard-coded inventory tree) and used the COF
directory to pick up the texture IDs to use in the bake (this should
have been provided as a list by the viewer, so that the inventory
structure is only dependent on the UI of the said viewer and on how
the users wish to arrange their own inventory). One of the flaws of
your approach is that your baking system can't detect when a change
is done to a wearable that is being worn (you admit it yourself in
the Wiki page, indicating yet another capability will be needed to
signal such a case)... A poor implementation choice, IMHO.

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Upcoming server side avatar baking

[Henri Beauchamp]

On Mon, 17 Dec 2012 05:35:06 -0800 (PST), Nicky Perian wrote:

> Henri
> I was able to merge and build and verify kokua on aditi; the top 2 commits 
> are post merge tweaks. I don't know if that can help diff wise but, feel free 
> to use.
> The last upstream merge to kokua was viewer-release, last Monday's merge.
> Nicky
> https://bitbucket.org/NickyP/kokua-sunshine-external/overview

I'm afraid it doesn't help. What I need to avoid wasting my little
free time in this period of the year, is a clean diff with only the
*relevant*, *minimal* changes in it.

The fact you could merge the sunshine branch with another v3-based
viewer doesn't help (you simply merged stuff that is still not
validated/adopted/committed to the viewer-development and viewer-beta
banches together the (soon) mandatory server side baking code).

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Upcoming server side avatar baking

[Henri Beauchamp]

On Mon, 17 Dec 2012 09:18:04 -0800 (PST), Nicky Perian wrote:

> I fail to see how anyone's time (LL devs included) is more or less valuable 
> during the upcoming holidays.
> 
> You can work this through to diff using hg by:
> 
> clone the sunshine repo.
> find the point of first sunshine commit.
> update to it
> give it a sunshine bookmark or branch. doesn't matter which
> update to tip and do a dummy commit (may not be needed)
> clone viewer-development
> pull the sunshine branch into v-d do not update or merge the branch
> hg graft the beginning to end sunshine branch change sets
> resolve the merges as you go
> once done the sunshine branch will be re-based to the front of v-d
> change the phase of all the cs, if not allready, to draft
> import all to mq
> un-apply all but first
> fold all the un-applied to the first 
> export a patch/diff.
>  
> this is more or less the procedure i have used to cherry pick.

Excepted that:
1.- the initial sunchine repo (from which the server baking branch was
forked: sunshine-internal ?) is not public;
2.- the first changes happened months ago and now that sunshine-external
was merged with viewer-develompent, it becomes impossible to
distinguish what commit was applied to what branch (repos are a
mess ! I always hated them !);
3.- I don't have the time to browse some 850+ pages of commits to see
when and which commit is relevant to the new code or not (it would
be simpler and faster for me to clean up by hand the diff between
viewer-develompent and sunshine-external) !

It would be MUCH simpler for LL to just clone the original repo (*they*
know when the repo was branched and what was the first commit to it),
merge the viewer-development commits into it (the same commits they
merged in the sunshine-external repo) and make the clone public.
I would then just download the sources for that clone and diff it with
sunshine-external: done !  All changes at hand in a single diff, and
all relevant to the actual task at hand.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] OpenSource reciprocal help (was: Re: Upcoming server side avatar baking)

[Henri Beauchamp]

On Mon, 17 Dec 2012 16:18:59 -0500, Oz Linden (Scott Lawrence) wrote:

> On 2012-12-17 03:43 , Henri Beauchamp wrote:
> > On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote:
> >
> > .../...
> > Could you please provide a repository which is the copy of the one that
> > was used to implement server side baking changes but that would be clean
> > of those changes (this way, we could create a clean diff containing only
> > the relevant changes, which would help immensely and prevent long trial
> > and error sessions figuring out what is needed or not) ?
> 
> No, we can't, sorry.

Did you ever say "yes" and actually provide any kind of useful help
to an OpenSource developer ?... I'm yet to find a case in which that
happened...

You, know, the time I spend sorting out LL's mess, I don't spend it
providing you with bugfixes (even if, because of the stupid CA stuff,
I must find convoluted ways to contribute, such as the private emails
I already sent to you to point out and explain nasty bugs in your
code).

FYI, there are currently two nasty bugs in the renderer code that I
was investigating:
- one bug deals with the new idleUpdate() code that was recently
  introduced in LL's v3 viewers and that I so far put on hold in my
  viewer because it causes bad issues (disappearing objects out of
  the FOV) when the camera mode is set to CAMERA_MODE_CUSTOMIZE_AVATAR
  (it seems that v3 viewers don't use this mode any more, even if the
  code is still there, but that's plain silly because the preview
  thumbnails (dynamic textures) in the wearable editor are then
  showing your avatar from the back or in random posistions instead
  of having it facing the camera).
- another, even more serious bug, deals with scripted, punctually
  moving objects (sliding and rotating doors, for example), which
  position fails to be updated in the renderer when they are off
  the camera FOV; click on an auto-closing door to open it, then
  turn away from it so that it's no more in the FOV and wait till
  it closes automatically, then turn around again to face it:
  surprise, it appears as still open (but it's not: you'd bump
  into it and right-clicking on the spot where it should be makes
  it render again) !
  Note that this bug is *not* related with the idleUpdate() issue
  (it also affects my viewer which doesn't include the new
  idleUpdate() buggy code).

Well, because of your "no", I will put the investigations on these
issues on hold and instead waste my time with guess work as to what
changes are actually related with the new server baking code or not
in the 2Mb diff I got...

Great achievement !...

> .../...
> If you have questions about how the code works, and especially the new 
> messages exchanged regarding avatar appearance, ask them here and we'll 
> do what we can to help.

I'm smart enough to figure out by myself how those messages work,
thank you !  I didn't ask you to explain me how your code works, but
*just* to provide me (and all TPV developers alike) with the *actual*,
*relevant* changes from the *current* viewer-development branch.

So, thank you for *nothing* !... >:-(

(A rather pissed off and fed up) Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] OpenSource reciprocal help (was: Re: Upcoming server side avatar baking)

[Henri Beauchamp]

On Tue, 18 Dec 2012 05:53:02 +0100, Latif Khalifa wrote:

> On Mon, Dec 17, 2012 at 10:18 PM, Oz Linden (Scott Lawrence)
> 
> People who don't fancy themselves to be the infallible gods of system
> design often find it beneficial to hear the feedback, especially in
> opensource projects. It might even lead to (gasp) more reliable system
> and better customer satisfaction.

In fact, it was not just feedback: there has been a "feedforward"
from me, months ago (see the quoted emails below, exchanged with Oz
back in July).

> Whenever I relapse into using my time to help improve Linden Lab's
> products by doing testing, filing bug reports and repro cases, Oz
> Linden's attitude quickly convinces me that it's not worth it.
> 
> (This email started as my feedback about some timing issue with
> network messages that could potentially cause bake fails, but then I
> saw all-knowing Oz dismiss any need for it)

I'd rather not judge "Oz, the man" because it is hard to tell whether
his actions are the only result of his own decisions and doings, or
are the materialization of LL's policy towards OpenSource and, if we
can judge from the resulting actions their policy would clearly be:
"take benefit of all the advantages OpenSource can bring to us (i.e.
free coding and debugging horsepower provided by volunteering
developers), and dismiss all the duties OpenSource cooperation
involves in return (such as providing clean diffs for changed we
made behind closed doors(*) before releasing them, but also providing
an *open* list of known bugs to developers)".

As far as I am concerned, while I am very sorry for the poor
implementation choice (and while I saw it coming and tried my best
to offer a smarter and yet easy alternative), I can live with it (in
35+ years of programming I've seen so many poor implementation
choices that I long lost the count and learned to make with them).

No, what bothers me most (and what I *can* and *do* judge) is that LL
(or Oz, or both), do(es)n't seem to (want to) understand what
OpenSource entails (as benefits, rights, but also *duties* !)...

Henri.

(*) This is one of the worst problems with LL's viewer development:
they modify stuff for months behind closed doors instead of doing
it in the open... That's *NOT* the OpenSource way of doing
things !!!

And here is the "feedforward" stuff:
---
Date: Tue, 17 Jul 2012 00:12:26 +0200
From: Henri Beauchamp 
To: "Oz Linden (Scott Lawrence)" 
Subject: Upcoming changes to the baking system and "current outfit" folder

Greetings,

Although I'm not invited to the TPV meetings (not that it would change
many things anyway, since those are performed on voice and I won't
understand half of what is said as a result), I was made aware that
you (LL) are planing to *impose* the use of the "current outfit" folder
to implement the future baking system...

I personally got many grudges against this "current outfit" folder
and the way the v2/3 viewers auto-create and auto-delete assets (be
them links for the COF or, for example, auto-re-creating calling
cards to mirror the friends list on login):

- It is totally useless from the user's point of view (especially
  with viewers that provide a proper "Worn Items" tab, with full
  folder/items list of worn items, like Snowglobe did) and it
  therefore clobbers the inventory for nothing.

- It is incompatible with OpenSim grids which don't support
  inventory links.

- It can cause inventory losses in case of asset server and/or sim
  server issues; typical case: either the asset server got issues or
  you just logged in/entered in a new RC channel sim, and you change
  your outfit: the viewer messes up with the COF, deleting and creating
  assets in it and bang ! your inventory gets corrupted (this is in
  no way an hypothetical issue: it happened to me once while testing
  viewer 3 on a RC channel on the main grid, to see if inventory
  updates were also failing with LL's viewer on this particular RC
  (which was indeed the case), and I lost my whole #RLV folder, a
  folder that the "support" team was unable (unwilling ?) to recover
  (they apparently have no backup or refuse to use them !!!).
  When things go wrong with asset and/or sim servers, users are told
  not to mess up with their inventory, but with viewer 2/3, the simple
  fact of changing an outfit *does* cause automatic items creations/
  deletions (and most users will be unaware of that)... This is BAD !

Because of the above issues, the Cool VL Viewer doesn't make use of
the current outfit folder (you may even delete that folder altogether
to keep your inventory lean and clean). Instead, it uses an XML/LLSD
file in the per-account settings directory (meaning there is one such

Re: [opensource-dev] Fw: Upcoming server side avatar baking

[Henri Beauchamp]

On Thu, 20 Dec 2012 00:03:03 -0800 (PST), Nicky Perian wrote:

> I decided to put some walk with my rather cheap talk.
> Here is a repackaged server side avatar baking repository.
> https://bitbucket.org/NickyP/viewer-development-sunshine-diff/overview

I'm afraid it didn't work... The diff I get with viewer-development
is still 2Mb big and includes many irrelevant changes such as UI code
refactoring, path finding tools changes, etc, etc, etc...

No need to waste your time any more, anyway, since I wasted mine
yesterday to clean up the 2Mb diff (which is now only 1.4Mb big,
i.e. 40% of the changes in sunshine-external are unrelated to the
new server-side baking code !).

If anyone wants this cleaned-up diff, let me know and I'll send it to
you.

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] gcc 4.7.1: lotsa warnings about boost

[Henri Beauchamp]

On Sun, 06 Jan 2013 11:56:31 +0100, Lance Corrimal wrote:

> Hi,
> 
> Whenever I'm building the current development source on openSUSE 12.2 (read: 
> with gcc 4.7.1) I get lots of warnings about boost-related things. Some of 
> them I've been able to correct myself, others I'm stumped... the causes seem 
> to be in 3p-boost itself, and i'd rather build with exactly the same libs as 
> the lab...
> 
> here's one of many examples:
> 
> http://paste.opensuse.org/77018665  (it's way too long and unreadable for 
> email)
> 
> any ideas / tips / hints for me? google results seem to suggest something or 
> the other about namespaces...

There is currently a horrible mix of boost libraries versions used to
build Linden's pre-built libraries (leading to many linking conflicts
and errors), not to mention that LL inexplicably migrated (from boost
v1.48 onwards) to shared boost libraries linking for the Linux viewer
builds, resulting in an enormous 20Mb boost regex shared lib to be
included into the Linux viewer package (while only 100Kb or so of this
library's functions are actually used by the viewer: that's INSANE !)...

My advice is therefore to stick with either boost v1.45 (for Linux
and Windows) or v1.48 (for MacOS-X) pre-built libraries, that will
link properly with the rest of LL's pre-built libraries for now.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] gcc 4.7.1: lotsa warnings about boost

[Henri Beauchamp]

On Sun, 6 Jan 2013 14:49:04 -0800, Tank Master wrote:

> Unfortunately, you can't use boost 1.45 ll provides because it lacks
> thread.

True, but I recompiled boost from 3p-boost v1.45. You can use the
pre-compiled libraries I'm using for the Cool VL Viewer, if you wish:
Linux:
http://sldev.free.fr/libraries/12650/boost-1.45.0-linux-20110310c.tar.bz2
(MD5: 5b4a0725053fe5076a12d591fd454ef5)

Windows:
http://sldev.free.fr/libraries/12650/boost-1.45.0-windows-20110310c.tar.bz2
(MD5: 1cad14c6c29fbc6588117bad831fa4b0)

For Darwin, I'm currently using LL's v1.48:
http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/3p-boost/rev/261457/arch/Darwin/installer/boost-1.48.0-darwin-20120710.tar.bz2
(MD5: 36aa500e13cdde61607b6e93065206ec)

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Upcoming server side avatar baking

[Henri Beauchamp]

On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote:

> For any of you developing viewers that are not in the TPV Directory and 
> so didn't get the notice there
> 
> We have now made available the code for our upcoming server side baking 
> changes - you will need to update to be compatible with this in order 
> for users to see avatars correctly once the server side change is rolled 
> out to the main grid (some time > 8 weeks from now, but no date has been 
> set yet).
> 
> See 
> https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance 
> for information on this new code, and watch it for updates.

The Linux viewer available for download from Sunshine's Wiki page has
alas been compiled with a way too new glibc end refuse to run on my
system (Mandriva 2010.2, glibc v2.11.1), aborting with:
bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6:
version `GLIBCXX_3.4.15' not found
(required by bin/do-not-directly-run-secondlife-bin)

Could we please get a viewer compiled on the same build system as the one
used for LL's other viewers ?

Thank you.

Henri.

PS: I'm currently testing a server-side baking compatible Cool VL Viewer
and trying to figure out a COF version missmatch issue (which ressembles
this one: https://jira.secondlife.com/browse/SUN-3) that could be due
to the inventory issues on Aditi: without a known, working viewer to
compare with, it's hard to figure out if it's a bug in my backport or
a bug in Aditi's inventory server...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Out of FOV rotating child prims update bug (was: Re: OpenSource reciprocal help)

[Henri Beauchamp]

On Tue, 18 Dec 2012 10:32:15 +0100, Henri Beauchamp wrote:

> On Mon, 17 Dec 2012 16:18:59 -0500, Oz Linden (Scott Lawrence) wrote:
> 
> > No, we can't, sorry.
> 
> Did you ever say "yes" and actually provide any kind of useful help
> to an OpenSource developer ?... I'm yet to find a case in which that
> happened...
> 
> You, know, the time I spend sorting out LL's mess, I don't spend it
> providing you with bugfixes (even if, because of the stupid CA stuff,
> I must find convoluted ways to contribute, such as the private emails
> I already sent to you to point out and explain nasty bugs in your
> code).
> 
> FYI, there are currently two nasty bugs in the renderer code that I
> was investigating:
> .../...
> - another, even more serious bug, deals with scripted, punctually
>   moving objects (sliding and rotating doors, for example), which
>   position fails to be updated in the renderer when they are off
>   the camera FOV; click on an auto-closing door to open it, then
>   turn away from it so that it's no more in the FOV and wait till
>   it closes automatically, then turn around again to face it:
>   surprise, it appears as still open (but it's not: you'd bump
>   into it and right-clicking on the spot where it should be makes
>   it render again) !

For what it is worth, I identified the bug that was preventing
step-rotating (llSetRot()) child primitives to be properly updated
while out of the FOV (the similar, sliding doors, issue was solved
in a recent patch that made its way to viewer-development lately).

The problem is in lldrawable.cpp, around line 562. You need to change:

else if (!isRoot() &&
 (!mVObjp->getAngularVelocity().isExactlyZero() ||
  dist_squared > 0.f))

for:

else if (!isRoot() && (target_rot != old_rot || dist_squared > 0.f))

This is because prims rotating with llSetRot() don't have a velocity.

Henri.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Upcoming server side avatar baking

[Henri Beauchamp]

On Wed, 9 Jan 2013 17:26:51 +0100, Henri Beauchamp wrote:

> The Linux viewer available for download from Sunshine's Wiki page has
> alas been compiled with a way too new glibc end refuse to run on my
> system (Mandriva 2010.2, glibc v2.11.1), aborting with:
> bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6:
> version `GLIBCXX_3.4.15' not found
> (required by bin/do-not-directly-run-secondlife-bin)
> 
> Could we please get a viewer compiled on the same build system as the one
> used for LL's other viewers ?
> 
> Thank you.
> 
> Henri.
> 
> PS: I'm currently testing a server-side baking compatible Cool VL Viewer
> and trying to figure out a COF version missmatch issue (which ressembles
> this one: https://jira.secondlife.com/browse/SUN-3) that could be due
> to the inventory issues on Aditi: without a known, working viewer to
> compare with, it's hard to figure out if it's a bug in my backport or
> a bug in Aditi's inventory server...

Nevermind (though, having a propely built Linux Sunshine-viewer would
still be a good thing), I figured out the bug (race condition between
links creation in COF and rebake requests).

The of the Cool VL Viewer v1.26.7.5  (experimental branch) has been
released today with server-side baking support.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Upcoming server side avatar baking

[Henri Beauchamp]

On Sat, 12 Jan 2013 02:56:53 +0100, Latif Khalifa wrote:

> On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp  wrote:
> > Nevermind (though, having a propely built Linux Sunshine-viewer would
> > still be a good thing), I figured out the bug (race condition between
> > links creation in COF and rebake requests).
> 
> How do you work around that? When I was implementing this in Radegast
> it seemed that the service would respond to link creation request and
> it would still sometimes fail with COF mismatch as if the baking
> service didn't get the message.

Well, my COF implementation is entirely different from LL's... For
example, it only uses 3 functions and one callback to sync the COF
(and that's because I also implemented *optional* attachments links
syncing; without the optional part, i.e. with systematic attachments
syncing, it'd take only 2 functions and one callback) and entirely
avoids LL's (ridiculously) convoluted code; so it's hard to describe
in a message...

But to avoid the race conditions, I also modified the
requestServerAppearanceUpdate() function and its callback
(RequestAgentUpdateAppearanceResponder) so that only one such callback
is active at any time (i.e. if other rebake requests are done before
the last rebake is completed (or failed), the requests are "queued"
(or more exactly, a mNeedsServerSideRebake flag is set and tested for
to fire a new rebake on completion of the ongoing one).
I also use a timer (gUpdateCOFTimer) that is reset each time a new
link is created and tested for before requestServerAppearanceUpdate()
is called (the latter being called in one place only, based on the
mNeedsServerSideRebake flag and on the timer value).

You'd better have a look at my code (at the end of llappearance.cpp)
for full understanding of how things work; note that I since found a
bug in it: in requestServerAppearanceUpdate(), the test for
RequestAgentUpdateAppearanceResponder::isActive() should be moved
inside the "if (!responder_ptr.get())" block. The bug only affects
rebakes when a request fails and is retried within the
RequestAgentUpdateAppearanceResponder callback (which didn't seem to
happen so far on Aditi, given the very low load on the server-side
rebaker).

Note that there seem to be a server-side race condition as well:
sometimes, the rebake request succeeds (with matching COF versions)
and the viewer does recieve the UUIDs for the baked textures, but
when it attempts to fetch the corresponding textures too soon
(with 150+ FPS in the testing sims, the delay between the request
acknowlegment and the texture fetch that happens at next frame can
indeed be very short) the texture fetch fails with a 404 error: if
you retrieve it later from a browser using the failed cap, you
however do get the corresponding texture, meaning that the rebaker
replied "ok" to the request before the texture could be made
available by the texture server...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Henri Beauchamp]

On Fri, 15 Feb 2013 09:54:16 -, MartinRJ Fayray wrote:

I have a similar fix for weeks in the Cool VL Viewer, but it is alas
not as simple as that...

There's a problem with resizing chid primitives (they don't resize
on screen, even when visible).
There's a problem with rotating and moving child primitives when
they are out of FOV, but fixing it by checking for target rot and
position changes like you did also breaks *some* vehicles (when you
or another avatar sits on such vehicles, some chil primitives
pertaining to this vehicle "stay behind" when the vehicle moves).

So, far, I came up with a proper fix for resizing child primitives
and an experimental fix for moving/rotating out of FOV child
primitives (I'm testing for flagUsePhysics() and not applying the
fix when the flag is TRUE, which should exclude vehicles cild prims).
By lack of vehicles to test the latter (I don't use vehicles in SL
and the couple I got in my inventory are not affected by this bug),
I cannot guarantee that it is "final".

Here is the code I use, for people interested in experiencing:

// Returns "distance" between target destination and resulting xfrom
F32 LLDrawable::updateXform(BOOL undamped)
{
BOOL damped = !undamped;

// Position
LLVector3 old_pos(mXform.getPosition());
LLVector3 target_pos;
if (mXform.isRoot())
{
// get root position in your agent's region
target_pos = mVObjp->getPositionAgent();
}
else
{
// parent-relative position
target_pos = mVObjp->getPosition();
}

// Rotation
LLQuaternion old_rot(mXform.getRotation());
LLQuaternion target_rot = mVObjp->getRotation();
bool no_target_omega = mVObjp->getAngularVelocity().isExactlyZero();

// Scaling
LLVector3 target_scale = mVObjp->getScale();
LLVector3 old_scale = mCurrentScale;
LLVector3 dest_scale = target_scale;

// Damping
F32 dist_squared = 0.f;
F32 camdist2 = mDistanceWRTCamera * mDistanceWRTCamera;

if (damped && isVisible())
{
F32 lerp_amt = 
llclamp(LLCriticalDamp::getInterpolant(OBJECT_DAMPING_TIME_CONSTANT),

  0.f, 1.f);
LLVector3 new_pos = lerp(old_pos, target_pos, lerp_amt);
dist_squared = dist_vec_squared(new_pos, target_pos);

LLQuaternion new_rot = nlerp(lerp_amt, old_rot, target_rot);
dist_squared += (1.f - dot(new_rot, target_rot)) * 10.f;

LLVector3 new_scale = lerp(old_scale, target_scale, lerp_amt);
dist_squared += dist_vec_squared(new_scale, target_scale);

if (dist_squared >= MIN_INTERPOLATE_DISTANCE_SQUARED * camdist2 
&&
dist_squared <= MAX_INTERPOLATE_DISTANCE_SQUARED)
{
// interpolate
target_pos = new_pos;
target_rot = new_rot;
target_scale = new_scale;
}
else if (no_target_omega)
{
// snap to final position (only if no target omega is 
applied)
dist_squared = 0.0f;
if (getVOVolume() && !isRoot())
{   // child prim snapping to some position, needs 
a rebuild
gPipeline.markRebuild(this, 
LLDrawable::REBUILD_POSITION,
  TRUE);
}
}
}

if (old_scale != target_scale)
{   // scale change requires immediate rebuild
mCurrentScale = target_scale;
if (!isRoot() && !isState(LLDrawable::ANIMATED_CHILD))
{
setState(LLDrawable::ANIMATED_CHILD);
mVObjp->dirtySpatialGroup();
}
gPipeline.markRebuild(this, LLDrawable::REBUILD_POSITION, TRUE);
}
else if (!isRoot() && !mVObjp->getRootEdit()->flagUsePhysics() &&
 (dist_squared > 0.f || old_pos != target_pos ||
  target_rot != old_rot || !no_target_omega))
{
// child prim moving relative to parent, tag as needing to be 
rendered
// atomically and rebuild
dist_squared = 1.f; // keep this object on the move list
if (!isState(LLDrawable::ANIMATED_CHILD))
{
setState(LLDrawable::ANIMATED_CHILD);
gPipeline.markRebuild(this, LLDrawable::REBUILD_ALL, 
TRUE);
mVObjp->dirtySpatialGroup();
}
}
else if (!getVO

Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Henri Beauchamp]

On Sat, 16 Feb 2013 19:44:51 -, MartinRJ Fayray wrote:

> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/616/
>
> Review request for Viewer.

Yes, it seems to work more or less OK. It however still fails to animate
visible small resizing primitives (I saw this first on scripted nipples:
the nipples failed to "stiffen" on screen while the prim actually
resized and only a change in LOD (zoom-out followed with zoom-in) would
update the prim size on screen).

To reproduce that bug, create two prims, link them, and in the root prim
put this script:

integer Expanded = FALSE;

default {
touch_start(integer n) {
vector scale = llList2Vector(llGetLinkPrimitiveParams(2, [ PRIM_SIZE 
]), 0);
Expanded = !Expanded;
if (Expanded) {
scale.x = 2.0 * scale.y;
} else {
scale.x = scale.y;
}
llSetLinkPrimitiveParamsFast(2, [ PRIM_SIZE, scale ]);
}
}

Then wear the resulting object and resize it down to a very small size.
Zoom on it and see how the child prim fails to resize when touching the
object.

To cure that bug you need to replace:

LLVector3 vec = mCurrentScale-target_scale;
if (vec*vec > MIN_INTERPOLATE_DISTANCE_SQUARED)

(which makes no sense whatsoever: only damping interpolations need to
be checked against MIN_INTERPOLATE_DISTANCE_SQUARED), with:
if (old_scale != target_scale)


Also, it makes no sense to use
dist_vec_squared(old_pos, target_pos) > 0.f ||
(1.f - dot(old_rot, target_rot)) * 10.f > 0.f
in the test you added to fix the out of FOV moving/rotating child
prims bug. You simply need to test for changed position and rotation
since you don't change the dist_squared variable in that case (this
will also avoid having very slow, or very slightly rotating out of
FOV prims to fail to update).

Attached to this email is the diff I propose to add to your patch.

Regards,

Henri.


diff.txt
Description: Binary data
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Henri Beauchamp]

 close the sources of the patched viewer !
The viewer code is LGPL, meaning that any viewer with a compatible
license (such as GPL viewers like mine) *can* include any part of
its code. That's the exact purpose of OPEN SOURCE code, mind you !

> By publishing changes to my fix on the LL mailinglist, this will also
> mean that I cannot use those changes for the LL viewer, and that
> seems very counterproductive for me.

Again, there is nothing that I published there but a trivial bugfix
that is NOT copyrightable. I would also add that whole chunks of LL's
viewer have been taken/adapted from other Open Source authors
(especially in llmath: you'll even see the mention for such code
borrowing in the comments), authors who NEVER signed a CA with LL
and are probably not even aware that their code is used in LL's
viewer: again that CA stuff is pure hypocrisy invented by a sick
lawyer at LL.

Henri Beauchamp.
Open Source contributor, for 6 years (and still counting) in SL and
its viewer.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Henri Beauchamp]

On Sun, 17 Feb 2013 10:59:47 +0100, Martin Fürholz wrote:

> Hello,
> me and others cannot reproduce your 'nipple bug', neither with your 'cool 
> nipples' from the marketplace, nor with the test setup you've given in your 
> earlier mail.

You can deny all you want, but I do know what I am seeing on my screen...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Henri Beauchamp]

On Sun, 17 Feb 2013 13:27:22 +0100, Henri Beauchamp wrote:

> On Sun, 17 Feb 2013 10:59:47 +0100, Martin Fürholz wrote:
> 
> > Hello,
> > me and others cannot reproduce your 'nipple bug', neither with your 'cool 
> > nipples' from the marketplace, nor with the test setup you've given in your 
> > earlier mail.
> 
> You can deny all you want, but I do know what I am seeing on my screen...
> 
> Henri.

And as a final proof: http://sldev.free.fr/misc/ResizeBugProof.ogv
(note: it's an OGV video: VLC can read it, if your standard player can't).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-840: Viewer 3.4.2 (Beta) breaks almost every sliding door script in SL

[Henri Beauchamp]

On Sun, 17 Feb 2013 16:08:37 +0100, Martin Fürholz wrote:

> Hello Henri,
> thank you for your video.
> 
> I was able to 'kind-of' reproduce it partially in LL Viewer 3.4.5 (270263). 
> The prim doesn't visually resize to it's full size, it's 10% smaller than it 
> should be until I zoom out and back it.

In fact, something could well influence this bug: the frame rate...
The higher the frame rate, and the most likely the buggy test will
fail in updateXform() (since the prim is smoothly resized server-side
and viewer-side, at high frame rate, the scale difference between the
current and the past frame will be (worngly) considered neglectable
because of that buggy test)...
Since I've got frame rates in the 100+ (up to 200 FPS with the Cool VL
Viewer in that skybox where I made the video), I'm probably more
impacted than someone with 20 FPS...

> I will try to fix that and update the repository. Tyvm.

Thanks.

> I cannot find a Jira issue for that bug, could you please file one?

Sorry, I stopped using the JIRA for reporting viewer bugs (I keep
using it for server bugs, since there's no other channel to do it
for them) after LL closed it, making it impossible for anyone else
than the JIRA issue creator and Lindens to read the reports...

I don't have time to loose, and I lost enough time and energy on
this issue already (especially for something so trivial !).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates

[Henri Beauchamp]

On Mon, 18 Feb 2013 03:02:40 -, MartinRJ Fayray wrote:

> I fixed that by comparing the original scale versus the new target
> scale (instead of comparing the original scale versus the new
> interpolated target scale), in lldrawable.cpp "updateXform" to decide
> whether a scale change requires an immediate rebuild or not.

Yes, the child primitive is properly resized in this case, BUT, it
snaps to its new size instead of resizing smoothly (which basically
means that the server side smooth resizing is done for nothing at
all !...). It's not very pretty and I'm pretty sure some makers and
vendors of scripted items (especially the ones with apparent
"mechanics" in their products) will not like it...

Granted:
LLVector3 vec = mCurrentScale - dest_scale;
if (vec * vec > MIN_INTERPOLATE_DISTANCE_SQUARED)

causes less stress than:
if (old_scale != target_scale)

But it's pretty rethorical and theorical since I'm still to see
a sim where thousands of child prims would resize simultaneously
to have high enough an impact on the frame rate in the second
case...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates

[Henri Beauchamp]

On Mon, 18 Feb 2013 10:44:21 +0100, Henri Beauchamp wrote:

> On Mon, 18 Feb 2013 03:02:40 -, MartinRJ Fayray wrote:
> 
> > I fixed that by comparing the original scale versus the new target
> > scale (instead of comparing the original scale versus the new
> > interpolated target scale), in lldrawable.cpp "updateXform" to decide
> > whether a scale change requires an immediate rebuild or not.
> 
> Yes, the child primitive is properly resized in this case, BUT, it
> snaps to its new size instead of resizing smoothly (which basically
> means that the server side smooth resizing is done for nothing at
> all !...). It's not very pretty and I'm pretty sure some makers and
> vendors of scripted items (especially the ones with apparent
> "mechanics" in their products) will not like it...
> 
> Granted:
> LLVector3 vec = mCurrentScale - dest_scale;
> if (vec * vec > MIN_INTERPOLATE_DISTANCE_SQUARED)
> 
> causes less stress than:
> if (old_scale != target_scale)
> 
> But it's pretty rethorical and theorical since I'm still to see
> a sim where thousands of child prims would resize simultaneously
> to have high enough an impact on the frame rate in the second
> case...

Addendum:

I guess you could do the stepped resizing for non-visible prims (you
could even increase the steps size) and do smooth resizing for visible
(in FOV) prims...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Server Side Avatar Appearance pile-on test

[Henri Beauchamp]

On Wed, 20 Feb 2013 15:54:42 -0500, Nyx Linden wrote:

> Please use our latest viewer as it has additional statistics gathering
> code that will allow us to calculate load patterns and measure the
> improvements expected for later releases.
> 
> Let me know if there are any questions!

Greetings,

Today, I'm having troubles on Aditi SunshineTest resgions: the
server-side baking seems broken. Whether I use LL's latest Sunshine
viewer(*) v3.4.5.270409 or the Cool VL Viewer v1.26.7, which both
used to work just fine before, I get "bad requests (400)" errors,
like so:

WARNING: RequestAgentUpdateAppearanceResponder::errorWithContent:
 appearance update request failed, status: 400 reason: Bad
 Request
DEBUG: RequestAgentUpdateAppearanceResponder::errorWithContent:
   content: 


INFO: RequestAgentUpdateAppearanceResponder::onFailure: retrying
(SecondLife v3.4.5.270409 for Windows)

or:
WARNING: RequestAgentUpdateAppearanceResponder::error: Appearance
 update request failed, status: 400 reason: Bad Request
INFO: RequestAgentUpdateAppearanceResponder::error: Retrying...
(Cool VL Viewer v1.26.7.11, either Linux or Windows builds)

Was something changed that is not yet propagated to the
sunshine-external sources repository (the last commit in it dates
back from 8 days ago) ?... If the answer is "yes", then please commit
the necessary changes today...

Regards,

Henri.

(*) The Linux build is still impossible to run for me because it
requires GLIBCXX_3.4.15: "bin/do-not-directly-run-secondlife-bin:
/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found
(required by bin/do-not-directly-run-secondlife-bin)"
when my system got libstdc++.so.5.0.7 (g++ v3.3.6) and
libstdc++.so.6.0.13 (g++ v4.4.3). Why don't you build the Sunshine
viewer on the same build system as for the other viewer branches
(which all run fine on my system) ?...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Server Side Avatar Appearance pile-on test

[Henri Beauchamp]

On Fri, 22 Feb 2013 11:00:19 -0500, Nyx Linden wrote:

> We saw similar errors for some users at the pile-on yesterday, it
> appears to be account-specific (some people can reproduce others cannot).

FYI and for what it is worth, while I managed to make SSB work with one
of my alts, after half a dozen of outfit changes with that avatar, I
again got "bad requests (400)" errors...

> There are a few commits that have not been pushed to sunshine-external
> yet,but nothing that should affect the behavior so fundamentally. We're
> going to be looking into this issue today, I'll send another email if
> we think we have a fix.

Thanks.

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Serious regression in SSB-enabled regions

[Henri Beauchamp]

Greetings,

I described a *serious*, *major* regression issue that I discovered
yesterday while reviewing (again) the SSB code and confirmed today
with tests on Aditi SunshineTest regions.

Please see: https://jira.secondlife.com/browse/SUN-38

For me (and I would guess, for most advanced SL users since we use the
avatar offset dozens of times over *each* SL session), this is even a
show stopper issue as far as SSB is concerned.

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Serious regression in SSB-enabled regions

[Henri Beauchamp]

On Sun, 24 Feb 2013 10:36:12 -0800, Darien Caldwell wrote:

> Yes,  this was brought up to Nyx and Oz at Oz's last User Group meeting,
> by inusaito.kanya

I alas can't participate in meetings held on voice... I regret the time
when Soft Linden was in charge of OpenSource and did care about
non-English speaking developers, holding his meetings in chat for
everyone to be able to communicate on an equal ground...

> They were supposed to file a bug under Sunshine, but probably good to
> have someone else do it as well, in case they didn't.

I searched for an equivalent issue before creating SUN-38, but found
none.

> I'm unable to comment on SUN issues (or even make them)

Gotta love the new closed JIRA !... Way to go, LL...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] DirectX SDK update: should we use it ?

[Henri Beauchamp]

Greetings,

Today, Windows Update proposed me this update:
http://support.microsoft.com/kb/2670838

I was well inspired to follow the "Find out more about this update"
link, because in the explanation page, they state:

"If you are a Windows 7 DirectX developer who uses the June 2010 DirectX
Software Development Kit (SDK), you will have to update your development
environments after you install this platform update."

And the June 2010 DirectX SDK is precisely used by the viewer...

Not being a Windows guru, I don't know whether applying the proposed
update and updating to the Windows 8 SDK (which is listed among the
possible solutions) is a good idea or not: will it break the viewer
builds ?... If not, will the viewer builds still work under Windows XP,
Vista and 7 ?... Couldn't we simply get entirely rid of the DirectX
calls in the Windows viewer builds ?

Any thought about this ?

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] DirectX SDK update: should we use it ?

[Henri Beauchamp]

On Fri, 1 Mar 2013 08:54:00 -0800, Darien Caldwell wrote:

> This is being offered to all Windows 7 Users, not just developers. Reading
> deeper here:
> 
> http://msdn.microsoft.com/library/windows/apps/jj863687.aspx
> 
> It's mostly backporting new features from Windows 8 to Windows 7. That's
> why they say you'll need the newer SDK, to take advantage of those new
> features.

So can we safely apply this update and keep using the June 2010 DirectX
SDK to build the viewer, and still get working builds on "all" (WinXP SP3
and newer) Windows versions ?... I doubt it, since they say:

"If you are a Windows 7 DirectX developer who uses the June 2010 DirectX
Software Development Kit (SDK), you will have to update your development
environments after you install this platform update. The following
development .dll files that are associated with the DirectX SDK are
incompatible with this platform update:

D3D10SDKLayers.dll
D3D11SDKLayers.dll
D3D10ref.dll
D2D1debug.dll

You can use one of the following applications or tools to update these
.dll files:

-  The Windows 8 SDK: This SDK updates the current development
   environment with new headers, libs, and tools. This includes the
   previously-listed development .dll files. This update does not
   update the C or C++ compilers or the IDE, but this update does
   enable developers to integrate the new features of the platform
   update into their applications.
"

So, this solution implies that we also update the "Windows SDK for
Windows 7 and .NET Framework 4" that is used to build the viewer with
VS2010, with the "Windows 8 SDK": won't it break the viewer builds ?...
Does it at all got a single chance to keep working with the VC++ 2010
compiler ?

Second propsed solution:

"
-  Microsoft Visual Studio 2012: This application includes the
   Windows 8 SDK, the Visual Studio 2012 IDE, and the new compilers.
   .../...
"

Here, I bet the viewer won't compile under VS2012, and I heard that
anything compiled with compilers newer than VS2010 is incompatible
with Windows XP...

Third propose solution:

"
- Remote Tools for Visual Studio 2012: These tools are the minimum
  requirement in order to continue using the Direct3D debug layer.
  These tools update only the previously-listed development .dll files.
  These tools do not enable developers to integrate the new features of
  the platform update into their applications. These tools are available
  in the "Remote Tools for Visual Studio 2012" section of the Visual
  Studio Download Center, or can be downloaded from the following
  links. These packages can be safely installed on development systems:
"

Is it the right thing to do ?... I don't know. Any clue ?

> Basically it's all centered around  D3D11, which I really doubt LL's
> viewer is using. .../... Of course I'm not exactly sure what parts
> of D3D the viewer is using, I was always under the impression it used
> OpenGL.

OpenGL is used for the rendering. D3D is only used for the graphics
card detection at startup... So if someone could find a way to use
another detection mechanism, we could get fully rid of the D3D calls
in the viewer code.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Serious regression in SSB-enabled regions

[Henri Beauchamp]

On Fri, 1 Mar 2013 16:20:10 -0500, Nyx Linden wrote:

> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806
> 
> Added a new parameter to shapes to replace the viewer-side height offset.
> Since it is stored in a wearable, the new back end can read and use the
> value. Will send an email to third party devs later today to let them know
> to pick up the patch.

ARRRG !

Adding a new parameter to the shape is NOT a suitable way to achieve
equivalent results as what we could get so far in non-SSB sims: each
time a new (sit, lay, kneel, crouch, crawl...) animation is played,
you need to adjust the Z-offset: this can't obviously be achieved by
each time changing a shape parameter, saving the new shape, and then
asking for a (full !) rebake: the Z-offset (and more exactly the avatar
height as requested by the viewer depending on the currently worn shape
and the Z-offset) needs to be accounted for in real time (like what
LLAgent::sendAgentSetAppearance() allowed to do), indenpendently of the
other visual parameters; the shape wearable itself should be left
untouched when the height is adjusted via the Z offset.

> Marking SUN-38 as resolved.

Nope, I'm sorry, but it's far from resolved 

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Serious regression in SSB-enabled regions

[Henri Beauchamp]

On Sun, 3 Mar 2013 13:43:26 +0100, Satomi Ahn wrote:

> Hello,
> 
> Since I cannot comment on SUN issues, may I make a suggestion here?
> 
> If adding new parameters to existing stuff belongs to allowed actions
> to resolve this issue, then couldn't we consider adding new parameters
> to poses/animations, so that they can exactly know how to adjust in
> order for the avatar not to sink into or float over ground?
> The 3 parameters of current RLV command @adjustheight more or less
> achieve this result. These parameters need to be adjusted on a
> per-animation basis and do not depend on the avatar shape (this was
> not possible with a single Z-offset parameter, because the needed
> absolute offset depends on each avatar hip/height ratio... but I am
> sure that Henri Beauchamp can explain this better).

It would be a good idea if it would not result in breaking all
existing content...

> I believe that what I propose would be the best solution for newly
> created poses. For already existing ones, since the animation system
> allows "layering" several animations, then this would become a
> possibility to create poses just for adjusting the Z-offset of
> existing ones.

No, this is a VERY BAD idea: "layering" animations most often
doesn't work as expected, because of their priority and how pretty
much all anims have been uploaded with the maximum priority, not to
mention the problem with having to create (and upload) one "correction"
anim for each existing animation (and the number of possible
(reference_height, scalar) couples is almost infinite !).

> Of course, it would be even better if the viewer was also still able
> to send bounding box update messages to the sim, as existing height
> adjustment systems would continue to work.

It won't be "better", for any "advanced user" (read: anyone caring
about not having their avatar floating above or sinking into the
ground when playing anims, or wanting to be able to adjust themselves
the pose on poseballs not providing scripted sit target adjustement)
it is a MANDATORY feature that MUST be implemented in SSB sims to
match what we have been doing for years in non-SSB ones (@adjustheight
is relatively new, but the Avatar-Z offset manual adjustment has
been around for years).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Serious regression in SSB-enabled regions

[Henri Beauchamp]

On Thu, 07 Mar 2013 15:53:03 +0100, Thomas Shikami wrote:

> Is there even a requirement zo have Z-offset be in the avatar
> appearance message?

The Z-offset is not transmitted to the server by the viewers
implementing it: what is transmitted is the sum of the Z-offset (which
can also be negative) and the avatar height as calculated from the
shoes and shape visual parameters. This causes the server to think
that the avatar is either taller or smaller while its shape and shoes
didn't change, but which also causes the animations to be played at a
higher or lower level above the floor (the server can auto-correct
properly standing animations for any worn shape or shoes, but of
course this auto-correction algorithm fails for sitting, kneeling,
laying, crouching, crawling anims since in those the feet to hip
length doesn't count for the same fraction as in standing anims).

In short, the viewer transmits to the server what it computed to be
the proper "avatar height" for the animation to be correctly leveled
with the floor; the server then adopts this new height, applies its
own auto-correction (the one that was designed for standing anims)
and relays the info to all viewers, making the avatar appear at the
proper level for everyone around.

> To me it looks more like that hip-offset would be better suited 
> to be in some animation parameter, which makes it incompatible with 
> older viewers, but a SSB-enabled simulator might translate that 
> animation parameter into an avatar appearance message for viewers not 
> supporting that idea of animation parameter.

I already replied to this suggestion to Satomi Ahn in this list,
explaining why it won't work properly and won't allow to perform the
equivalent operations as what non-SSB servers have been allowing since
day one of SL (and OpenSim).

Ideally, yes, the animations should have allowed to enter the "reference
height" (the height of the avatar for which the anim is properly leveled
with the floor) and "scalar" (the scalar to apply to the difference
between the reference height and the current height of the avatar playing
the anim so to find the Z-offset to add to this latter height so to allow
a proper leveling with the floor).

However, all existing anims would still fail to play properly if LL was
to add these parameters now without supporting the Z-offset feature.

This is not the solution we need, even if adding such parameters to the
anims could be a future improvement (but you will always need Z-offet
support for all the existing anims, as well as for correcting manually
the sit target of pose-balls/furniture not having a scripted anim height
adjustment).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future

[Henri Beauchamp]

On Thu, 14 Mar 2013 20:13:19 -0400, Monty Brandenberg wrote:

> We now have three channels and a number of regions available for testing:
> 
> .../...
>   o TextureTest2.  High texture count, no meshes, low residency
> limit to prevent interference when doing benchmark testing.
> .../...
>   o TextureTest2H.  Identical to TextureTest.
> .../...
>   o TextureTest2A.  Identical to TextureTest.

"Sorry, you do not have access to this teleport destination"...

Care to open access ?...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] DSG Experiment needs a few more Participants; Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online)

[Henri Beauchamp]

On Thu, 21 Mar 2013 07:03:21 -0700 (PDT), Nicky Perian wrote:

> I am getting security warnings from my browser when going to these
> links. 

Probably an invalid certificate (self-certifed site). Plus, the
URL contains an IP (107.7.21.233) instead of a domain name, and there
is no reverse-DNS entry for this IP ('nslookup 107.7.21.233' returns:
** server can't find 233.21.7.107.in-addr.arpa.: NXDOMAIN).

If I were you, I would simply not try to follow such a link...

I am also quite surprised by these emails we get in this list: I don't
see any interest in them (I don't even see what they are supposed to
deal with: in what aspect are they at all related to viewers
development ?).

They also got huge attachments (pictures), which makes them a pain to
retrieve when your connection is slow.

Not sure what is the list moderator's stance on this...

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Outdated master message template

[Henri Beauchamp]

Greetings.

While compiling the viewer, I get:

-
Verifying message template
master: 
http://bitbucket.org/lindenlab/master-message-template/raw/tip/message_template.msg
current: /usr/src/linden/scripts/messages/message_template.msg
--- PASS ---
Newer
in message ObjectFlagUpdate: has 1 extra blocks
in message AvatarAppearance: has 1 extra blocks
in message SimStats: has 1 extra blocks
in message GodUpdateRegionInfo: has 1 extra blocks
in message RegionHandshake: has 1 extra blocks
in message RegionInfo: has 1 extra blocks
-

The ObjectFlagUpdate change dates back from the new Physics parameters
(introduced at the same time as meshes), and I already signaled it back
then, see:
http://lists.secondlife.com/pipermail/opensource-dev/2012-April/008902.html

The other messages have been introduced with SSB support, mainly...

Anyone left, at LL, to update this simple file ?...

Thanks in advance,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Not all Open Source developers are honest...

[Henri Beauchamp]

I'm pissed off !

Here's why: http://sldev.free.fr/forum/viewtopic.php?f=5&t=1230

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Not all Open Source developers are honest...

[Henri Beauchamp]

On Sat, 1 Jun 2013 18:40:16 +0200, Martin Fürholz wrote:

> Hi Henri,
> I'm curious:
> why are you posting a link to this mailinglist about a 4+ year old incident?

It is 15 days old, not 4 years old...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Not all Open Source developers are honest...

[Henri Beauchamp]

On Sat, 1 Jun 2013 18:57:31 +0200, Martin Fürholz wrote:

> Ah! I misread the “joined” date on that forum page as the “posted” date, 
> this happens all the time :D
> I’m sorry, last time that I’ve heard anything about Kirstenlee’s viewer was 
> a couple of years ago, and S19 is also a couple of years old, as far as I 
> can tell (and I’m pretty sure about that). See 
> http://virtyou.com/viewer_track/ as a proof (Kirstenlee’s viewer “S20” was 
> built in 2010).

S20 is a v2 viewer, so it's obviously a different branch.
It is quite possible that Kirsten used the Cool VL Viewer sources and the
incremental patches I publish with every release to follow my progresses on
it, but it's obviously the very same viewer with just a couple of patches
added (a 600Kb diff is NOTHING, especially when you see what the changes
are about in this diff... a i++ instead of a ++i is not significant a
change !).

In fact, I don't care if Kirsten forks my viewer, what I care about is that
he obviously pretends being the person behind the 3000+ hours of coding *I*
spent on this code over the 6+ years of continuous development !

If anyone got more to say about this matter, please let's move it to the
Cool VL Viewer forum: I don't want to polute this list more than I already
did (but I thought it was important to bring up such an issue).

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Viewer branches and their repositories

[Henri Beauchamp]

Greetings,

I'm a bit confused with LL's new release process: many beta and project
viewers are available for download as binaries on the Wiki (see:
https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers )
but there is no corresponding repositories in the mercurial (see:
http://hg.secondlife.com/ ): in particular, I see no repository for
the Beta and Beta Maintenance (with the new particles code) channels.

Also, some new features announced in the release notes of the RC channels
for the latest releases (for example, the new UpdateAgentAppearance
capability for SSB regions, appearaing in RC Magnum v13.07.15.278606
release notes) are not even yet available in the corresponding viewer
repository (for UpdateAgentAppearance, it should be in sunshine-external).

I am also noticing errors and contradictions between the available code
sources and the server release notes (e.g. RC Magnum v13.07.15.278606
release notes advertize "Added IncrementCofVersion capability" but this
capability is actually not enabled in the sims running this server
release, and when I asked Nyx last Monday, at the Content User Group
meeting, he replied this capability was abandonned: who is right ?...).

Could someone at LL please enlighten us about what's going on exactly
and why all those discrepancies ?...

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Viewer branches and their repositories

[Henri Beauchamp]

On Wed, 17 Jul 2013 15:52:37 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2013-07-17 13:38 , Henri Beauchamp wrote:
> > Greetings,
> >
> > I'm a bit confused with LL's new release process: many beta and project
> > viewers are available for download as binaries on the Wiki (see:
> > https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers )
> > but there is no corresponding repositories in the mercurial (see:
> > http://hg.secondlife.com/ ): in particular, I see no repository for
> > the Beta and Beta Maintenance (with the new particles code) channels.
> 
> See 
> https://wiki.secondlife.com/wiki/Linden_Lab_Official:Viewer_Source_Repositories

Ah, yes, thank you... What about putting a link to that page on the
https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers
page ?...

> > Also, some new features announced in the release notes of the RC channels
> > for the latest releases (for example, the new UpdateAgentAppearance
> > capability for SSB regions, appearaing in RC Magnum v13.07.15.278606
> > release notes) are not even yet available in the corresponding viewer
> > repository (for UpdateAgentAppearance, it should be in sunshine-external).
> >
> > I am also noticing errors and contradictions between the available code
> > sources and the server release notes (e.g. RC Magnum v13.07.15.278606
> > release notes advertize "Added IncrementCofVersion capability" but this
> > capability is actually not enabled in the sims running this server
> > release, and when I asked Nyx last Monday, at the Content User Group
> > meeting, he replied this capability was abandonned: who is right ?...).
> >
> 
> The Sunshine project isn't ready with their next round of viewer 
> changes... they'll appear in those repos when they are closer to being 
> integrated, and there will be test versions available for the viewer at 
> around the same time.

*Grumbles something about Lindens being slow ;-P*
Alright, but about the IncrementCofVersion capability: is it abandoned
or not (i.e. should I remove the corresponding code from my viewer) ?

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Viewer branches and their repositories

[Henri Beauchamp]

On Mon, 22 Jul 2013 13:52:57 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2013-07-18 05:20 , Henri Beauchamp wrote:
> >> >See
> >> >https://wiki.secondlife.com/wiki/Linden_Lab_Official:Viewer_Source_Repositories
> > Ah, yes, thank you... What about putting a link to that page on the
> > https://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers
> > page ?...
> >
> The alternate viewers page is for people who want to download and run 
> viewers, not develop them, so I don't think it's appropriate.
> 
> I did add a link from the primary wiki page on getting viewer source: 
> https://wiki.secondlife.com/wiki/Get_source_and_compile

I also added a link in:
https://wiki.secondlife.com/wiki/Viewer_Integration_and_Release_Processes#Mercurial_Repositories

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] ThrottleBandwidthKBPS - kilobit per second or kiloBYTE per second?

[Henri Beauchamp]

On Fri, 26 Jul 2013 11:04:25 +0200, Lance Corrimal wrote:

> Hi all,
> 
> 
> I'm not quite clear about the ThrottleBandwidthKBPS debug setting... the 
> sources suggest the value is understood as kilobit per second, but the name 
> of 
> the debug setting itself suggests kiloBYTE per second. Which one is it?

They indeed are kilo *bits* per second.

> ...and is it even still relevant with most traffic being tcp/http now instead 
> of udp?

This setting is indeed only relevant to UDP traffic, or at least in LL's
and most TPV viewers. IIRC, I saw attempts to account for this limit
with HTTP texture fetching traffic in Singularity, but that would need
to be checked for certainty.

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Viewer branches and their repositories

[Henri Beauchamp]

On Fri, 26 Jul 2013 13:45:26 -0400, Log Linden wrote:

> Henri,
> 
> For the increment capability, the name is "IncrementCOFVersion" instead of
> "IncrementCofVersion". I transcribed it wrong when I handed the release
> notes off to Maestro.
> 
> Sorry for the confusion,
> Log

Ah... Yes, much better !... And just in time for tomorrow's Cool VL Viewer
releases !  Thanks !

What about UpdateAgentAppearance however ?...
There's still no trace of code using it in sunshine-external
(https://bitbucket.org/lindenlab/sunshine-external).

Regards,

Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges