[opensource-dev] LLSingleton class question.

[lists . secondlife . com]

Hi all.

In the LLSingleton header, there is a comment:

// Reference version of getInstance()
// Preferred over getInstance() as it disallows checking for NULL

My question is, is there a difference between
MyClass::instance()->someFunction(); and
MyClass::getInstance()->someFunction(); ?

If not, is there a preference of using one over the other?

Linden Lab viewer code has about 35% ::instance use vs.
65% ::getInstance use.

-- Techwolf Lupindo
___
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

[lists . secondlife . com]

On Sat, 4 Aug 2012 00:52:40 +0200
Carlo Wood  wrote:

> On Thu, 02 Aug 2012 12:21:20 -0700
> Kadah  wrote:
> 
> I stand corrected :/. And I'm disappointed in the mail viewer
> that I use (Claws Mail). I see nothing, and it treats your
> message as an attachment. When I click on that it allows
> me to "Open" it with abiword -- which I normally only need
> to open .doc documents -- hence my accusation...
> Before this mail program I used mutt, and that had no problem
> showing signed mails directly :\
> 

I am currently using Claws Mail here too and don't see anything wrong.
I see the entire mail including the plain text pgp stuff at the end.

-- Techwolf Lupindo
___
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] Missing code.

[lists . secondlife . com]

On Mon, Nov 11, 2013 at 4:45 PM, Oz Linden (Scott Lawrence)
 wrote:
> On 2013-11-10 21:14 , Techwolf Lupindo wrote:
> > Is there a reason why 
> > https://bitbucket.org/lindenlab/3p-gtk-atk-pango-glib is empty?
> 
> Because we don't have the sources?
> 
> -- 
> *Scott Lawrence* | /Director of Open Development/
> Skype ozlinden  | Second Life Oz Linden 
> 

Does anyone know where the code is for 3p-gtk-atk-pango-glib that was
used to build
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/gtk-atk-pango-glib-linux-20101001.tar.bz2
and
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/gtk-atk-pango-glib-windows-20101001a.tar.bz2


Also, found 3p-gstreamer empty also. Doesn anyone know where the source
code that was used to build
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/gstreamer-linux-20101013.tar.bz2
is?

-- Techwolf Lupindo
___
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] Fw: [git] Include Jira Ticket Number in Commits, Please!

[lists . secondlife . com]

Begin forwarded message:

Date: Wed, 02 Jul 2014 11:32:09 -0700
From: OnLive Jira Watcher 
Subject: [git] Include Jira Ticket Number in Commits, Please!


This notice is to remind you that you need to include valid Jira ticket
numbers in all of your Git commits!

We encountered the following problems in your recent commits.

Commits with no reference to any jira tickets:

  https://github.onlive.com/Engineering/ol-secondlife/commit/3a5fae14
Clean up and rework FMOD.cmake and FindFMOD.cmake
FMOD.cmake:
Move include(Prebuilt) to prebuilt section. It is only used for
  prebuilt anyway. set(FMOD_FIND_REQUIRED ON) due to FMOD variable is
  use elsewhere in cmake files. This behaviour is the same as openal.
  Remove redudent error messages and code due to above. Rework the
  logic to be more cleaner. Clean up whitespace.
FindFMOD.cmake
Remove redudent paths as cmake allready uses them as default.
  Use PATH_SUFFIXES instead. The above will result in cmake looking in
  a lot more places and can handle custom build setups better. Change
  FMOD to FMOD_FOUND. FMOD should not be change withen cmake.
  Whitespace cleanup. --
  https://github.onlive.com/Engineering/ol-secondlife/commit/ef220319
Allow the passing of addational fmod lib names via FMOD_NAMES from the
  build envorment. This will allow one to pass via command line custom
  fmod lib names. ie: -DFMOD_NAMES:STRING:"fmod-4.44" - Commits
  which reference invalid Jira ticket numbers that don't exist or have
  already been closed:

  https://github.onlive.com/Engineering/ol-secondlife/commit/999f782a
