Re: [opensource-dev] how to read minidumps

[Thickbrick Sleaford]

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.

See 
http://code.google.com/p/google-
breakpad/wiki/LinuxStarterGuide#Processing_the_minidump_to_produce_a_stack_trace


-- 
Thickbrick
___
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: Change pre-login viewer display URL to prepare for new community information display

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/399/#review883
---



indra/newview/app_settings/settings.xml


Setting the default value to something other than an empty string would 
override the selected grid's login page in LLGridManager::getGridInfo and 
LLGridManager::getLoginPage, which is probably not the desired result. In fact, 
I wonder why this setting is persistent at all. This should probably be renamed 
to CmdLineLoginPage, to be consistent with CmdLineLoginURI etc.


- Thickbrick


On July 16, 2011, 6:12 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/399/
> ---
> 
> (Updated July 16, 2011, 6:12 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This changes the URL from which the upper part of the viewer window is loaded 
> prior to login.
> 
> At the moment, the new URL is internally redirected to the same content as 
> before, but shortly it will have new community and activity information on 
> what's going on in Second Life.
> 
> 
> This addresses bug storm-1510.
> http://jira.secondlife.com/browse/storm-1510
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml c6f2f4af65e5 
>   indra/newview/llviewernetwork.cpp c6f2f4af65e5 
>   indra/newview/tests/llviewernetwork_test.cpp c6f2f4af65e5 
> 
> Diff: http://codereview.secondlife.com/r/399/diff
> 
> 
> Testing
> ---
> 
> Confirmed using the log file that the new URL is being requested.
> Changed the settings file locally to point to an internal prototype of the 
> new screen and confirmed that it is displayed correctly.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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] Is it just me? Avatar textures downloading last.

[Thickbrick Sleaford]

On Saturday 18 June 2011 20:00:04 Lee ponzu wrote:
> However, and unrelated to shadows, I began to notice last night that while
> my scenes had all downloaded, the avatars around me were still all gray.
>  Their objects were OK, it was just their skin and cloth final bake that is
> missing.  They do show up after several minutes, but long after everything
> else.
> 

I've noticed avatar bakes taking very long to un-gray too, when trying the SL 
v2 viewer recently after not using it for a long-ish while. This is especially 
noticeable in crowded areas.

Looking at the texture console, it looks like any fetch that is using udp 
(i.e. bakes, since they can not be fetched via http) is always at the bottom 
of the list, and usually gets bumped out quickly. I haven't tested this, but I 
get the feeling that the udp fetches are starved out of processing by the 
regular http fetches. If I stay a while in a gray people gathering, and then 
relog, the once-gray people have at least one discard level of their bakes 
quickly decoded, probably from cache. This makes me think that this is a 
prioritization issue, possibly caused by the quick turn-around of http 
textures.

-- 
Thickbrick
___
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: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/
---

(Updated June 13, 2011, 2:39 p.m.)


Review request for Viewer.


Changes
---

- Fixed typo in comment ("intermediary").
- Changed file-scope constants to static const.
- At Oz's suggestion (in email), delays are now exponential. Oz suggested 
leaving this to hammer the server indefinitely, but I feel more comfortable 
with a limit of 7 attempts. The first attempt is immediate, and 6 retries are 
done with delays: 2s, 4s, ... 64s. The delays sum up to 126 seconds.


Summary
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


This addresses bug VWR-24889.
http://jira.secondlife.com/browse/VWR-24889


Diffs (updated)
-

  indra/newview/llassetuploadresponders.h df4801993ea4 
  indra/newview/llassetuploadresponders.cpp df4801993ea4 
  indra/newview/lltexlayer.h df4801993ea4 
  indra/newview/lltexlayer.cpp df4801993ea4 

Diff: http://codereview.secondlife.com/r/152/diff


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

Thickbrick

___
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: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

> On June 13, 2011, 8:20 a.m., Oz Linden wrote:
> > indra/newview/lltexlayer.cpp, line 518
> > <http://codereview.secondlife.com/r/152/diff/4/?file=1013#file1013line518>
> >
> > what's with the minus one here?

mUploadFailCount counts failures, while BAKE_UPLOAD_ATTEMPTS is the number of 
attempts. When doUpload() is called for the last attempt, mUploadFailCount 
equals BAKE_UPLOAD_ATTEMPTS - 1, since the last failure hasn't occurred yet. 
This tries to do the last upload via the old asset store (UDP), just in case 
the HTTP capability isn't working. Does this still makes sense, or will the 
asset store not be supported soon anyway?


> On June 13, 2011, 8:20 a.m., Oz Linden wrote:
> > indra/newview/lltexlayer.h, line 369
> > <http://codereview.secondlife.com/r/152/diff/4/?file=1012#file1012line369>
> >
> > This would be more clear as an enum: when looking at a call to this 
> > method, a value 'true' or 'false' is much less informative that 
> > 'isHighestRes' or 'isLowRes'

I'm not sure that an enum would make this clearer. This is never called with 
hard-coded values, and the value for the only call to this c'tor is taken from 
the result (BOOL) of mTexLayerSet::isLocalTextureDataFinal. Converting the BOOL 
to an enum, just to check later for equality to one of the enum values seems 
redundant to me.


- Thickbrick


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/#review740
---


