[opensource-dev] building on Mac OS X 10.6 is giving me multiple headaches... anyone able to help?

2011-01-24 Thread Lance Corrimal
Hi there,

I'm trying to build 2.4.x based on Mac OS X and I'm having several problems 
with that...


- I'm pretty sure that I've located every place in the source that defines the 
name of the resulting .app and changed them to read "Dolphin Viewer 2.app" 
instead of "Second Life.app" and yet, the build process still tries to install 
some of the resulting stuff in Second Life.app and some in Dolphin Viewer 
2.app, and at that point only Second Life.app exists so the build fails.

-how do i configure the build on mac os to use GCC 4.0 instead of 4.2 If i 
want to build using unix makefiles instead of the xcode gui?

- how do i configure the build process to builds against the 10.5 SDK instead 
of the 10.6 SDK when using unix makefiles instead of xcode gui?



anyone got hints for me?



bye,
LC
___
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: make PREHASH variables char const* const

2011-01-24 Thread Oz Linden

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


If the file is generated, what is it doing checked into the source tree at all? 
 This sounds to me like an invitation to future errors.

Is there some reason why we should not just delete the checked in version and 
have it generated every time it's needed?

- Oz


On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/100/
> ---
> 
> (Updated Jan. 22, 2011, 7:40 a.m.)
> 
> 
> Review request for Viewer and Seth ProductEngine.
> 
> 
> Summary
> ---
> 
> For the reason for this change, see 
> https://jira.secondlife.com/browse/VWR-24487 and 
> https://jira.secondlife.com/browse/VWR-24522
> 
> What I did:
> In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant 
> pointers to constants by search/replace. Then I tried to compile and added 
> const qualifiers in dependent code as needed to stop the compiler complaining.
> 
> Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files 
> have been generated from the message template. Because this generation might 
> not have been a one-off thing, I changed the generating code, too, so it 
> won't override this change here when the generation happens the next time. 
> However, that part of the code is not called by Viewer, although the relevant 
> function — dump_prehash_files() — ends up in the Viewer binary. That function 
> probably gets called by the simulator, when one runs the latter with 
> -prehash. (See 
> https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532
>  )
> 
> 
> This addresses bug VWR-24487.
> http://jira.secondlife.com/browse/VWR-24487
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt fc7e5dcf3059 
>   indra/llmessage/message.cpp fc7e5dcf3059 
>   indra/llmessage/message_prehash.h fc7e5dcf3059 
>   indra/llmessage/message_prehash.cpp fc7e5dcf3059 
>   indra/llprimitive/llprimitive.h fc7e5dcf3059 
>   indra/llprimitive/llprimitive.cpp fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.h fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 
>   indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 
>   indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 
> 
> Diff: http://codereview.secondlife.com/r/100/diff
> 
> 
> Testing
> ---
> 
> Compiled (standalone, 64bit Linux) with and without LL_TESTS.
> Started the viewer, logged in, walked and flew around a bit. Everything seems 
> to work.
> 
> 
> Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in 
> indra/llui/tests/llurlentry_stub.cpp and 
> indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually 
> are never dereferenced, even when not NULL, so that using NULL pointers 
> instead of place holder data won't change what code paths gets tested. Both 
> tests binaries executed without crashes and all the contained tests passed.
> 
> Locally invoked start_messaging_system() with b_dump_prehash_file == true 
> instead of FALSE, to see what would be generated after my change to 
> dump_prehash_files().
> The message_prehash.(h|cpp) generated by that had the correct type qualifiers 
> and formatting, but some lines were removed or added compared to the modified 
> files from the source tree. That probably means that the files aren't fully 
> synchronized with the message template file in the source tree. Because the 
> "added" constants are spread all over the file, while the "removed" ones were 
> at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree 
> are actually more up-to-date than the message template file in the source 
> tree.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: make PREHASH variables char const* const

2011-01-24 Thread Kent Quirk


> On Jan. 24, 2011, 6:42 a.m., Oz Linden wrote:
> > If the file is generated, what is it doing checked into the source tree at 
> > all?  This sounds to me like an invitation to future errors.
> > 
> > Is there some reason why we should not just delete the checked in version 
> > and have it generated every time it's needed?

