Re: [opensource-dev] Review Request: STORM-1315: Ability to do simple math in numeric edit fields

[Yoz Linden]

No review, just gratitude: This is a seriously nifty feature, so thanks for 
picking up Aimee's work and helping it over the finish line!

-- Yoz

On Jun 29, 2011, at 11:57 PM, Kadah Coba wrote:

> STORM-1315

___
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] No Viewer Evolution Meeting July 1

[Oz Linden (Scott Lawrence)]

 taking an extended holiday weekend.

See you next week.

___
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] Shader typo

[Boroondas Gupte]

On 06/28/2011 08:45 PM, Altair Sythos Memo wrote:
> SecondLife-i686-2.7.6.233972/app_settings/shaders/class2/deferred/sunlightSSAOMSF.glsl
>
> should be sunLightSSAOMSF.glsl
>
> renaming turn ON again shadows
Looks like that's already been fixed in b3e5a757f275

a week ago. Can you try whether it's working correctly in recent
viewer-development test builds?

Cheers,
Boroondas
___
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] (no subject)

[malachi]

I just tried to compile the viewer 2 source. Following the instructions on
the wiki. And have come across a ton of errors. I do not have these errors
while building snowglobe or 1.2x viewer source. Any help would be
appreciated. Just want to start working on viewer 2 source. Have a bit of
free time and would like something to keep me busy.









== Build: 3 succeeded, 5 failed, 31 up-to-date, 2 skipped ==



Error1error MSB6006: "cmd.exe" exited with code 1.C:\Program
Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets151
Error2error C2371: 'int_fast16_t' : redefinition; different basic
typesC:\Program Files (x86)\QuickTime
SDK\CIncludes\GNUCompatibility\stdint.h49
Error3error C2371: 'uint_fast16_t' : redefinition; different basic
typesC:\Program Files (x86)\QuickTime
SDK\CIncludes\GNUCompatibility\stdint.h50
Warning4warning C4005: 'INT8_C' : macro redefinitionC:\Program
Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h168
Warning5warning C4005: 'INT16_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 169
Warning6warning C4005: 'INT32_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 170
Warning7warning C4005: 'INT64_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 171
Warning8warning C4005: 'UINT8_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 173
Warning9warning C4005: 'UINT16_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 174
Warning10warning C4005: 'UINT32_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 175
Warning11warning C4005: 'UINT64_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 176
Warning12warning C4005: 'INTMAX_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 179
Warning13warning C4005: 'UINTMAX_C' : macro redefinition   
C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility\stdint.h  
 180
Error14error MSB6006: "cmd.exe" exited with code 1.C:\Program
Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets151
Error15error MSB6006: "cmd.exe" exited with code 1.C:\Program
Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets151
Error16error MSB3073: The command ""C:\Program Files (x86)\CMake
2.8\bin\cmake.exe" -E copy
C:/v2/build-vc100/llplugin/slplugin/Release/SLPlugin.exe
C:/v2/build-vc100/test_apps/llplugintest/Release/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy
C:/v2/build-vc100/sharedlibs/Release/llcommon.dll
C:/v2/build-vc100/test_apps/llplugintest/Release/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy
C:/v2/build-vc100/media_plugins/webkit/Release/media_plugin_webkit.dll
C:/v2/build-vc100/test_apps/llplugintest/Release/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy
C:/v2/build-vc100/media_plugins/quicktime/Release/media_plugin_quicktime.dll
C:/v2/build-vc100/test_apps/llplugintest/Release/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy
C:/v2/build-vc100/media_plugins/example/Release/media_plugin_example.dll
C:/v2/build-vc100/test_apps/llplugintest/Release/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy
C:/v2/indra/test_apps/llplugintest/bookmarks.txt
C:/v2/build-vc100/test_apps/llplugintest/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E copy
C:/v2/indra/test_apps/llplugintest/bookmarks.txt
C:/v2/build-vc100/test_apps/llplugintest/Release/
if errorlevel 1 goto :VCEnd
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe"
-DBIN_NAME="C:/v2/build-vc100/test_apps/llplugintest/Release/llmediaplugintest.exe"
-DSEARCH_DIRS="C:/v2/build-vc100/sharedlibs/Release;C:/v2/build-vc100/sharedlibs/Release;C:\Windows/system32"
-DDST_PATH="C:/v2/build-vc100/test_apps/llplugintest/Release" -P
C:/v2/indra/cmake/DeploySharedLibs.cmake
if errorlevel 1 goto :VCEnd
:VCEnd" exited with code 1.C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets113
17IntelliSense: too many characters in character constant   
c:\program files (x86)\quicktime sdk\cincludes\aeregistry.h814
18IntelliSense: too many characters in character constant   
c:\program files (x86)\quicktime sdk\cincludes\folders.h192
19IntelliSense: too many characters in character constant   
c:\program files (x86)\quicktime sdk\cincludes\folders.h197
20IntelliSense: too many charact