SNOW-746: Finished Google BreakPad cmake for standalone
(transplanted from 5a7ee78d029e973084e28d0d23a7233e0d976dca)

--HG--
extra : transplant_source :
Z%7E%E7%8D%02%9E%970%84%E2%8D%0D%23%A7%23%3E%0D%97m%CA --
  https://github.onlive.com/Engineering/ol-secondlife/commit/a6def839
VWR-20893: "class Linux_x86_64Manifest" missing from viewer_manifest.py
Breaking linux 64-bit build. (transplanted from
111a293c0e1c9062b1aa83dda7cf28aa22754930)

--HG--
extra : transplant_source :
%11%1A%29%3C%0E%1C%90b%B1%AA%83%DD%A7%CF%28%AA%22uI0 --
  https://github.onlive.com/Engineering/ol-secondlife/commit/5ff89857
SNOW-599/SNOW-747: Pulseaudio should be optional on Linux.
-

Please be more careful in future commits.

For information about installing the local onlive git hooks, which can
help you remember, see
https://wiki.onlive.com/display/DOCS/OnLive+Git+Hooks
___
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] Second Life Package Repo

[lists . secondlife . com]

I've been maintaining a gentoo overlay. Just got done doing some updates to it 
now. While there is a secondlife client in portage, it lacks voice support on 
64-bit systems, spacenav joystick support, etc. I managed to re-verce engineer 
LL build process on my own and develop a much better ebuild. While its is more 
complex, its has full voice/spacenav support and is actually more flexible 
then the one supplied by portage.

Because I've been doing this, I submitted several patches to fix the builds of 
problems that I have encountered.

--Techwolf Lupindo
gentoo.techwolf.net
___
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] Brown-bag meeting to continue dialog on TVPV

[lists . secondlife . com]