These files were generated, but the generation is a manual process and needs to 
take place on both the server and the viewer to ensure compatibility because 
this is part of a protocol definition. This is an area where we could end up 
breaking compatibility if we're not very careful, so please make only the 
changes needed to make it compile and make no semantic changes.


- Kent


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


On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/100/
> ---
> 
> (Updated Jan. 22, 2011, 7:40 a.m.)
> 
> 
> Review request for Viewer and Seth ProductEngine.
> 
> 
> Summary
> ---
> 
> For the reason for this change, see 
> https://jira.secondlife.com/browse/VWR-24487 and 
> https://jira.secondlife.com/browse/VWR-24522
> 
> What I did:
> In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant 
> pointers to constants by search/replace. Then I tried to compile and added 
> const qualifiers in dependent code as needed to stop the compiler complaining.
> 
> Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files 
> have been generated from the message template. Because this generation might 
> not have been a one-off thing, I changed the generating code, too, so it 
> won't override this change here when the generation happens the next time. 
> However, that part of the code is not called by Viewer, although the relevant 
> function — dump_prehash_files() — ends up in the Viewer binary. That function 
> probably gets called by the simulator, when one runs the latter with 
> -prehash. (See 
> https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532
>  )
> 
> 
> This addresses bug VWR-24487.
> http://jira.secondlife.com/browse/VWR-24487
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt fc7e5dcf3059 
>   indra/llmessage/message.cpp fc7e5dcf3059 
>   indra/llmessage/message_prehash.h fc7e5dcf3059 
>   indra/llmessage/message_prehash.cpp fc7e5dcf3059 
>   indra/llprimitive/llprimitive.h fc7e5dcf3059 
>   indra/llprimitive/llprimitive.cpp fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.h fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 
>   indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 
>   indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 
> 
> Diff: http://codereview.secondlife.com/r/100/diff
> 
> 
> Testing
> ---
> 
> Compiled (standalone, 64bit Linux) with and without LL_TESTS.
> Started the viewer, logged in, walked and flew around a bit. Everything seems 
> to work.
> 
> 
> Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in 
> indra/llui/tests/llurlentry_stub.cpp and 
> indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually 
> are never dereferenced, even when not NULL, so that using NULL pointers 
> instead of place holder data won't change what code paths gets tested. Both 
> tests binaries executed without crashes and all the contained tests passed.
> 
> Locally invoked start_messaging_system() with b_dump_prehash_file == true 
> instead of FALSE, to see what would be generated after my change to 
> dump_prehash_files().
> The message_prehash.(h|cpp) generated by that had the correct type qualifiers 
> and formatting, but some lines were removed or added compared to the modified 
> files from the source tree. That probably means that the files aren't fully 
> synchronized with the message template file in the source tree. Because the 
> "added" constants are spread all over the file, while the "removed" ones were 
> at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree 
> are actually more up-to-date than the message template file in the source 
> tree.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] building on Mac OS X 10.6 is giving me multiple headaches... anyone able to help?

2011-01-24 Thread Arrehn Oberlander
Here's some example lines I use for building firestorm on macosx.
You'll want to change the variables,strings,and optimizations to fit
Dolphin. I hope this helps. A key takeaway is to use "xcodebuild" for
command line builds and not make.



./develop.py -t $BTYPE configure -DPACKAGE:BOOL=ON
-DVIEWER_CHANNEL:STRING=Firestorm-$CHANNEL
-DVIEWER_LOGIN_CHANNEL:STRING=Firestorm-$CHANNEL


# LL build wants this directory to exist, but doesn't make it itself.

mkdir -p ./build-darwin-i386/newview/Release/Firestorm.app



xcodebuild -project build-darwin-i386/SecondLife.xcodeproj \

 -alltargets -configuration $BTYPE GCC_VERSION=4.2 \

 -sdk macosx10.5 GCC_OPTIMIZATION_LEVEL=3 ARCHS=i386 \

GCC_ENABLE_SSE3_EXTENSIONS=YES