On March 1, 2011, 8:58 a.m., Thickbrick Sleaford wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/152/
> ---
> 
> (Updated March 1, 2011, 8:58 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> When a bake upload fails, the viewer doesn't retry it, and subsequently 
> doesn't send a AgentSetAppearance message. This can happen without the user 
> being aware, leaving the avatar looking good on their screen, but not updated 
> to the same outfit on other people's screens. The avatar will remain in that 
> state until the user does something that causes a rebake (manually rebake or 
> change outfit.) The solution here is to retry the upload after a small delay.
> 
> What this diff changes: when a full-res upload fails, retry to upload it 
> after a 5s delay, up to 5 times (in case the cap is available, last attempt 
> is via the old asset store.) Also, some clearer log messages. This implements 
> an old *FIX: comment:
> // *FIX: retry upload after n seconds, asset server could be busy
> 
> This isn't needed for low res uploads, because they don't block subsequent 
> full-res uploads (mNeedsUpload isn't set to FALSE in 
> LLTexLayerSetBuffer::doUpload in low-res uploads.)
> 
> 
> This addresses bug VWR-24889.
> http://jira.secondlife.com/browse/VWR-24889
> 
> 
> Diffs
> -
> 
>   indra/newview/llassetuploadresponders.h 767feb16f05f 
>   indra/newview/llassetuploadresponders.cpp 767feb16f05f 
>   indra/newview/lltexlayer.h 767feb16f05f 
>   indra/newview/lltexlayer.cpp 767feb16f05f 
> 
> Diff: http://codereview.secondlife.com/r/152/diff
> 
> 
> Testing
> ---
> 
> Attempted outfit changes using a problematic connection (not recently used 
> outfits to avoid using cached bakes). Looked for "Baked full res texture 
> upload for  failed" log messages, observed the subsequent 
> retries and successful upload for that region. Observed that eventually the 
> fully-baked avatar is visible to other users.
> 
> 
> Thanks,
> 
> Thickbrick
> 
>

___
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] A CALL FOR HHHEEELLLPPP

[Thickbrick Sleaford]

That error message is basically saying "you can't assign to a const variable." 
Line 21 in your paste is reusing file_name, which is one of the method's 
arguments, and is const. You need a local variable which isn't const there.

But, I don't think this makes sense otherwise. In what cases will from_id be 
null? I would guess you will have no way to recover a name in those cases. If 
that really happens, I think that's a server bug.

I think a better approach is to look for the places that call this method, and 
make sure it is passed a username and not a "legacy name" or "complete name" 
as its first argument. You can convert a "legacy name" (but not a "complete 
name"!) to a username with the static method LLCacheName::buildUsername(), 
without needing to look it up in the name cache.

I see these occurrences:

llgiveinventory.cpp
314:LLIMModel::instance().logToFile(full_name, 
LLTrans::getString("SECOND_LIFE"), im_session_id, 
LLTrans::getString("inventory_item_offered-im"));

llimview.cpp
859:if (log2file) logToFile(session_id, from_name, from_id, utf8_text);
2471:   LLIMModel::instance().logToFile(session_name, 
SYSTEM_FROM, LLUUID::null, message.getString());

llnotificationhandlerutil.cpp
278:LLIMModel::instance().logToFile(session_name, from, from_id, 
message);


/* rant, please ignore... */
Considering the level of scrutiny trivial patches get here, how did the 
display names code got merged into the viewer in the first place? It made 
already messy code much more messy and inconsistent. Name-handling methods now 
rely on the caller knowing which of the different 4-5 kinds a "name" argument 
is expected to be (username, legacy (2 kinds of that?), complete, or display). 
"Display" and legacy names should have been banished to the lest steps of the 
chain, leaving them for display only, and everything else should have been 
converted to usernames, or preferably, a new type (not std::string.) Looks 
like there was some attempt to do that with LLAvatarName, but logic that 
depends on knowledge of internals of this class is all over the place.


On Wednesday 16 March 2011 03:30:02 WolfPup Lowenhar wrote:
> First References:
> 
> Jira : https://jira.secondlife.com/browse/STORM-941
> 
> 
> 
> Code Snippet : http://codepad.org/9cVTMJTD
> 
> 
> 
> Now the problem:
> 
> When I compile the code I get error C2678: binary '=' : no operator found
> which takes a left-hand operand of type 'const std::string' (or there is no
> acceptable conversion) in reference to line 21of the code snippet. I need
> to be able to force the user name in this case.
> 
> 
> 
> Here is how this case can happen:
> 
> PersonA dose not use Display Names or is on a non-Display Names viewer.
> 
> PersonB dose use Display Names and also keeps logs of all chat, Group and
> P2P messages.
> 
> 
> 
> PersonA offers PersonB and inventory item after PersonA has talked to
> PersonB in P2P conversation. PersonB checks their logs later to read about
> item again to discover there are now two logs for the same person one log
> is using the Legacy name and contains only the system message about the
> inventory offer while the other log that is named using the user name
> contains the conversation about that item.

-- 
Thickbrick
___
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-1038: crash in texture cache pruning

[Thickbrick Sleaford]

On Thursday 03 March 2011 22:12:54 Oz Linden wrote:
> http://jira.secondlife.com/browse/storm-1038
...
> Diff: http://codereview.secondlife.com/r/172/diff

Isn't this the same bug as the one patched by Aleric in VWR-24337? (I haven't 
followed the logic through, but it seems to trigger the same assert.)

See:
https://jira.secondlife.com/browse/VWR-24337
https://codereview.secondlife.com/r/93/

-- 
Thickbrick
___
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: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/
---

(Updated March 1, 2011, 8:58 a.m.)


Review request for Viewer.


Changes
---

More comment spelling.


Summary
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


This addresses bug VWR-24889.
http://jira.secondlife.com/browse/VWR-24889