On Friday 09 April 2010 11:49:48 am Joe Miller wrote:
> 
> 
> 
> 
>   
>   
> 
> 
> No apology necessary.  I just wanted to restate that if TPV authors
> are staying away from this meeting because of some perceived "catch-22" on
> acceptance of the updated TOS, that shouldn't be an issue as they are
> governed by the TOS in effect prior to 3/31.
> 
> Tateru Nino wrote:
> 
> http-equiv="Content-Type">
> My apologies, Joe - I'll email you directly.
>   
> On 10/04/2010 1:28 AM, Joe Miller wrote:
>   
>   http-equiv="Content-Type">
> Tateru,
> 
> You can continue down this road if you wish, but the facts are the
> words in 13.3 do not become effective for Residents who had registered
> before March 31, 2010 until April 30 2010.  (See the blog post   moz-do-not-send="true"
>  href="https://blogs.secondlife.com/community/community/blog/2010/03/31/upd
> ated-second-life-terms-of-service">here with additional words to that
> effect.)  The updated TOS text was pushed to everyone so they would
> have the benefit of a full 30 days to review it before acknowledging
> formal acceptance of it by accessing the system after April 30.  
> 
> So, please, do not add to the rhetoric here by telling me about
> contract law, charges of fraud, coercion or whatever point you're
> trying to make.  The TOS in force today was the agreement accepted by
> all Residents of record prior to March 31.  After April 30, everything
> you say about section 13.3 in the new TOS is reasonably accurate.
> 
> The purpose of my brown bag is to talk about the new TPV policy and the
> concerns raised by several members of the open source community.  I
> intend to listen to listen to all reasonable proposals to address those
> concerns.  Those who do not wish to participate in that synchronous
> event can email me instead if they so choose.   Again, I'm
> looking forward to a productive exchange of specific ideas to address
> specific shared concerns, whether at these meetings or via some other
> channel. 
> If you have nothing to offer, there is no reason to come.
> 
> -- Joe
> 
> 
> Tateru Nino wrote:
> 
> http-equiv="Content-Type">
> That clear statement is inadmissible by the terms of the TOS §13.3,
> I'm afraid, which disclaims such as not being a valid part of the
> agreement. No part of the agreement that is made admissible by §13.3
> suggests or implies any commencement date other than immediately.
>   
> Nor does it permit any explanation, FAQ, supplement, or discussion to
> be considered relevant (except as provided, which none have been).
> Boilerplate it may be, but it is binding boilerplate. It could say that
> "This agreement grants you a lifetime supply of banana custard", but
> that's not actually in there. It would be an assurance that is
> disclaimed within the agreement. §10.3 absolves the Lab and its
> representatives of charges of fraud if they say something about the
> agreements that aren't strictly speaking true, in order to obtain
> agreement.
>   
> As a general rule for contracts and agreements (leaving aside the TPVP,
> the TOS, and Linden Lab for a moment), it's widely considered remiss to
> act based on inadmissible representations or explanations of a contract
> from the other party to the actual agreement. That's the sort
> of thing lawyers warn you not to do.
>   
>   
> On 9/04/2010 3:32 PM, Joe Linden wrote:
> cite="mid:i2m6b9495c41004082232mc2320c1by1c03619be336f...@mail.gmail.com"
>  type="cite">Of course you can.  The ToS presented at login clearly
> states it becomes effective on 4/30.  In the meantime, you continue to
> use the service under the terms of the prior ToS which doesn't contain
> the TPV provisions.  If one has issues with the prior ToS agreement,
> and hasn't previously accepted those terms, then I agree, this meeting
> isn't for you.
> 
> -- joe
> 
> On Thu, Apr 8, 2010 at 7:32 PM, Boy
> Lane <  href="mailto:boy.l...@yahoo.com";>boy.l...@yahoo.com>
> wrote:
>   style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt
> 0.8ex; padding-left: 1ex;">Thanks Joe.
>   
> Unfortunately one can not attend without going inworld and accepting
> ToS/TPV in the first place.
>   
>   
> style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt
> 0.8ex; padding-left: 1ex;">- Original
> Message - Date: Thu, 8 Apr 2010 13:24:57 -0700
> From: Joe Linden <  href="mailto:j...@lindenlab.com";
> target="_blank">j...@lindenlab.com> Subject: [opensource-dev]
> Brown-bag meeting to continue dialog on TVPV next Tuesday (4/13)
> To: OpenSource-Dev <  href="mailto:opensource-dev@lists.secondlife.com";
> target="_blank">opensource-dev@lists.secondlife.com>
> Message-ID:
> <  href="mailto:v2k6b9495c41004081324ibd5ec762zb8d098a09c7f0...@mail.gmail.co
> m"
> target="_blank">v2k6b9495c41004081324ibd5ec762zb8d098a09c7f0...@mail.gmail
> .com> Content-Type: text/plai

[opensource-dev] Problems porting VWR-12984 to snowglobe 2.0

[lists . secondlife . com]

When porting over VWR-12984, I hit a snag. Turns out an enum was added to from 
1.x to 2.x that put it at 32 bits. The port added one more causing to go over 
to 33 bits. From the comments section of the jira.

==
These warnings are indeed sign of a serious problem: The enum's values are 
used to shift a 1 (a set bit) around within (32-bit) ints, to produce flags 
and masks. Other than in Snowglobe 1.x, the enum already had 32 values before 
the patch. The patch added a 33rd, pushing the shifted-around 1 off the type 
size boundary.

This results in some objects staying blurry and and others disappearing 
seemingly at random or not showing at all. Most of the values of the enum are 
being assigned values from other enums, so either this was very, very 
carefully crafted or we were extremely "lucky" that the bit-shifting didn't 
push the 32bit limit already before this patch.

The warnings can be avoided by doing the shifting within long ints instead of 
ints. This of course doesn't solve the problem, as the types of the variables 
to which the resulting masks get assigned are still too small and would have 
to be changed, too. (Which could lead to other variables and constants having 
to be changed. Didn't check that, yet.)

If (at least) one of the values of the enum isn't used to shift bits around (I 
haven't looked yet whether that's the case), that one could be put at the end 
of the enum, thus keeping the others below 32. However, that solution would be 
even hackier than than the current code and would cause major maintenance 
headaches. (E.g., what happens when that value has later to be used to define 
a mask, too?)