[opensource-dev] Shameless self-promotion...

[Lee ponzu]

I sent in an application for a couple of the positions open at Linden Lab.
 (My real name is Lee Sailer.)

If any of you feel inclined to put in a good word for me at HR, please feel
free  8-)  In fact, if LL has a finders fee for employees who recommend
someone, I'd be glad to ay you recommended me.

thanks mucho,

Lee Sailer Ponzu
___
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] Shader typo

[Sythos]

On Fri, 01 Jul 2011 14:14:08 +0200
Boroondas Gupte  wrote:

> On 06/28/2011 08:45 PM, Altair Sythos Memo wrote:
> > SecondLife-i686-2.7.6.233972/app_settings/shaders/class2/deferred/sunlightSSAOMSF.glsl
> >
> > should be sunLightSSAOMSF.glsl
> >
> > renaming turn ON again shadows
> Looks like that's already been fixed in b3e5a757f275
> 
> a week ago. Can you try whether it's working correctly in recent
> viewer-development test builds?

i'll check asap, btw last night i've seen [COUNT] in prim cpunt edit
floater... maybe my version is too 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] Compile errors (was: no subject)

[Ima Mechanique]

> I just tried to compile the viewer 2 source. Following the instructions on
> the wiki. And have come across a ton of errors. I do not have these errors
> while building snowglobe or 1.2x viewer source. Any help would be
> appreciated. Just want to start working on viewer 2 source. Have a bit of
> free time and would like something to keep me busy.

Which wiki page. There are a few concerned with building on Windows.
Some of them are more useful (and more up to date) than others.
The one you should be reading is:

http://wiki.secondlife.com/wiki/Viewer_2_Microsoft_Windows_Builds

it assumes you are setting up from a clean system. So if you're not
don't skip steps as that can mess things up if you used different
instructions

--
Ima Mechanique
ima.mechanique(at)blueyonder.co.uk

___
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] Virtual Destructors

[Ricky]

Poking around in the llmanip* files working on VWR-25739, I started to
get annoyed at the coding inconsistencies between those files.  So I
started looking at what it would take to make the 3 subclasses
(translate, scale, and rotate) consistent, when I tripped across the
detail that llmaniptranslate.h has the destructor declared virtual
while llmanipscale.h has it declared plainly, and llmaniprotate.h
doesn't explicitly declare a destructor.

When I looked up some reasons why a destructor should be virtual it
seems that it should be virtual when the class is going to be used in
a polymorphic way and will have delete called on a pointer to it.  IE:
// MyClass is a ParentClass
ParentClass* p = new MyClass();
destroy p;