On Mon, Jan 24, 2011 at 4:29 AM, Lance Corrimal
wrote:

> Hi there,
>
> I'm trying to build 2.4.x based on Mac OS X and I'm having several problems
> with that...
>
>
> - I'm pretty sure that I've located every place in the source that defines
> the
> name of the resulting .app and changed them to read "Dolphin Viewer 2.app"
> instead of "Second Life.app" and yet, the build process still tries to
> install
> some of the resulting stuff in Second Life.app and some in Dolphin Viewer
> 2.app, and at that point only Second Life.app exists so the build fails.
>
> -how do i configure the build on mac os to use GCC 4.0 instead of 4.2 If i
> want to build using unix makefiles instead of the xcode gui?
>
> - how do i configure the build process to builds against the 10.5 SDK
> instead
> of the 10.6 SDK when using unix makefiles instead of xcode gui?
>
>
>
> anyone got hints for me?
>
>
>
> bye,
> LC
> ___
> 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] Review Request: make PREHASH variables char const* const

2011-01-24 Thread Oz Linden

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


Given that Boroondas reports that the message.cpp in the viewer source tree 
does not produce the same generated file as what we have checked in, and Q's 
comment that this shared code, should we remove the message.cpp from this tree 
and just use the generated file?  Would that break tests?

It seems axiomatic to me that there should only be one source for this - if the 
authoritative one is the one in the simulator sources, that's fine, but there 
should only be one.

I don't like the idea of making changes (however good they are, and I agree 
that the new declarations are cleaner) that are not in sync with the server 
side.

- Oz


On Jan. 22, 2011, 7:40 a.m., Boroondas Gupte wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/100/
> ---
> 
> (Updated Jan. 22, 2011, 7:40 a.m.)
> 
> 
> Review request for Viewer and Seth ProductEngine.
> 
> 
> Summary
> ---
> 
> For the reason for this change, see 
> https://jira.secondlife.com/browse/VWR-24487 and 
> https://jira.secondlife.com/browse/VWR-24522
> 
> What I did:
> In indra/llmessage/message_prehash.(h|cpp), I turned everything into constant 
> pointers to constants by search/replace. Then I tried to compile and added 
> const qualifiers in dependent code as needed to stop the compiler complaining.
> 
> Note that comments in indra/llmessage/message_prehash.(h|cpp) say these files 
> have been generated from the message template. Because this generation might 
> not have been a one-off thing, I changed the generating code, too, so it 
> won't override this change here when the generation happens the next time. 
> However, that part of the code is not called by Viewer, although the relevant 
> function — dump_prehash_files() — ends up in the Viewer binary. That function 
> probably gets called by the simulator, when one runs the latter with 
> -prehash. (See 
> https://bitbucket.org/lindenlab/viewer-development/src/fc7e5dcf3059/indra/llmessage/message.cpp#cl-2532
>  )
> 
> 
> This addresses bug VWR-24487.
> http://jira.secondlife.com/browse/VWR-24487
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt fc7e5dcf3059 
>   indra/llmessage/message.cpp fc7e5dcf3059 
>   indra/llmessage/message_prehash.h fc7e5dcf3059 
>   indra/llmessage/message_prehash.cpp fc7e5dcf3059 
>   indra/llprimitive/llprimitive.h fc7e5dcf3059 
>   indra/llprimitive/llprimitive.cpp fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.h fc7e5dcf3059 
>   indra/llprimitive/llvolumemessage.cpp fc7e5dcf3059 
>   indra/llui/tests/llurlentry_stub.cpp fc7e5dcf3059 
>   indra/newview/tests/llremoteparcelrequest_test.cpp fc7e5dcf3059 
> 
> Diff: http://codereview.secondlife.com/r/100/diff
> 
> 
> Testing
> ---
> 
> Compiled (standalone, 64bit Linux) with and without LL_TESTS.
> Started the viewer, logged in, walked and flew around a bit. Everything seems 
> to work.
> 
> 
> Locally set _PREHASH_AgentData and _PREHASH_AgentID to (char const*)0x1 in 
> indra/llui/tests/llurlentry_stub.cpp and 
> indra/newview/tests/llremoteparcelrequest_test.cpp to verify they actually 
> are never dereferenced, even when not NULL, so that using NULL pointers 
> instead of place holder data won't change what code paths gets tested. Both 
> tests binaries executed without crashes and all the contained tests passed.
> 
> Locally invoked start_messaging_system() with b_dump_prehash_file == true 
> instead of FALSE, to see what would be generated after my change to 
> dump_prehash_files().
> The message_prehash.(h|cpp) generated by that had the correct type qualifiers 
> and formatting, but some lines were removed or added compared to the modified 
> files from the source tree. That probably means that the files aren't fully 
> synchronized with the message template file in the source tree. Because the 
> "added" constants are spread all over the file, while the "removed" ones were 
> at the end, I'd wager that message_prehash.(h|cpp) in the viewer source tree 
> are actually more up-to-date than the message template file in the source 
> tree.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] from debug to prefences