Diffs (updated)
-

  indra/newview/llassetuploadresponders.h 767feb16f05f 
  indra/newview/llassetuploadresponders.cpp 767feb16f05f 
  indra/newview/lltexlayer.h 767feb16f05f 
  indra/newview/lltexlayer.cpp 767feb16f05f 

Diff: http://codereview.secondlife.com/r/152/diff


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

Thickbrick

___
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: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/
---

(Updated March 1, 2011, 8:28 a.m.)


Review request for Viewer.


Changes
---

New diff, fixes the typo in the comment pointed out by Merov.


Summary
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


This addresses bug VWR-24889.
http://jira.secondlife.com/browse/VWR-24889


Diffs (updated)
-

  indra/newview/llassetuploadresponders.h 767feb16f05f 
  indra/newview/llassetuploadresponders.cpp 767feb16f05f 
  indra/newview/lltexlayer.h 767feb16f05f 
  indra/newview/lltexlayer.cpp 767feb16f05f 

Diff: http://codereview.secondlife.com/r/152/diff


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

Thickbrick

___
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] Is 'STANDALONE' confusing?

[Thickbrick Sleaford]

On Monday 21 February 2011 16:38:01 Boroondas Gupte wrote:
> On 02/21/2011 03:28 PM, Oz Linden (Scott Lawrence) wrote:
> > If we are going to change it, the replacement term should, in addition
> > to being more accurately descriptive of what it does, be an affirmative
> > term - don't suggest any 'NO_*" replacements.
> 
> Would it be acceptable to invert the setting's semantic in order to
> avoid a negation? I.e., STANDALONE=OFF would become NEW_SETTING=ON and
> vice versa. That'd allow for easy-to-understand names like
> USE_PREBUILD_LIBS or DOWNLOAD_NEEDED_DEPENDENCIES.
> 
> Off course, the default value should be inverted together with the
> setting's semantic, such that the default behavior does not change.
> 

I agree with Boroondas. I think it *should* be changed, and my vote goes to 
USE_PREBUILT_LIBS (which should default to on.)


-- 
Thickbrick
___
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: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

> On Feb. 17, 2011, 1:59 p.m., Boroondas Gupte wrote:
> >

Both comments are addressed in the new diff.


- Thickbrick


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/#review375
---


On Feb. 19, 2011, 9:08 a.m., Thickbrick Sleaford wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/152/
> ---
> 
> (Updated Feb. 19, 2011, 9:08 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> When a bake upload fails, the viewer doesn't retry it, and subsequently 
> doesn't send a AgentSetAppearance message. This can happen without the user 
> being aware, leaving the avatar looking good on their screen, but not updated 
> to the same outfit on other people's screens. The avatar will remain in that 
> state until the user does something that causes a rebake (manually rebake or 
> change outfit.) The solution here is to retry the upload after a small delay.
> 
> What this diff changes: when a full-res upload fails, retry to upload it 
> after a 5s delay, up to 5 times (in case the cap is available, last attempt 
> is via the old asset store.) Also, some clearer log messages. This implements 
> an old *FIX: comment:
> // *FIX: retry upload after n seconds, asset server could be busy
> 
> This isn't needed for low res uploads, because they don't block subsequent 
> full-res uploads (mNeedsUpload isn't set to FALSE in 
> LLTexLayerSetBuffer::doUpload in low-res uploads.)
> 
> 
> This addresses bug VWR-24889.
> http://jira.secondlife.com/browse/VWR-24889
> 
> 
> Diffs
> -
> 
>   indra/newview/llassetuploadresponders.h 379da6bd50a5 
>   indra/newview/llassetuploadresponders.cpp 379da6bd50a5 
>   indra/newview/lltexlayer.h 379da6bd50a5 
>   indra/newview/lltexlayer.cpp 379da6bd50a5 
> 
> Diff: http://codereview.secondlife.com/r/152/diff
> 
> 
> Testing
> ---
> 
> Attempted outfit changes using a problematic connection (not recently used 
> outfits to avoid using cached bakes). Looked for "Baked full res texture 
> upload for  failed" log messages, observed the subsequent 
> retries and successful upload for that region. Observed that eventually the 
> fully-baked avatar is visible to other users.
> 
> 
> Thanks,
> 
> Thickbrick
> 
>

___
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: VWR-24889: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/
---

(Updated Feb. 19, 2011, 9:08 a.m.)


Review request for Viewer.


Summary (updated)
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


This addresses bug VWR-24889.
http://jira.secondlife.com/browse/VWR-24889


Diffs (updated)
-

  indra/newview/llassetuploadresponders.h 379da6bd50a5 
  indra/newview/llassetuploadresponders.cpp 379da6bd50a5 
  indra/newview/lltexlayer.h 379da6bd50a5 
  indra/newview/lltexlayer.cpp 379da6bd50a5 

Diff: http://codereview.secondlife.com/r/152/diff


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

Thickbrick

___
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] Hacking up to Visual Studio 2010 ...

[Thickbrick Sleaford]

On Friday 18 February 2011 16:55:06 Twisted Laws wrote:
> Thanks  i'm unclear of what i should do next then.   (I primarily work
> in windows)   Can i just delete the files in
> /usr/local/lib/python2.6/dist-packages/autobuild ?
> 

That's what I did (together with /usr/local/bin/autobuild). Maybe there's a 
proper way of removing packages installed with easy_install, but I couldn't 
figure it out...


-- 
Thickbrick
___
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] Hacking up to Visual Studio 2010 ...

[Thickbrick Sleaford]