Apparently this is about the only case for declaring the destructor
virtual. (see http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx
and especially http://www.erata.net/programming/virtual-destructors/ )
 It also comes with a minor performance hit, but that's outside of
scope.

It turns out that LLManipScale _is_ being used in such a way in
LLToolComp - as are LLManipScale and LLManipRotate:
lltoolcomp.h line 92: LLManip* mManip;
lltoolcomp.cpp line 194: mManip = new LLManipTranslate(this);
lltoolcomp.cpp line 203: delete mManip;
lltoolcomp.cpp line 321: mManip = new LLManipScale(this);
lltoolcomp.cpp line 330: delete mManip;
lltoolcomp.cpp line 520: mManip = new LLManipRotate(this);
lltoolcomp.cpp line 530: delete mManip;

So it looks like to me that there might be a memory leak in the scale
and rotate classes, as their destructors might NOT be being called.
Of course, Translate's destructor has only an empty definition, and
Rotate doesn't even have one, but Scale does have a full-on
destructor.  And because it is not virtual, it might not be being
called.

Looking over the history of the files gives me the following:
The Rotate destructor was last touched by Steven Bennets on 2008-03-11
in rev 341 - when LLLinkedList was culled in favor of another
technique.
The Translate destructor was emptied by James Cook on 2009-12-10 in
rev 4496 - switched to a std::vector
The Scale destructor seems to have never existed in revision history.

Anyone with more familiarity with C++'s nuances in such cases have any
thoughts/suggestions?

Ricky
Cron Stardust
___
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] Virtual Destructors

[Ricky]

Looks like the destructors might only be called at program
termination, so this may not be a big problem anyway.  However it IS
inconsistent and weird.  And I have it within reach to clean up if it
seems good to do so.

Ricky
Cron Stardust

On Fri, Jul 1, 2011 at 3:25 PM, Ricky  wrote:
> Poking around in the llmanip* files working on VWR-25739, I started to
> get annoyed at the coding inconsistencies between those files.  So I
> started looking at what it would take to make the 3 subclasses
> (translate, scale, and rotate) consistent, when I tripped across the
> detail that llmaniptranslate.h has the destructor declared virtual
> while llmanipscale.h has it declared plainly, and llmaniprotate.h
> doesn't explicitly declare a destructor.
>
> When I looked up some reasons why a destructor should be virtual it
> seems that it should be virtual when the class is going to be used in
> a polymorphic way and will have delete called on a pointer to it.  IE:
> // MyClass is a ParentClass
> ParentClass* p = new MyClass();
> destroy p;
>
> Apparently this is about the only case for declaring the destructor
> virtual. (see 
> http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx
> and especially http://www.erata.net/programming/virtual-destructors/ )
>  It also comes with a minor performance hit, but that's outside of
> scope.
>
> It turns out that LLManipScale _is_ being used in such a way in
> LLToolComp - as are LLManipScale and LLManipRotate:
> lltoolcomp.h line 92: LLManip* mManip;
> lltoolcomp.cpp line 194: mManip = new LLManipTranslate(this);
> lltoolcomp.cpp line 203: delete mManip;
> lltoolcomp.cpp line 321: mManip = new LLManipScale(this);
> lltoolcomp.cpp line 330: delete mManip;
> lltoolcomp.cpp line 520: mManip = new LLManipRotate(this);
> lltoolcomp.cpp line 530: delete mManip;
>
> So it looks like to me that there might be a memory leak in the scale
> and rotate classes, as their destructors might NOT be being called.
> Of course, Translate's destructor has only an empty definition, and
> Rotate doesn't even have one, but Scale does have a full-on
> destructor.  And because it is not virtual, it might not be being
> called.
>
> Looking over the history of the files gives me the following:
> The Rotate destructor was last touched by Steven Bennets on 2008-03-11
> in rev 341 - when LLLinkedList was culled in favor of another
> technique.
> The Translate destructor was emptied by James Cook on 2009-12-10 in
> rev 4496 - switched to a std::vector
> The Scale destructor seems to have never existed in revision history.
>
> Anyone with more familiarity with C++'s nuances in such cases have any
> thoughts/suggestions?
>
> Ricky
> Cron Stardust
>
___
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] Virtual Destructors