2011-01-24 Thread Jonathan Welch
There are approximately 1,100 entries in settings.xml, which is the
list you see in the Debug Settings floater (perhaps it should be
renamed to just Settings).  I don't see any practical way of having
all those available in any kind of sane preferences menu system.

It would be good to generate a list of entries that are in there and
never used by the code.  Those could be eliminated without much
discussion.

You can find a pretty recent list here
http://wiki.secondlife.com/wiki/Debug_Settings
___
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] Feature Request - feet option

2011-01-24 Thread Cristy Husbands
As a user and builder I would like to be able to build without having to pull 
out measuring tapes or my calculater to get accurate "foot" measurement to keep 
things to a realistic size.  I would love for their to be an option in the 
build 
tool to translate the meters to feet.  Just have a little drop down that says 
use "feet" measurement.I noticed that the library contains examples of 
avatar height, doors, ceilings, all this would be unneeded if we could 
translate 
the measurement by feet.

Thank you

 "Anything worth doing, is worth doing well"
___
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] Daily Scrum Summary - Friday, January 21

2011-01-24 Thread Anya Kanevsky
 Whoa, sorry. Better late than never.

Friday, January 21, 2011 General Notes
--

   - MMOTD: Oz
   - Please remember to put descriptions next to the jira number in your
   report when possible.

Team Status
--
 Merov Linden
--

*PAST*

   - STORM-745 : KDU Perf : Redone the plan so to gather consistent data
   (see JIRA). Ran it for Mac. Will run for Windows and Linux Monday.
   - SH-761 and others: merge test, fail, discussing with shining how best
   to get that in viewer-development
   - Code reviews: trying to reduce my backlog here and get JIRAs to move
   along sprint 10

*FUTURE*

   - SH-761, etc : get a clear merge list from shining
   - STORM-748 : Fix TC builds
   - STORM-745 : waiting pattern till Monday

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - Merge Monkey
   - Patch triage from codereview
   - Enhanced contribution stats script
  - tolerates reordered lines in contributions.txt
  - counts files & lines touched

*FUTURE*

   - Merge Monkey
   - More code reviews
   - STORM-312

*IMPEDIMENTS*

   - none

 Q Linden
--

*PAST*

   - Passed off VWR-24426 to Oz
   - Internal meetings
   - Dr Appts
   - triage
   - 2.5 beta 1 blog post and monitoring
   - Planning trip to SF

*FUTURE*

   - Meetings
   - 2.5 beta 2 review

*IMPEDIMENTS*

   - none

Esbee Linden
--

*PAST*

   - Jira ticket reviews and cleanup
   - Finished reviewing tickets assigned to Esbee Linden
   - Finished reviewing tickets assigned to Snowstorm Team
   - Completed last PO review (approved a bunch of tickets)
   - Wrote goodbye email to fellow Lindens

FUTURE

   - Go back to being a Resi

IMPEDIMENTS

   - Goodbye, friends. I love you, Snowstormers.

*FUTURE*

   - Review Snowstorm Team product backlog and bug log
   - Tix which require feedback: STORM-28, -812, -226, -174
   - Review developer build for the tix in the PO review queue:

STORM-2, -383, -484, -844, -834, -832, -715
https://jira.secondlife.com/secure/IssueNavigator.jspa?requestId=13662&mode=hide

   - Hopefully work on STORM-26 w/Q
   - Review tickets assigned to me

*IMPEDIMENTS*

   - None


Paul ProductEngine
--

*PAST*

   - BUG STORM-680 (Avaline callers are added to the Recent list)
  - Worked on this bug, but it'll take much more time to fix it without
  debugger. For some reason voice is unavailable in debug mode (in
Linux). As
  tomorrow I'll install Windows on my machine, in which voice is working in
  debug mode, I'll fix it.
   - BUG STORM-513 ("Allow media to auto - play" check-box is enable after
   Media check-box was unchecked)
  - WIP. 90%. Estimate ~ 1 hour.

*FUTURE*

   - Install Windows 7 on my machine as second OS.
   - BUG STORM-513 ("Allow media to auto - play" check-box is enable after
   Media check-box was unchecked)
   - BUG STORM-680 (Avaline callers are added to the Recent list)

*IMPEDIMENTS*

   - none

Seth Productengine
--

*PAST*

   - BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
   Name/System Folders to Top Do not apply and settings changes do not persist
   after relogging.
  - Investigating problems and suggestions given in latest comments.
  Asked questions to product owner in jira.

*FUTURE*

   - Story (STORM-526) Log out failure during Login causes loss of pending
   offers, including inventory

*IMPEDIMENTS*

   - BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
   Name/System Folders to Top Do not apply and settings changes do not persist
   after relogging.
  - Waiting for product owner answers.

Vadim Productengine
--

*PAST*

   - Resolved as not reproducible:
  - Bug STORM-371 (One instance of Viewer is crashed while restarting if
  language was changed in one of two running viewer's instance).
  - Bug STORM-345 (Landmark's overflow list appears after deleting a
  Landmark from the Favorites Bar).
  - Bug STORM-534 (Number of characters that can be typed in Nearby Chat
  is less than 1024 characters).
  - Bug STORM-633 (Objects are displayed in the Texture Picker while
  inventory items are loaded from server).


   - Bug STORM-513 ("Allow media to auto - play" check-box is enable after
   Media check-box was unchecked):
  - Reverted Paul's fix per Andrey's request.
   - Bug STORM-600 ("My name", "Group titles" checkboxes should be disabled
   if Name tags are off):
  - 
Resolved as "Won't finish" per Andrey's suggestion.
   - Bug STORM-465 (Missing Strings from strings.xml):
  - 
Submitted fix.

*FUTURE*

   - Work on bugs from the bug queue.

*IMPEDIMENTS*

   - none

Andrey ProductEngine
--

*PAST*

   - proceeded with v-d regression testing
   - verified bunch of CannotRepro tickets
   - review

Re: [opensource-dev] google-breakpad VS2010 build project. Linden Dev Help Please.

2011-01-24 Thread Brad Kittenbrink (Brad Linden)
On Fri, Jan 21, 2011 at 6:40 PM, Nicky Perian  wrote:

> I am trying to prove a no harm done 2005 build first. Then on to 2010.
> the build-cmd.sh script references "build_sln" for several entries.
> Example: build_sln src/client/windows/breakpad_client.sln "release|win32"
> exception_handler
>
> These all fail when I try them. Is build_sln common to the LL build system
> and not included in 3p-google-breakpad source?
>
> The sln files build with  cd src/client/windows
> ../../tools/gyp/gyp -G msvs_version=2005
>
> Is this just and automation thingy?
> Can I just build with debug and release or do I need build_sln's magic?
> Nicky
>
>

Yes, it's for automation.   The shell function build_sln is part of our new
third party lib build system which we're starting to document here:
http://wiki.secondlife.com/wiki/Autobuild and here:
http://wiki.secondlife.com/wiki/Autobuild_How_To

You're a bit ahead of the curve, and we haven't quite kicked all of this off
with great fanfare just yet.  But thanks for diving in fearlessly :)

If you want to run the build, in theory you should just need to check out
our autobuild repository , put its
bin directory in your PATH, and run 'autobuild install && autobuild build &&
autobuild package'