On Friday 18 February 2011 15:50:11 Twisted Laws wrote:
> When I try running autobuild on Linux (Ubuntu) using this autobuild and
> viewer-autobuild2010, it immediately fails with a pathcheck error looking
> for boto.  Looking at common.py (in
> /usr/local/lib/python2.6/dist-packages/autobuild/common.py) I see that the
> pathcheck lines in there contain "lib/python2.5/...".  So I'm assuming
> that this doesn't work with Python 2.6 ??
> 

I had a similar problem after I installed the autobuild package system-wide 
with the setup.py that came with it (./setup.py build && sudo ./setup.py 
install). It turns out it does not work when installed system wide. As far as 
I could tell, the python version in the pre-packaged files' path don't matter.

Also, it seems prone to leaving bad files /var/tmp/$USER/install.cache/ when 
bailing due to exceptions, and barfing when encountering those files on 
subsequent runs.

-- 
Thickbrick
___
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] Review Request: When a bake texture upload fails, retry instead of giving up.

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/152/
---

Review request for Viewer.


Summary
---

When a bake upload fails, the viewer doesn't retry it, and subsequently doesn't 
send a AgentSetAppearance message. This can happen without the user being 
aware, leaving the avatar looking good on their screen, but not updated to the 
same outfit on other people's screens. The avatar will remain in that state 
until the user does something that causes a rebake (manually rebake or change 
outfit.) The solution here is to retry the upload after a small delay.

What this diff changes: when a full-res upload fails, retry to upload it after 
a 5s delay, up to 5 times (in case the cap is available, last attempt is via 
the old asset store.) Also, some clearer log messages. This implements an old 
*FIX: comment:
// *FIX: retry upload after n seconds, asset server could be busy

This isn't needed for low res uploads, because they don't block subsequent 
full-res uploads (mNeedsUpload isn't set to FALSE in 
LLTexLayerSetBuffer::doUpload in low-res uploads.)


This addresses bug VWR-24889.
http://jira.secondlife.com/browse/VWR-24889


Diffs
-

  indra/newview/llassetuploadresponders.h 379da6bd50a5 
  indra/newview/llassetuploadresponders.cpp 379da6bd50a5 
  indra/newview/lltexlayer.h 379da6bd50a5 
  indra/newview/lltexlayer.cpp 379da6bd50a5 

Diff: http://codereview.secondlife.com/r/152/diff


Testing
---

Attempted outfit changes using a problematic connection (not recently used 
outfits to avoid using cached bakes). Looked for "Baked full res texture upload 
for  failed" log messages, observed the subsequent retries and 
successful upload for that region. Observed that eventually the fully-baked 
avatar is visible to other users.


Thanks,

Thickbrick

___
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] Review Request: VWR-24420: PNG images which specify "background color" lose alpha layer when imported.

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/74/
---

Review request for Viewer.


Summary
---

Current code composites RGBA PNG images that contain a bKGD chunk down to RGB, 
discarding the alpha channel. This patch removes that code, since it 
contradicts purpose of the bKGD chunk as described in the PNG spec and as 
commonly used.


This addresses bug VWR-24420.
http://jira.secondlife.com/browse/VWR-24420


Diffs
-

  doc/contributions.txt UNKNOWN 
  indra/llimage/llpngwrapper.h UNKNOWN 
  indra/llimage/llpngwrapper.cpp UNKNOWN 

Diff: http://codereview.secondlife.com/r/74/diff


Testing
---

Tested uploading the 2 images attached to VWR-24420 with and without the patch. 
Before patch, "bad alpha.png" was uploaded as RGB, after patch, both images 
were uploaded as RGBA.


Thanks,

Thickbrick

___
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: Restructure loops that use breaks without need (reviewboard test)

[Thickbrick Sleaford]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/2/#review13
---



indra/newview/llappviewer.cpp


Somewhat tangential to this patch: this line is wrong. It should use 
gFrameIntervalSeconds, not gFarmeTimeSeconds. As it is, max_idle_time will 
always be clamped to 0.005.

The comment is also wrong/outdated. It should be something like "50 
ms/second, up to 5 ms/frame."


- Thickbrick


On 2010-12-01 19:57:24, Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/2/
> ---
> 
> (Updated 2010-12-01 19:57:24)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This review is mostly a first test of reviewboard.
> 
> I do have an esthetic dislike for the 'break' statement anywhere but as the 
> end of a case, so I chose to change some instances of break usage that were 
> not justified by any extreme need.
> 
> 
> This addresses bug storm-606.
> http://jira.secondlife.com/browse/storm-606
> 
> 
> Diffs
> -
> 
>   indra/newview/llappviewer.cpp bf98b026bcb1 
> 
> Diff: http://codereview.secondlife.com/r/2/diff
> 
> 
> Testing
> ---
> 
> None at all... have not even compiled it yet.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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] Draw Distance

[Thickbrick Sleaford]

On Sunday 22 August 2010 18:22:56 Lance Corrimal wrote:
> related line of thought:
> 
> 
> how much faster could the viewer be if every single of these "do not
> change this ever" settings was replaced with a #define in a central
> include file?
> or in other words, what is the cpu cycle penalty for a
> SavedSettings.getBOOL() and the others?
> 

Please, no #defines...

You can cache the value of a settings and rely on callback magic to change the 
cached var when the setting has changed:

#include "llcontrol.h" (or llviewercontrol.h in 1.x, with a slightly different 
constructor)

static LLCachedControl cached_foo(gSavedSettings, "SettingFoo");