My question for the group is how is the best way to fix this? Can 
RENDER_TYPE_PASS_* be moved into its own enum?

--Techwolf Lupindo
___
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] I was told this need to be dropped on the mailing list.

[lists . secondlife . com]

>From http://jira.secondlife.com/browse/VWR-20751

I've added changesets for you to work with. These are the ones I used to get 
viewer-devolment to build on linux 64-bit standalone.
These patches/changeset have been updated to viewer-devolment as it was 
different from snowglobe 2.x code.

https://bitbucket.org/Techwolf/viewer-development/changeset/5a7ee78d029e
SNOW-746: Finished Google BreakPad cmake for standalone

https://bitbucket.org/Techwolf/viewer-development/changeset/ff09fdf21fde
cmake patch from SNOW-543 updated for viewer-development

https://bitbucket.org/Techwolf/viewer-development/changeset/fd6fcea097f0
viewer_manifest.py fixes from SNOW-334, SNOW-47, SNOW-517, and SNOW-543. They 
all touch each other code, so combined into one changeset. Add doc/contrub 
credit in the right places.

https://bitbucket.org/Techwolf/viewer-development/changeset/111a293c0e1c
VWR-20893: "class Linux_x86_64Manifest" missing from viewer_manifest.py. 
Breaking linux 64-bit build.

https://bitbucket.org/Techwolf/viewer-development/changeset/00bd21962052
SNOW-512/SNOW-287: Build of LLPlugin fails on 64bit linux due to non PIC code 
linking into the DSO.
Formatting, cleanup, and one minor change by Techwolf Lupindo. Minor change 
was a move of the hunk in indra/media_plugins/webkit/CmakeLists.txt to same 
area as the other plugins CmakeLists.txt files.

https://bitbucket.org/Techwolf/viewer-development/changeset/15d19316812c
SNOW-599/SNOW-747: Pulseaudio should be optional on Linux.

https://bitbucket.org/Techwolf/viewer-development/changeset/5697874b390b
Add missing "if (LL_TESTS)" from SNOW-651/SNOW-654

-
I've allready done the work. But the process to getting in the process is 
still unclear. Red tape golore. I hope that can be changed.

--Techwolf Lupindo
___
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] User Story: Improved Cache

[lists . secondlife . com]

On Saturday 18 September 2010 9:51:22 pm Argent Stonecutter wrote:
> I honestly think that going to a straight squid-style cache for textures
> would so improve the user experience that worrying about extra features
> like "preferred places" would become irrelevant.

I have managed to get a local squid proxy set up on my system and I use it all 
the time. The local squid proxy works on 1.5 based code. Viewer 2.x can not 
use it due to no http texture proxy setting.

I use a 32GB squid proxy cache and it performs quiet well.

-- Techwolf Lupindo
___
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] Rainbow texture problem.

[lists . secondlife . com]

Hi all.

I've been trying to fix a rainbow texture corruption bug the past few days 
with little success. Using UDP, its ok. Using http texture fetch, it get 
corrupted.

I've managed to figure what is causing the texture to get corrupted after 
downloading and displaying it. What happens is that on textures that have the 
same file size for discard level 1 and 0, the data size sent to the decoder is 
incorrect. See http://pastebin.com/Kc9x5BNS for the detailed debug output for 
that texture.

I've managed to trace back to the function that is returning the incorrect 
data recieved in lltextruefetch.cpp, "mFormattedImage->getDataSize()". That 
function is used to calculate the amount of data to memcopy and to send to the 
decoder.

"mFormattedImage->getDataSize()" goes back to llimage.cpp and from there who 
knows, i've can't trace it back anymore.

Somewhere between libcurl returning data and lltextruefetch, the amount of 
data recieved is getting corrupted somewhere. If someone knows of this bug or 
can point me in the right direction of how the size data from libcurl gets to 
lltexturefetch.cpp I would be grateful.

--Techwolf Lupindo
___
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