Anyways, in addition to that, a simple substitute definition for the
function is as follows:
build_sln() {
local solution=$1
local config=$2
local proj=$3

if [ -z "$proj" ] ; then
devenv.com "$(cygpath -m "$solution")" /build "$config"
else
devenv.com "$(cygpath -m "$solution")" /build "$config" /project
"$proj"
fi
}

-Brad
___
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] Anyone playing with Android and Second Life?

2011-01-24 Thread Opensource Obscure
For the record there's an update, as the previously mentioned
Android viewer is now back in the TPV Directory.

(as already explained -see quote below- this doesn't *guarantee*
anything by itself, but it's encouraging).

Opensource Obscure


On Wed, Dec 29, 2010 at 18:04, Brian McGroarty  wrote:
> On Tue, Dec 28, 2010 at 8:05 AM, Tateru Nino  wrote:
>>
>> On 29/12/2010 2:57 AM, Robin Cornelius wrote:
>> > On Tue, Dec 28, 2010 at 3:55 PM, Robin Cornelius
>> >   wrote:
>> >
>> >   v1.13.852
>> > * the whole login process is now handled by the mobile device itself,
>> > from now on no passwords nor their hashes are transfered to our
>> > servers.
>> >
>> > So that avoids 2.e
>> I'd be more concerned about capabilities URIs, myself. The login
>> credentials are only the front-gate.
>
> Ultimately, there's a big risk in using any third-party viewer. Getting the
> initial authentication off of the third-party server narrows scope a bit. It
> removes credentials that could have been used for real currency cash outs,
> makes compromise of the third-party authentication server a less severe
> problem, and improves governance's chances of slowing down bad actors
> without having to take down a whole service. But, in no way do we intend it
> as a safeguard against a malicious TPV dev.
> --
> Brian McGroarty | Linden Lab
> Sent from my Newton MP2100 via acoustic coupler
___
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] from debug to prefences

2011-01-24 Thread Nyx Linden
Also keep in mind most debug preferences were written by coders who want 
to provide the functionality to debug features and provide QA with the 
tools to test features. The debug options themselves often are not 
formalized / well tested / well supported.

This would be providing more formal support for untested features. 
Certainly there's an argument that some specific options have been 
around long enough and are stable enough that they should be upgraded to 
supported options. We've moved a few of these into the advanced and 
develop menus.

There are multiple classes of debug options here: some that are stable 
and would do better with bigger visibility, some that are incredibly 
useful but require more debugging and QA time to be upgraded, and some 
that probably aren't useful enough to justify the effort.

  -Nyx

On 01/24/2011 01:05 PM, Jonathan Welch wrote:
> There are approximately 1,100 entries in settings.xml, which is the
> list you see in the Debug Settings floater (perhaps it should be
> renamed to just Settings).  I don't see any practical way of having
> all those available in any kind of sane preferences menu system.
>
> It would be good to generate a list of entries that are in there and
> never used by the code.  Those could be eliminated without much
> discussion.
>
> You can find a pretty recent list here
> http://wiki.secondlife.com/wiki/Debug_Settings
> ___
> 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] from debug to prefences

2011-01-24 Thread Trilo Byte
Perhaps the experimental/developer-related debug settings should be accessible 
from the Developer menu (further removing it from casual users).  Then an 
'Advanced Preferences' floater could be made available from the Advanced Menu.  
This would allow for an effort to seriously streamline the main/basic SL 
preferences.  

Net result (other than lots of people complaining about changes lol) would be 
that candy-coating prefs could seriously reduce the learning curve for new 
residents and the 'casual gamer' crowd, as well as provide an improved 
experience for power users.

If it gets done, I propose that the existing preference and debug menu still be 
made available as some sort of 'legacy' option.  Quite a few residents already 
seem to feel there have been far too many sweeping UI changes to the Viewer, 
forcing them into another set without giving them the option to continue with 
the existing controls would only cause more dissension.

On Jan 24, 2011, at 12:42 PM, Nyx Linden wrote:

> Also keep in mind most debug preferences were written by coders who want 
> to provide the functionality to debug features and provide QA with the 
> tools to test features. The debug options themselves often are not 
> formalized / well tested / well supported.
> 
> This would be providing more formal support for untested features. 
> Certainly there's an argument that some specific options have been 
> around long enough and are stable enough that they should be upgraded to 
> supported options. We've moved a few of these into the advanced and 
> develop menus.
> 
> There are multiple classes of debug options here: some that are stable 
> and would do better with bigger visibility, some that are incredibly 
> useful but require more debugging and QA time to be upgraded, and some 
> that probably aren't useful enough to justify the effort.
> 
>  -Nyx
> 
> On 01/24/2011 01:05 PM, Jonathan Welch wrote:
>> There are approximately 1,100 entries in settings.xml, which is the
>> list you see in the Debug Settings floater (perhaps it should be
>> renamed to just Settings).  I don't see any practical way of having
>> all those available in any kind of sane preferences menu system.
>> 
>> It would be good to generate a list of entries that are in there and
>> never used by the code.  Those could be eliminated without much
>> discussion.
>> 
>> You can find a pretty recent list here
>> http://wiki.secondlife.com/wiki/Debug_Settings
>> ___
>> 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

___
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] from debug to prefences

2011-01-24 Thread Robert Martin
On Mon, Jan 24, 2011 at 7:53 PM, Trilo Byte  wrote:
> Perhaps the experimental/developer-related debug settings should be 
> accessible from the Developer menu (further removing it from casual users).  
> Then an 'Advanced Preferences' floater could be made available from the 
> Advanced Menu.  This would allow for an effort to seriously streamline the 
> main/basic SL preferences.

what needs to happen is a full bore IRS level accounting needs to be
done on which preferences are actually used and which are
outdated 2.* series prefs (pull these out)
outdated 1.* series prefs (pull these out)
oddball but still used prefs
dangerous prefs
normal and menu accessable prefs
power user prefs
nonlinden admin prefs
Linden Only Prefs
TPV prefs that slipped into the stock viewer (was the feature added to stock??)

and then sit down and document what each one of those does (and
safe/dangerous values for same)

-- 
Robert L Martin
* note categories should be adjusted as needed
___
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] STORM-2 test build

2011-01-24 Thread Philippe (Merov) Bossut
Hi,

Oz build binaries for this project (STORM-2 : As a User, I want to set my
own default views with specific UI layout so I can tailor my Viewer
experience to the activities I'm most interested in).

They are available here:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-3/rev/219546/index.html

Cheers,
- Merov
___
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] Rendering bug with 2.5 and 2.6

2011-01-24 Thread Erin Mallory

https://jira.secondlife.com/browse/VWR-24605 was reported to me and I am able 
to repo it with every 2.5 and 2.6 version i have.   I however cannot repo it 
with 2.4. I suspect it was introduced fairly early on in 2.5.  Im kicking 
myself because i didn't notice this until it was brought to my attention.  
however, now that it has, its now something that's become hard for me not to 
notice.   
  ___
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] STORM-643

2011-01-24 Thread Twisted Laws

Added a patch to https://jira.secondlife.com/browse/STORM-643 Embed Minimap 
into Nearby list of People Sidebar.   I know I never make the meetings that 
would probably help determine if this would be included in the viewer, but it 
does help make viewer 2 just a little better than it was in my opinion.  
Additionally, selecting a user in the nearby avatar list will highlight the 
avatar on the minimap.  The patch also corrects an error I don't see in the 
Jira where the minimap hovertip is incorrect if double click teleport is 
enabled. 
 
I hope you find the patch useful.
  ___
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] VWR-3156

2011-01-24 Thread Erin Mallory

VWR-3156 has over 200 votes.  Its asking for the return of the pre-2007 
bandwidth and packetloss quick-glance bars to the viewer toolbars, possibly 
beside search. personally, if there's a need for those, I usually go to the 
stats bar, but there are some compelling arguments in the comments for bringing 
back such a feature, and I myself am wondering if it might prove useful myself 
and other users as well. 

  ___
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] Daily Scrum Summary - Monday, January 24

2011-01-24 Thread Anya Kanevsky
Monday, January 24, 2011 General Notes
--

   - MMOTD: Oz
   - Please remember to put descriptions next to the jira number in your
   report when possible.