This way you can use cached_foo to get the value of the setting in methods 
that get called often, without doing a lookup in a big std::map.

> 
> bye,
> LC
> 

-- 
Thickbrick
___
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] Closing on SG2.0 : Releasing Snowglobe 2.0.2 (RC2)

[Thickbrick Sleaford]

On Thursday 29 July 2010 19:26:24 Ricky wrote:
> Ok, I don't yet fully understand the properties of the installer
> template Thickbrick added to the Snowglobe wiki page... :/   Could
> someone update it who does?
> 
> (and maybe explain how to help maintain this.  Or a link to somewhere
> that explains it!  I'm used to regular wiki editing, but functions and
> variables in a wiki page are rather unusual...)
> 
> Thanks,
> Ricky
> Cron Stardust
> 

I didn't create those templates, I just made copies of the 1.x ones for 2.x 
installers. I think Rob Linden wrote them originally.

Those templates create the three platform links from the build number, and the 
versions numbers. There's an added complication that the trunk templates use 
another template for localization of the description and for the purpose of 
alternating between "Test build (trunk)" and "Release Candidate." (at least I 
think that's the reason.)

I think that the idea is that the Release template always points to a released 
build (i.e. 1.3.2 currently for 1.x). The trunk template should point to trunk 
most of the time, except for during the RC stages, after a release branch is 
branched, but before it is deemed "released,". During that stage it should 
point to the RC builds.

I updated the 2.x trunk and branch and 1.x trunk templates already. I hope 
Merov doesn't object.

The relevant wiki pages for 2.x are:
* https://wiki.secondlife.com/wiki/Template:Snowglobe_2-installers
(which points to 2.0.2 (RC2). This is against the rule I wrote above, but we 
don't have a "released" 2.x build yet.)
* https://wiki.secondlife.com/wiki/Template:Snowglobe_2-installers-trunk
(which point to 2.1.0)
* https://wiki.secondlife.com/wiki/Template:Snowglobe_2-installers-trunk/en

And for 1.x:
https://wiki.secondlife.com/wiki/Template:Snowglobe-installers
(1.3.2, no change here)
https://wiki.secondlife.com/wiki/Template:Snowglobe-installers-trunk
(1.4.1 RC1, this is now tracking release candidates until we release 1.4)
https://wiki.secondlife.com/wiki/Template:Snowglobe-installers-trunk/en

I hope that clears things up (and didn't include false info...)

I also put a mockup of my suggestion on how to clarify prettify the snowglobe 
download links a bit here:
https://wiki.secondlife.com/wiki/User:Thickbrick_Sleaford/Sandbox

-- 
Thickbrick
___
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] Linux + QtWebKit + Flash 10.1.x = Crash

[Thickbrick Sleaford]

Hello all,

It looks like recent (>10.1) Flash versions can't work with any QtWebKit 
browser including the webkit plugin in Snowglobe 1.x and Viewer 2 on Linux. 
This is because those versions of Flash don't initialize gtk properly (Adobe 
assuming that the browser is gtk based, i.e. Firefox.)

This results in the crash of the SLPlugin process when trying to show the 
login page, or any other web page (though some of the pages sometimes get 
half-rendered).

There is a fix for this in upstream QtWebKit, but this would require 
rebuilding the prebuilt llqtwebkit packages. Until then, Linux users who are 
trying to stay safe have a problem, because Flash 10.0 is not getting security 
updates on Linux anymore, apparently (and the chances of Adobe fixing this are 
close to zero.) So I think we need to solve this as quickly as possible.

Here are the relevant bugs:
http://jira.secondlife.com/browse/SNOW-548
https://bugs.webkit.org/show_bug.cgi?id=40567


This is what Flash spits out on stdout before crashing:
(process:2096): GLib-GObject-CRITICAL **: 
/build/buildd/glib2.0-2.24.0/gobject/gtype.c:2706: You forgot to call 
g_type_init()
(process:2096): GLib-CRITICAL **: g_once_init_leave: assertion 
`initialization_value != 0' failed
(process:2096): GLib-GObject-CRITICAL **: g_object_new: assertion 
`G_TYPE_IS_OBJECT (object_type)' failed

-- 
Thickbrick
___
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] Migrating open development focus to 2.x

[Thickbrick Sleaford]

> On Friday 28 May 2010 00:50:55 Oz Linden (Scott Lawrence) wrote:
> > Please respond to this thread with your favorite reasons not to move 
> > development to 2.x.   We will review the list at the 6 June open source 
> > meeting with the goal of setting some priorities.

Oz, I think open source developers will naturally spend most of their time 
working on the viewer they use most. And there are problems with 2.0 that for 
me are much more insurmountable than just changes to muscle memory:
* Modal UI. Enough was said about this already.
* Most important for me, I just can't read the fonts in 2.0 without straining. 
UI Widgets are too big and fonts are too small, for any UI size setting that 
leaves a bit of 3d-world visible. I guess I am in the minority here (having 
bad eyesight,) but I think this is a big minority group of existing and 
potential SL users that would simply write off 2.0 as unusable.

Yes, there are improvements in 2.0 as well, but I can't enjoy them.


On Friday 28 May 2010 15:45:14 Lance Corrimal wrote:
> ... backport the alpha layer / tattoo layer / inventory links / script
> info  from about land into snowglobe 1.4... 50% of that are already done
> anyways, want a patch?

Yes please!

I wonder, can we flex the rule about contributor agreement for patches  
backporting code that was originally written by linden lab?

-- 
Thickbrick
___
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] HTTP viewer map on non-Agni grids (SNOW-77)