[Joshua Bell]

Destructors of derived classes are automatically virtual if the base class
destructor is virtual.

http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.7

The inheritance chain is:

LLMouseHandler > LLTool > LLManip > LLManipScale

... and both LLMouseHandler and LLTool declare the destructor as virtual.

It wouldn't hurt to explicitly mark ~LLManip and ~LLManipScale as virtual
for clarity in the code, but it won't actually change anything.

On Fri, Jul 1, 2011 at 4:02 PM, Ricky  wrote:

> Looks like the destructors might only be called at program
> termination, so this may not be a big problem anyway.  However it IS
> inconsistent and weird.  And I have it within reach to clean up if it
> seems good to do so.
>
> Ricky
> Cron Stardust
>
> On Fri, Jul 1, 2011 at 3:25 PM, Ricky  wrote:
> > Poking around in the llmanip* files working on VWR-25739, I started to
> > get annoyed at the coding inconsistencies between those files.  So I
> > started looking at what it would take to make the 3 subclasses
> > (translate, scale, and rotate) consistent, when I tripped across the
> > detail that llmaniptranslate.h has the destructor declared virtual
> > while llmanipscale.h has it declared plainly, and llmaniprotate.h
> > doesn't explicitly declare a destructor.
> >
> > When I looked up some reasons why a destructor should be virtual it
> > seems that it should be virtual when the class is going to be used in
> > a polymorphic way and will have delete called on a pointer to it.  IE:
> > // MyClass is a ParentClass
> > ParentClass* p = new MyClass();
> > destroy p;
> >
> > Apparently this is about the only case for declaring the destructor
> > virtual. (see
> http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx
> > and especially http://www.erata.net/programming/virtual-destructors/ )
> >  It also comes with a minor performance hit, but that's outside of
> > scope.
> >
> > It turns out that LLManipScale _is_ being used in such a way in
> > LLToolComp - as are LLManipScale and LLManipRotate:
> > lltoolcomp.h line 92: LLManip* mManip;
> > lltoolcomp.cpp line 194: mManip = new LLManipTranslate(this);
> > lltoolcomp.cpp line 203: delete mManip;
> > lltoolcomp.cpp line 321: mManip = new LLManipScale(this);
> > lltoolcomp.cpp line 330: delete mManip;
> > lltoolcomp.cpp line 520: mManip = new LLManipRotate(this);
> > lltoolcomp.cpp line 530: delete mManip;
> >
> > So it looks like to me that there might be a memory leak in the scale
> > and rotate classes, as their destructors might NOT be being called.
> > Of course, Translate's destructor has only an empty definition, and
> > Rotate doesn't even have one, but Scale does have a full-on
> > destructor.  And because it is not virtual, it might not be being
> > called.
> >
> > Looking over the history of the files gives me the following:
> > The Rotate destructor was last touched by Steven Bennets on 2008-03-11
> > in rev 341 - when LLLinkedList was culled in favor of another
> > technique.
> > The Translate destructor was emptied by James Cook on 2009-12-10 in
> > rev 4496 - switched to a std::vector
> > The Scale destructor seems to have never existed in revision history.
> >
> > Anyone with more familiarity with C++'s nuances in such cases have any
> > thoughts/suggestions?
> >
> > Ricky
> > Cron Stardust
> >
> ___
> 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
>
___
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] Virtual Destructors

[Ricky]

Thanks Josh! That's good to know, and thanks for the link.  While I've
gotten used to a fair number of languages, C++ has a LOT of territory
filled with dark corners and pits.  So I try to proceed cautiously. :D

Ricky
Cron Stardust

