On Sat, Oct 9, 2010 at 11:30 PM, Tateru Nino tateru.n...@gmail.com wrote:
Well, that depends. That element might be used for something else,
elsewhere.
If the _intended_ behaviour of the function (and of the array/container) is
documented, then it's relatively easy to make decisions about
Well, this is pretty common idiom for code that deals with bit masks.
Funny. The problem is that the bitmask (hard to understand?) was replaced
with a simple array (easy to understand? and that is when the error was
introduced.
On Sat, Oct 9, 2010 at 2:59 PM, Zabb65 zab...@gmail.com wrote:
I
This code below means it used to be inline, but now is a function call
(unless the compiler is optimizing or something). You guys know the code
wy better tahn I, but is it worth moving it back to the .h file?
return type mRenderTypeEnabled[type]
looks hard to beat for inlining, and it is
The original code looks very efficient, especially for inlining.
Anyone have any idea if it actually does what it is supposed to do by
accident or by design?
On 11/10/2010 3:47 AM, Ponzu wrote:
This code below means it used to be inline, but now is a function call
(unless the compiler is
Putting in now.
Funny thing is I *like* seeing my hair and glasses when I am in Mouselook.
it makes me feel like I am really looking out of my avatars eyes.
Maybe it needs to be an option 8-)
On Fri, Oct 8, 2010 at 10:31 PM, Philippe (Merov) Bossut
me...@lindenlab.com wrote:
return (type !=
I don't normally gripe about stuff like this, but somehow this one
triggered my twitches from 20 years of supporting PhD programmers.
Brilliant guys, but sometimes it's SO hard to figure out what they're
trying to do.
This is a case where the trinary ?: operator is much more readable
and
I tend to agree with Argent on this, it should have a comment if there
is a hack in place to make it all function.
I ran it through hg blame and it claims that revision 11977 was when a
big block in pipeline.cpp changed
11977: BOOL LLPipeline::hasRenderType(const U32 type) const
11977: {
11977:
On 10/09/2010 08:59 PM, Zabb65 wrote:
I ran it through hg blame and it claims that revision 11977 was when a
big block in pipeline.cpp changed
[...]
http://hg.secondlife.com/viewer-development/changeset/c09f9bcd9d20
however does not show this, and I suspect that it is heavily truncated
on
Would it be better to just store FALSE in mRenderTypeEnabled[0]?
On Sat, Oct 9, 2010 at 12:19 PM, Argent secret.arg...@gmail.com wrote:
I don't normally gripe about stuff like this, but somehow this one
triggered my twitches from 20 years of supporting PhD programmers.
Brilliant guys, but
On 10/9/2010 10:07, Ponzu wrote:
Photo attached, from behind my eyes 8-)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated
Well, that depends. That element might be used for something else,
elsewhere.
If the _intended_ behaviour of the function (and of the array/container)
is documented, then it's relatively easy to make decisions about how
best to implement that, clearly, concisely and efficiently - or at least
Hi guys,
I need to go home and can't clean up the whole hg/JIRA now but, for you at
home who can build and can test, I think I've a neat one liner to fix that
one:
diff -r b0cd7e150009 indra/newview/pipeline.cpp
--- a/indra/newview/pipeline.cppWed Oct 06 19:57:45 2010 -0700
+++
12 matches
Mail list logo