[Thickbrick Sleaford]

Hello all,

I attached a new patch (based on Geyeda Bechir's earlier patch) to SNOW-77. I  
think this answers Eddy Stryker's comments there regarding the Opensim side of 
things with my previous patch.

The question that remains now is what do Lindens (Merov in particular) think 
about this: Is there something in the pipeline that will be incompatible with 
this? It's time we resolved this, as currently Snowglobe and Viewer 2.0 have 
an almost useless map on Aditi, and a completely useless map on Opensim grids.

Patch:
http://jira.secondlife.com/secure/attachment/39646/SNOW-77_map_url_cap.diff

Relevant JIRAs:
http://jira.secondlife.com/browse/SNOW-77
http://jira.secondlife.com/browse/VWR-17711

Quick summary of what that patch does:
Once per region, fetches the LLSD map from the address given by the 
HTTPMapURLRequest capability, and uses the value of the the key "mapurl" as 
the base url for http map tiles. If there's no capability, it uses a debug 
setting which defaults to the SL/Agni map.

Please review and discuss...

-- 
Thickbrick
___
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] no autobuilds for snowglobe 1.x anymore?

[Thickbrick Sleaford]

On Tuesday 25 May 2010 11:39:11 Lance Corrimal wrote:
> Hey,
> 
> is it just me being blind, or are there no automated builds of snowglobe
> 1.x anymore?
> 
> 
> bye,
> LC

The last build was of r3371, and there were no changes to the 1.x tree since 
then:
https://lists.secondlife.com/pipermail/sldev-commits/2010-May/003913.html

It looks like the download links on the wiki template haven't been updated 
yet, though.

-- 
Thickbrick
___
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] Banning by client

[Thickbrick Sleaford]

I don't know if this store is (badly) detecting client versions/channels 
through the media plugins' user agent strings, or if it's just that I didn't 
move enough for their taste after teleporting. I went there with my test alt, 
using Snowglobe 2.0.0 () Apr 22 2010 00:11:09 (CommunityDeveloper) on 
linux, and was banned and ejected after a couple of minutes:

[13:14] Second Life: You have been teleported home by the object 'zF RedZone 
v3.2.3' on the parcel 'Furniture and Prefabs @ The Loft II'.
[13:14] zF RedZone v3.2.3: You have been removed for using copybot.


On Saturday 01 May 2010 22:20:26 Glen Canaday wrote:
> That's me on the list. You go in Snowglobe V2? My partner was also there
> in Emerald and did not get banned - that's why I was asking about
> client-based ban (and hence why I even brought it up on this list, even
> though it's only on topic in a very cursory way).
> 
> --GC
> 

-- 
Thickbrick
___
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] Source of boost libraries

[Thickbrick Sleaford]

The boost packages are not "in" svn, but the urls for the packages are listed 
in install.xml, and they are downloaded and unpacked into the build tree by 
the build system.

You only need to provide your own boost if you are doing a standalone build 
(which I assume you aren't, since you are on windows,) or using a version of 
VS for which there's no prebuilt boost packages (2005 only, I think.)


On Friday 30 April 2010 18:51:19 Jonathan Welch wrote:
> I'm trying to compile Snowglobe 1.4 on Windows XP / VC 2005 Express
> Edition (aka VC80) and was told the boost libraries would be part of
> the svn, but apparently they are not.
> 
> Can some kind soul please point me to where I can pick them up?
> 
> -jonathan
> ___
> 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
> 

-- 
Thickbrick
___
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 viewer map (was: Oh, the drama.)

[Thickbrick Sleaford]

See http://jira.secondlife.com/browse/SNOW-77
This has been stagnant for too long (incidentally, it was brought up at 
yesterday's Snowglobe meeting.)

I think the way forward is standardizing this in a way that allows opensim to 
implement it, not going back to UDP, region-local map tiles.

SNOW-77 has a patch attached that handles using a capability to find the base 
url for the map tiles, but still sticks to assumptions about the url 
structure.

I added a comment there last December, and will repeat it here, that I think 
the grid should not just tell the viewer about the base url, but send a 
template to prevent depending on a rigid url structure. This looks like 
something RUSS can be used for, but that has a dire warning about security 
implications of using an untrusted format string:
http://wiki.secondlife.com/wiki/Recursive_URL_Substitution_Syntax

I don't know if this is a problem here (is it?), but I think we should find 
*some* way to prevent hard-coding the url structure in the viewer.


On Friday 30 April 2010 14:00:43 Tateru Nino wrote:
> The most obvious solution - from where I'm sitting - is to abstract it,
> and provide different access methods underneath. The higher levels of
> the viewer application should neither know nor care just where the map
> tiles are coming from, beyond making an API call to fetch one. Later,
> one can look at a method by which a grid service might make certain
> representations as to where and how those tiles are located and to be
> fetched, but compartmentalizing the hard-wired knowledge (at this stage)
> seems to be the best option, presently.
> 
> On 30/04/2010 8:20 PM, Lance Corrimal wrote:
> > "patching opensim"...
> >
> > ...how do you "patch" the people who provide a service for free, to make
> > them rent an expensive distributed storage provider for their map tiles?
> > are you going to rent S3 yourself, for your own little local grid?

-- 
Thickbrick
___
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] Quiet amendments of TPV (again)

[Thickbrick Sleaford]

On Tuesday 20 April 2010 17:02:26 Joe Linden wrote:
> Boy,
> 
> There was nothing quiet, or "in the background" about it, believe me.  This
> update is the topic of conversation at the noon PDT brown bag I'm hosting
> today.  The changes were pushed live ahead of the meeting, so there would
>  be no question they are incorporated in to the TPV and TOS, both of which
>  are effective on 4/30.
> 
> I'll see those of you still interested in the subject at noon here:
> http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29
> 
> -- joe
> 

This is somewhat belated, but: Thank you Joe!

The TPVp is still not ideal from my perspective, but it is now certainly 
something I think an open source community can work with.

I still wish it would not force viewers to enforce DRM, specifically in cases 
where the user has an appropriate license from the creator that supersedes the 
DRM. But I guess this is pretty much a given when a user chooses to create 
their content in a grid that is very much DRM-centric. Hopefully the DRM will 
be extended soon to include an "export ok" flag, now that the TPVp made it a 
critical thing.

Anyway, thanks for listening!

-- 
Thickbrick
___
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] test on SG2