On Fri, Jul 1, 2011 at 4:08 PM, Joshua Bell  wrote:
> Destructors of derived classes are automatically virtual if the base class
> destructor is virtual.
> http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.7
> The inheritance chain is:
> LLMouseHandler > LLTool > LLManip > LLManipScale
> ... and both LLMouseHandler and LLTool declare the destructor as virtual.
> It wouldn't hurt to explicitly mark ~LLManip and ~LLManipScale as virtual
> for clarity in the code, but it won't actually change anything.
> On Fri, Jul 1, 2011 at 4:02 PM, Ricky  wrote:
>>
>> Looks like the destructors might only be called at program
>> termination, so this may not be a big problem anyway.  However it IS
>> inconsistent and weird.  And I have it within reach to clean up if it
>> seems good to do so.
>>
>> Ricky
>> Cron Stardust
>>
>> On Fri, Jul 1, 2011 at 3:25 PM, Ricky  wrote:
>> > Poking around in the llmanip* files working on VWR-25739, I started to
>> > get annoyed at the coding inconsistencies between those files.  So I
>> > started looking at what it would take to make the 3 subclasses
>> > (translate, scale, and rotate) consistent, when I tripped across the
>> > detail that llmaniptranslate.h has the destructor declared virtual
>> > while llmanipscale.h has it declared plainly, and llmaniprotate.h
>> > doesn't explicitly declare a destructor.
>> >
>> > When I looked up some reasons why a destructor should be virtual it
>> > seems that it should be virtual when the class is going to be used in
>> > a polymorphic way and will have delete called on a pointer to it.  IE:
>> > // MyClass is a ParentClass
>> > ParentClass* p = new MyClass();
>> > destroy p;
>> >
>> > Apparently this is about the only case for declaring the destructor
>> > virtual. (see
>> > http://blogs.msdn.com/b/oldnewthing/archive/2004/05/07/127826.aspx
>> > and especially http://www.erata.net/programming/virtual-destructors/ )
>> >  It also comes with a minor performance hit, but that's outside of
>> > scope.
>> >
>> > It turns out that LLManipScale _is_ being used in such a way in
>> > LLToolComp - as are LLManipScale and LLManipRotate:
>> > lltoolcomp.h line 92: LLManip* mManip;
>> > lltoolcomp.cpp line 194: mManip = new LLManipTranslate(this);
>> > lltoolcomp.cpp line 203: delete mManip;
>> > lltoolcomp.cpp line 321: mManip = new LLManipScale(this);
>> > lltoolcomp.cpp line 330: delete mManip;
>> > lltoolcomp.cpp line 520: mManip = new LLManipRotate(this);
>> > lltoolcomp.cpp line 530: delete mManip;
>> >
>> > So it looks like to me that there might be a memory leak in the scale
>> > and rotate classes, as their destructors might NOT be being called.
>> > Of course, Translate's destructor has only an empty definition, and
>> > Rotate doesn't even have one, but Scale does have a full-on
>> > destructor.  And because it is not virtual, it might not be being
>> > called.
>> >
>> > Looking over the history of the files gives me the following:
>> > The Rotate destructor was last touched by Steven Bennets on 2008-03-11
>> > in rev 341 - when LLLinkedList was culled in favor of another
>> > technique.
>> > The Translate destructor was emptied by James Cook on 2009-12-10 in
>> > rev 4496 - switched to a std::vector
>> > The Scale destructor seems to have never existed in revision history.
>> >
>> > Anyone with more familiarity with C++'s nuances in such cases have any
>> > thoughts/suggestions?
>> >
>> > Ricky
>> > Cron Stardust
>> >
>> ___
>> 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
>
>
___
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: Searching in the world map clears the destination arrow but not the destination beacon

[Kadah Coba]

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

Review request for Viewer.


Summary
---

A single line change to more completely clear the tracking beacon when text is 
entered in to the world map's search field.

https://bitbucket.org/Kadah_Coba/vwr-25753


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


Diffs
-

  indra/newview/llfloaterworldmap.cpp c7a4b7a24e05 

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


Testing
---

Built and ran, world map's search field fallowed the expected behavior 
described in VWR-25753.


Thanks,

Kadah

___
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