Team Status
--
 Merov Linden
--

*PAST*

   - STORM-748 : Fixed TC builds, added KDU_X86_INTRINSICS to Mac and
   Windows builds. Linux already built with that by default. On Mac, no perf
   difference though. Need to measure on Windows.
   - Code reviews: more of this, only 2 (long ones) left to review...

*FUTURE*

   - SH-761, etc : get a clear merge list from shining
   - STORM-745 : Perf baseline : complete the plan as I wrote it
   - STORM-748 : Build with KDU_X86_INTRINSICS: build on Windows, measure
   perf

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - Merge Monkey
   - Patch triage from codereview
   - Updates to Third Party Viewer Directory
   - STORM-312

*FUTURE*

   - Merge Monkey
   - More code reviews
   - STORM-312

*IMPEDIMENTS*

   - none

Q Linden
--

*PAST*

   - Planning trip to SF
   - Planning meetings and presentations in SF

*FUTURE*

   - Between travel and OOO time, will not be available tomorrow at all.
   - Will not attend tomorrow's scrum or other meetings.

*IMPEDIMENTS*

   - none; see you Wed.

Paul ProductEngine
--

*PAST*

   - BUG STORM-513 ("Allow media to auto - play" check-box is enable after
   Media check-box was unchecked)
  - Fixed. Will correct some issue according to Vadim's commentaries and
  send for review. Estimate ~ 10 minutes.
   - Installed Windows 7 on my machine. Finished installing and configuring
   all needed software for SL in VS 2005. Built and ran it. Unfortunately it
   took more time than i expected.
   - Almost finished with configuring in Ubuntu. Estimate ~ 1 hour.

*FUTURE*

   - Finish configuring SL in Ubuntu
   - BUG STORM-513 ("Allow media to auto - play" check-box is enable after
   Media check-box was unchecked)
   - Other tickets by priority

*IMPEDIMENTS*

   - none

Seth Productengine
--

*PAST*

   - Story (STORM-526) Log out failure during Login causes loss of pending
   offers, including inventory
  - Found possible reason for inventory loss, described it in jira.
  Deferring work on this issue until I have some ideas on how to confirm my
  assumptions and ways to fix the issue.

*FUTURE*

   - BUG (STORM-843) Inventory incremental string search not working (search
   starts over)

*IMPEDIMENTS*

   - BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
   Name/System Folders to Top Do not apply and settings changes do not persist
   after relogging.
  - Waiting for product owner answers.

Vadim Productengine
--

*PAST*

   - Assisted Paul with setting up Windows dev environment.
   - Bug STORM-610 (Changes to Environment Editor: water color change is not
   saved): WIP.

*FUTURE*

   - Fix STORM-610.
   - Other bugs.

*IMPEDIMENTS*

   - Need PO answer in STORM-2 (Customizable viewer layouts).

Andrey ProductEngine
--

*PAST*

   - corrected Inspectors, My Inventory, and Object Profile test plans. See
   "TPEQA Test Plans" shared folder
   - integrated tickets verification
   - proceeded with regression testing of v-d r219350 build

*FUTURE*

   - pickup 2.5.0 Beta2 build?
   - continue reviewing of SideBar test plans, we have no a good one for My
   Landmarks and Create/View/Edit Landmarks

*IMPEDIMENTS*

   - none

Jonathan Yap
--

*PAST*

   - STORM-845 (Up arrow icon on nearby chat for "Shows/hides nearby chat
   log" always shows as an up arrow. Should change to down arrow to indicate
   close when log is open

*FUTURE*

   - STORM - 845

*IMPEDIMENTS*

   - None

Cummere Mayo
--

*PAST*

   - pretriage vwr patches
   - rechecked a couple of snow issues
   - design sketches
   - tested the storm-236 test build.

*FUTURE*

   - viewer testing for develper, developement, and firestorm
   - more jira organization/cleanup
   - some feature requests i want to do
   - some feature requests i want to update

*IMPEDIMENTS*

   - exahausted
   - rl work
   - other commitments
   -
___
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