[Thickbrick Sleaford]

On Tuesday 20 April 2010 20:55:57 Tayra Dagostino wrote:
> is there a way to:
... 
> 2) enable/disable SLPlugin (totally, if audio and multimedia turned off
> one SLPlugin session lunched anyway)
> 

I think that one SLPlugin is the QtWebKit loaded at startup to show the login 
page. I don't know of any way to prevent this, short of deleting the plugins' 
.so files or editing skins/default/xui/en/mime_types_linux.xml to remove all 
the instances of "media_plugin_webkit".

-- 
Thickbrick
___
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] build errors in template classes in svn with alternative set to gcc 4.3

[Thickbrick Sleaford]

On Saturday 24 April 2010 04:03:24 Glen Canaday wrote:
> Still getting svn build errors in Ubuntu 9.10 with my gcc alternative
> set to g++4.3.
> 
> Output:
> 
> [ 4%] Building CXX object llcommon/CMakeFiles/llcommon.dir/llcoros.o
> In file included from
> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boo
> st/coroutine/coroutine.hpp:44, from
> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/llcommon/llcoros.h:39,
> from
> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/llcommon/llcoros.cpp:39:
> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boo
> st/coroutine/detail/coroutine_impl.hpp:59: error: declaration of ‘typedef
>  class
> boost::coroutines::detail::context_base
> boost::coroutines::detail::coroutine_impl ContextImpl>::context_base’
> /home/glen/Programs/SL_BUILD/snowglobe/trunk/indra/../libraries/include/boo
> st/coroutine/detail/context_base.hpp:55: error: changes meaning of
>  ‘context_base’ from ‘class
> boost::coroutines::detail::context_base’
> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/llcoros.o] Error 1
> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
> make: *** [all] Error 2
> g...@glen-desktop:~/Programs/SL_BUILD/snowglobe/trunk/indra/viewer-linux-i6
> 86-relwithdebinfo$
> 

This looks like SNOW-505. There is a small patch for this in JIRA that was 
posted to this list a few weeks ago by Lynx Linden. I think this is only a 
problem in gcc >=4.3, but not sure. We can't commit this to svn, since this is 
in the prepackaged boost library.

http://jira.secondlife.com/browse/SNOW-505

-- 
Thickbrick
___
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] SG 1-4 artwork zip file corrupted. SNOW-604

[Thickbrick Sleaford]

On Friday 09 April 2010 20:45:41 Nicky Perian wrote:
> http://jira.secondlife.com/browse/SNOW-604?ticket=ST-1291-Du2hp64P1FjUKtaRa
> 4G1hKGawJEXOEadOKW-20
> 
> Could a Linden please take a look?
> 
> Thanks
> Nicky

The S3 urls in doc/asset_urls.txt give a 403 error ("Access Denied"):
http://svn.secondlife.com/trac/linden/browser/projects/2009/snowglobe/trunk/doc/asset_urls.txt

This looks like it's the same problem as with build log urls from sldev-commit 
messages, which we discussed yesterday at the open source meeting. Merov said 
he will be looking into it, IIRC.

-- 
Thickbrick
___
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] Can we, open source devs, still support Snowglobe? was: Can we be more productive, please?

[Thickbrick Sleaford]

On Friday 02 April 2010 16:36:45 Aleric Inglewood wrote:

> Who of the active contributors (speak up if I missed you) are willing to
> make a stand and stop at least developing for snowglobe, unless we
> get a clear, understandable and official explanation what kind of legal
> liability TPV devs are facing? Don't you think we owe that to the other
> open developers that do not work on snowglobe, but on some TPV?
> 

I don't know if the TPV policy (agreement, really) really does expose 
developers to additional liability, but I don't know that it doesn't either. 
That is a BIG problem for hobbyist developers who are not going to hire  a 
lawyer to decipher the agreement for them.

I hope someone in a position to make policy decisions at LL asks the question 
of whether LL is interested in the existence of an open source community of 
(largely hobbyist) viewer developers, or is it content with having source that 
is open and a few business partners who use that source.

If the answer is the former, then this can be easily fixed by sending that 
document for another iteration to the lawyer who drafted it, with the 
instructions to make the problematic clauses clear in both English and 
Legalese.

Personally, even though I'm not directly affected by this agreement (it 
explicitly excludes Snowglobe), I don't see much point in continuing my 
involvement in this open source process if TPV developers were to be shut out 
of it.

This is very unfortunate since we are just now seeing the fruits of a large 
Linden effort (by Merov and others) to open the development process. This is 
is something we have been asking for for a long time, and deserves to be 
lauded publicly, not rewarded with the current opensource-dev drama.

This investment of time and effort by LL leads me to think that disruption of 
the open source community is NOT what this policy was intended to do.

Hoping this will be resolved soon,
-- 
Thickbrick
___
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] Question related with rotation of object

[Thickbrick Sleaford]

On Wednesday 17 March 2010 17:06:27 Rustam Rakhimov wrote:
> Reason why I need it,
> 
> I want to know what's rotation has an object, then I can rotate it back,
> 
> But actually I want to calculate rotation of some point in 3D world, so
> that's why I decide learn how's rotations are going. There are a lot of
> things related with matrix, Quaternion class, LLVector3 class.
> 
> Anyway I need that value, and I want to know where exactly these values are
> located.
> 

LLViewerObject  inherits from LLPrimitive which inherits from LLXform. If you 
look at LLXform you can see it stores rotation as a quaternion, in mRotation. 
The various ways of getting and setting that rotation (matrix, Euler angles) 
all translate to/from LLQuaternion eventually.

http://omvviewer.byteme.org.uk/snowglobe_1_x_doxygen/classLLViewerObject.html

> And last question is what does it means jira from your sentence "which jira
> is relevant to this?"
> 

http://jira.secondlife.com/

I hope this helps...

-- 
Thickbrick
___
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] svn compile failure on Ubuntu 9.10

[Thickbrick Sleaford]

On Sunday 07 March 2010 02:14:57 Glen Canaday wrote:
> /home/glen/Programs/Second
> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d
> etail/coroutine_impl.hpp:59: error: declaration of ‘typedef class
> boost::coroutines::detail::context_base
> boost::coroutines::detail::coroutine_impl ContextImpl>::context_base’
> /home/glen/Programs/Second
> Life/Snowglobe-2.0-build/trunk/indra/../libraries/include/boost/coroutine/d
> etail/context_base.hpp:55: error: changes meaning of ‘context_base’ from
>  ‘class
> boost::coroutines::detail::context_base’
> 

What I did to get a non-standalone 32-bit build going with gcc4.4 was replace 
the boost in install.xml to the one from snowglobe 1.x trunk (REAL 1.39), then 
copy the libraries/include/boost/coroutine/ folder from the original boost 
package that came with 2.0 (1.34, but the file is named 1.39) into the 
unpacked new tree. Hopefully there will be proper 1.39 boost packages for 2.0 
soon.

Other than this and the SNOW-506 problem you listed above, I also had copy my 
system's libuuid.so.1 into the build tree, because (I think) the supplied 
version didn't agree with my system's DBus.

-- 
Thickbrick

___
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] svn compile failure on Ubuntu 9.10

[Thickbrick Sleaford]

On Sunday 07 March 2010 00:57:42 Glen Canaday wrote:
> Dead compile:
> 
> /home/glen/Programs/Second
> Life/Snowglobe-2.0-build/trunk/indra/llcommon/llinstancetracker.h:170:
> error: ‘LLInstanceTracker’ is an
> inaccessible base of ‘LLEventTimer’
> make[2]: *** [llcommon/CMakeFiles/llcommon.dir/lleventtimer.o] Error 1
> make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
> make: *** [all] Error 2
> 
> I'm no good with templates - never use them. Anyone?
> 
> --GC


This looks like SNOW-506:
http://jira.secondlife.com/browse/SNOW-506

IIRC there are two places where this happens (this and SNOW-514), and in both 
replacing the inheritance from protected to public seems to work.

-- 
Thickbrick
___
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] latest SG1.3.2

[Thickbrick Sleaford]

On Sunday 28 February 2010 01:23:21 Tayra Dagostino wrote:
> receiveMessage:943: GStreamer010 media instance failed to set up 
...
> (:24128): GStreamer-CRITICAL **: gst_element_set_state:
> assertion `GST_IS_ELEMENT (element)' failed
> 
> somebody else notice this on a lenny+backports?

Does your Audio Driver: line in Help -> About show "(noce)"? If so, I think 
this sounds similar to
http://jira.secondlife.com/browse/SNOW-541

I think that normally when the sound device can't be opened, OpenAL will try 
to open first ALSA, then OSS, and only then PulseAudio. but it seems in 
SNOW-541 it first tried PulseAudio, even though it didn't exist, resulting in 
non-working sound and non-working gstreamer plugin. (This is just a guess, and 
I haven't seen this on my system.)

-- 
Thickbrick
___
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] Client-side scripting in Snowglobe

[Thickbrick Sleaford]

On Thursday 18 February 2010 17:57:52 Kent Quirk (Q Linden) wrote:
> This makes me sad.
> 
> I've been trying to have an open discussion about some of the design issues
>  in my office hours, specifically to understand the constraints and
>  requirements of the community. But every office hour seems to be followed
>  up by flames on this list and in other forums interpreting what was said
>  in the worst possible way.
> 
> I'm afraid the tone and direction of this discussion are making it
>  impossible for us to talk about this project productively.
> 
>   Q

I think this is a good point in this budding flamewar to bring this up:
http://lwn.net/Articles/370157/
Josh Berkus' patented ten-step method on how to free a project of unwelcome 
community involvement.

(A little) more seriously, if the current trend towards secrecy at LL is a 
result of 3rd party viewers based on LL code "stealing" mindshare, it should 
be pointed that the developers of those viewers chose that route mainly as a 
result of LLs past lack of involvement with open source contributors, and 
(again, past) opaque and SLOW process of patch submission.

To move this to a more productive direction, can you give a summary of what 
Firefly is, for those of us who weren't at your office hour?


-- 
Thickbrick
___
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