From jhwelch at gmail.com Wed Dec 1 04:46:22 2010 From: jhwelch at gmail.com (Jonathan Welch) Date: Wed, 1 Dec 2010 07:46:22 -0500 Subject: [opensource-dev] Comments wanted - (Un)docking sidebar tabs/sidebar opens closes Message-ID: Good morning-- Have you been using those new tear off sidebar tabs? I have, and when I redock one I find it disturbing that the sidebar leaps out and then has to be manually closed. The converse of this is when the sidebar is open and you tear off a tab and the sidebar closes. Here is a jira on my proposal to stop this from happening: https://jira.secondlife.com/browse/VWR-24008 There may be a number of different opinions on what one would like to see happen in this case, so your comment would be very much appreciated. From sldev at catznip.com Wed Dec 1 06:46:08 2010 From: sldev at catznip.com (Kitty) Date: Wed, 1 Dec 2010 15:46:08 +0100 Subject: [opensource-dev] Autoupdater Flashback In-Reply-To: References: Message-ID: <000301cb9166$89097060$9b1c5120$@com> Would it be possible to get the protocol specification for the updater service on the server-side? It's always possible to work backwards from the code in the viewer, but it would be handy to just have an overview of the viewer<->web service exchanges :). Kitty From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Brad Kittenbrink (Brad Linden) Sent: dinsdag 30 november 2010 22:34 To: Bunny Halberd Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Autoupdater Flashback Oops, thanks for the heads-up. The background updater is new in viewer 2.4 (as it's not released in beta yet, it doesn't have release notes yet, so sorry for the surprise). Yesterday we deployed the server side work in preparation for the beginning of the 2.4 beta releases, and it turned on. Unfortunately we hadn't been paying attention to the Second Life Development channel, and there was some obsolete data in the database. Anyways, thanks again for testing this for us. We should be getting it fixed shortly. -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101201/d4920bd7/attachment.htm From akanevsky at productengine.com Wed Dec 1 11:33:57 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 1 Dec 2010 13:33:57 -0600 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, December 1 Message-ID: Wednesday, December 1, 2010 General Notes ------------------------------ - FEEL BETTER ESBEEEEE! - Merge Monkey of the Day: Oz - IMPORTANT: When reopening issues from prior sprints, please move into unscheduled (remove Sprint X) and comment that it was reopnened. Reopnened current sprint issues should stay in current sprint. - if it?s intended for Beta, please make sure it?s in a beta branch and builds in TC _before_ you ask for a merge. - 2 new fields in jira: Target viewer version - set to indicate which branch should go (beta or dev) - PE - if there?s any chance it will go to beta (bug fixes), please branch from beta. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-151: kdu compression: A day of experiments: produced my first jp2 images, read more example code, understood some of the arcane stuff in jp2. I'm testing few different options and flags. All local test code though. - Hold OH *FUTURE* - STORM-151: kdu compression: Move to implementing compression code into viewer code. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Realized that the codereview system doesn't have enough disk space, researched how to resize it - Worked on clarifying rules for use of the Map API javascript code (WEB-1560) - Prepped some documentation for codereview usage - Commented on a bunch of Jonathan?s issues (need Esbee for most) - Finally got access to S3 resources I needed... *FUTURE* - Resize codereview file system - Post test review - Announce/Open code review system - Document code review system on wiki - Merge Monkeying *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Office hour - Beta announce - Builds - Meetings *FUTURE* - Beta 2.4 - meetings - Merge meeting *IMPEDIMENTS* - none Esbee Linden ------------------------------ - OOO - sick Paul ProductEngine ------------------------------ *PAST* - STORM - 696 (Event Details floater doesn't follow opacity settings) - Fixed & sent to bitbucket - STORM - 697 (Nearby Chat window is semitransparent even if inactive opacity is 1) - Fixed & sent to the bitbucket - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - WIP. Estimate ~ 12 hours *FUTURE* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - BUG (STORM-667) Nametag barely readable due to poor contrast - Fixed. - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - Implemented according to Esbee's latest comments. Not pushing until the fix for STORM-667 is merged to avoid conflicts. *FUTURE* - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - BUG (STORM-378) Snapshot animation should be played when snapshot is actually taken, not sent - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Critical bug STORM-527 (Jumping Halts Strafing Movement). - Investigated further. Made sure it's server-side, left comment in ticket about this and unassigned. - Major bug STORM-673 (duplicated XUI ID: error basename="panel_preferences_privacy.xml" message="Duplicate node exists: id=cache_size_label_l"). - Fixed and put on review. - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Investigated. Discussed with Vadim and Plan. Asked questions in ticket. Rough estimate- 3 days. *FUTURE* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). *IMPEDIMENTS* - STORM-34 - question in jira - STORM-527 needs a new home Vadim Productengine ------------------------------ *PAST* - Task STORM-686 (Transparency settings aren't applied to the map preview inside Map floater): - Tried fixing but failed (due to lack of OpenGL knowledge) and unassigned. - Re-fixed STORM-676 and STORM-677 (opacity of texture/color pickers) according to feedback from Q, but my fix seems to break STORM-697 (nearby chat opacity). Investigating. *FUTURE* - STORM-676 and STORM-677. *IMPEDIMENTS* - none Andrey Productengine ------------------------------ *PAST* - picked up Beta1 2.4.0 r215641 build - re-run smoke & integrity tests against this build - proceed with 2.4.0 bugfixes verification (+re-run previously deferred tickets) *FUTURE* - r215641 regression testing - bugfixes verification *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - Email to Esbee - list of things I would like to take up in the next scrum. As these are changes they need to be considered in advance. - Send daily email to dev mailing list - soliciting comments. *FUTURE* - Daily email to dev mailing list. - Looking into other issues & ideas. - [long range] - Update lsl wiki - remove Unsupported icon next to llTextBox. Timing of when to make this edit? *IMPEDIMENTS* - none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101201/4dd4a4e8/attachment-0001.htm From trilobyte550m at gmail.com Wed Dec 1 17:02:25 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 1 Dec 2010 17:02:25 -0800 Subject: [opensource-dev] Autoupdater Flashback In-Reply-To: References: Message-ID: <3F21DF60-7BB4-4E9D-B586-B6517CB05467@gmail.com> Is there any chance we can get a build that doesn't serve AutoUpdater Errors when you launch the app, or is that all server side? TriloByte Zanzibar On Nov 30, 2010, at 1:34 PM, Brad Kittenbrink (Brad Linden) wrote: > Oops, thanks for the heads-up. > > The background updater is new in viewer 2.4 (as it's not released in beta yet, it doesn't have release notes yet, so sorry for the surprise). Yesterday we deployed the server side work in preparation for the beginning of the 2.4 beta releases, and it turned on. Unfortunately we hadn't been paying attention to the Second Life Development channel, and there was some obsolete data in the database. > > Anyways, thanks again for testing this for us. We should be getting it fixed shortly. > > -Brad > > On Mon, Nov 29, 2010 at 7:42 PM, Bunny Halberd wrote: > Hey Guys - > > So, when I got home from work I grabbed whatever the current Snowstorm > build at the time is to use for the evening. (Build 215642 today.) > Shortly after logging in I see that a new version of SL has been > downloaded and will be installed on the next restart... thought that > was weird since I'd never seen that message before. > > When I restarted the SL Viewer a console window opened up and a new > version of the viewer was installed. Version: > > - Second Life 2.1.2 (209456) Sep 13 2010 16:05:27 (Second Life Development) > > Which is much older than 215642. :) > > So yay! The autoupdater works! Except, uh, it's handing out a really > old version! :) > > - Bunny > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101201/033956af/attachment.htm From oz at lindenlab.com Wed Dec 1 19:57:24 2010 From: oz at lindenlab.com (Oz Linden) Date: Thu, 02 Dec 2010 03:57:24 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) Message-ID: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/ ----------------------------------------------------------- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/94d64463/attachment.htm From oz at lindenlab.com Wed Dec 1 20:10:35 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 01 Dec 2010 23:10:35 -0500 Subject: [opensource-dev] Autoupdater Flashback In-Reply-To: <3F21DF60-7BB4-4E9D-B586-B6517CB05467@gmail.com> References: <3F21DF60-7BB4-4E9D-B586-B6517CB05467@gmail.com> Message-ID: <4CF71C3B.6070404@lindenlab.com> > Is there any chance we can get a build that doesn't serve AutoUpdater > Errors when you launch the app, or is that all server side? > That set of problems is the subject of quite a lot of attention. From wolfpup67 at earthlink.net Wed Dec 1 20:54:32 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 02 Dec 2010 04:54:32 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202045432.1539.30120@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review1 ----------------------------------------------------------- Ship it! testing new review system. code looks clean to me - Wolfpup 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/bda745ff/attachment.htm From zidonuke at gmail.com Wed Dec 1 20:55:55 2010 From: zidonuke at gmail.com (zidonuke at gmail.com) Date: Thu, 02 Dec 2010 04:55:55 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202045432.1539.30120@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202045432.1539.30120@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202045555.1489.72193@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-01 20:54:32, Wolfpup Lowenhar wrote: > > testing new review system. > > > > code looks clean to me Heh, commenting on his comment seems to work. - Zidonuke ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review1 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/37046b5f/attachment.htm From kf6kjg at gmail.com Wed Dec 1 21:26:11 2010 From: kf6kjg at gmail.com (Cron Stardust) Date: Thu, 02 Dec 2010 05:26:11 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202052611.2974.62488@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review4 ----------------------------------------------------------- Based on the logic of the removed break, line 1192 of the fixed file: idleTimer.getElapsedTimeF64() >= max_idle_time should be idleTimer.getElapsedTimeF64() < max_idle_time The variable "S32 pending;" is redeclared on line 1613 of the fixed file. The previous edition didn't have this issue due to scoping. Looks like the break on 4224 can't be easily removed: it's a tail test in a loop that seems to be required to be a head-test loop. Maybe the logic and purpose can be reanalyzed, but then this would be more than a refactor. - Cron 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/ed90e123/attachment-0001.htm From wolfpup67 at earthlink.net Wed Dec 1 21:42:19 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 02 Dec 2010 05:42:19 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202052611.2974.62488@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202052611.2974.62488@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202054219.1489.68095@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-01 21:26:12, Cron Stardust wrote: > > Based on the logic of the removed break, line 1192 of the fixed file: > > idleTimer.getElapsedTimeF64() >= max_idle_time > > should be > > idleTimer.getElapsedTimeF64() < max_idle_time > > > > The variable "S32 pending;" is redeclared on line 1613 of the fixed file. The previous edition didn't have this issue due to scoping. > > > > Looks like the break on 4224 can't be easily removed: it's a tail test in a loop that seems to be required to be a head-test loop. Maybe the logic and purpose can be reanalyzed, but then this would be more than a refactor. we are just testing here :p - Wolfpup ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review4 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/da9f2919/attachment.htm From kf6kjg at gmail.com Wed Dec 1 22:03:33 2010 From: kf6kjg at gmail.com (Cron Stardust) Date: Thu, 02 Dec 2010 06:03:33 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202052611.2974.62488@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202052611.2974.62488@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202060333.1553.98566@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-01 21:26:12, Cron Stardust wrote: > > Based on the logic of the removed break, line 1192 of the fixed file: > > idleTimer.getElapsedTimeF64() >= max_idle_time > > should be > > idleTimer.getElapsedTimeF64() < max_idle_time > > > > The variable "S32 pending;" is redeclared on line 1613 of the fixed file. The previous edition didn't have this issue due to scoping. > > > > Looks like the break on 4224 can't be easily removed: it's a tail test in a loop that seems to be required to be a head-test loop. Maybe the logic and purpose can be reanalyzed, but then this would be more than a refactor. > > Wolfpup Lowenhar wrote: > we are just testing here :p True, but reporting errors (and getting them fixed) is as much part of the test (IMHO) as everything else. :D - Cron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review4 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/869ea087/attachment.htm From open at autistici.org Thu Dec 2 01:03:58 2010 From: open at autistici.org (Opensource Obscure) Date: Thu, 02 Dec 2010 10:03:58 +0100 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <1148384dd96143c6ac6be1bb8e0bf05b@inventati.org> On Thu, 02 Dec 2010 03:57:24 -0000, "Oz Linden" wrote: > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/2/ > ----------------------------------------------------------- > > Review request for Viewer. > > > Summary > ------- > > This review is mostly a first test of reviewboard. I just want to point out (as a reminder to other list members) that the reviewboard is for code contributors only, that is "In order to post reviews or comment on them in this system, you must have executed a Contribution Agreement". I would assume that we non-contributors still can comment here in the mailing list, if appropriate. Opensource Obscure From oz at lindenlab.com Thu Dec 2 03:37:15 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 02 Dec 2010 06:37:15 -0500 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <1148384dd96143c6ac6be1bb8e0bf05b@inventati.org> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> <1148384dd96143c6ac6be1bb8e0bf05b@inventati.org> Message-ID: <4CF784EB.3050503@lindenlab.com> > > I just want to point out (as a reminder to other list members) > that the reviewboard is for code contributors only, that is > > "In order to post reviews or comment on them in this system, > you must have executed a Contribution Agreement". > > I would assume that we non-contributors still can comment > here in the mailing list, if appropriate. Or better yet, become contributors. From sllists at boroon.dasgupta.ch Thu Dec 2 04:41:47 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 02 Dec 2010 13:41:47 +0100 Subject: [opensource-dev] [META][WEB] Registering a SL Review Board account: Jira email address vs. mailing list address (was: Re: Review Request: Restructure loops that use breaks without need (reviewboard test)) In-Reply-To: References: Message-ID: <4CF7940B.9050801@boroon.dasgupta.ch> https://codereview.secondlife.com/account/register/ advises: > Use the email address that you have associated with that Jira account. However, as mails automatically generated from my actions on Review Board get sent to the mailing list, I now changed the address in my SL Review Board profile to my mailing list address, so that future messages won't get rejected. Cheers, Boroondas On 12/02/2010 12:40 PM, opensource-dev-owner at lists.secondlife.com wrote: > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > opensource-dev-owner at lists.secondlife.com. > > -------- Attached Email -------- > Subject: Re: Review Request: Restructure loops that use breaks > without need (reviewboard test) > Date: Thu, 02 Dec 2010 11:40:12 -0000 > From: Boroondas Gupte <*[The address I use for jira* (different from > the one I use for the mailing list and not intended for public > visibility)*]*> > To: Boroondas Gupte <*[...]*>, Oz Linden , Viewer > > > > > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/2/ > > > indra/newview/llappviewer.cpp > > (Diff revision 1) > bool LLAppViewer::mainLoop() > 1188 > S32 total_io_pending = 0; > 1188 > S32 total_io_pending = 0; > > While you're at it, please fix the whitespace errors in the touched (and nearby) code. (In a separate changeset, though, if possible) > > The Review-Board diff view conveniently highlights them in red, so they are hard to miss ;-) > > indra/newview/llappviewer.cpp > > (Diff revision 1) > bool LLAppViewer::mainLoop() > 1195 > work_pending += LLAppViewer::getTextureCache()->update(1); // unpauses the texture cache thread > 1199 > work_pending += LLAppViewer::getTextureCache()->update(1); // unpauses the texture cache thread > > e.g. here: spaces before tabs > > indra/newview/llappviewer.cpp > > (Diff revision 1) > bool LLAppViewer::cleanup() > 1624 > if(!pending) > 1623 > } while ( pending && idle_time < max_idle_time) > > Your change even introduces new whitespace errors (trailing whitespace here) > > - Boroondas > > > On December 1st, 2010, 7:57 p.m., Oz Linden wrote: > > Review request for Viewer. > By Oz Linden. > > /Updated 2010-12-01 19:57:24/ > > > Description > > 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. > > > Testing > > None at all... have not even compiled it yet. > > *Bugs: * storm-606 > > > Diffs > > * indra/newview/llappviewer.cpp (bf98b026bcb1) > > View Diff > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/4dfbc3d9/attachment-0001.htm From sllists at boroon.dasgupta.ch Thu Dec 2 04:52:10 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 02 Dec 2010 12:52:10 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202125210.1539.96210@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review10 ----------------------------------------------------------- indra/newview/llappviewer.cpp e.g. here, some lines are indented by spaces and others by tabs - Boroondas 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/ea0f1094/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 2 04:54:52 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 02 Dec 2010 12:54:52 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202125210.1539.96210@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202125210.1539.96210@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202125452.1485.28568@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-02 04:52:10, Boroondas Gupte wrote: > > EDITED TO ADD: (apparently Review Board can't handle comments on comments on lines (sic!) and new comments on lines at the same time) "The Review-Board diff view conveniently highlights them in red, so they are hard to miss ;-)" Of course, Review Board can't detect all whitespace mistakes: - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review10 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/04205e85/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 2 05:01:04 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 02 Dec 2010 13:01:04 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202125210.1539.96210@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202125210.1539.96210@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202130104.2974.11622@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-02 04:52:10, Boroondas Gupte wrote: > > > > Boroondas Gupte wrote: > EDITED TO ADD: (apparently Review Board can't handle comments on comments on lines (sic!) and new comments on lines at the same time) > "The Review-Board diff view conveniently highlights them in red, so they are hard to miss ;-)" > Of course, Review Board can't detect all whitespace mistakes: Ah, I guess I should have read http://www.reviewboard.org/docs/manual/1.5/users/reviews/reviewing-diffs/#reading-existing-comments , first: "It?s important to note that this is meant to be used as a reference to see if other people have already said what you plan to say. The comment box is not the place to reply to those comments. Instead, you can click the Reply link next to the particular comment, which will take you back to the review request page and open a reply box." - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/2/#review10 ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/2f99b9c9/attachment.htm From jhwelch at gmail.com Thu Dec 2 05:23:09 2010 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 2 Dec 2010 08:23:09 -0500 Subject: [opensource-dev] Registering a SL Review Board Message-ID: Will the email address we input during the registration process be visible at any point? From oz at lindenlab.com Thu Dec 2 05:41:15 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 02 Dec 2010 08:41:15 -0500 Subject: [opensource-dev] Registering a SL Review Board In-Reply-To: References: Message-ID: <4CF7A1FB.9030507@lindenlab.com> On 2010-12-02 8:23, Jonathan Welch wrote: > Will the email address we input during the registration process be > visible at any point? Yes, since the email that reviewboard sends about whatever you did will be the From address. If you prefer, you can use the email address that you use for the opensource list (I'd still suggest that you make both of those addresses the same, but the jira address can be changed too). My main concern is that the usernames be the same, so that if ReviewBoard actually does OpenId (it is on their backlog), then we can start using that. From oz at lindenlab.com Thu Dec 2 05:52:10 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 02 Dec 2010 08:52:10 -0500 Subject: [opensource-dev] ReviewBoard email to this list? Message-ID: <4CF7A48A.2090808@lindenlab.com> As you'll have inferred, we now have a system set up for doing open code reviews. It's not perfect, but it's pretty nice and very easy to use. It also generates quite a bit of email - one for each newly posted request, and one (properly threaded) for each comment or other action on that review. If I understand the capabilities correctly, the software allows each 'review group' to either: 1. Configure a single mailing list address for the group (of which at present we have only the one 'viewer' group) 2. Leave that address blank If a list address is configured, all emails for reviews in that group are sent to the list address. If it is left blank, then individual emails are sent to each of the members of the review group. I chose to configure the opensource-dev list as the mailing list, and the messages do get sent there (as From the user, so the address you configure for your account needs to match the one you use for the list, or that mail will fail). This will mean a considerable increase in list traffic, I think, since every commit to viewer-development should be reviewed. I think that the increase in transparency of what is happening, and the opportunities for everyone to learn more about more of the code base makes this increase worth it, but am interested in the opinions of other list members. Note that these emails are easy to set up filters for - not only will all of them have 'Review Request' in the Subject lines, there are also a couple of custom headers in each message that make them easy to recognize. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/73aeaa10/attachment.htm From wolfpup67 at earthlink.net Thu Dec 2 05:58:08 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 2 Dec 2010 08:58:08 -0500 Subject: [opensource-dev] Registering a SL Review Board In-Reply-To: <4CF7A1FB.9030507@lindenlab.com> References: <4CF7A1FB.9030507@lindenlab.com> Message-ID: <000601cb9228$f355e170$da01a450$@net> I would be nice if the review board system had an address that was something that people that use email programs( I.E. Outlook, Thunderbird, Incredimail) could much easier filter. Like noreply at codereview.secondlife.com or something similar that way if they set up a filter it would not interfere with any other filters they have set up that are for SL. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Oz Linden (Scott Lawrence) Sent: Thursday, December 02, 2010 8:41 AM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Registering a SL Review Board On 2010-12-02 8:23, Jonathan Welch wrote: > Will the email address we input during the registration process be > visible at any point? Yes, since the email that reviewboard sends about whatever you did will be the From address. If you prefer, you can use the email address that you use for the opensource list (I'd still suggest that you make both of those addresses the same, but the jira address can be changed too). My main concern is that the usernames be the same, so that if ReviewBoard actually does OpenId (it is on their backlog), then we can start using that. _______________________________________________ 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3292 - Release Date: 12/01/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d26531bb/attachment.htm From lee.ponzu at gmail.com Thu Dec 2 06:28:56 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 2 Dec 2010 09:28:56 -0500 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: <4CF7A48A.2090808@lindenlab.com> References: <4CF7A48A.2090808@lindenlab.com> Message-ID: ponzu On Thu, Dec 2, 2010 at 8:52 AM, Oz Linden (Scott Lawrence) wrote: > As you'll have inferred, we now have a system set up for doing open code > reviews. It's not perfect, but it's pretty nice and very easy to use. > > It also generates quite a bit of email - one for each newly posted request, > and one (properly threaded) for each comment or other action on that review. > > If I understand the capabilities correctly, the software allows each > 'review group' to either: > > 1. Configure a single mailing list address for the group (of which at > present we have only the one 'viewer' group) > 2. Leave that address blank > > If a list address is configured, all emails for reviews in that group are > sent to the list address. If it is left blank, then individual emails are > sent to each of the members of the review group. > > I chose to configure the opensource-dev list as the mailing list, and the > messages do get sent there (as From the user, so the address you configure > for your account needs to match the one you use for the list, or that mail > will fail). > > This will mean a considerable increase in list traffic, I think, since > every commit to viewer-development should be reviewed. I think that the > increase in transparency of what is happening, and the opportunities for > everyone to learn more about more of the code base makes this increase worth > it, but am interested in the opinions of other list members. > > Note that these emails are easy to set up filters for - not only will all > of them have 'Review Request' in the Subject lines, there are also a couple > of custom headers in each message that make them easy to recognize. > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/f62af11f/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 2 06:41:30 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 02 Dec 2010 15:41:30 +0100 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: <4CF7A48A.2090808@lindenlab.com> References: <4CF7A48A.2090808@lindenlab.com> Message-ID: <4CF7B01A.4070609@boroon.dasgupta.ch> On 12/02/2010 02:52 PM, Oz Linden (Scott Lawrence) wrote: > Note that these emails are easy to set up filters for - not only will > all of them have 'Review Request' in the Subject lines, there are also > a couple of custom headers in each message that make them easy to > recognize. On 12/02/2010 02:58 PM, WolfPup Lowenhar wrote: > > I would be nice if the review board system had an address that was > something that people that use email programs( I.E. Outlook, > Thunderbird, Incredimail) could much easier filter. Like > noreply at codereview.secondlife.com > or something similar that > way if they set up a filter it would not interfere with any other > filters they have set up that are for SL. > Even easier (for subscribers) would be to have a separate mailing list for the automatic Review Board emails. Then, everyone can decide themselves whether to subscribe to that, too (or even only to that). Non-subscribers would still have the option of seeing the threads on the list's archive website. This would be consistent with existing and previous single-purpose lists like Jira-notify , viewer-development-builds , viewer-development-commits and sldev-commits (or whatever the SVN commit notification list was called back then.) Cheers, Boroondas PS: Is there any reason why the viewer-development-builds Archives are 'private' (i.e. only available to list members)? ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/e9f82f14/attachment-0001.htm From stickman at gmail.com Thu Dec 2 06:49:02 2010 From: stickman at gmail.com (Stickman) Date: Thu, 2 Dec 2010 06:49:02 -0800 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: <4CF7B01A.4070609@boroon.dasgupta.ch> References: <4CF7A48A.2090808@lindenlab.com> <4CF7B01A.4070609@boroon.dasgupta.ch> Message-ID: > Even easier (for subscribers) would be to have a separate mailing list for > the automatic Review Board emails. Then, everyone can decide themselves > whether to subscribe to that, too (or even only to that). Non-subscribers > would still have the option of seeing the threads on the list's archive > website. The review board emails are closely tied with viewer/opensource development. I'm not sure splitting them out into a separate list would work very well as there's too much overlapping content and they would be constantly spilling back into this list as discussions started up based on them. Or worse, not spilling back into this list as discussions pertinent to viewer development started up. Stickman From oz at lindenlab.com Thu Dec 2 06:59:32 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 02 Dec 2010 09:59:32 -0500 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: <4CF7B01A.4070609@boroon.dasgupta.ch> References: <4CF7A48A.2090808@lindenlab.com> <4CF7B01A.4070609@boroon.dasgupta.ch> Message-ID: <4CF7B454.4010900@lindenlab.com> On 2010-12-02 9:41, Boroondas Gupte wrote: > > PS: Is there any reason why the viewer-development-builds Archives > > are 'private' (i.e. only available to list members)? No... but I'll have to dig up the admin password to fix it... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/8f5370f1/attachment.htm From kf6kjg at gmail.com Thu Dec 2 07:30:18 2010 From: kf6kjg at gmail.com (Ricky) Date: Thu, 2 Dec 2010 07:30:18 -0800 Subject: [opensource-dev] Registering a SL Review Board In-Reply-To: <000601cb9228$f355e170$da01a450$@net> References: <4CF7A1FB.9030507@lindenlab.com> <000601cb9228$f355e170$da01a450$@net> Message-ID: Or if it prefixed the message subjects with a [RB] tag, or similar. That would provide the same filterability, at least in gmail, while being easier to implement. Ricky Cron Stardust On Thu, Dec 2, 2010 at 5:58 AM, WolfPup Lowenhar wrote: > I would be nice if the review board system had an address that was something > that people that use email programs( I.E. Outlook, Thunderbird, Incredimail) > could much easier filter. Like noreply at codereview.secondlife.com or > something similar that way if they set up a filter it would not interfere > with any other filters they have set up that are for SL. > > > > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Oz Linden > (Scott Lawrence) > Sent: Thursday, December 02, 2010 8:41 AM > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Registering a SL Review Board > > > > On 2010-12-02 8:23, Jonathan Welch wrote: >> Will the email address we input during the registration process be >> visible at any point? > > Yes, since the email that reviewboard sends about whatever you did will > be the From address. > > If you prefer, you can use the email address that you use for the > opensource list (I'd still suggest that you make both of those addresses > the same, but the jira address can be changed too). > > My main concern is that the usernames be the same, so that if > ReviewBoard actually does OpenId (it is on their backlog), then we can > start using that. > > _______________________________________________ > 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 > > ________________________________ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1170 / Virus Database: 426/3292 - Release Date: 12/01/10 > > _______________________________________________ > 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 > From kf6kjg at gmail.com Thu Dec 2 07:38:39 2010 From: kf6kjg at gmail.com (Ricky) Date: Thu, 2 Dec 2010 07:38:39 -0800 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: References: <4CF7A48A.2090808@lindenlab.com> <4CF7B01A.4070609@boroon.dasgupta.ch> Message-ID: I agree, I prefer them here. However, in such a case, they need to be a tad easier to filter, which is why I suggested an [RB] (or similar) subject tag. This would be consistent with the policies for this list, and would allow easy filtering. The string "Review Request:" is a tad ambiguous, as that might show up in someone's email, and it inconsistent with the existing list policies of [META], [POLICY], etc. Ricky Cron Stardust On Thu, Dec 2, 2010 at 6:49 AM, Stickman wrote: >> Even easier (for subscribers) would be to have a separate mailing list for >> the automatic Review Board emails. Then, everyone can decide themselves >> whether to subscribe to that, too (or even only to that). Non-subscribers >> would still have the option of seeing the threads on the list's archive >> website. > > The review board emails are closely tied with viewer/opensource > development. I'm not sure splitting them out into a separate list > would work very well as there's too much overlapping content and they > would be constantly spilling back into this list as discussions > started up based on them. Or worse, not spilling back into this list > as discussions pertinent to viewer development started up. > > Stickman > _______________________________________________ > 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 > From oz at lindenlab.com Thu Dec 2 07:46:10 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 02 Dec 2010 10:46:10 -0500 Subject: [opensource-dev] How to filter ReviewBoard mail In-Reply-To: <000601cb9228$f355e170$da01a450$@net> References: <4CF7A1FB.9030507@lindenlab.com> <000601cb9228$f355e170$da01a450$@net> Message-ID: <4CF7BF42.9060604@lindenlab.com> On 2010-12-02 8:58, WolfPup Lowenhar wrote: > > I would be nice if the review board system had an address that was > something that people that use email programs( I.E. Outlook, > Thunderbird, Incredimail) could much easier filter. Like > noreply at codereview.secondlife.com > or something similar that > way if they set up a filter it would not interfere with any other > filters they have set up that are for SL. > There are two easy recognizers for these messages; which is better for you will vary with what mail systems you're using: 1. The Subject lines will all begin either 'Review Request:' or 'Re: Review Request:' 2. They all have 'X-ReviewBoard-URL' and 'X-ReviewRequest-URL' headers (the contents are URLs to the site and the review respectively). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/0e0fe725/attachment.htm From jhwelch at gmail.com Thu Dec 2 08:41:11 2010 From: jhwelch at gmail.com (Jonathan Welch) Date: Thu, 2 Dec 2010 11:41:11 -0500 Subject: [opensource-dev] Review board & lists Message-ID: Oz, there is a flaw in your logic about our ability to filter out review messages sent to this list. I receive this list in digest format. It's easier for me to scan through it that way, so I have no ability to filter out these review board messages. I'm with Boroondas--please set up another mailing list to receive these messages. -Jonathan From angel_of_crimson at hotmail.com Thu Dec 2 08:48:47 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 2 Dec 2010 11:48:47 -0500 Subject: [opensource-dev] Review board & lists In-Reply-To: References: Message-ID: I'm adding my voice to that request as well. As someone that primarily tests builds, finds bugs, and suggests/pushes/begs new features, and who doesnt really understand code, these code reviews do nothing but clutter up an email address that I already don't have time to give the attention it should. Please consider a new email list. > Date: Thu, 2 Dec 2010 11:41:11 -0500 > From: jhwelch at gmail.com > To: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] Review board & lists > > Oz, there is a flaw in your logic about our ability to filter out > review messages sent to this list. > > I receive this list in digest format. It's easier for me to scan > through it that way, so I have no ability to filter out these review > board messages. > > I'm with Boroondas--please set up another mailing list to receive > these messages. > > -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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d7dc2064/attachment.htm From wolfpup67 at earthlink.net Thu Dec 2 09:00:43 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 2 Dec 2010 12:00:43 -0500 Subject: [opensource-dev] Starting Investigation into Storm-236 Message-ID: <002701cb9242$75469d50$5fd3d7f0$@net> I have created a repository for https://jira.secondlife.com/browse/STORM-236 to investigate the best way to go about providing this functionality to those that do not use voice or use it intermittently. My thoughts are to have one of the following: 1. Have the Speak button follow the Voice Preference setting ( on or off ) and either be visible or not accordingly instead of being just being grayed out with the indicator showing not available. 2. Include option 1 pulse include in the bottom tray context menu the ability to toggle Voice off or on as this would then in turn toggle the Speak buttons visibility and add more accessibility to that setting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/aaa4b0b5/attachment-0001.htm From thickbrick.sleaford at gmail.com Thu Dec 2 09:05:38 2010 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Thu, 02 Dec 2010 17:05:38 -0000 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101202170538.1553.88622@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/7b248f87/attachment.htm From esbee at lindenlab.com Thu Dec 2 09:18:58 2010 From: esbee at lindenlab.com (Sarah (Esbee) Kuehnle) Date: Thu, 2 Dec 2010 12:18:58 -0500 Subject: [opensource-dev] Starting Investigation into Storm-236 In-Reply-To: <002701cb9242$75469d50$5fd3d7f0$@net> References: <002701cb9242$75469d50$5fd3d7f0$@net> Message-ID: Wolfpup, Just a heads up - this is not work we've committed to doing yet. I pulled it into STORM so we could review it internally and decide if it gets pulled onto our backlog - that's why you'll see it marked as being in the 'Product Backlog Proposals' version. There is a different internal team who own Voice, so we'll likely submit this to them so they can decide on its business and product value. --Esbee On Thu, Dec 2, 2010 at 12:00 PM, WolfPup Lowenhar wrote: > I have created a repository for > https://jira.secondlife.com/browse/STORM-236 to investigate the best way > to go about providing this functionality to those that do not use voice or > use it intermittently. > > My thoughts are to have one of the following: > > 1. Have the Speak button follow the Voice Preference setting ( on or > off ) and either be visible or not accordingly instead of being just being > grayed out with the indicator showing not available. > > 2. Include option 1 pulse include in the bottom tray context menu the > ability to toggle Voice off or on as this would then in turn toggle the > Speak buttons visibility and add more accessibility to that setting. > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/978f20f5/attachment.htm From gigstaggart at gmail.com Thu Dec 2 12:05:05 2010 From: gigstaggart at gmail.com (Gigs) Date: Thu, 02 Dec 2010 15:05:05 -0500 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <20101202170538.1553.88622@domU-12-31-38-00-90-68.compute-1.internal> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> <20101202170538.1553.88622@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4CF7FBF1.3030105@gmail.com> I'm getting "To protect your privacy, Thunderbird has blocked remote content." Why do the message include external images? As well because the "From" field is a person and not the list, I would have to whitelist every contributor to get rid of the message. On 12/02/2010 12:05 PM, Thickbrick Sleaford wrote: > > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/2/ > > > indra/newview/llappviewer.cpp > > (Diff revision 1) > > bool LLAppViewer::mainLoop() > > 1184 > > const F64 max_idle_time = llmin(.005*10.0*gFrameTimeSeconds, 0.005); // 5 ms a second > > 1184 > > const F64 max_idle_time = llmin(.005*10.0*gFrameTimeSeconds, 0.005); // 5 ms a second > > 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 December 1st, 2010, 7:57 p.m., Oz Linden wrote: > > Review request for Viewer. > By Oz Linden. > > /Updated 2010-12-01 19:57:24/ > > > Description > > 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. > > > Testing > > None at all... have not even compiled it yet. > > *Bugs: * storm-606 > > > Diffs > > * indra/newview/llappviewer.cpp (bf98b026bcb1) > > View Diff > > > > _______________________________________________ > 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 From sldev at catznip.com Thu Dec 2 12:27:28 2010 From: sldev at catznip.com (Kitty) Date: Thu, 2 Dec 2010 21:27:28 +0100 Subject: [opensource-dev] Starting Investigation into Storm-236 In-Reply-To: <002701cb9242$75469d50$5fd3d7f0$@net> References: <002701cb9242$75469d50$5fd3d7f0$@net> Message-ID: <000001cb925f$61ceead0$256cc070$@com> I have a patch for that already if you like. The button's visibility will follow the voice preference (visible when voice is enabled, and invisible when voice is disabled), along with the bottom tray context menu option to hide it even when voice is enabled (so the same as your option 2). I've been using it for just under 3 months so there shouldn't be any major issues with it anymore (I hope :p). Kitty From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of WolfPup Lowenhar Sent: donderdag 2 december 2010 18:01 To: OpenSource Mailing List Subject: [opensource-dev] Starting Investigation into Storm-236 I have created a repository for https://jira.secondlife.com/browse/STORM-236 to investigate the best way to go about providing this functionality to those that do not use voice or use it intermittently. My thoughts are to have one of the following: 1. Have the Speak button follow the Voice Preference setting ( on or off ) and either be visible or not accordingly instead of being just being grayed out with the indicator showing not available. 2. Include option 1 pulse include in the bottom tray context menu the ability to toggle Voice off or on as this would then in turn toggle the Speak buttons visibility and add more accessibility to that setting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/6f458756/attachment.htm From kf6kjg at gmail.com Thu Dec 2 14:58:17 2010 From: kf6kjg at gmail.com (Ricky) Date: Thu, 2 Dec 2010 14:58:17 -0800 Subject: [opensource-dev] Review Request: Restructure loops that use breaks without need (reviewboard test) In-Reply-To: <4CF7FBF1.3030105@gmail.com> References: <20101202035724.1486.22193@domU-12-31-38-00-90-68.compute-1.internal> <20101202170538.1553.88622@domU-12-31-38-00-90-68.compute-1.internal> <4CF7FBF1.3030105@gmail.com> Message-ID: Hmm, it appears to have "background-image: url('http://codereview.secondlife.comrb/image=s/review_request_box_top_bg.png');" in the style attribute for one of the tables. (Don't know why tables were used instead of divs like the site is built...) Beyond the fact that it isn't necessary, the URL is also wrong. The correct URL is: https://codereview.secondlife.com/media/rb/images/review_request_box_top_bg.png Ricky Cron Stardust On Thu, Dec 2, 2010 at 12:05 PM, Gigs wrote: > I'm getting "To protect your privacy, Thunderbird has blocked remote > content." ? Why do the message include external images? ?As well because > the "From" field is a person and not the list, I would have to whitelist > every contributor to get rid of the message. > > On 12/02/2010 12:05 PM, Thickbrick Sleaford wrote: >> >> This is an automatically generated e-mail. To reply, visit: >> http://codereview.secondlife.com/r/2/ >> >> >> indra/newview/llappviewer.cpp >> >> (Diff revision 1) >> >> bool LLAppViewer::mainLoop() >> >> 1184 >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? const ?F64 ?max_idle_time ?= ?llmin(.005*10.0*gFrameTimeSeconds, ?0.005); ?// 5 ms a second >> >> ? ? ? 1184 >> >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? const ?F64 ?max_idle_time ?= ?llmin(.005*10.0*gFrameTimeSeconds, ?0.005); ?// 5 ms a second >> >> 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 December 1st, 2010, 7:57 p.m., Oz Linden wrote: >> >> Review request for Viewer. >> By Oz Linden. >> >> /Updated 2010-12-01 19:57:24/ >> >> >> ? Description >> >> 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. >> >> >> ? Testing >> >> None at all... have not even compiled it yet. >> >> *Bugs: * storm-606 >> >> >> ? Diffs >> >> ? ? * indra/newview/llappviewer.cpp (bf98b026bcb1) >> >> View Diff >> >> >> >> _______________________________________________ >> 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 > From wolfpup67 at earthlink.net Thu Dec 2 17:44:21 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 2 Dec 2010 20:44:21 -0500 Subject: [opensource-dev] POTENTIAL SHOW STOPPER Message-ID: <000001cb928b$9b68b0b0$d23a1210$@net> Well it could be for OS devs still working with viewer-development if mesh-development get merged to v-d in its current condition. Attached is the outputs from me trying to get mesh-development to build on my system plust the debug outputs for TWO failing integration test and the generated viewer. All three crash immediately on start. A viewer built on the LL build farms will start just fine, at least the one I had installed a couple of weeks ago. My development environment: CPU: Intel Pentum D 820 running @ 2.8GHz Memory: 2GB OS: Windows 7 32-bit Graphics card: nVida GForce 8500 GT w/1GB video memory on the card IDE: Visual Studio 2005 Pro plus all needed extra programs and SDK's Now I can build viewer-development just fine even though it takes me ~3Hrs to do a full build that includes all test to make sure everything is working the way it should. I can even run my builds of v-d with no problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d1720aac/attachment-0001.htm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Output-Build-2010-12-02-1901-in debug mode.txt Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d1720aac/attachment-0004.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Output-Debug-INTEGRATION_TEST_llcapabilitylistener-2010-12-02.txt Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d1720aac/attachment-0005.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Output-Debug-INTEGRATION_TEST_llsdmessage-2010-12-02.txt Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d1720aac/attachment-0006.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Output-Debug-secondlife-bin-2010-12-02.txt Url: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d1720aac/attachment-0007.txt From trilobyte550m at gmail.com Thu Dec 2 18:24:41 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Thu, 2 Dec 2010 18:24:41 -0800 Subject: [opensource-dev] POTENTIAL SHOW STOPPER In-Reply-To: <000001cb928b$9b68b0b0$d23a1210$@net> References: <000001cb928b$9b68b0b0$d23a1210$@net> Message-ID: The latest Mesh Project Snapshot build for Mac (downloaded from LL as Second Life Developer, build 215879) was trash for me, though apparently different reason. Major regression, deferred rendering filled the screen with a mix of black and glowing chunks of graphics garbage. I'm thinking it had to be a mistake somewhere, as the downloaded file had the name "SecondLife_2_1_2_215879_DEVELOPER.dmg" (the 2_1_2 ought to have been a 2_4_0 or 2_5_0). TriloByte Zanzibar On Dec 2, 2010, at 5:44 PM, WolfPup Lowenhar wrote: > Well it could be for OS devs still working with viewer-development if mesh-development get merged to v-d in its current condition. Attached is the outputs from me trying to get mesh-development to build on my system plust the debug outputs for TWO failing integration test and the generated viewer. All three crash immediately on start. A viewer built on the LL build farms will start just fine, at least the one I had installed a couple of weeks ago. > > My development environment: > CPU: Intel Pentum D 820 running @ 2.8GHz > Memory: 2GB > OS: Windows 7 32-bit > Graphics card: nVida GForce 8500 GT w/1GB video memory on the card > IDE: Visual Studio 2005 Pro plus all needed extra programs and SDK?s > > Now I can build viewer-development just fine even though it takes me ~3Hrs to do a full build that includes all test to make sure everything is working the way it should. I can even run my builds of v-d with no problems. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/2a0e9fae/attachment.htm From angel_of_crimson at hotmail.com Thu Dec 2 19:36:25 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 2 Dec 2010 22:36:25 -0500 Subject: [opensource-dev] amusing but annoying and confusing... Message-ID: In preferences, under sound.... Where Voice Chat used to be... we have Voice Cha... Might be a little something we should fix no? Second Life 2.5.0 (215755) Nov 30 2010 16:58:32 (Second Life Development) Release Notes You are at 165,052.0, 239,824.0, 278.0 in Dreamworld Rhino located at sim5279.agni.lindenlab.com (216.82.23.42:12035) Second Life Server 10.11.29.215604 Release Notes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/92b1666a/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: VoiceChaWaaa.JPG Type: image/jpeg Size: 84845 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/92b1666a/attachment-0001.jpeg From chuckbaggettweb at gmail.com Thu Dec 2 20:36:35 2010 From: chuckbaggettweb at gmail.com (Chuck Baggett) Date: Thu, 2 Dec 2010 22:36:35 -0600 Subject: [opensource-dev] nametag opacity Message-ID: Are the nametags fixed at 100 per cent opaque or are they of variable opacity? By nametags I mean avatar names and group titles. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/d04ef95c/attachment.htm From chuckbaggettweb at gmail.com Thu Dec 2 20:45:21 2010 From: chuckbaggettweb at gmail.com (Chuck Baggett) Date: Thu, 2 Dec 2010 22:45:21 -0600 Subject: [opensource-dev] sidebar covering the bottom bar Message-ID: Is there any hope of not having the sidebar cover the bottom bar? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101202/1f24ca3f/attachment.htm From akanevsky at productengine.com Thu Dec 2 22:43:40 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Fri, 3 Dec 2010 00:43:40 -0600 Subject: [opensource-dev] Daily Scrum Summary - Thursday, December 2 Message-ID: Thursday, December 2, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-151: kdu compression: More work on this. Explored some viewer j2c compression usage while at it. Started to write doc on all this: https://wiki.lindenlab.com/wiki/Kakadu_Update (LL internal for the moment). *FUTURE* - STORM-151: kdu compression: Push some compression code into my public repo. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Resize codereview file system - Post test review - Announce/Open code review system - Pulled a bunch of issues for viewer-development - turned out some of these should have been beta, so have to re-do them *FUTURE* - Merge Monkeying - Document code review system on wiki *IMPEDIMENTS* - none Q Linden ------------------------------ - OOO Esbee Linden ------------------------------ *PAST* - - OOO - sick - Provided default transparency info on STORM-535 *FUTURE* - Work on internal reporting documents - Get caught up *IMPEDIMENTS* - Still sick and moving a bit slower than I'd like _ FEEL BETTER ESBEEEEEEE! Paul ProductEngine ------------------------------ *PAST* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - WIP. Estimate ~ 8 hours *FUTURE* - STORM-684 subtasks (fix transparency in some panels/floaters). *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log - WIP. Working on using custom style for SLURLs in chat. Looks like it may be possible if SLURLs will use custom style only for residents' and objects' names, not for any SLURL occurrence in chat. - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - Got the fix approved and pushed to bitbucket repo. *FUTURE* - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Investigated further. Discussed with Vadim. Started implementing. Estimate - 3d, but tomorrow will evaluate what is done and what is left, and depending on it may give part of work to Sergey if I will not be able to complete implementation on my own before the sprint ends. *FUTURE* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). *IMPEDIMENTS* - STORM-527 needs a new home _ Q is looking for it Vadim Productengine ------------------------------ *PAST* - Made additional fixes for: - Task STORM-676 (Color swatches inside transparent floater are not transparent). - Task STORM-677 (Texture pickers inside transparent floater are not transparent). - Bug STORM-432 (Trash button in People > My Friends tab can be moved). - Fixed: - Task STORM-687 (Snapshot thumbnail in the Email Snapshot floater doesn't honor floater opacity settings). *FUTURE* - Continue with transparency-related fixes. *IMPEDIMENTS* - Our transparency-related work still hasn't been integrated into beta. _ It's going to be as soon as we release beta 1. - Will Esbee take a look at STORM-28? _ Not in this sprint - Is there a way to assign STORM-564 to Monroe Linden? _ Done. LEAP-20 Andrey Productengine ------------------------------ *PAST* - re-ran smoke & integrity tests against Beta1 r215703 build - verified STORM-667 hotfix for beta - 2.4.0 bugfixes verification, see spreadsheet *FUTURE* - switch to the latest v-d build - verify integrated tickets and do some regression testing in scope of recent changes *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - Commented on code review system. - STORM-713 -- This should be fixed before a viewer is released. - STORM-523 - Could not reproduce myself or with another tester. Need a screen shot from the reporter. Reporter says she could reproduce this with my test object. Better way would be to send these notifications to local chat. - VWR-24053 (Start Location preference not always obeyed) *FUTURE* - [long range] - Update lsl wiki - remove Unsupported icon next to llTextBox. Timing of when to make this edit? *IMPEDIMENTS* - I need someone to assign VWR-24053 to me after converting it to Storm _ STORM-726 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/b89e31c4/attachment-0001.htm From hitomi.tiponi at yahoo.co.uk Fri Dec 3 00:02:49 2010 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Fri, 3 Dec 2010 08:02:49 +0000 (GMT) Subject: [opensource-dev] Is there any hope of not having the sidebar cover the bottom bar? Message-ID: <80102.29115.qm@web23904.mail.ird.yahoo.com> That appears to have been a design decision. Suggest you raise it as an issue if you feel you would like an alternative. I know that while most of my users like the shortened sidebar some still prefer the full-length bar - so it may be better as an option. Hitomi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/31139df5/attachment.htm From angel_of_crimson at hotmail.com Fri Dec 3 02:50:49 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 3 Dec 2010 05:50:49 -0500 Subject: [opensource-dev] nametag opacity In-Reply-To: References: Message-ID: they are now variable. they seem to be tied to the bubble text settings... at least for me.... Date: Thu, 2 Dec 2010 22:36:35 -0600 From: chuckbaggettweb at gmail.com To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] nametag opacity Are the nametags fixed at 100 per cent opaque or are they of variable opacity? By nametags I mean avatar names and group titles. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/1b47f399/attachment.htm From secret.argent at gmail.com Fri Dec 3 03:02:00 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 3 Dec 2010 05:02:00 -0600 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: <4CF7A48A.2090808@lindenlab.com> References: <4CF7A48A.2090808@lindenlab.com> Message-ID: <3964BAE7-305F-424A-B3A4-A8438B041B8C@gmail.com> On 2010-12-02, at 07:52, Oz Linden (Scott Lawrence) wrote: > This will mean a considerable increase in list traffic, I think, since every commit to viewer-development should be reviewed. I think that the increase in transparency of what is happening, and the opportunities for everyone to learn more about more of the code base makes this increase worth it, but am interested in the opinions of other list members. I remember a number of occasions where discussions were shut down because of the effect on traffic on this list. I don't disagree with any of those occasions, I think "a substantial increase in list traffic" needs to be viewed with some alarm. From sllists at boroon.dasgupta.ch Fri Dec 3 03:28:09 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 03 Dec 2010 12:28:09 +0100 Subject: [opensource-dev] nametag opacity In-Reply-To: References: Message-ID: <4CF8D449.4070804@boroon.dasgupta.ch> On 12/03/2010 05:36 AM, Chuck Baggett wrote: > Are the nametags fixed at 100 per cent opaque or are they of variable > opacity? > > By nametags I mean avatar names and group titles. The opacity is variable, but the control for the setting isn't obvious, as it's labeled "bubble chat opacity", although it also applies to nametags while not chatting and even when the bubble chat option is off. In Viewer 1.23: 1. Open Preferences (*Ctrl-P*) 2. Go to tab *Text Chat* 3. Section *Bubble Chat* has an *Opacity* slider In Viewer 2.3 (current release): 1. Open Preferences (*Ctrl-P*) 2. Go to tab *Advaced* 3. In the section with the *walking person* icon (sic!), below the *Bubble chat* checkbox, there is an *Opacity* slider In current viewer-development code: Since the recent preferences overhaul (see STORM-31 and in particular STORM-573 ) 1. Open Preferences (*Ctrl-P*) 2. Go to tab *Colors* 3. Section *Bubble Chat* has an *Opacity* slider The section should probably relabeled to reflect that the setting applies to both, nametags and bubble chat. There were several issues with the nametags and their transparency and color, recently: * STORM-584 The settings didn't have any effect. The text color was just white. * Fixing this made tags unreadable for everyone who didn't set a custom color, because the default of the color setting was still black. (So you had black text on black background.) * STORM-667 Even after the above was fixed, contrast was poor due to the text in the tag being semitrasparent. o The slider did only influence the background opacity. That's probably what it was supposed to do, but the (non-customizable) text opacity should have been fully opaque. o As far as I can tell by eye, this is fixed in latest viewer-development code. * On Mac, there were (and maybe still are) issues that nametags would appear unreadable or not at all on ATi cards. o Is there a separate issue for this, yet? * VWR-24017 text on name tags is visible, even if the background of the nametag gets occluded by objects. I guess the underlying reason is the same as for why floating text is not occluded anymore (SH-489 ) STORM-584 will probably lead to further changes , which aren't in viewer-development, yet. (Text in the tag being determined by the same settings as for the chat window, the "bubble chat" color setting affecting the tag's background instead (hopefully with yet again changed default, so we keep the contrast).) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/dd6438d6/attachment.htm From sllists at boroon.dasgupta.ch Fri Dec 3 03:36:10 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 03 Dec 2010 12:36:10 +0100 Subject: [opensource-dev] nametag opacity In-Reply-To: <4CF8D449.4070804@boroon.dasgupta.ch> References: <4CF8D449.4070804@boroon.dasgupta.ch> Message-ID: <4CF8D62A.5060608@boroon.dasgupta.ch> On 12/03/2010 12:28 PM, Boroondas Gupte wrote: > Since the recent preferences overhaul (see STORM-31 > and in particular > STORM-573 ) err, STORM-583 , not STORM-573 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/1a0ad5e9/attachment.htm From open at autistici.org Fri Dec 3 05:23:45 2010 From: open at autistici.org (Opensource Obscure) Date: Fri, 03 Dec 2010 14:23:45 +0100 Subject: [opensource-dev] =?utf-8?q?ReviewBoard_email_to_this_list=3F?= In-Reply-To: <4CF7A48A.2090808@lindenlab.com> References: <4CF7A48A.2090808@lindenlab.com> Message-ID: <8227037db9617b210a1a705b78586946@inventati.org> On Thu, 02 Dec 2010 08:52:10 -0500, "Oz Linden (Scott Lawrence)" wrote: > I chose to configure the opensource-dev list as the mailing list, and > the messages do get sent there (as From the user, so the address you > configure for your account needs to match the one you use for the > list, or that mail will fail). > > This will mean a considerable increase in list traffic, I think, > since every commit to viewer-development should be reviewed. I think > that the increase in transparency of what is happening, and the > opportunities for everyone to learn more about more of the code base > makes this increase worth it, but am interested in the opinions of > other list members. I'm OK with this approach, and I find it appropriate for this mailing list. Maybe it will also help to shift the balance between technical and emotional-personal-drama-fueled messages toward 'technical'. Only slightly related: maybe not everybody know that this mailing list can be read through web archives, and you can even subscribe to it while not receiving messages at all and preserving your ability to write to the mailing list. This may work for some people who don't read the list often but sometimes want to reply. Opensource Obscure From q at lindenlab.com Fri Dec 3 05:33:21 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri, 3 Dec 2010 08:33:21 -0500 Subject: [opensource-dev] nametag opacity In-Reply-To: <4CF8D62A.5060608@boroon.dasgupta.ch> References: <4CF8D449.4070804@boroon.dasgupta.ch> <4CF8D62A.5060608@boroon.dasgupta.ch> Message-ID: <22083AC1-1AD9-4D75-B358-EE74AD58B911@lindenlab.com> This was the subject of some confusion and we're still working on it. Please bear with us. Q On Dec 3, 2010, at 6:36 AM, Boroondas Gupte wrote: > On 12/03/2010 12:28 PM, Boroondas Gupte wrote: >> >> Since the recent preferences overhaul (see STORM-31 and in particular STORM-573) > err, STORM-583, not STORM-573 > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/ca994019/attachment-0001.htm From oz at lindenlab.com Fri Dec 3 06:15:30 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 03 Dec 2010 09:15:30 -0500 Subject: [opensource-dev] POTENTIAL SHOW STOPPER In-Reply-To: <000001cb928b$9b68b0b0$d23a1210$@net> References: <000001cb928b$9b68b0b0$d23a1210$@net> Message-ID: <4CF8FB82.7050603@lindenlab.com> On 2010-12-02 20:44, WolfPup Lowenhar wrote: > > Well it could be for OS devs still working with viewer-development if > mesh-development get merged to v-d in its current condition. Attached > is the outputs from me trying to get mesh-development to build on my > system plust the debug outputs for TWO failing integration test and > the generated viewer. All three crash immediately on start. A viewer > built on the LL build farms will start just fine, at least the one I > had installed a couple of weeks ago. > > First of all, the mesh integration is not imminent, so the extreme tone of ALARM USING ALL CAPS is in no way justified. Secondly, please try to prepare a more concise statement of the problem rather than just posting 4 large log files and leaving us to guess or hunt for what the problem might be. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/fed071b4/attachment.htm From oz at lindenlab.com Fri Dec 3 06:22:53 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 03 Dec 2010 09:22:53 -0500 Subject: [opensource-dev] ReviewBoard email to this list? In-Reply-To: <4CF7A48A.2090808@lindenlab.com> References: <4CF7A48A.2090808@lindenlab.com> Message-ID: <4CF8FD3D.8080004@lindenlab.com> As of this moment, I don't see a strong consensus either way. It happens that I'm on vacation next week (returning Dec 13th). I'd prefer not to make any final decisions or configuration changes on the last day before I leave (I probably will have little or no Net access while I'm gone), so this will remain as it is at least until I get back. I appreciate the many thoughtful and informative points made so far, and look forward to catching up on how people feel about it when I return. From TammyNowotny at mac.com Fri Dec 3 06:43:04 2010 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Fri, 03 Dec 2010 09:43:04 -0500 Subject: [opensource-dev] nametag opacity In-Reply-To: <22083AC1-1AD9-4D75-B358-EE74AD58B911@lindenlab.com> References: <4CF8D449.4070804@boroon.dasgupta.ch> <4CF8D62A.5060608@boroon.dasgupta.ch> <22083AC1-1AD9-4D75-B358-EE74AD58B911@lindenlab.com> Message-ID: <4CF901F8.5090401@mac.com> For me it was confusing because I never use bubble chat. And, it was also confusing because it wasn't exactly self-evident that nametags and bubble chat were so closely related. --Tammy Nowotny On 12/3/10 8:33 AM, Kent Quirk (Q Linden) wrote: > This was the subject of some confusion and we're still working on it. > Please bear with us. > Q > > > On Dec 3, 2010, at 6:36 AM, Boroondas Gupte wrote: > >> On 12/03/2010 12:28 PM, Boroondas Gupte wrote: >>> Since the recent preferences overhaul (see STORM-31 >>> and in particular >>> STORM-573 ) >> err, STORM-583 , not >> STORM-573 >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/36c8a194/attachment.htm From brad at lindenlab.com Fri Dec 3 13:58:59 2010 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Fri, 3 Dec 2010 13:58:59 -0800 Subject: [opensource-dev] Autoupdater Flashback In-Reply-To: <000301cb9166$89097060$9b1c5120$@com> References: <000301cb9166$89097060$9b1c5120$@com> Message-ID: I have posted this info here: https://wiki.secondlife.com/wiki/Viewer_Update_Service/Protocol -Brad On Wed, Dec 1, 2010 at 6:46 AM, Kitty wrote: > Would it be possible to get the protocol specification for the updater > service on the server-side? > > > > It?s always possible to work backwards from the code in the viewer, but it > would be handy to just have an overview of the viewer<->web service > exchanges :). > > > > Kitty > > > > *From:* opensource-dev-bounces at lists.secondlife.com [mailto: > opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Brad > Kittenbrink (Brad Linden) > *Sent:* dinsdag 30 november 2010 22:34 > *To:* Bunny Halberd > *Cc:* opensource-dev at lists.secondlife.com > *Subject:* Re: [opensource-dev] Autoupdater Flashback > > > > Oops, thanks for the heads-up. > > The background updater is new in viewer 2.4 (as it's not released in beta > yet, it doesn't have release notes yet, so sorry for the surprise). > Yesterday we deployed the server side work in preparation for the beginning > of the 2.4 beta releases, and it turned on. Unfortunately we hadn't been > paying attention to the Second Life Development channel, and there was some > obsolete data in the database. > > Anyways, thanks again for testing this for us. We should be getting it > fixed shortly. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/98bf30b0/attachment.htm From merov at lindenlab.com Fri Dec 3 17:17:14 2010 From: merov at lindenlab.com (Merov Linden) Date: Sat, 04 Dec 2010 01:17:14 -0000 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available Message-ID: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/3/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This rather big patch accomplish the following: - makes llkdu public and open source: this contains decompression and compression implementations using the KDU API - links the viewer to KDU v6.4.1 statically if USE_KDU set at build time (and assuming you do have a licensed version of Kakadu) - links statically to OpenJpeg otherwise This addresses bug STORM-151. http://jira.secondlife.com/browse/STORM-151 Diffs ----- indra/CMakeLists.txt d94b8cf6891f indra/cmake/Copy3rdPartyLibs.cmake d94b8cf6891f indra/cmake/LLKDU.cmake d94b8cf6891f indra/integration_tests/llui_libtest/CMakeLists.txt d94b8cf6891f indra/llimage/CMakeLists.txt d94b8cf6891f indra/llimage/llimage.cpp d94b8cf6891f indra/llimage/llimagej2c.h d94b8cf6891f indra/llimage/llimagej2c.cpp d94b8cf6891f indra/llkdu/CMakeLists.txt PRE-CREATION indra/llkdu/llimagej2ckdu.h PRE-CREATION indra/llkdu/llimagej2ckdu.cpp PRE-CREATION indra/llkdu/llkdumem.h PRE-CREATION indra/llkdu/llkdumem.cpp PRE-CREATION indra/newview/CMakeLists.txt d94b8cf6891f indra/newview/viewer_manifest.py d94b8cf6891f install.xml d94b8cf6891f Diff: http://codereview.secondlife.com/r/3/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101204/f0b1f84a/attachment.htm From merov at lindenlab.com Fri Dec 3 17:28:51 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 3 Dec 2010 17:28:51 -0800 Subject: [opensource-dev] STORM-151 : KDU v6.4.1 upgrade update In-Reply-To: References: <4CDE7BE9.8050704@lindenlab.com> <329517AE-7A30-4AA8-9AA0-6C37E8FCEBC7@gmail.com> Message-ID: Hi, We're close to completion here: the compression to j2c is now back on and working apparently (for the few tests I did on Mac and Windows). I'm still thinking about optimization and such but that's good to have a complete basis to work from. I pushed STORM-151 to "Review" and created my first (massive!) diff for Review Board. For those not inclined to read code, I also posted binaries: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-features/rev/216087/index.html Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101203/9a92bdbc/attachment.htm From gcanaday at gmail.com Fri Dec 3 17:48:44 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Fri, 3 Dec 2010 20:48:44 -0500 Subject: [opensource-dev] Arrow Keys Always Move Me Message-ID: <201012032048.45074.gcanaday@gmail.com> Hey, I'm a little curious - what's the expected behavior of "Arrow Keys Always Move Me"? I was under the impression that this was meant to cause the arrow keys to be the only movement keys, freeing up the rest of the keyboard for chat. I'm wrong, aren't I? --GC From gcanaday at gmail.com Fri Dec 3 17:52:14 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Fri, 3 Dec 2010 20:52:14 -0500 Subject: [opensource-dev] Arrow keys - nm Message-ID: <201012032052.14932.gcanaday@gmail.com> All, My fault. Wrong checkbox! Please disregard. --GC From aklo at skyhighway.com Fri Dec 3 21:24:55 2010 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Fri, 3 Dec 2010 21:24:55 -0800 (PST) Subject: [opensource-dev] Message Reception Message-ID: <954e5e8534f246389c944123476a189f.squirrel@cruziomail.cruzio.com> Hey, an in-world club employee (security) i have worked with would like to know if there is some way to be able to pick up local text chat without moving the avi closer to the chat source, like the way you can cfg the viewer to hear voice chat from either where the avi's at or where the camera's at. i was sure i'd seen a way to do it, but i haven't been able to find the setting again. If there is a setting, but it doesn't work for pre-version 2 viewers, that won't be helpful. The user doesn't want to change to a version 2 viewer. Please excuse me if this is not the place to be asking this question. Thanks! Have an awesome day, - AK From bunny at bunnynet.org Fri Dec 3 21:44:21 2010 From: bunny at bunnynet.org (Bunny Halberd) Date: Fri, 3 Dec 2010 23:44:21 -0600 Subject: [opensource-dev] Message Reception In-Reply-To: <954e5e8534f246389c944123476a189f.squirrel@cruziomail.cruzio.com> References: <954e5e8534f246389c944123476a189f.squirrel@cruziomail.cruzio.com> Message-ID: On Fri, Dec 3, 2010 at 11:24 PM, wrote: > Hey, an in-world club employee (security) i have worked with would like to > know if there is some way to be able to pick up local text chat without > moving the avi closer to the chat source, like the way you can cfg the > viewer to hear voice chat from either where the avi's at or where the > camera's at. ?i was sure i'd seen a way to do it, but i haven't been able > to find the setting again. Not without violating the Second Life terms of service. "Remotely monitoring conversations, posting conversation logs, or sharing conversation logs without consent are all prohibited in Second Life and on the Second Life Forums." http://secondlife.com/corporate/cs.php - Bunny From aklo at skyhighway.com Fri Dec 3 22:29:56 2010 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Fri, 3 Dec 2010 22:29:56 -0800 (PST) Subject: [opensource-dev] Message Reception Message-ID: <27ea1efb9fcc4e2e594b0d27c7ba5c6c.squirrel@cruziomail.cruzio.com> Bunny, one of the reasons i asked the question is that the "remote" idea here is not real clear. My friend has worked in the same SL club several hours per day, almost every day, since something like early 2007 as club security. The idea is to keep the place PG, among other things, since it gets a lot of traffic and you know how some people just can't behave. The club is big enough that people can hang out in corners and be out of text chat range for security. Security sometimes has to be kind of sneaky to catch people at what they're doing before they cause serious problems, often for minors or the usual griefer sort of thing. It's not like the idea is to listen in on someone who's even outside the club, and especially not in another region. Just 2x or maybe 3x text chat distance reception would be a fine solution. Thanks! - AK From daleinnisemail at gmail.com Sat Dec 4 05:29:56 2010 From: daleinnisemail at gmail.com (Dale Innis) Date: Sat, 4 Dec 2010 08:29:56 -0500 Subject: [opensource-dev] Message Reception In-Reply-To: <27ea1efb9fcc4e2e594b0d27c7ba5c6c.squirrel@cruziomail.cruzio.com> References: <27ea1efb9fcc4e2e594b0d27c7ba5c6c.squirrel@cruziomail.cruzio.com> Message-ID: Random thoughts: I'm pretty sure there is no viewer setting to do this (I would imagine that the data isn't even sent to the viewer if you're out of range, so it would require server cooperation to raise the chat-hearing limit, and the server doesn't have such a function afaik). It would be simple enough for security to place little chat-relay objects around the club, that would listen to open chat and rebroadcast it using llShout() or llRegionSay() or other applicable methods on a different channel, and then security could listen to it with a receiver that listens on that channel. To avoid ToS violation ("without consent") there should be clearly visible signage saying "by being in this club you consent to having security monitor whatever you say in open chat"; I'm not a Linden, but I would expect that would be sufficient. If someone's plotting to cause trouble, they'll be doing it in IM anyway :) and you definitely can't monitor that. I guess you might be able to get early warning of trouble if Resi A starts cursing out Resi B in open chat, out of normal chat distance of security. Dunno if that happens often enough to make a system of chat relays and ToS-covering signage worth the trouble... -- Dale From trilobyte550m at gmail.com Sat Dec 4 07:52:42 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sat, 4 Dec 2010 07:52:42 -0800 Subject: [opensource-dev] STORM-151 : KDU v6.4.1 upgrade update In-Reply-To: References: <4CDE7BE9.8050704@lindenlab.com> <329517AE-7A30-4AA8-9AA0-6C37E8FCEBC7@gmail.com> Message-ID: <4A06DE25-D70B-462E-9460-7B9A25B66DF7@gmail.com> Excellent, Merov, thanks! Downloaded the binary and started banging on the Mac client... - Loading textures from inventory is MUCH faster. I pulled dozens of images up in my inventory, and noticed no stalling or delays. - Tested a series of image uploads from JPG, PNG, and TGA sources (including some with alpha), everything uploaded normally. - Tested rezzing by visiting a few texture and sculpt-heavy builds. Everything loaded quickly (even faster than previous developer builds?) Sculpties also seem to rez much more quickly for Mac users. I tweak my viewer settings with RenderVolumeLODfactor set to 6.0 (seems to work best for my GPU), but previous versions of the KDU library seemed to take noticeably longer to rez sculpt-maps than other textures, and certainly longer than the PC client. I haven't compared against the PC client on this build, but comparing against older KDU library versions it appears to be considerably faster. Side note: changing the RenderVolumeLODfactor default setting to 2.0 for macs with Intel integrated graphics and 4.0 for all other machines would result in a much better performance 'out of the box' for Mac users IMO. On Dec 3, 2010, at 5:28 PM, Philippe (Merov) Bossut wrote: > Hi, > > We're close to completion here: the compression to j2c is now back on and working apparently (for the few tests I did on Mac and Windows). I'm still thinking about optimization and such but that's good to have a complete basis to work from. > > I pushed STORM-151 to "Review" and created my first (massive!) diff for Review Board. > > For those not inclined to read code, I also posted binaries: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-features/rev/216087/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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101204/9e49a38b/attachment.htm From lee.ponzu at gmail.com Sat Dec 4 08:30:55 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 4 Dec 2010 11:30:55 -0500 Subject: [opensource-dev] Almost certainly not your fault... Message-ID: ...but I thought I should at least mention it. I have been experimenting with compilers on OS X. GCC 4.2 LLVM. Clang. Self educational OS X stuff. Compile and link seems to work, but starting up Second Life leads to a kernel panic. This is the only time I have ever seen OS X panic, so this is a pretty cool accomplishment. FYI, LLVM is a very cool change to the compile-optimize-link chain. it should lead to new and approved link-time optimizations. Clang, on the other hand, is a new C++ parser front end. It is supposed to be much faster than GCC. We shall see. regards, ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101204/4df61cf4/attachment.htm From lee.ponzu at gmail.com Sat Dec 4 08:34:18 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 4 Dec 2010 11:34:18 -0500 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available In-Reply-To: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> References: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: A question about the static KDU issue. I believe this means that when I do a build on my local machine, I do NOT have a KDU license. Is that true? Or, do I somehow inherit rights from Linden Lab? ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101204/e862fe1d/attachment.htm From lee.ponzu at gmail.com Sat Dec 4 08:37:29 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 4 Dec 2010 11:37:29 -0500 Subject: [opensource-dev] Arrow Keys Always Move Me In-Reply-To: <201012032048.45074.gcanaday@gmail.com> References: <201012032048.45074.gcanaday@gmail.com> Message-ID: I believe it is related to chat input. If you are typing chat, do the arrow keys move the cursor or do they move the agent? On Fri, Dec 3, 2010 at 8:48 PM, Glen Canaday wrote: > Hey, > > I'm a little curious - what's the expected behavior of "Arrow Keys Always > Move > Me"? I was under the impression that this was meant to cause the arrow keys > to > be the only movement keys, freeing up the rest of the keyboard for chat. > I'm > wrong, aren't I? > > --GC > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101204/547b1a5b/attachment.htm From bunny at bunnynet.org Sat Dec 4 09:20:01 2010 From: bunny at bunnynet.org (Bunny Halberd) Date: Sat, 4 Dec 2010 11:20:01 -0600 Subject: [opensource-dev] Message Reception In-Reply-To: <27ea1efb9fcc4e2e594b0d27c7ba5c6c.squirrel@cruziomail.cruzio.com> References: <27ea1efb9fcc4e2e594b0d27c7ba5c6c.squirrel@cruziomail.cruzio.com> Message-ID: On Sat, Dec 4, 2010 at 12:29 AM, wrote: > one of the reasons i asked the question is that the "remote" idea here is > not real clear. No one on this list can answer that question... it's certainly not about viewer development. This is a question for whatever became of the G-Team (governance team). They used to hold office hours just so you could ask questions like this, but I'm not sure what became of them. Maybe if you file a support ticket it'll get routed to them? I have no idea. Dale's exactly right that scripting it would be not a big deal, but... On a personal note... as someone that's help run a PG sim for years... don't fret about things you aren't aware of. If it's a problem, someone will tell you. Otherwise you lose sleep at night worried that someone somewhere might use some language they shouldn't just out of your chat range. Just relax and trust that if someone is being a problem, it'll get reported. (Odds are there's a lot that goes on that you aren't aware of, and the greifers will just use IM!) It the only sane thing you can do; being omnipresent would suck. - Bunny From tateru at taterunino.net Sat Dec 4 10:51:13 2010 From: tateru at taterunino.net (Tateru Nino) Date: Sun, 05 Dec 2010 05:51:13 +1100 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available In-Reply-To: References: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4CFA8DA1.4070604@taterunino.net> Basically, if you build a viewer, you can't include KDU in it, unless you have a license to do so. Assuming that you *do* have a license to do so, you cannot then distribute that viewer to any other person unless it is allowed by that license. Linden Lab doesn't - insofar as I am aware - have a license that allows it to distribute any of the code to us or to anyone else - therefore, any viewer you build based off the code-base that supports static KDU linkage can't be built - by you or me or anyone - to include KDU statically, unless you've purchased a license from Kakadu. tl;dr: No KDU for you, unless you pay Kakadu for it. You will have to build with an alternative JPG2K library, otherwise. On 5/12/2010 3:34 AM, Ponzu wrote: > A question about the static KDU issue. I believe this means that when > I do a build on my local machine, I do NOT have a KDU license. Is > that true? Or, do I somehow inherit rights from Linden Lab? > > 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 -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101205/4288d7c0/attachment.htm From gcanaday at gmail.com Sat Dec 4 13:07:54 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Sat, 4 Dec 2010 16:07:54 -0500 Subject: [opensource-dev] Almost certainly not your fault... In-Reply-To: References: Message-ID: <201012041607.54660.gcanaday@gmail.com> On Saturday, December 04, 2010 11:30:55 am Ponzu wrote: > ...but I thought I should at least mention it. > > I have been experimenting with compilers on OS X. GCC 4.2 LLVM. Clang. > Self educational OS X stuff. > > Compile and link seems to work, but starting up Second Life leads to a > kernel panic. This is the only time I have ever seen OS X panic, so this > is a pretty cool accomplishment. > > FYI, LLVM is a very cool change to the compile-optimize-link chain. it > should lead to new and approved link-time optimizations. Clang, on the > other hand, is a new C++ parser front end. It is supposed to be much > faster than GCC. We shall see. > > regards, > ponzu You can get it to panic with faulty hardware, too. Happened to my powerbook G4 way back, when the airport died. Never ever saw it happen with software, so yeah that's a pretty crazy achievement. --GC From blindwanderer at gmail.com Sat Dec 4 13:16:48 2010 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sat, 4 Dec 2010 16:16:48 -0500 Subject: [opensource-dev] Autoupdater Flashback In-Reply-To: References: <000301cb9166$89097060$9b1c5120$@com> Message-ID: While the background updater is new, having an updater is not. In the past all that was required was a request to a URL and it would return to you the latest installer for the grid you specified. Will this old mechanism be phased out? I rather liked the ability to download the recommended client for an arbitrary grid. The URLs have been a fixture on my wiki user pages for years. On Fri, Dec 3, 2010 at 4:58 PM, Brad Kittenbrink (Brad Linden) < brad at lindenlab.com> wrote: > I have posted this info here: > https://wiki.secondlife.com/wiki/Viewer_Update_Service/Protocol > > -Brad > > > On Wed, Dec 1, 2010 at 6:46 AM, Kitty wrote: > >> Would it be possible to get the protocol specification for the updater >> service on the server-side? >> >> >> >> It?s always possible to work backwards from the code in the viewer, but it >> would be handy to just have an overview of the viewer<->web service >> exchanges :). >> >> >> >> Kitty >> >> >> >> *From:* opensource-dev-bounces at lists.secondlife.com [mailto: >> opensource-dev-bounces at lists.secondlife.com] *On Behalf Of *Brad >> Kittenbrink (Brad Linden) >> *Sent:* dinsdag 30 november 2010 22:34 >> *To:* Bunny Halberd >> *Cc:* opensource-dev at lists.secondlife.com >> *Subject:* Re: [opensource-dev] Autoupdater Flashback >> >> >> >> Oops, thanks for the heads-up. >> >> The background updater is new in viewer 2.4 (as it's not released in beta >> yet, it doesn't have release notes yet, so sorry for the surprise). >> Yesterday we deployed the server side work in preparation for the beginning >> of the 2.4 beta releases, and it turned on. Unfortunately we hadn't been >> paying attention to the Second Life Development channel, and there was some >> obsolete data in the database. >> >> Anyways, thanks again for testing this for us. We should be getting it >> fixed shortly. >> >> -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101204/8abece61/attachment.htm From Lance.Corrimal at eregion.de Sat Dec 4 14:29:19 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 4 Dec 2010 23:29:19 +0100 Subject: [opensource-dev] minimap broken in 2.3 and above? Message-ID: <201012042329.19916.Lance.Corrimal@eregion.de> Hi there, is it just my imagination, or is the minimap majorly broken in any 2.x viewer since 2.3-release? More often than not it simply refuses to load any ground textures, so the minimap looks like you're way out on open water... not useful for sailing at all. Is there already a jira for it? bye, LC From secret.argent at gmail.com Sat Dec 4 15:55:37 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 4 Dec 2010 17:55:37 -0600 Subject: [opensource-dev] Arrow Keys Always Move Me In-Reply-To: <201012032048.45074.gcanaday@gmail.com> References: <201012032048.45074.gcanaday@gmail.com> Message-ID: <06BA04E5-B1B0-42CD-91CE-9359DB731283@gmail.com> See STORM-560 for more details. On 2010-12-03, at 19:48, Glen Canaday wrote: > Hey, > > I'm a little curious - what's the expected behavior of "Arrow Keys Always Move > Me"? I was under the impression that this was meant to cause the arrow keys to > be the only movement keys, freeing up the rest of the keyboard for chat. I'm > wrong, aren't I? > > --GC > _______________________________________________ > 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 "Welcome back, Anonymous, we're glad to see you again!" From kf6kjg at gmail.com Sat Dec 4 20:28:32 2010 From: kf6kjg at gmail.com (Ricky) Date: Sat, 4 Dec 2010 20:28:32 -0800 Subject: [opensource-dev] minimap broken in 2.3 and above? In-Reply-To: <201012042329.19916.Lance.Corrimal@eregion.de> References: <201012042329.19916.Lance.Corrimal@eregion.de> Message-ID: I spend most of my time in region-wide sandboxes using whatever version (2.5.0.215253 at the moment) of the developer version is available when I get around to it, and I havent had a problem. However, take it with a grain of salt, as platforms tend to obstruct ground level.. (As they should.) Have you verified with viewers from the beta and development downloads? That could tell if what you are seeing is still in the codebase or whether it disappeared already. I figure that you have, just have to ask for clarification. :) Ricky Cron Stardust On Sat, Dec 4, 2010 at 2:29 PM, Lance Corrimal wrote: > Hi there, > > > is it just my imagination, or is the minimap majorly broken in any 2.x > viewer since 2.3-release? More often than not it simply refuses to > load any ground textures, so the minimap looks like you're way out on > open water... not useful for sailing at all. > > Is there already a jira for it? > > 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 > From Lance.Corrimal at eregion.de Sun Dec 5 02:42:51 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 5 Dec 2010 11:42:51 +0100 Subject: [opensource-dev] minimap broken in 2.3 and above? In-Reply-To: References: <201012042329.19916.Lance.Corrimal@eregion.de> Message-ID: <201012051142.51961.Lance.Corrimal@eregion.de> Am Sonntag, 5. Dezember 2010 schrieb Ricky: > I spend most of my time in region-wide sandboxes using whatever > version (2.5.0.215253 at the moment) of the developer version is > available when I get around to it, and I havent had a problem. > However, take it with a grain of salt, as platforms tend to > obstruct ground level.. (As they should.) > > Have you verified with viewers from the beta and development > downloads? That could tell if what you are seeing is still in the > codebase or whether it disappeared already. I figure that you have, > just have to ask for clarification. :) right now i'm seeing that behaviour in the "official" 2.3.x, in viewer-beta and viewer-development. Am building fresh builds of the latter two with recent source to verify. bye, LC > > Ricky > Cron Stardust > > On Sat, Dec 4, 2010 at 2:29 PM, Lance Corrimal > > wrote: > > Hi there, > > > > > > is it just my imagination, or is the minimap majorly broken in > > any 2.x viewer since 2.3-release? More often than not it simply > > refuses to load any ground textures, so the minimap looks like > > you're way out on open water... not useful for sailing at all. > > > > Is there already a jira for it? > > > > 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 From jhwelch at gmail.com Sun Dec 5 07:01:01 2010 From: jhwelch at gmail.com (Jonathan Welch) Date: Sun, 5 Dec 2010 10:01:01 -0500 Subject: [opensource-dev] Comments solicited -- distinguishing name vs message in chat Message-ID: Hey folks, This one just came to my attention -- a little change to be able to distinguish where the name in chat leaves off and where the message begins. With Display Names now active it's no longer easy to figure this out. Please take a look at this and put in a little comment on what you think. https://jira.secondlife.com/browse/VWR-24076 -Jonathan From sldev at catznip.com Sun Dec 5 12:53:37 2010 From: sldev at catznip.com (Kitty) Date: Sun, 5 Dec 2010 21:53:37 +0100 Subject: [opensource-dev] Comments solicited -- distinguishing name vs message in chat In-Reply-To: References: Message-ID: <000301cb94be$86b224f0$94166ed0$@com> It's https://jira.secondlife.com/browse/STORM-578 that needs to be reverted/redone (for chat toasts). There's https://jira.secondlife.com/browse/STORM-579 as well (for plain text chat history) and there seems to be a partial (un)fix at https://bitbucket.org/seth_productengine/storm-579/changeset/bdc0809e25a0 but it hasn't been pulled into viewer-development/viewer-beta yet I think. Kitty -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Jonathan Welch Sent: zondag 5 december 2010 16:01 To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Comments solicited -- distinguishing name vs message in chat Hey folks, This one just came to my attention -- a little change to be able to distinguish where the name in chat leaves off and where the message begins. With Display Names now active it's no longer easy to figure this out. Please take a look at this and put in a little comment on what you think. https://jira.secondlife.com/browse/VWR-24076 -Jonathan From arrehn at gmail.com Mon Dec 6 07:52:50 2010 From: arrehn at gmail.com (Arrehn Oberlander) Date: Mon, 6 Dec 2010 10:52:50 -0500 Subject: [opensource-dev] Comments solicited -- distinguishing name vs message in chat In-Reply-To: <000301cb94be$86b224f0$94166ed0$@com> References: <000301cb94be$86b224f0$94166ed0$@com> Message-ID: I've added similar functionality in firestorm last week. Names are colored and have their own preference color. I think the next step forward for plaintext chat is to fix the vertical line spacing issue that still appears to be neglected. On Sun, Dec 5, 2010 at 3:53 PM, Kitty wrote: > It's https://jira.secondlife.com/browse/STORM-578 that needs to be > reverted/redone (for chat toasts). > > There's https://jira.secondlife.com/browse/STORM-579 as well (for plain > text > chat history) and there seems to be a partial (un)fix at > https://bitbucket.org/seth_productengine/storm-579/changeset/bdc0809e25a0 > but it hasn't been pulled into viewer-development/viewer-beta yet I think. > > Kitty > > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Jonathan > Welch > Sent: zondag 5 december 2010 16:01 > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Comments solicited -- distinguishing name vs > message in chat > > Hey folks, > > This one just came to my attention -- a little change to be able to > distinguish where the name in chat leaves off and where the message > begins. With Display Names now active it's no longer easy to figure > this out. > > Please take a look at this and put in a little comment on what you think. > > https://jira.secondlife.com/browse/VWR-24076 > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/5486bd0a/attachment.htm From moriz.gupte at gmail.com Mon Dec 6 11:39:10 2010 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Mon, 6 Dec 2010 12:39:10 -0700 Subject: [opensource-dev] Support for external editors in viewer2 beta? Message-ID: Hello, I tried to find some documentation on 'support for external editors SL viewer beta' but could not find any. How do you use this feature? Any ideas? Thanks Ramesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/efdb43ab/attachment.htm From techiedavid at gmail.com Mon Dec 6 11:52:37 2010 From: techiedavid at gmail.com (David Simmons) Date: Mon, 6 Dec 2010 11:52:37 -0800 Subject: [opensource-dev] Support for external editors in viewer2 beta? In-Reply-To: References: Message-ID: https://jira.secondlife.com/browse/STORM-52? It mentions to that the editor can be specified: via "ExternalEditor" setting in settings.xml via LL_SCRIPT_EDITOR variable On Mon, Dec 6, 2010 at 11:39 AM, Moriz Gupte wrote: > Hello, > I tried to find some documentation on 'support for external editors SL > viewer beta' but could not find any. > How do you use this feature? Any ideas? > Thanks > Ramesh > > > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From akanevsky at productengine.com Mon Dec 6 13:46:25 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 6 Dec 2010 15:46:25 -0600 Subject: [opensource-dev] Daily Scrum Summary - Friday, December 3 Message-ID: Friday, December 3, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-151: kdu compression: Have compression working decently. W00t! Same settings as before though. Not too bad but I think we can do better compression wise and perf wise. Pushed changesets to the dev repo. - STORM-150: Updated kakadu upgrade wiki documentation. Pushed to review. Assigned to Q. *FUTURE* - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Merge Monkeying - All queues emptied, waiting to push many beta branch commits - Assorted internal stuff that consumed much time *FUTURE* - Document code review system on wiki - more internal stuff... *IMPEDIMENTS* - waiting for the beta branch to unlock... Q Linden ------------------------------ - OOO Esbee Linden ------------------------------ *PAST* - Reviewed integration queue list and specifically the target viewer version list - Moved STORM-564 to LEAP so Monroe can take a look at it - Discussed LEAP-20/SOCIAL-267 with Callum and Monroe (closed LEAP-20 as a dupe) - Talked to Wolfpup about STORM-236 (will follow up with the voice team) - Worked with Gez to identify STORM-722 - Started review Jonathan Yap's list of work from email - Moved VWR-18743 --> STORM-723 *FUTURE* - Prep for next sprint - Spend more time looking into Jonathan Yap's email list of work (I couldn't provide quick feedback on all tickets yesterday and will take some investigation) - Design discussion about saved layouts w/Q - Discuss color prefs with Q - Provided additional detail on STORM-236. I have contacted the Voice product owner so he is aware of the request and can weigh-in. He's away on vacation this week and into next week, so it may take a few days to hear back. *IMPEDIMENTS* - Still sick Paul ProductEngine ------------------------------ *PAST* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - WIP. Hard to give estimates... Hope to fix tomorrow. *FUTURE* - STORM-684 subtasks (fix transparency in some panels/floaters). *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log - WIP. Working on applying the preffered URL color to object and avatar names in chat. The problem is that underlining such SLURLs on mouse hover cannot be applied. *FUTURE* - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - WIP. Implemented save/ load to and from file of favorite landmarks names along with their global coords. But to use coordinates in login screen a lot of changes in login code are needed (and it's dangerous and will take a lot of time), so after discussion with Vadim decision was made to store SLURLs instead of coords in file, but it will require requests to server for each landmark in favorite. Figuring out a good way to get them in time. Estimate - 2.5-3d. *FUTURE* - Normal task STORM-34. - Implement mechanizm of retrieving slurls for all favorites beforehand, and updating them when changes occur. Start changing login panel comboboxes. *IMPEDIMENTS* - STORM-527 needs a new home Vadim Productengine ------------------------------ *PAST* Made additional fixes for: - Task STORM-676 (Color swatches inside transparent floater are not transparent). - Task STORM-677 (Texture pickers inside transparent floater are not transparent). - Bug STORM-432 (Trash button in People > My Friends tab can be moved). Fixed: - Task STORM-687 (Snapshot thumbnail in the Email Snapshot floater doesn't honor floater opacity settings). *FUTURE* - Continue with transparency-related fixes. *IMPEDIMENTS* - Our transparency-related work still hasn't been integrated into beta. - Will Esbee take a look at STORM-28? - Is there a way to assign STORM-564 to Monroe Linden? Andrey Productengine ------------------------------ *PAST* - re-ran smoke & integrity tests against Beta1 r215703 build - verified STORM-667 hotfix for beta - 2.4.0 bugfixes verification, see spreadsheet *FUTURE* - switch to the latest v-d build - verify integrated tickets and do some regression testing in scope of recent changes *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - Commented on code review system. - STORM-713 -- This should be fixed before a viewer is released. - STORM-523 - Could not reproduce myself or with another tester. Need a screen shot from the reporter. Reporter says she could reproduce this with my test object. Better way would be to send these notifications to local chat. - VWR-24053 (Start Location preference not always obeyed) *FUTURE* - [long range] - Update lsl wiki - remove Unsupported icon next to llTextBox. Timing of when to make this edit? *IMPEDIMENTS* - I need someone to assign VWR-24053 to me after converting it to Storm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/2b856944/attachment-0001.htm From akanevsky at productengine.com Mon Dec 6 13:53:05 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 6 Dec 2010 15:53:05 -0600 Subject: [opensource-dev] Daily Scrum Summary - Monday, December 6 Message-ID: Monday, December 6, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov - Scrum scrapped for sprint review and retrospective Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-151 : kdu compression: Prepared this for review and integration. Tested on Windows. Build on all platforms and provided binaries. Move to Review. - STORM-174 : Discussed with Andrew. There's no byte-code prod on the client with that patch (thankfully), it's all about fixing the "target" flag for scripts saved in inventory. We should do that but correctly. Commented in JIRA. - Tried out Review Board, devised a way to produce clean diffs from complex repo with lots of changes. - Updated wiki to document the use of --logperformance : https://wiki.secondlife.com/wiki/Performance_Tracking - Lots of email clean up... *FUTURE* - Merge Monkeying - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ - OOO - Vacation. Q Linden ------------------------------ *PAST* - SH-178 - Multiple internal policy discussions - Color UI - Beta updater *FUTURE* - Beta 2 - Triage - Crashhunters *IMPEDIMENTS* - a cold Esbee Linden ------------------------------ *PAST* - Reviewed integration queue list and made sure "target viewer version" is updated for merge monkey - Reviewed Jonathan's jira work list and provided feedback - STORM cleanup in Jira - VWR Triage - Discussed color prefs w/Q and re-opend STORM-584 - Viewer 2.4 Beta 1 release *FUTURE* - Prep for next sprint - Keep an eye out for tickets that require review - Update sketch for saved layouts and note in Jira - Design discussion about saved layouts w/Q - Discuss next steps for keyboard shortcuts w/Q *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - WIP. Estimate 16 hours *FUTURE* - STORM-622 *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log - Fixed. Sent for review. - BUG (STORM-378) Snapshot animation should be played when snapshot is actually taken, not sent - Fixed. Sent for review. - TASK (STORM-729) Cache favorites landmarks slurls for further saving without waiting for responses from server - WIP. Added retrieving SLURLs for Favorites and syncing them upon adding or rearranging Favorites. *FUTURE* - TASK (STORM-729) Cache favorites landmarks slurls for further saving without waiting for responses from server - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - Estimated: 1 day *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - WIP.Working on mechanizm of retrieving slurls for all favorites beforehand, and updating them when changes occur. In process of changing username and "Start at" controls in login screen. Resolving problems that appear. - Major task STORM-729 (Cache favorites landmarks slurls for further saving without waiting for responses from server). - - Created task, assigned to Sergey and brought him up to speed regarding this issue. Gave him a patch with my changes, cause they are not publicly available in the moment. *FUTURE* - Normal task STORM-34. - Finish with controls mentioned above and implement preferences needed for this task and their behavior. Integrate my and Sergey's. Estimate - 1 day. *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Task STORM-544 (Create preference to allow transparency to be modified): ** Made additional fix: changed default transparency for inactive floaters to 65%. - Task STORM-717 (Toasts don't honor floater transparency settings). - Fixed - Task STORM-690 (Second layer is visible when undocked panel is inactive and semitransparent): WIP. *FUTURE* - Complete STORM-690. *IMPEDIMENTS* - none Andrey Productengine ------------------------------ *PAST* - smoke & integrity testing of Beta1 2.4.0 r215891 against Windows, Linux, and OSX - verified CHOP-240 & STORM-716 *FUTURE* - switch to the latest v-d build - verify integrated tickets and do some regression testing in scope of recent changes *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - Researching more ideas and sending them to Esbee for consideration. - Writing code to convert settings.xml to a format that can be put into an updated Debug Settings wiki page. The current page is woefully out of date. - STORM-523 (Notification toasts overlay each other) - Made one more change. More testing needed. - Feel better long-term solution is to have system (OK type) messages sent to local chat, eliminating extra mouse clicks. - STORM-726 (Can't login to where preferences specify) -- fixed. *FUTURE* - STORM - 523 - Add link to new test viewer in a comment on the jira page. - STORM-737 (Add "+" control to Inventory Recent panel) - [long range] - Update lsl wiki - remove Unsupported icon next to llTextBox. Timing of when to make this edit? *IMPEDIMENTS* - STORM - 523 - Need url to test build of viewer from Merov. Oz sent me an email saying the build was finished but forgot to include the link to it. Wolfpup Lowenhar ------------------------------ *PAST* - worked @ in-world job and RL Job - emailed Esbee about VWR-18773 waiting on reply. *FUTURE* - work @ real job. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actualy work on code. - Right Hand - Trying to find something to actually work on. - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/e47c4101/attachment-0001.htm From angel_of_crimson at hotmail.com Mon Dec 6 16:39:45 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 6 Dec 2010 19:39:45 -0500 Subject: [opensource-dev] pasting into quick search Message-ID: Can someone see if they can repo this? On todays builds, if i click into an empty quick search bar (the one by the L$) and attempt to paste something using control-v, it doesn't let me paste. Instead it opens a drop box of everything ive previously searched for. however if i right click paste or if i enter something into the box first, I can use control v. Anyone else experiencing this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/731fa1e4/attachment.htm From gcanaday at gmail.com Mon Dec 6 17:03:01 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Mon, 6 Dec 2010 20:03:01 -0500 Subject: [opensource-dev] User Story - Shared Media Message-ID: <201012062003.01555.gcanaday@gmail.com> Thought I'd post this here, since a few people might remember me trying this from a while back: https://jira.secondlife.com/browse/VWR-24104 Got it wortking well enough, but can't right-click! User Story (OK, a copy/paste from the Jira): "When using a web-based VNC client to display a working desktop in SL, one would expect to be able to perform the same functions through VNC as through a standard desktop. There is no way to do that without being able to send mouse events other than the standard left click. I've included a screenshot that shows what happens when you right-click. To solve this, a key/click combo, such as "Alt+Shift+Click" or something, could be set up to send a standard right-click when the cursor is over a Shared Media-enable surface." --GC From trilobyte550m at gmail.com Mon Dec 6 19:00:54 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Mon, 6 Dec 2010 19:00:54 -0800 Subject: [opensource-dev] pasting into quick search In-Reply-To: References: Message-ID: <2D254D8A-E28C-49C8-9066-385EE13B3949@gmail.com> Search box working normally/as expected on Mac client (we use cmd-v in place of Windows' ctrl-v), build 216217. TriloByte Zanzibar On Dec 6, 2010, at 4:39 PM, Erin Mallory wrote: > Can someone see if they can repo this? > On todays builds, if i click into an empty quick search bar (the one by the L$) and attempt to paste something using control-v, it doesn't let me paste. Instead it opens a drop box of everything ive previously searched for. however if i right click paste or if i enter something into the box first, I can use control v. Anyone else experiencing this? > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/f7b5d317/attachment.htm From merov at lindenlab.com Mon Dec 6 20:57:33 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 6 Dec 2010 20:57:33 -0800 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available In-Reply-To: References: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Hi, On Sat, Dec 4, 2010 at 8:34 AM, Ponzu wrote: > A question about the static KDU issue. I believe this means that when I do > a build on my local machine, I do NOT have a KDU license. Is that true? > It's true: our Kakadu license doesn't extend to other developers. That being said you can get a license from Kakadu for your own use though it's not free (see http://www.kakadusoftware.com/index.php?option=com_content&task=blogcategory&id=6&Itemid=12for details). The good news with the new code though is that *if* you have a Kakadu license, you *can* build a viewer using KDU without requiring any special code from us: just drop the coresystem library in the libraries folder and a set of kdu headers in include/kdu and you're set. There's no need to reverse engineer the llkdu lib we provided before. I haven't documented that in detail though. If anyone is interested, please contact me. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101206/8a784b53/attachment.htm From q at lindenlab.com Tue Dec 7 07:41:21 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue, 7 Dec 2010 10:41:21 -0500 Subject: [opensource-dev] pasting into quick search In-Reply-To: References: Message-ID: <66563F0E-720D-4E57-B3FB-943912229C07@lindenlab.com> That was a bug I fixed last week. STORM-716. It seems to be fixed in both beta and viewer-development. Are you sure you're using the latest build? On Dec 6, 2010, at 7:39 PM, Erin Mallory wrote: > Can someone see if they can repo this? > On todays builds, if i click into an empty quick search bar (the one by the L$) and attempt to paste something using control-v, it doesn't let me paste. Instead it opens a drop box of everything ive previously searched for. however if i right click paste or if i enter something into the box first, I can use control v. Anyone else experiencing this? > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101207/e3851d2a/attachment.htm From chuckbaggettweb at gmail.com Tue Dec 7 08:13:41 2010 From: chuckbaggettweb at gmail.com (Chuck Baggett) Date: Tue, 7 Dec 2010 10:13:41 -0600 Subject: [opensource-dev] Is there any hope of not having the sidebar cover the bottom bar? In-Reply-To: <80102.29115.qm@web23904.mail.ird.yahoo.com> References: <80102.29115.qm@web23904.mail.ird.yahoo.com> Message-ID: Here's the jira issue I made about making the sidebar leave the bottom bar alone: VWR-24087 As a user, the bottom bar should remain the same size, never being altered by the sidebar. http://jira.secondlife.com/browse/VWR-24087 On Fri, Dec 3, 2010 at 2:02 AM, Hitomi Tiponi wrote: > That appears to have been a design decision. Suggest you raise it as an > issue if you feel you would like an alternative. I know that while most of > my users like the shortened sidebar some still prefer the full-length bar - > so it may be better as an option. > Hitomi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101207/97b9d898/attachment.htm From dave at meadowlakearts.com Tue Dec 7 08:45:18 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Tue, 07 Dec 2010 10:45:18 -0600 Subject: [opensource-dev] Any hope of STORM-727 getting a little love? Message-ID: <4CFE649E.2090804@meadowlakearts.com> It's graded "Minor" but I really think it falls into the "Major" category - Functionality is seriously broken (landmark creation) and the only workaround is to relog. I also think its importance is increased by the fact that v2 (and this bug has been around since 2.0) is supposed to provide a "better new user experience" and this is a bug that will most seriously impact new users. It's minor for longtimers who already have a well populated and pretty static folder of landmarks but for new users having the places tab cease functioning every time they create a landmark is a much more significant impact. Dave. From akanevsky at productengine.com Tue Dec 7 11:47:45 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 7 Dec 2010 13:47:45 -0600 Subject: [opensource-dev] Any hope of STORM-727 getting a little love? In-Reply-To: <4CFE649E.2090804@meadowlakearts.com> References: <4CFE649E.2090804@meadowlakearts.com> Message-ID: Dave, there's a very good chance it will get love in this sprint :) a 2010/12/7 Dave Booth > It's graded "Minor" but I really think it falls into the "Major" > category - Functionality is seriously broken (landmark creation) and the > only workaround is to relog. I also think its importance is increased by > the fact that v2 (and this bug has been around since 2.0) is supposed to > provide a "better new user experience" and this is a bug that will most > seriously impact new users. It's minor for longtimers who already have a > well populated and pretty static folder of landmarks but for new users > having the places tab cease functioning every time they create a > landmark is a much more significant impact. > > Dave. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101207/291a00cf/attachment-0001.htm From elllamcmahon at googlemail.com Tue Dec 7 12:19:10 2010 From: elllamcmahon at googlemail.com (Ellla McMahon) Date: Tue, 7 Dec 2010 20:19:10 +0000 Subject: [opensource-dev] pasting into quick search In-Reply-To: <66563F0E-720D-4E57-B3FB-943912229C07@lindenlab.com> References: <66563F0E-720D-4E57-B3FB-943912229C07@lindenlab.com> Message-ID: The fix version on STORM-716 is Second Life 2.4.0 (215891) Dec 2 2010 14:24:59 (Second Life Beta Viewer) But VWR-24070 reports this issue on Second Life 2.5.0 (216008) Dec 3 2010 06:12:47 (Second Life Developer) Not sure what this indicates !! :)) On 7 December 2010 15:41, Kent Quirk (Q Linden) wrote: > That was a bug I fixed last week. STORM-716. > > It seems to be fixed in both beta and viewer-development. Are you sure > you're using the latest build? > > > On Dec 6, 2010, at 7:39 PM, Erin Mallory wrote: > > Can someone see if they can repo this? > On todays builds, if i click into an empty quick search bar (the one by the > L$) and attempt to paste something using control-v, it doesn't let me > paste. Instead it opens a drop box of everything ive previously searched > for. however if i right click paste or if i enter something into the box > first, I can use control v. Anyone else experiencing this? > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101207/31c89288/attachment.htm From tateru at taterunino.net Tue Dec 7 20:32:24 2010 From: tateru at taterunino.net (Tateru Nino) Date: Wed, 08 Dec 2010 15:32:24 +1100 Subject: [opensource-dev] Any hope of STORM-727 getting a little love? In-Reply-To: <4CFE649E.2090804@meadowlakearts.com> References: <4CFE649E.2090804@meadowlakearts.com> Message-ID: <4CFF0A58.8000403@taterunino.net> I'd generally grade that as a showstopper. Anything that needs the user to relog or restart to restore normal functionality is, essentially, requiring the user to restart their show. It's a showstopper for the user. On 8/12/2010 3:45 AM, Dave Booth wrote: > It's graded "Minor" but I really think it falls into the "Major" > category - Functionality is seriously broken (landmark creation) and the > only workaround is to relog. I also think its importance is increased by > the fact that v2 (and this bug has been around since 2.0) is supposed to > provide a "better new user experience" and this is a bug that will most > seriously impact new users. It's minor for longtimers who already have a > well populated and pretty static folder of landmarks but for new users > having the places tab cease functioning every time they create a > landmark is a much more significant impact. > > Dave. > _______________________________________________ > 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 > -- Tateru Nino http://dwellonit.taterunino.net/ From kf6kjg at gmail.com Tue Dec 7 23:28:39 2010 From: kf6kjg at gmail.com (Cron Stardust) Date: Wed, 08 Dec 2010 07:28:39 -0000 Subject: [opensource-dev] Review Request: STORM-34 As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be. In-Reply-To: <20101206163320.10133.77693@domU-12-31-38-00-90-68.compute-1.internal> References: <20101206163320.10133.77693@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101208072839.10132.40902@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-06 08:33:21, Seth ProductEngine wrote: > > Looks good for a first version of the task implementation, considering the issues mentioned in the description. Agreed. The code looks clean. (As expected from the pro's! :D ) Thought I had found a style issue, but double checked the style guide (no guidance found there,) and then checked similar code and found the same style. So no problem. :) - Cron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/4/#review14 ----------------------------------------------------------- On 2010-12-06 08:00:40, Andrew ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/4/ > ----------------------------------------------------------- > > (Updated 2010-12-06 08:00:40) > > > Review request for Viewer. > > > Summary > ------- > > Saving of user's favorites into file and showing them in "Start at" combobox on login screen was implemented. > > > Implementation details: > > - File is saved on exit from viewer and not immediately on changes as was written in spec. It is done to make this file consistent with favorites order: order of favorites is saved on exit, > so if favorites info is saved in other moment earlier, crashing viewer or other unexpected way of finishing its work (i.e. via Windows task bar) would cause inconsistence between favorites order > saved per account and one from this new file. > > - File is saved in user_settings\stored_favorites.xml. > > - If you uncheck the option in Preferences and press OK, the file gets immediately deleted (according to spec). > > > Issues that require further changes: > > - Currently only favorites of last logged in user are shown in login screen. Showing favorites of multiple users will be implemented later when design for it is approved by Esbee. > > - Preference is now global for all users, because design states it may be changed before login, and we don't have account info at the moment. But it doesn't seem to be a good idea, so changes in design are needed. > > - Currently the way of retrieving SLURLs needs optimization in a separate ticket. > > More detailed design approved by Esbee is needed to develop it further, perhaps in new tickets. > > > This addresses bug storm-34. > http://jira.secondlife.com/browse/storm-34 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml e843e274fa58 > indra/newview/llfavoritesbar.cpp e843e274fa58 > indra/newview/llfloaterpreference.h e843e274fa58 > indra/newview/llfloaterpreference.cpp e843e274fa58 > indra/newview/llpanellogin.h e843e274fa58 > indra/newview/llpanellogin.cpp e843e274fa58 > indra/newview/llviewerinventory.cpp e843e274fa58 > indra/newview/skins/default/xui/en/notifications.xml e843e274fa58 > indra/newview/skins/default/xui/en/panel_preferences_privacy.xml e843e274fa58 > > Diff: http://codereview.secondlife.com/r/4/diff > > > Testing > ------- > > > Thanks, > > Andrew > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101208/25888978/attachment.htm From akanevsky at productengine.com Wed Dec 8 00:07:26 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 8 Dec 2010 02:07:26 -0600 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, December 7 Message-ID: Tuesday, December 7, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov - Sprint 9 planning today Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - Merge Monkeying mostly - Helped DNOC with a map bug - Sprint closing *FUTURE* - Merge Monkeying - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ - OOO - Vacation. Q Linden ------------------------------ *PAST* - Color UI - Internal administrivia - Discussion of DN-202 - Beta *FUTURE* - Meetings - Triage *IMPEDIMENTS* - a cold Esbee Linden ------------------------------ *PAST* - Reviewed integration queue list and made sure "target viewer version" is updated for merge monkey - Added multiple user design detail around STORM-34 (list of favorites available on login screen) - Looked into folder sorting as reported in STORM-219 (Residents wish to also sort folders by date in addition to name) - STORM cleanup in Jira - VWR Triage *FUTURE* - Meetings - Snowstorm and Viewer presentation prep - Uploaded sketches of saved layouts - Provide input on kb shortcuts - Review integration queue list and made sure "target viewer version" is updated for merge monkey - Discuss folder sorting as reported in STORM-219 (Residents wish to also sort folders by date in addition to name) with Q *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - Traditionally WIP. Implementing solution. Tomorrow will finish and hope it'll work. ** Estimate ~ 4h if solution will work. *FUTURE* - TASK STORM- 622 *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - TASK (STORM-729) Cache favorites landmarks slurls for further saving without waiting for responses from server - Fixed. - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - WIP. Have to enable setting color swatch opacity via slider in preferences. *FUTURE* - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - Estimated: 1 day *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - - Finished single-user implementation and sent for review. Special thanks to Sergey for help with this one :) - Normal bug STORM-726 (I do not get logged into where my preferences specify I should go). - - Reviewed and approved. *FUTURE* - Major bug STORM-728 (Viewer crashes while trying to send Snapshot to Email in mouselook mode). *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Reported bug STORM-731 (Crash in LLRemoteParcelInfoProcessor::addObserver). - Task STORM-690 (Second layer is visible when undocked panel is inactive and semitransparent): - - Fixed. - Task STORM-730 (Voice control panel doesn't honor active floater opacity setting): - Fixed. *FUTURE* - Task STORM-695 (Texture preview doesn't follow opacity settings). - Task STORM-686 (Transparency settings aren't applied to the map preview inside Map floater). *IMPEDIMENTS* - We can't work on severe bug STORM-524 (When I purchase Linden Dollars, I have to close the viewer and restart it in order for the Lindens to appear in my account) because we reside outside US. A Linden should take a look. - We can't work on major bug STORM-706 (OSX-specific: SLVoice quit unexpectedly) because we have no Mac devs. Andrey Productengine ------------------------------ *PAST* - picked up v-d build r216151 - integrated tickets verification - test plan design for Floaters Opacity - Preferences test plan revising *FUTURE* - regression testing in scope of changes - finish with Preferences test plan review *IMPEDIMENTS* - none Jonathan Yap ------------------------------ *PAST* - Wrote code to convert settings.xml to a format that can be put into an updated Debug Settings wiki page. Found 1 pair of unnecessary tags, 1 missing value, about 3 duplicated entries and 1 triplicated entry. Wrote vwr-24100 - Sent project list to Esbee, so she can see at a glance the status of what I need feedback on. - STORM-523 (Notification toasts overlay each other) - Awaiting results from testers. - STORM-737 (Add "+" control to Inventory Recent panel) -- finished *FUTURE* [long range] - Update lsl wiki - Change Unsupported icon next to llTextBox to New Feature. *IMPEDIMENTS* - STORM - 523 -- cannot read EXT-4149 to see why messages are no longer sent to chat. Wolfpup Lowenhar ------------------------------ *PAST* - worked @ in-world job and RL Job - emailed Esbee waiting on reply. *FUTURE* - work @ real job. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actualy work on code. - Right Hand - Trying to find something to actualy work on. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101208/71805587/attachment-0001.htm From esbee at lindenlab.com Wed Dec 8 12:24:28 2010 From: esbee at lindenlab.com (Sarah (Esbee) Kuehnle) Date: Wed, 8 Dec 2010 15:24:28 -0500 Subject: [opensource-dev] Snowstorm Sprint 9 Message-ID: Hi all, We've kicked off Sprint 9 for the Snowstorm Team. Here's a link to our task board for this sprint (hopefully the link will work!): https://jira.secondlife.com/secure/TaskBoard.jspa?selectedBoardId=&type=VB&selectedProjectId=10244&colPage=1 Q and I are in the process of triaging additional tickets for this sprint that might be of interest to the community. I'll send out another note once we've got some of that sorted out. --Esbee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101208/4603e8a0/attachment.htm From lee.ponzu at gmail.com Wed Dec 8 12:48:39 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 8 Dec 2010 15:48:39 -0500 Subject: [opensource-dev] Destination Guide Categories not working... Message-ID: Open Sidebar, and hand of SL icon Click Open Destination Guide. Click on the Category: All pop down. Select one of the items. So far as I can tell, clicking on a category doesn't do anything. No highlighting, no list refresh, no click...nada. I don't see a relevant Jira. This happens with SL beta and SL V2. If someone can point me at the relevant source files, I can take a look at it. regards, lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101208/3a7b6b22/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2010-12-08 at 3.43.13 PM.png Type: image/png Size: 99983 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101208/3a7b6b22/attachment-0001.png From techiedavid at gmail.com Wed Dec 8 14:45:37 2010 From: techiedavid at gmail.com (David Simmons) Date: Wed, 8 Dec 2010 14:45:37 -0800 Subject: [opensource-dev] Has anyone revisited the Puppeteering using the MS Kinect camera? Message-ID: http://www.popsci.com/diy/article/2010-11/five-hacks-free-microsofts-kinect-xbox http://wiki.secondlife.com/wiki/Puppeteering http://svn.secondlife.com/svn/linden/branches/2008/Puppeteering080323/ -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From merov at lindenlab.com Wed Dec 8 21:59:58 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 09 Dec 2010 05:59:58 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance Message-ID: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). I modified the tooltip to reflect this new functionality. This addresses bug STORM-524. http://jira.secondlife.com/browse/STORM-524 Diffs ----- indra/newview/llstatusbar.h 094773a5a314 indra/newview/llstatusbar.cpp 094773a5a314 indra/newview/skins/default/xui/en/panel_status_bar.xml 094773a5a314 Diff: http://codereview.secondlife.com/r/6/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/caae7c09/attachment.htm From akanevsky at productengine.com Thu Dec 9 00:39:58 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 9 Dec 2010 02:39:58 -0600 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, December 8 Message-ID: Wednesday, December 8, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov - Sprint 9 planning poker today Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - Sprint planning - Office Hour - STORM-706 : SLVoice crash : Investigated. Apparently "fixed" switching back to vivox 3.1. Need to find out why we updated to 3.2. *FUTURE* - Merge Monkeying - STORM-706 : SLVoice crash : decision on this - STORM-524 : L$ balance display : investigate and fix - STORM-453 : libcurl : just inherited that one... - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ - OOO - Vacation. Q Linden ------------------------------ *PAST* - Snowstorm planning - Office hour - Review backlog - Being sick *FUTURE* - Snowstorm triage *IMPEDIMENTS* - sick means i don't work extra hours Esbee Linden ------------------------------ *PAST* - Meetings - Reviewed integration queue list and made sure "target viewer version" is updated for merge monkey - Snowstorm Office Hour - VWR Triage *FUTURE* - Meetings - Snowstorm and Viewer presentation prep - Uploaded sketches of saved layouts - Review integration queue list and made sure "target viewer version" is updated for merge monkey - Snowstorm Triage w/Q - Design work for Sprint 9 *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - WIP. Completed 90%. Good day. Finished implementing my idea. Seems works fine. But it is a draft version. There is one resizing problem left, but it's not very serious. I think it'll take about 4 hours to fix it. And about 4-5 hours to make a final version of fix. In total, estimate ~8 - 9 h. *FUTURE* - STORM-622 *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - TASK (STORM-34) As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be. - Investigated the issue with favorites list not saving if at least one of the landmarks is not valid. After discussion with Andrew decided to remove the check for all landmarks to have the corresponding SLURLs for now. - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - WIP. Working on color swatch transparency setting to be reflected by a color swatch. Currently color swatches do not support alpha setting. *FUTURE* - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal bug STORM-708 (Speak button is always disabled after deleting ".secondlife" settings folder). - - Closed as cannot reproduce. - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Found and fixed a problem in current version of fix. Implementing saving favorites for multiple users. 60% ready. Estimate- 6 hours. *FUTURE* - Finish STORM-34. - Crititcal bug STORM-525 (Runtime Error message from the Microsoft Visual C++ Runtime Library eventually leads to Crash). *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* *PAST* Fixed: - Task STORM-732 (Voice Morphing floater is opaque on first open). - Task STORM-733 (Build Tools floaters are opaque on first open). - Task STORM-735 (Group icons are opaque in inactive People > My Groups tab). - Bug STORM-710 (Small, empty drop down menu is opened after pressing downArrow button in the Search text field). Resolved as not reproducible: - Task STORM-734 (Report Abuse message is opaque on first open). - Task STORM-740 (Email Snapshot floater is opaque on first open). - Bug STORM-736 (partly no opacity on edit dialog). WIP: - Bug STORM-436 (Favorites overflow list appears if select Teleport in the favorites context menu). *FUTURE* - Fix STORM-436, switch to other bugs in v-b/v-d bug queues. *IMPEDIMENTS* Someone more experienced with OpenGL than us needs to take a look at these issues: - Task STORM-686 (Transparency settings aren't applied to the map preview inside Map floater). - Task STORM-695 (Texture preview doesn't follow opacity settings). - Task STORM-675 (Web page inside web browser floater is not transparent). Andrey Productengine ------------------------------ *PAST* - picked up Beta2 2.4.0 r216220 build - passed smoke & integrity tests - started regression testing of Beta2 build *FUTURE* - finish regression testing of Beta2 build *IMPEDIMENTS* - none -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/c898ce05/attachment-0001.htm From opensourceobscure at gmail.com Thu Dec 9 00:46:51 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Thu, 9 Dec 2010 09:46:51 +0100 Subject: [opensource-dev] Has anyone revisited the Puppeteering using the MS Kinect camera? In-Reply-To: References: Message-ID: On Wed, Dec 8, 2010 at 23:45, David Simmons wrote: > > http://www.popsci.com/diy/article/2010-11/five-hacks-free-microsofts-kinect-xbox > http://wiki.secondlife.com/wiki/Puppeteering > http://svn.secondlife.com/svn/linden/branches/2008/Puppeteering080323/ If I remember correctly, Puppeteering features and testing requires dedicate server software; a SL region running that software had been available on Preview Grid for a short time, but then it was put offline (and had never been updated anyway) opensource obscure From vsavchuk at productengine.com Thu Dec 9 01:41:06 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 09 Dec 2010 09:41:06 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> References: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101209094106.9034.21563@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/#review17 ----------------------------------------------------------- Ship it! Looks fine to me. - Vadim On 2010-12-08 21:59:58, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/6/ > ----------------------------------------------------------- > > (Updated 2010-12-08 21:59:58) > > > Review request for Viewer. > > > Summary > ------- > > Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). > I modified the tooltip to reflect this new functionality. > > > This addresses bug STORM-524. > http://jira.secondlife.com/browse/STORM-524 > > > Diffs > ----- > > indra/newview/llstatusbar.h 094773a5a314 > indra/newview/llstatusbar.cpp 094773a5a314 > indra/newview/skins/default/xui/en/panel_status_bar.xml 094773a5a314 > > Diff: http://codereview.secondlife.com/r/6/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/5cf72878/attachment.htm From wolfpup67 at earthlink.net Thu Dec 9 05:46:19 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 09 Dec 2010 13:46:19 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> References: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101209134619.10133.35899@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/#review18 ----------------------------------------------------------- This will be a much appreciated feature as it means residents will no longer have to request someone send them a single L$ to force a refresh as the will be able to do it themselves simply by clicking on their balance. - Wolfpup On 2010-12-08 21:59:58, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/6/ > ----------------------------------------------------------- > > (Updated 2010-12-08 21:59:58) > > > Review request for Viewer. > > > Summary > ------- > > Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). > I modified the tooltip to reflect this new functionality. > > > This addresses bug STORM-524. > http://jira.secondlife.com/browse/STORM-524 > > > Diffs > ----- > > indra/newview/llstatusbar.h 094773a5a314 > indra/newview/llstatusbar.cpp 094773a5a314 > indra/newview/skins/default/xui/en/panel_status_bar.xml 094773a5a314 > > Diff: http://codereview.secondlife.com/r/6/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/c6ebbd3b/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 9 05:55:34 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 09 Dec 2010 13:55:34 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> References: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101209135534.9032.73351@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/#review19 ----------------------------------------------------------- Ship it! Didn't test, but code looks good. indra/newview/llstatusbar.cpp consider to break long comments onto several lines Other then that, go for it! - Boroondas On 2010-12-08 21:59:58, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/6/ > ----------------------------------------------------------- > > (Updated 2010-12-08 21:59:58) > > > Review request for Viewer. > > > Summary > ------- > > Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). > I modified the tooltip to reflect this new functionality. > > > This addresses bug STORM-524. > http://jira.secondlife.com/browse/STORM-524 > > > Diffs > ----- > > indra/newview/llstatusbar.h 094773a5a314 > indra/newview/llstatusbar.cpp 094773a5a314 > indra/newview/skins/default/xui/en/panel_status_bar.xml 094773a5a314 > > Diff: http://codereview.secondlife.com/r/6/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/40aca4f4/attachment.htm From malachi at tamzap.com Thu Dec 9 06:11:10 2010 From: malachi at tamzap.com (Malachi Prophit) Date: Thu, 09 Dec 2010 09:11:10 -0500 Subject: [opensource-dev] STORM-524 In-Reply-To: References: Message-ID: Couldn't it just be done by calling LLStatusBar::sendMoneyBalanceRequest(); in bool LLAppViewer::mainLoop()? or is there something i am missing? From wolfpup67 at earthlink.net Thu Dec 9 06:28:16 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 9 Dec 2010 09:28:16 -0500 Subject: [opensource-dev] STORM-524 In-Reply-To: References: Message-ID: <002301cb97ad$520a8a70$f61f9f50$@net> What your suggesting would make it to 'spamy' to the servers because if the viewer was sending a refresh request even just once say every 1800 frames considering there are at least 10K users online at any given moment that that could eventually cause a data request overload to the servers and thus generate more 'lag' for the user which by making is a manual request this can be avoided. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Malachi Prophit Sent: Thursday, December 09, 2010 9:11 AM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] STORM-524 Couldn't it just be done by calling LLStatusBar::sendMoneyBalanceRequest(); in bool LLAppViewer::mainLoop()? or is there something i am missing? _______________________________________________ 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3305 - Release Date: 12/09/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/c5a98068/attachment-0001.htm From malachi at tamzap.com Thu Dec 9 10:48:34 2010 From: malachi at tamzap.com (Malachi Prophit) Date: Thu, 09 Dec 2010 13:48:34 -0500 Subject: [opensource-dev] STORM-524 In-Reply-To: <002301cb97ad$520a8a70$f61f9f50$@net> References: <002301cb97ad$520a8a70$f61f9f50$@net> Message-ID: I tested my idiotic idea and it crashes nearly instantly lol. I decided to try with a timer. Roughly every 10-15 minutes. Works like a charm. I understand the click to refresh idea of keeping lag down BUT wouldnt it just be easier to automatically refresh the balance? On Thu, 09 Dec 2010 09:28:16 -0500, WolfPup Lowenhar wrote: > What your suggesting would make it to 'spamy' to the servers because if > the > viewer was sending a refresh request even just once say every 1800 frames > considering there are at least 10K users online at any given moment that > that could eventually cause a data request overload to the servers and > thus > generate more 'lag' for the user which by making is a manual request this > can be avoided. > > > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Malachi > Prophit > Sent: Thursday, December 09, 2010 9:11 AM > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] STORM-524 > > > Couldn't it just be done by calling > LLStatusBar::sendMoneyBalanceRequest(); in bool LLAppViewer::mainLoop()? > or is there something i am missing? > _______________________________________________ > 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 > > _____ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1170 / Virus Database: 426/3305 - Release Date: 12/09/10 > -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From akanevsky at productengine.com Thu Dec 9 11:23:33 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 9 Dec 2010 13:23:33 -0600 Subject: [opensource-dev] Daily Scrum Summary - Thursday, December 9 Message-ID: Thursday, December 9, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-706 : SLVoice crash : Posted a patch (rollback vivox to 3.1 for Mac). Moved to Review (assigned to Q) - STORM-524 : L$ balance display : Implemented a "click to refresh" solution. Moved to Review (assigned to Vadim) *FUTURE* - Merge Monkeying - STORM-524 : L$ balance display : take feedback into account and submit again - STORM-453 : libcurl : just inherited that one... - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ - OOO - Vacation. Q Linden ------------------------------ - OOO - medical Esbee Linden ------------------------------ *PAST* - Meetings - Reviewed integration queue list and made sure "target viewer version" is updated for merge monkey - VWR Triage *FUTURE* - Meetings - Snowstorm and Viewer presentations prep - Upload sketches of saved layouts - Review integration queue list and made sure "target viewer version" is updated for merge monkey - Snowstorm Triage w/Q - Design work for Sprint 9 - Closed STORM-686, -695, & -675 as expected behavior. *IMPEDIMENTS* - Lots of meetings Paul ProductEngine ------------------------------ *PAST* - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - Fixed. Tomorrow will send for a review. *FUTURE* - STORM-625 (Multiple cut-offs in the Preferances floater if UI size differs from 1.0) *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - TASK (STORM-584) Fix color and opacity setting for Bubble Chat - Fixed. Sent for review. - BUG (STORM-579) Resident SLURL font color doesn't match Chat preferences for plain text Nearby Chat log - Set back to fixed. Re-opened STORM-578 instead. - BUG (STORM-578) SLURL font color in the nearby chat toast doesn't respect Chat preferences - Fixed. Sent for review. *FUTURE* - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - Estimated: 1 day *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Almost finished implementation, but encountered a problem with resizing "Start at" combobox in list. Searching for a way to fix it. Estimate- 3 hours. *FUTURE* - Finish STORM-34. - Crititcal bug STORM-525 (Runtime Error message from the Microsoft Visual C++ Runtime Library eventually leads to Crash). *IMPEDIMENTS* - none Vadim Productengine ------------------------------ *PAST* - Fixed: - Bug STORM-436 (Favorites overflow list appears if select Teleport in the favorites context menu). - Bug STORM-727 (Close and "<=" buttons are disabled when create new Landmark). - Bug STORM-529 (Undo feature missing from BUILD menu in VIEWER SL2.1). - Task STORM-766 (Day cycling image doesn't follow opacity settings). - Resolved as not reproducible: - Task STORM-768 (Script Error floater appears opaque). - Task STORM-765 (llDialog, llGiveInventory, llGotoURL messages are opaque on first open). - Task STORM-769 (Sell Land floater appears always opaque). - Task STORM-767 (Media Settings Preview doesn't follow opacity settings). - Task STORM-764 (Voice Notification is opaque on first open). - Task STORM-770 (Top Scripts & Top Colliders floaters open opaque). - Provided estimates for most sprint 9 tasks. *FUTURE* - Continue with 2.4 bugs or pick something from sprint 9. *IMPEDIMENTS* Someone more experienced with OpenGL than us needs to take a look at these issues: - Task STORM-686 (Transparency settings aren't applied to the map preview inside Map floater). - Task STORM-695 (Texture preview doesn't follow opacity settings). - Task STORM-675 (Web page inside web browser floater is not transparent). Andrey Productengine ------------------------------ *PAST* - finished Beta2 2.4.0 r216220 testing, see shared spreadsheet in the IQA-45 *FUTURE* - pickup next v-d- build and verify integrated tickets - complete Preferences TP revision *IMPEDIMENTS* - STORM-378 Jonathan Yap ------------------------------ *PAST* - Tried to use codereview + postreview command. Got message: Unable to log in: HTTP 404 Will wait for Oz to publish instructions on the wiki. - STORM-737 - investigated reported problem (bug in permissions processing). Determined it is unrelated to this change. Gave jira # of this issue to Wolfpup. *FUTURE* - Write jira on object notification toasts workflow/design flaw. - [long range] Update lsl wiki - Change Unsupported icon next to llTextBox to New Feature. *IMPEDIMENTS* - None Wolfpup Lowenhar ------------------------------ *PAST* - worked @ in-world job & real job - Attended Sprint planing meeting. - Attened Esbee's OH - Emailed Esbee and Q concerning STORM-2 . *FUTURE* - Looking for something to actualy work on in the sprint. - Try again to build mesh-development locally and see if still getting same results, unless have something to work on in v-d. - Wonders if it will build in other OS environments and if the mesh team is realy interested in the fact that it is not building in an OS environment. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actualy work on code. - Right Hand(it is slowly healing but will take time since it is the tip of middle finger) - Not having something to actualy work on yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/22c6a7f0/attachment-0001.htm From vsavchuk at productengine.com Thu Dec 9 11:51:47 2010 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Thu, 9 Dec 2010 21:51:47 +0200 Subject: [opensource-dev] [SNOWSTORM] Daily Scrum Summary - Thursday, December 9 In-Reply-To: References: Message-ID: Hi Wolfpup. On Thu, Dec 9, 2010 at 9:23 PM, Anya Kanevsky wrote: > Wolfpup Lowenhar > ------------------------------ > > *PAST* > > - worked @ in-world job & real job > - Attended Sprint planing meeting. > - Attened Esbee's OH > - Emailed Esbee and Q concerning STORM-2 . > > PE is taking STORM-2. Was there anything in the email that you would like to share with us? Thanks, -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/4f31e2ce/attachment.htm From merov at lindenlab.com Thu Dec 9 11:55:40 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 09 Dec 2010 19:55:40 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> References: <20101209055958.9038.76056@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101209195540.10132.75120@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/ ----------------------------------------------------------- (Updated 2010-12-09 11:55:40.026264) Review request for Viewer. Changes ------- I added some LLStatusBar::sendMoneyBalanceRequest() calls in few L$ UI that didn't do it. Hope it'll catch them all. Summary ------- Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). I modified the tooltip to reflect this new functionality. This addresses bug STORM-524. http://jira.secondlife.com/browse/STORM-524 Diffs (updated) ----- indra/newview/llbuycurrencyhtml.cpp 25bd6007e3d2 indra/newview/llfloaterbuycurrency.cpp 25bd6007e3d2 indra/newview/llfloaterbuycurrencyhtml.cpp 25bd6007e3d2 indra/newview/llstatusbar.h 25bd6007e3d2 indra/newview/llstatusbar.cpp 25bd6007e3d2 indra/newview/skins/default/xui/en/panel_status_bar.xml 25bd6007e3d2 Diff: http://codereview.secondlife.com/r/6/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/5e723977/attachment.htm From lee.ponzu at gmail.com Thu Dec 9 13:06:31 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 9 Dec 2010 16:06:31 -0500 Subject: [opensource-dev] STORM-524 In-Reply-To: References: <002301cb97ad$520a8a70$f61f9f50$@net> Message-ID: Be sure to comment the relevant code to discourage TPV developers from putting in auto-refresh at a rate that might upset the servers. ponzu On Thu, Dec 9, 2010 at 1:48 PM, Malachi Prophit wrote: > I tested my idiotic idea and it crashes nearly instantly lol. I decided to > try with a timer. Roughly every 10-15 minutes. Works like a charm. I > understand the click to refresh idea of keeping lag down BUT wouldnt it > just be easier to automatically refresh the balance? > > > On Thu, 09 Dec 2010 09:28:16 -0500, WolfPup Lowenhar > wrote: > > > What your suggesting would make it to 'spamy' to the servers because if > > the > > viewer was sending a refresh request even just once say every 1800 frames > > considering there are at least 10K users online at any given moment that > > that could eventually cause a data request overload to the servers and > > thus > > generate more 'lag' for the user which by making is a manual request this > > can be avoided. > > > > > > From: opensource-dev-bounces at lists.secondlife.com > > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of > Malachi > > Prophit > > Sent: Thursday, December 09, 2010 9:11 AM > > To: opensource-dev at lists.secondlife.com > > Subject: [opensource-dev] STORM-524 > > > > > > Couldn't it just be done by calling > > LLStatusBar::sendMoneyBalanceRequest(); in bool LLAppViewer::mainLoop()? > > or is there something i am missing? > > _______________________________________________ > > 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 > > > > _____ > > > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 10.0.1170 / Virus Database: 426/3305 - Release Date: 12/09/10 > > > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/5a747bde/attachment.htm From sl.nicky.ml at googlemail.com Thu Dec 9 13:43:34 2010 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Thu, 9 Dec 2010 22:43:34 +0100 Subject: [opensource-dev] Any hope of STORM-727 getting a little love? In-Reply-To: <4CFF0A58.8000403@taterunino.net> References: <4CFE649E.2090804@meadowlakearts.com> <4CFF0A58.8000403@taterunino.net> Message-ID: It's pesky, isn't it? :) Incidentally it bit me as well this week. Patch attached. Not sure if it is really the 100% golden way, but it works good for me. Maybe someone can make good use of the patch. Cheers, Nicky -------------- next part -------------- A non-text attachment was scrubbed... Name: storm-727 Type: application/octet-stream Size: 661 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/1e3d319a/attachment.obj From malachi at tamzap.com Thu Dec 9 15:28:59 2010 From: malachi at tamzap.com (Malachi Prophit) Date: Thu, 09 Dec 2010 18:28:59 -0500 Subject: [opensource-dev] STORM-524 In-Reply-To: References: <002301cb97ad$520a8a70$f61f9f50$@net> Message-ID: I do not normally release patches. However I do from time to time share code with other developers but they usually just develop for personal use as well. On Thu, 09 Dec 2010 16:06:31 -0500, Ponzu wrote: > Be sure to comment the relevant code to discourage TPV developers from > putting in auto-refresh at a rate that might upset the servers. > > ponzu > > On Thu, Dec 9, 2010 at 1:48 PM, Malachi Prophit > wrote: > >> I tested my idiotic idea and it crashes nearly instantly lol. I decided >> to >> try with a timer. Roughly every 10-15 minutes. Works like a charm. I >> understand the click to refresh idea of keeping lag down BUT wouldnt it >> just be easier to automatically refresh the balance? >> >> >> On Thu, 09 Dec 2010 09:28:16 -0500, WolfPup Lowenhar >> wrote: >> >> > What your suggesting would make it to 'spamy' to the servers because >> if >> > the >> > viewer was sending a refresh request even just once say every 1800 >> frames >> > considering there are at least 10K users online at any given moment >> that >> > that could eventually cause a data request overload to the servers and >> > thus >> > generate more 'lag' for the user which by making is a manual request >> this >> > can be avoided. >> > >> > >> > From: opensource-dev-bounces at lists.secondlife.com >> > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of >> Malachi >> > Prophit >> > Sent: Thursday, December 09, 2010 9:11 AM >> > To: opensource-dev at lists.secondlife.com >> > Subject: [opensource-dev] STORM-524 >> > >> > >> > Couldn't it just be done by calling >> > LLStatusBar::sendMoneyBalanceRequest(); in bool >> LLAppViewer::mainLoop()? >> > or is there something i am missing? >> > _______________________________________________ >> > 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 >> > >> > _____ >> > >> > No virus found in this message. >> > Checked by AVG - www.avg.com >> > Version: 10.0.1170 / Virus Database: 426/3305 - Release Date: 12/09/10 >> > >> >> >> -- >> Using Opera's revolutionary email client: http://www.opera.com/mail/ >> _______________________________________________ >> 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 >> -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From wolfpup67 at earthlink.net Thu Dec 9 16:43:20 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 9 Dec 2010 19:43:20 -0500 Subject: [opensource-dev] Noticed Something interesting while investigating STORM-776 Message-ID: <000001cb9803$3e373380$baa59a80$@net> Please see : https://jira.secondlife.com/browse/STORM-776 Since I have started investigating this I have found that there is actually duplicated code and xml files for object 'profiles'. 1. sidebar_task_info: this section of code and related xml allows the editing of the permissions of rezed(inworld) objects. 2. sidebar_item_info: dose the same thing but for non-rezed(inventory) although currently this has issues that this jira is addressing. Question is do we really need this code duplication since the code for the inwolrd object 'profile' dose all perm settings without a problem and can we use the same code for the ones in inventory? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101209/8a75af42/attachment.htm From vsavchuk at productengine.com Thu Dec 9 21:54:32 2010 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Fri, 10 Dec 2010 07:54:32 +0200 Subject: [opensource-dev] Any hope of STORM-727 getting a little love? In-Reply-To: References: <4CFE649E.2090804@meadowlakearts.com> <4CFF0A58.8000403@taterunino.net> Message-ID: On Thu, Dec 9, 2010 at 11:43 PM, Nicky D. wrote: > It's pesky, isn't it? :) Incidentally it bit me as well this week. > Patch attached. > Not sure if it is really the 100% golden way, but it works good for > me. Maybe someone > can make good use of the patch. > Thanks Nicky, but STORM-727 is already fixed. :-)` -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/54be14d6/attachment.htm From vsavchuk at productengine.com Fri Dec 10 00:08:24 2010 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Fri, 10 Dec 2010 10:08:24 +0200 Subject: [opensource-dev] [SNOWSTORM] Daily Scrum Summary - Thursday, December 9 In-Reply-To: References: Message-ID: <4D01DFF8.4060200@productengine.com> On 12/09/2010 09:23 PM, Anya Kanevsky wrote: > > > Jonathan Yap > > ------------------------------------------------------------------------ > > *PAST* > > * Tried to use codereview + postreview command. Got message: > Unable to log in: HTTP 404 > > Will wait for Oz to publish instructions on the wiki. > By the way, for anyone getting the following message when trying to use the post-review script: Error creating review request: The repository path specified is not in the list of known repositories The reason is that post-review is very sensitive to the way you specify remote repository in the [paths] section of your /REPO//.hg/hgrc. It must be exactly the same as in Review Board settings. Here is the one that works for me: [paths] default = http://bitbucket.org/lindenlab/viewer-beta/ Note that neither of the following URLs will work, despite being valid and pointing to the same repo: * https://bitbucket.org/lindenlab/viewer-beta/ * http://bitbucket.org/lindenlab/viewer-beta * http://hg.secondlife.com/viewer-beta/ Hope this helps, -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/1860ae83/attachment-0001.htm From vsavchuk at productengine.com Fri Dec 10 00:23:35 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Fri, 10 Dec 2010 08:23:35 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101209195540.10132.75120@domU-12-31-38-00-90-68.compute-1.internal> References: <20101209195540.10132.75120@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101210082335.15358.94617@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/#review21 ----------------------------------------------------------- Merov, why do we need those added calls? And the one in draw() looks suspicious to me: are you sure it won't be ever called, say, 100 times per second? - Vadim On 2010-12-09 11:55:40, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/6/ > ----------------------------------------------------------- > > (Updated 2010-12-09 11:55:40) > > > Review request for Viewer. > > > Summary > ------- > > Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). > I modified the tooltip to reflect this new functionality. > > > This addresses bug STORM-524. > http://jira.secondlife.com/browse/STORM-524 > > > Diffs > ----- > > indra/newview/llbuycurrencyhtml.cpp 25bd6007e3d2 > indra/newview/llfloaterbuycurrency.cpp 25bd6007e3d2 > indra/newview/llfloaterbuycurrencyhtml.cpp 25bd6007e3d2 > indra/newview/llstatusbar.h 25bd6007e3d2 > indra/newview/llstatusbar.cpp 25bd6007e3d2 > indra/newview/skins/default/xui/en/panel_status_bar.xml 25bd6007e3d2 > > Diff: http://codereview.secondlife.com/r/6/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/fe0900ad/attachment.htm From esbee at lindenlab.com Fri Dec 10 05:44:20 2010 From: esbee at lindenlab.com (Sarah (Esbee) Kuehnle) Date: Fri, 10 Dec 2010 08:44:20 -0500 Subject: [opensource-dev] Destination Guide Categories not working... In-Reply-To: References: Message-ID: Hi Ponzu, That's all web content the Viewer team doesn't control. Could you file a WEB ticket in Jira? Thanks! Esbee On Wed, Dec 8, 2010 at 3:48 PM, Ponzu wrote: > Open Sidebar, and hand of SL icon > Click Open Destination Guide. > Click on the Category: All pop down. > Select one of the items. > > So far as I can tell, clicking on a category doesn't do anything. No > highlighting, no list refresh, no click...nada. > > I don't see a relevant Jira. > > This happens with SL beta and SL V2. > > If someone can point me at the relevant source files, I can take a look at > it. > > regards, > lee > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/71444260/attachment.htm From dave at meadowlakearts.com Fri Dec 10 06:58:09 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Fri, 10 Dec 2010 08:58:09 -0600 Subject: [opensource-dev] Any hope of STORM-727 getting a little love? In-Reply-To: References: <4CFE649E.2090804@meadowlakearts.com> <4CFF0A58.8000403@taterunino.net> Message-ID: <4D024001.3060002@meadowlakearts.com> On 12/9/2010 23:54, Vadim Savchuk wrote: > Thanks Nicky, but STORM-727 is already fixed. :-)` Confirm fix works for me in latest dev build. From jhwelch at gmail.com Fri Dec 10 09:31:57 2010 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 10 Dec 2010 12:31:57 -0500 Subject: [opensource-dev] Display song title being played Message-ID: I was looking over some jiras and found this one Add support for displaying the title of the song playing on the stream https://jira.secondlife.com/browse/SNOW-381 There is already an (old) patch to do this for linux. Does someone want to step up and do it for the rest of the platforms? From nickyperian at yahoo.com Fri Dec 10 09:32:47 2010 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 10 Dec 2010 09:32:47 -0800 (PST) Subject: [opensource-dev] Multiple Manifest Errors vs2005 pro builds Message-ID: <22441.3331.qm@web43516.mail.sp1.yahoo.com> I can't get past these multiple manifest errors. This http://pastebin.com/WFnt6YRb is a build log of viewer-development 2.5.0.0 that was current as of yesterday Dec 9 ~ 1800Z. I thought I was past this error at one time but, it is back. Request suggestions to resolve. Thanks, Nicky P.S. I isolated this build from my normal system inside Linux->Virtual Box-> Windows XP Virtual Machine and got this same result. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/6f703b4b/attachment.htm From mike.chase at alternatemetaverse.com Fri Dec 10 09:51:54 2010 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 10 Dec 2010 12:51:54 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer Message-ID: <4D0268BA.2060409@alternatemetaverse.com> Hi all, I have a new machine coming and given the amount of memory it has I'd really like to run it 64bit linux (probably ubuntu). I'd really like to stay with the ability to run SnowStorm (and the Mesh viewer builds). Can someone point me to a summary of 64bit support for Linux for that series of viewers? I know in the past I was able to run a 32bit version but with no streaming media. Thats a non starter for me as I own a club in SL and its kinda nice to be able to hear what's being played in the club. Thanks in advance for the help! Mike From sythos at gmail.com Fri Dec 10 12:33:36 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Fri, 10 Dec 2010 21:33:36 +0100 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D0268BA.2060409@alternatemetaverse.com> References: <4D0268BA.2060409@alternatemetaverse.com> Message-ID: <20101210213336.65db7c5f.sythos@gmail.com> On Fri, 10 Dec 2010 12:51:54 -0500 Mike Chase wrote: > Hi all, I have a new machine coming and given the amount of memory it > has I'd really like to run it 64bit linux (probably ubuntu). I'd > really like to stay with the ability to run SnowStorm (and the Mesh > viewer builds). Can someone point me to a summary of 64bit support > for Linux for that series of viewers? I know in the past I was able > to run a 32bit version but with no streaming media. Thats a non > starter for me as I own a club in SL and its kinda nice to be able to > hear what's being played in the club. sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl From mike.chase at alternatemetaverse.com Fri Dec 10 12:54:36 2010 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 10 Dec 2010 15:54:36 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <20101210213336.65db7c5f.sythos@gmail.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> Message-ID: <4D02938C.2030705@alternatemetaverse.com> On 12/10/2010 03:33 PM, Altair Sythos Memo wrote: > On Fri, 10 Dec 2010 12:51:54 -0500 > Mike Chase wrote: > >> Hi all, I have a new machine coming and given the amount of memory it >> has I'd really like to run it 64bit linux (probably ubuntu). I'd >> really like to stay with the ability to run SnowStorm (and the Mesh >> viewer builds). Can someone point me to a summary of 64bit support >> for Linux for that series of viewers? I know in the past I was able >> to run a 32bit version but with no streaming media. Thats a non >> starter for me as I own a club in SL and its kinda nice to be able to >> hear what's being played in the club. > sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl > Yes, but that doesn't address the gstreamer issue. As far as I know unless something has changed. I suppose I could bite the bullet and get used to building form source. But I was hopeful with the excellent work being done in sprints by the team that a 64bit Linux client might have been addressed. Mike From sythos at gmail.com Fri Dec 10 13:14:09 2010 From: sythos at gmail.com (Altair Sythos Memo) Date: Fri, 10 Dec 2010 22:14:09 +0100 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D02938C.2030705@alternatemetaverse.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <4D02938C.2030705@alternatemetaverse.com> Message-ID: <20101210221409.621c59a0.sythos@gmail.com> On Fri, 10 Dec 2010 15:54:36 -0500 Mike Chase wrote: > Yes, but that doesn't address the gstreamer issue. As far as I know > unless something has changed. I suppose I could bite the bullet and > get used to building form source. But I was hopeful with the > excellent work being done in sprints by the team that a 64bit Linux > client might have been addressed. here work fine (on pulseaudio, but dunno if this can change something) From akanevsky at productengine.com Fri Dec 10 13:17:28 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Fri, 10 Dec 2010 15:17:28 -0600 Subject: [opensource-dev] Daily Scrum Summary - Friday, December 10 Message-ID: Friday, December 10, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov Team Status ------------------------------ Merov Linden ------------------------------ *PAST* PAST - STORM-524 : L$ balance display : Took feedback into account. Implemented extra balance updates. Moved to Review (assigned to Vadim) - STORM-34 : Favorites drop down on login: built binary on TC for Esbee to review - Merge Monkeying: lots of... *FUTURE* - Merge Monkeying - STORM-453 : libcurl - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ - OOO - Vacation. Q Linden ------------------------------ - OOO - medical Esbee Linden ------------------------------ - OOO Paul ProductEngine ------------------------------ *PAST* - STORM-625 (Multiple cut-offs in the Preferances floater if UI size differs from 1.0) - WIP. Estimate ~4 hours. - TASK STORM- 622 (Texture picker screws up when multiple textures are opened) - Sent for review *FUTURE* - STORM-625 (Multiple cut-offs in the Preferances floater if UI size differs from 1.0) - Commit fix for STORM-622 - Pick up something from Sprint 9. *IMPEDIMENTS* - none Seth Productengine ------------------------------ *PAST* - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - WIP. Changed opacity settings for Preview thumbnails in the Edit Wearable but they don't apply. Investigating what affects the opacity of the preview widgets draw context. - Code reviews. *FUTURE* - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - BUG (STORM-378) Snapshot animation should be played when snapshot is actually taken, not sent *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Fixed and sent for review. Merov, please do a TC build, so Esbee can review. - Crititcal bug STORM-525 (Runtime Error message from the Microsoft Visual C++ Runtime Library eventually leads to Crash). - Tried to reproduce, but couldn't, because I was ejected from parcel because it was "private". - Story 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). - Discussed with Vadim. Started investigating. Rough estimate - 1 week. *FUTURE* - STORM-2 *IMPEDIMENTS* - Couldn't stay in parcel from STORM-525's comments, because it has access restrictions and ejected me. Perhaps to reproduce it I will need access. Vadim Productengine ------------------------------ *PAST* - Task STORM-774 (IM and notification toasts don't honor floater transparency settings): - Implemented. - Bug STORM-728 (Viewer crashes while trying to send Snapshot to Email in mouselook mode): - Fixed. - Bug STORM-727 (Close and "<=" buttons are disabled when create new Landmark): - Committed fix. - Code review. *FUTURE* - Severe bug STORM-636 (Pulseaudio support is crashing web media on some new Linux distros). *IMPEDIMENTS* - Need Esbee to review STORM-529. Andrey Productengine ------------------------------ *PAST* - picked up Beta2 r216393 build - passed smoke & integrity tests, see IQA-57 for more details *FUTURE* - switch to verification of v-d integrated tickets - pick up Release build (?) *IMPEDIMENTS* - None Wolfpup Lowenhar ------------------------------ *PAST* - STORM-765 : Re-Opened and updated to include images showing issue is still present. (left this unassigned as I did not know who best to assign it to.) - Attended Scrum meeting. - STORM-776 : Imported by Merov at my request as this is a bug fix and began work. - Posted email to opensource-dev concerning STORM-776 . *FUTURE* - STORM-776 : estimating 7 days total time maybe even longer. (need to talk to Esbee and Q concerning this) *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand(it is slowly healing but will take time since it is the tip of middle finger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/d1534fc4/attachment-0001.htm From marc at inworlddesigns.com Fri Dec 10 13:29:13 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Fri, 10 Dec 2010 16:29:13 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <20101210221409.621c59a0.sythos@gmail.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <4D02938C.2030705@alternatemetaverse.com> <20101210221409.621c59a0.sythos@gmail.com> Message-ID: Pulseaudio is the default in all ubuntu versions. 64bit gstreamer will not work with 32bit Secondlife Viewer even with pulseaudio because secondlife accesses the gstreamer lib not pulseaudio. Gstreamer is the one to access the pulseaudio subsystem. The only way to get it to work is to build a 64bit Secondlife Viewer or hack through your system and install a 32bit gstreamer which may or may not cause other system wide issues so building the viewer in 64bit is the better option. Building the viewer in 64bit is currently a really really difficult task even for people who know what they are doing. I've been hoping for linden to really work on simplifying the 64bit building because 64bit systems are being more and more popular with the need for more and more memory. I do believe someone was working on fixing this in the opensource community but I don't recall who or how far they got. On Fri, Dec 10, 2010 at 4:14 PM, Altair Sythos wrote: > On Fri, 10 Dec 2010 15:54:36 -0500 > Mike Chase wrote: > >> Yes, but that doesn't address the gstreamer issue. As far as I know >> unless something has changed. ?I suppose I could bite the bullet and >> get used to building form source. ?But I was hopeful with the >> excellent work being done in sprints by the team that a 64bit Linux >> client might have been addressed. > > here work fine (on pulseaudio, but dunno if this can change something) > _______________________________________________ > 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 > From yoz at lindenlab.com Fri Dec 10 14:28:01 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri, 10 Dec 2010 14:28:01 -0800 Subject: [opensource-dev] Destination Guide Categories not working... In-Reply-To: References: Message-ID: Coincidentally, this particular issue has just started being investigated from an internal report. However it seems to be really weird; so far, the team has only been able to repro it reliably on two of the many PCs in the office, despite all using the same (or close enough) viewer versions. The internal issue has been cloned & linked to WEB-3396. If you can throw any extra light on it, we'd appreciate it! On 10 December 2010 05:44, Sarah (Esbee) Kuehnle wrote: > Hi Ponzu, > > That's all web content the Viewer team doesn't control. Could you file a > WEB ticket in Jira? > > Thanks! > Esbee > > > > On Wed, Dec 8, 2010 at 3:48 PM, Ponzu wrote: > >> Open Sidebar, and hand of SL icon >> Click Open Destination Guide. >> Click on the Category: All pop down. >> Select one of the items. >> >> So far as I can tell, clicking on a category doesn't do anything. No >> highlighting, no list refresh, no click...nada. >> >> I don't see a relevant Jira. >> >> This happens with SL beta and SL V2. >> >> If someone can point me at the relevant source files, I can take a look at >> it. >> >> regards, >> lee >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/5507b194/attachment.htm From yoz at lindenlab.com Fri Dec 10 16:21:09 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri, 10 Dec 2010 16:21:09 -0800 Subject: [opensource-dev] Destination Guide Categories not working... In-Reply-To: References: Message-ID: Oops - after further investigation (and actually paying attention to the finer details of what Ponzu had written) it turns out that this *is* a viewer issue after all. VWR-24164 On 10 December 2010 14:28, Yoz Grahame wrote: > Coincidentally, this particular issue has just started being investigated > from an internal report. However it seems to be really weird; so far, the > team has only been able to repro it reliably on two of the many PCs in the > office, despite all using the same (or close enough) viewer versions. > The internal issue has been cloned & linked to WEB-3396. If you can throw > any extra light on it, we'd appreciate it! > > > On 10 December 2010 05:44, Sarah (Esbee) Kuehnle wrote: > >> Hi Ponzu, >> >> That's all web content the Viewer team doesn't control. Could you file a >> WEB ticket in Jira? >> >> Thanks! >> Esbee >> >> >> >> On Wed, Dec 8, 2010 at 3:48 PM, Ponzu wrote: >> >>> Open Sidebar, and hand of SL icon >>> Click Open Destination Guide. >>> Click on the Category: All pop down. >>> Select one of the items. >>> >>> So far as I can tell, clicking on a category doesn't do anything. No >>> highlighting, no list refresh, no click...nada. >>> >>> I don't see a relevant Jira. >>> >>> This happens with SL beta and SL V2. >>> >>> If someone can point me at the relevant source files, I can take a look >>> at it. >>> >>> regards, >>> lee >>> >>> _______________________________________________ >>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/de489b6c/attachment.htm From merov at lindenlab.com Fri Dec 10 16:21:57 2010 From: merov at lindenlab.com (Merov Linden) Date: Sat, 11 Dec 2010 00:21:57 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101209195540.10132.75120@domU-12-31-38-00-90-68.compute-1.internal> References: <20101209195540.10132.75120@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101211002157.15582.47710@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/ ----------------------------------------------------------- (Updated 2010-12-10 16:21:57.124487) Review request for Viewer. Changes ------- Took Vadim's comment into account pulling the balance update out of updateUI() and only in onClick() calls or close UI calls Summary ------- Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). I modified the tooltip to reflect this new functionality. This addresses bug STORM-524. http://jira.secondlife.com/browse/STORM-524 Diffs (updated) ----- indra/newview/llbuycurrencyhtml.cpp 8668b574c1f3 indra/newview/llfloaterbuycurrency.cpp 8668b574c1f3 indra/newview/llfloaterbuycurrencyhtml.cpp 8668b574c1f3 indra/newview/llstatusbar.h 8668b574c1f3 indra/newview/llstatusbar.cpp 8668b574c1f3 indra/newview/skins/default/xui/en/panel_status_bar.xml 8668b574c1f3 Diff: http://codereview.secondlife.com/r/6/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101211/3f915c28/attachment.htm From carlo at alinoe.com Fri Dec 10 17:06:21 2010 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 11 Dec 2010 02:06:21 +0100 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <20101210213336.65db7c5f.sythos@gmail.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> Message-ID: <20101211010621.GA10916@alinoe.com> On Fri, Dec 10, 2010 at 09:33:36PM +0100, Altair Sythos Memo wrote: > On Fri, 10 Dec 2010 12:51:54 -0500 > Mike Chase wrote: > > > Hi all, I have a new machine coming and given the amount of memory it > > has I'd really like to run it 64bit linux (probably ubuntu). I'd > > really like to stay with the ability to run SnowStorm (and the Mesh > > viewer builds). Can someone point me to a summary of 64bit support > > for Linux for that series of viewers? I know in the past I was able > > to run a 32bit version but with no streaming media. Thats a non > > starter for me as I own a club in SL and its kinda nice to be able to > > hear what's being played in the club. > > sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl Huh huh... No need to install 32bit libs! Just compile the viewer yourself! I've been running native 64 bit since day one. -- Carlo Wood From nickyperian at yahoo.com Fri Dec 10 17:59:51 2010 From: nickyperian at yahoo.com (Nicky Perian) Date: Fri, 10 Dec 2010 17:59:51 -0800 (PST) Subject: [opensource-dev] [SOLVED] Multiple Manifest Errors vs2005 pro builds In-Reply-To: References: <22441.3331.qm@web43516.mail.sp1.yahoo.com> Message-ID: <22018.48718.qm@web43505.mail.sp1.yahoo.com> @Arrehn Thanks for the reply. I had Auto-updates on for windows only. Set it to Windows and other microsoft products and selected update for three times and several VS2005 updates were applied. With in VS2005 did Build->Clean and Build->Rebuild and all built including the Tests that in the past had been failing. ________________________________ From: Arrehn Oberlander To: Nicky Perian Sent: Fri, December 10, 2010 11:45:57 AM Subject: Re: [opensource-dev] Multiple Manifest Errors vs2005 pro builds They can be exceeding aggravating. If you turn windows autoupdates on and run through windows update multiple times until you're fully patched, you should get the right downloads to resolve it. One issue I hit was that the updates that resolved it didn't even show up in windows update until I turned auto updates on. On Fri, Dec 10, 2010 at 12:32 PM, Nicky Perian wrote: I can't get past these multiple manifest errors. This http://pastebin.com/WFnt6YRb is a build log of viewer-development 2.5.0.0 that was current as of yesterday Dec 9 ~ 1800Z. > > >I thought I was past this error at one time but, it is back. >Request suggestions to resolve. > > >Thanks, > >Nicky > > >P.S. I isolated this build from my normal system inside Linux->Virtual Box-> >Windows XP Virtual Machine and >got this same result. > > > >_______________________________________________ >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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101210/9ef9a890/attachment-0001.htm From mike.chase at alternatemetaverse.com Fri Dec 10 19:46:15 2010 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Fri, 10 Dec 2010 22:46:15 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <20101211010621.GA10916@alinoe.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> Message-ID: <4D02F407.5000603@alternatemetaverse.com> On 12/10/2010 08:06 PM, Carlo Wood wrote: > On Fri, Dec 10, 2010 at 09:33:36PM +0100, Altair Sythos Memo wrote: >> On Fri, 10 Dec 2010 12:51:54 -0500 >> Mike Chase wrote: >> >>> Hi all, I have a new machine coming and given the amount of memory it >>> has I'd really like to run it 64bit linux (probably ubuntu). I'd >>> really like to stay with the ability to run SnowStorm (and the Mesh >>> viewer builds). Can someone point me to a summary of 64bit support >>> for Linux for that series of viewers? I know in the past I was able >>> to run a 32bit version but with no streaming media. Thats a non >>> starter for me as I own a club in SL and its kinda nice to be able to >>> hear what's being played in the club. >> sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl > Huh huh... No need to install 32bit libs! Just compile the viewer > yourself! I've been running native 64 bit since day one. > Carlo, do you have a script or a pointer to the steps to do the build? Is it simply the standard steps or something special. Mike From vector at leafpile.com Fri Dec 10 23:56:37 2010 From: vector at leafpile.com (Vector Hastings) Date: Fri, 10 Dec 2010 23:56:37 -0800 Subject: [opensource-dev] Upcoming depth-of-field feature In-Reply-To: <4CF52D91.5040002@lindenlab.com> References: <8d8d3ba11429ee4ace15d41b2f854143@inventati.org> <4CEEC871.80903@gmail.com> <4CF52D91.5040002@lindenlab.com> Message-ID: <039801cb9908$f0827260$d1875720$@com> Awesome!! Haven't looked at it yet, but that is a very exciting prospect for a Yuletime Toy! Honestly, I really had put this on my list to santa. Cheers! Vector Hastings. -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Nyx Linden Sent: Tuesday, November 30, 2010 9:00 AM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Upcoming depth-of-field feature Depth of Field is a quick feature one of our devs developed while looking into anti-aliasing bugs. It didn't take a substantial amount of time away from bug-hunting, and should be useful for a variety of purposes (photography and machinima for starters). At this point it should be considered a toy, in that its a feature that hasn't yet been formally finished, debugged, qa'd, or had a good interface put on top of it. Feedback is appreciated for when we do prepare to polish it up of course. As always, you can see the changes we've made in the mesh branch in our public repository: http://hg.secondlife.com/mesh-development You can always get the latest successful build of our changes here (link is also on the wiki downloads page): http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-develop ment/latest.html Feedback is appreciated to be put into jira-form under the mesh beta project for specific bug reports and feature requests, or on the forums for any topics that could require discussion: http://blogs.secondlife.com/community/forums/mesh Thanks for noticing, and thanks for the feedback! -Nyx On 11/25/2010 06:54 PM, Ricky wrote: > Agreed, DOF is on my long-list not my short-list of things I'd like to > see done. However, I expect that SL's deferred rendering system has a > laundry list of issues. Just look at it's history; it's been little > more than a pet-project since it's inception. A pet project with the > capability to go far, but still just a pet project. Getting the > client into a stronger codebase (2.0) and then stabilized with very > little new features has been the largest pushes in recent history. > > In fact, we've (LL and OS devs,) been working stability for so many > months that it might be time to push for a cool, if small, new > feature. However, with the new level of visibility, it won't be as > much a surprise. I hope. From my reading here, most people don't like > surprises! :P Maybe something nice, like a good UI skinning system... > See http://wiki.secondlife.com/wiki/Skinning#Phase_2_-_Switchable_Skins > Or maybe a roll-out of meshes, but I suspect that's wishing too hard! > :P > > As to the original question about DoF, here's what is known: > http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=%22depth+of+field%22 +OR+DOF+site:secondlife.com > Which gives the following JIRAs: > https://jira.secondlife.com/browse/VWR-19244 PROFESSIoNAL TOOL: > Snapshot: add functions: Dynamic Focus, Depth of field and Blurr > https://jira.secondlife.com/browse/VWR-3921 photographic tools: DoF > > In VWR-3921 Adeon Writer pointed to this build of the mesh viewer: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/mesh-develop ment/rev/215482/index.html > > Ricky > Cron Stardust > > On Thu, Nov 25, 2010 at 3:11 PM, Geenz Spad wrote: > >> I wonder how awesome it'll run on top of the already awesome deferred >> renderer that has really awesome performance on really awesome video cards >> that have really awesome drivers? >> >> Honestly, as nifty as DOF is as far as the "pretty" factor is concerned, >> right now the deferred renderer needs a few more optimizations before any >> additional features are added to it, and it still needs a few more work >> arounds for buggy drivers (for example, successfully running the deferred >> renderer on ATI hardware still tends to vary from person to person, >> depending on their hardware and driver combination). On top of that, you >> still need a pretty powerful video card in order to really take advantage of >> it, though I think that really has to do with bottle necks within the >> rendering system as a whole, not just bottle necks presented by the deferred >> renderer its self (although deferred rendering does have it's own bottle >> necks, and SL's deferred renderer in particular presents a few interesting >> ones of its own due to its flexibility). >> >> On Thu, Nov 25, 2010 at 4:43 PM, Ricky wrote: >> >>> Things ARE getting fixed, just look at the daily scrum reports or the >>> progress tracking in the JIRA. Also take note that sometimes "adding" >>> a single feature will often resolve several bugs and feature requests. >>> For instance the Deferred rendering channel will add the ability to >>> have greater than 7 light-sources, solving several issues with >>> facelights and other lights taking out room lighting. >>> >>> As to optimization, things are pretty optimized. Yes, they CAN get >>> better, but without a major restructuring of how content is created, >>> we will never have the high render rates found in the online and >>> offline games. Even so, the work being done on upgrading KDU looks >>> like it is improving load/render rates as it is. >>> >>> Don't forget that there are multiple people in multiple teams working >>> on this program. Some are better at adding new features, and so are >>> better utilized in that area. Some are better testers than coders, >>> and so that's where they get used. Some, fairly rare, are really good >>> at making existing code much better. All these people types are at >>> work here, and putting them all into "optimizing or fixing things" >>> would be a death-knell for the company. >>> >>> I'd say, instead of berating new (and very cool,) advancements, we >>> should all applaud the work being done. At the very least it will >>> make someone's day that much brighter. >>> >>> Just my opinion, >>> Ricky >>> Cron Stardust >>> >>> On Thu, Nov 25, 2010 at 12:34 PM, Rob Nelson >>> wrote: >>> >>>> Oh good, let's add more features instead of either optimizing things or >>>> fixing things. >>>> >>>> Rob >>>> >>>> On 11/25/2010 8:56 AM, Opensource Obscure wrote: >>>> >>>>> Thanks to BlakOpal today I saw these very cool images: >>>>> http://twitpic.com/3a0vag/full >>>>> >>>>> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/554285311901 6406770 >>>>> >>>>> http://picasaweb.google.com/Runitai/DeferredRendering#slideshow/554306251872 8480114 >>>>> >>>>> Where can I find more information about this depth-of-field >>>>> feature? (wiki pages, blog/forums, JIRA...) >>>>> >>>>> It really looks good. I'm going to download a test build now. >>>>> >>>>> >>>>> Thanks in advance >>>>> Opensource Obscure >>>>> _______________________________________________ >>>>> 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 >>> >> >> _______________________________________________ >> 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 From vsavchuk at productengine.com Sat Dec 11 03:37:00 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Sat, 11 Dec 2010 11:37:00 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101211002157.15582.47710@domU-12-31-38-00-90-68.compute-1.internal> References: <20101211002157.15582.47710@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101211113700.15580.57723@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/#review22 ----------------------------------------------------------- Ship it! No more objections. - Vadim On 2010-12-10 16:21:57, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/6/ > ----------------------------------------------------------- > > (Updated 2010-12-10 16:21:57) > > > Review request for Viewer. > > > Summary > ------- > > Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). > I modified the tooltip to reflect this new functionality. > > > This addresses bug STORM-524. > http://jira.secondlife.com/browse/STORM-524 > > > Diffs > ----- > > indra/newview/llbuycurrencyhtml.cpp 8668b574c1f3 > indra/newview/llfloaterbuycurrency.cpp 8668b574c1f3 > indra/newview/llfloaterbuycurrencyhtml.cpp 8668b574c1f3 > indra/newview/llstatusbar.h 8668b574c1f3 > indra/newview/llstatusbar.cpp 8668b574c1f3 > indra/newview/skins/default/xui/en/panel_status_bar.xml 8668b574c1f3 > > Diff: http://codereview.secondlife.com/r/6/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101211/609a5006/attachment.htm From lee.ponzu at gmail.com Sat Dec 11 08:27:52 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Sat, 11 Dec 2010 11:27:52 -0500 Subject: [opensource-dev] Destination Guide Categories not working... In-Reply-To: References: Message-ID: I got excited, and added this comment to WEB-3396 ======================= In my opinion, this is not MINOR. It is almost a Show Stopper. USER STORY: I want SL to be Faster, Easier, and Funner, so I open the Destination Guide to quickly find something new to do. Goddam! Why doesn't this work? Am I just not clicking on it right? Maybe I ned to relog. Hmmmm. Maybe I need to clear cache. No. Damn, maybe I should download Phoenix after all, this SL viewer sucks!! Is that what you want? Then this is minor. There is nothing less fun, less easier, and less fast than screwing around tearing your hair out because you cannot get something like the Destination Guide to work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101211/0edcfde9/attachment.htm From sllists at boroon.dasgupta.ch Sat Dec 11 18:12:29 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 12 Dec 2010 03:12:29 +0100 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D02F407.5000603@alternatemetaverse.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> Message-ID: <4D042F8D.5000208@boroon.dasgupta.ch> Hi Mike, On 12/10/2010 06:51 PM, Mike Chase wrote: > Can someone point me to a summary of 64bit support for Linux > for that series of viewers? I know in the past I was able to run a > 32bit version but with no streaming media. See the forum thread Linux 64 bits and medias . On 12/10/2010 10:29 PM, Marc Adored wrote: > I've been hoping for linden > to really work on simplifying the 64bit building because 64bit systems > are being more and more popular with the need for more and more > memory. I do believe someone was working on fixing this in the > opensource community but I don't recall who For the viewer-development branch, that'd be me. Although I mostly just ported others' fixes that already existed for the 1.x code base and/or Snowglobe 2. > or how far they got. Should be fully working now (see below), if you start form viewer-development (or viewer-beta or viewer-release). About the mesh-development branch ... well, that's another animal entirely when it comes to building 64bit (due to new dependencies and whatnot). On 12/11/2010 04:46 AM, Mike Chase wrote: > On 12/10/2010 08:06 PM, Carlo Wood wrote: >> Huh huh... No need to install 32bit libs! Just compile the viewer >> yourself! I've been running native 64 bit since day one. > Carlo, do you have a script or a pointer to the steps to do the build? All necessary steps should be on the wiki at Compiling the viewer (Linux) . > Is it simply the standard steps or something special. Because Linden Lab does not provide pre-built libraries for 64bit linux, you'll have to build "standalone", i.e., using system libraries. (See What does 'Standalone' mean? ) Thus you'll need to have all build time dependencies installed into your system. The wiki article linked above lists debian and ubuntu package names for most dependencies. Standalone-specific steps are included and marked as such (e.g. through section naming). The build documentation tends to get out-of-date quickly. If you decide to build yourself and run into troubles or have further questions, please do ask on this mailing list or on IRC (channel #opensl on freenode ) so that you can be helped and the documentation improved/corrected. Good luck & cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101212/912cd962/attachment.htm From marc at inworlddesigns.com Sat Dec 11 19:38:15 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Sat, 11 Dec 2010 22:38:15 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D042F8D.5000208@boroon.dasgupta.ch> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> Message-ID: Awesome I will checkout the latest then and try to compile it. I wasn't aware it was even close to working. I'm excited now. On Sat, Dec 11, 2010 at 9:12 PM, Boroondas Gupte wrote: > Hi Mike, > > On 12/10/2010 06:51 PM, Mike Chase wrote: > > Can someone point me to a summary of 64bit support for Linux > for that series of viewers? I know in the past I was able to run a > 32bit version but with no streaming media. > > See the forum thread Linux 64 bits and medias. > > On 12/10/2010 10:29 PM, Marc Adored wrote: > > I've been hoping for linden > to really work on simplifying the 64bit building because 64bit systems > are being more and more popular with the need for more and more > memory. I do believe someone was working on fixing this in the > opensource community but I don't recall who > > For the viewer-development branch, that'd be me. Although I mostly just > ported others' fixes that already existed for the 1.x code base and/or > Snowglobe 2. > > or how far they got. > > Should be fully working now (see below), if you start form > viewer-development (or viewer-beta or viewer-release). About the > mesh-development branch ... well, that's another animal entirely when it > comes to building 64bit (due to new dependencies and whatnot). > > > On 12/11/2010 04:46 AM, Mike Chase wrote: > > On 12/10/2010 08:06 PM, Carlo Wood wrote: > > Huh huh... No need to install 32bit libs! Just compile the viewer > yourself! I've been running native 64 bit since day one. > > Carlo, do you have a script or a pointer to the steps to do the build? > > All necessary steps should be on the wiki at Compiling the viewer (Linux). > > Is it simply the standard steps or something special. > > Because Linden Lab does not provide pre-built libraries for 64bit linux, > you'll have to build "standalone", i.e., using system libraries. (See What > does 'Standalone' mean?) Thus you'll need to have all build time > dependencies installed into your system. The wiki article linked above lists > debian and ubuntu package names for most dependencies. Standalone-specific > steps are included and marked as such (e.g. through section naming). > > The build documentation tends to get out-of-date quickly. If you decide to > build yourself and run into troubles or have further questions, please do > ask on this mailing list or on IRC (channel #opensl on freenode) so that you > can be helped and the documentation improved/corrected. > > Good luck & 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 > From makosoft at gmail.com Sun Dec 12 07:02:08 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Sun, 12 Dec 2010 15:02:08 +0000 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> Message-ID: On 12/12/10, Marc Adored wrote: > Awesome I will checkout the latest then and try to compile it. I > wasn't aware it was even close to working. I'm excited now. It's actually been possible for a while, but until recently you had to manually dig up patches from the Wiki in order to compile a 64-bit viewer successfully. Last time I tried, the major obstacles were: * Having compiled Google Breakpad, getting the viewer build process to find it is fiddly. It seems to require a slightly odd layout for the header files. I had to manually create some directories with the correct names and copy the headers to them. * Building a 64-bit version of llqtwebkit is a real pain. I believe the Imprudence developers have created a pre-compiled version of this recently - if it was available when I was trying, I'd have been tempted to use it. From trilobyte550m at gmail.com Sun Dec 12 08:39:54 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sun, 12 Dec 2010 08:39:54 -0800 Subject: [opensource-dev] Tab key? Message-ID: <7CB3AE52-0684-4BE6-9EE0-CF9EEADF1E2E@gmail.com> Has anybody else noticed that the tab key is no longer working as expected in build 216577? At least in the Mac client, the tab key used to be able to be used to jump between fields. For example in the build/edit box on the general tab, type in a Name and then type in the description. Or in the debug settings, enter the switch, tab, enter the value (if it's a text field). That doesn't seem to be working in this build. https://jira.secondlife.com/browse/VWR-24172 TriloByte Zanzibar From secret.argent at gmail.com Sun Dec 12 13:09:06 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 12 Dec 2010 15:09:06 -0600 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> Message-ID: <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> You know what would really help people get over the hump of setting up for building SL? A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. On 2010-12-12, at 09:02, Aidan Thornton wrote: > On 12/12/10, Marc Adored wrote: >> Awesome I will checkout the latest then and try to compile it. I >> wasn't aware it was even close to working. I'm excited now. > > It's actually been possible for a while, but until recently you had to > manually dig up patches from the Wiki in order to compile a 64-bit > viewer successfully. Last time I tried, the major obstacles were: > * Having compiled Google Breakpad, getting the viewer build process to > find it is fiddly. It seems to require a slightly odd layout for the > header files. I had to manually create some directories with the > correct names and copy the headers to them. > * Building a 64-bit version of llqtwebkit is a real pain. I believe > the Imprudence developers have created a pre-compiled version of this > recently - if it was available when I was trying, I'd have been > tempted to use it. > _______________________________________________ > 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 "Welcome back, Anonymous, we're glad to see you again!" From mike.chase at alternatemetaverse.com Sun Dec 12 18:03:13 2010 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Sun, 12 Dec 2010 21:03:13 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> Message-ID: <4D057EE1.5090009@alternatemetaverse.com> On 12/12/2010 04:09 PM, Argent Stonecutter wrote: > You know what would really help people get over the hump of setting up for building SL? > > A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. Or a KVM/qemu image assuming the target audience is running 64bit Linux. On a related note, the voice components are proprietary. Is it possible to get them to work? Can you use a 32 voice and SLPlugin component with the 64bit application? Mike From secret.argent at gmail.com Sun Dec 12 18:46:14 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 12 Dec 2010 20:46:14 -0600 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D057EE1.5090009@alternatemetaverse.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> <4D057EE1.5090009@alternatemetaverse.com> Message-ID: <0A05A385-0EDB-4172-BD87-23EFF906F07C@gmail.com> On 2010-12-12, at 20:03, Mike Chase wrote: > On 12/12/2010 04:09 PM, Argent Stonecutter wrote: >> You know what would really help people get over the hump of setting up for building SL? >> >> A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. > Or a KVM/qemu image assuming the target audience is running 64bit Linux. VMware Player runs just fine under 64 bit Linux. I have a number of users using that combination for their meagre Windows needs. Really, an OVF image would be best, so it can be run under any VM. From marc at inworlddesigns.com Sun Dec 12 19:48:10 2010 From: marc at inworlddesigns.com (Marc Adored) Date: Sun, 12 Dec 2010 22:48:10 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D057EE1.5090009@alternatemetaverse.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> <4D057EE1.5090009@alternatemetaverse.com> Message-ID: Yes 32bit SLVoice can run with 64bit viewer because the viewer is not using it as a lib its a network connection between each other so none of that matters. On Sun, Dec 12, 2010 at 9:03 PM, Mike Chase wrote: > On 12/12/2010 04:09 PM, Argent Stonecutter wrote: >> You know what would really help people get over the hump of setting up for building SL? >> >> A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. > Or a KVM/qemu image assuming the target audience is running 64bit Linux. > > On a related note, the voice components are proprietary. ?Is it possible > to get them to work? ?Can you use a 32 voice and SLPlugin component with > the 64bit application? > > Mike > > _______________________________________________ > 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 > From mike.chase at alternatemetaverse.com Sun Dec 12 20:27:37 2010 From: mike.chase at alternatemetaverse.com (Mike Chase) Date: Sun, 12 Dec 2010 23:27:37 -0500 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> <4D057EE1.5090009@alternatemetaverse.com> Message-ID: <4D05A0B9.4030306@alternatemetaverse.com> On 12/12/2010 10:48 PM, Marc Adored wrote: > Yes 32bit SLVoice can run with 64bit viewer because the viewer is not > using it as a lib its a network connection between each other so none > of that matters. > Ok, so maybe one thing that might be considered for a 64 bit build is to build the core client 64bit but do the voice and SLPlugin stuff as 32bit. Can the build scripts be taught to do that? It seems building standalone with such a config would produce a fully functional client (all the pieces would work). Mike > On Sun, Dec 12, 2010 at 9:03 PM, Mike Chase > wrote: >> On 12/12/2010 04:09 PM, Argent Stonecutter wrote: >>> You know what would really help people get over the hump of setting up for building SL? >>> >>> A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. >> Or a KVM/qemu image assuming the target audience is running 64bit Linux. >> >> On a related note, the voice components are proprietary. Is it possible >> to get them to work? Can you use a 32 voice and SLPlugin component with >> the 64bit application? >> >> Mike >> >> _______________________________________________ >> 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 >> From chaosstar at gmail.com Mon Dec 13 01:28:42 2010 From: chaosstar at gmail.com (Ambrosia) Date: Mon, 13 Dec 2010 10:28:42 +0100 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <4D05A0B9.4030306@alternatemetaverse.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> <4D057EE1.5090009@alternatemetaverse.com> <4D05A0B9.4030306@alternatemetaverse.com> Message-ID: On Mon, Dec 13, 2010 at 05:27, Mike Chase wrote: > On 12/12/2010 10:48 PM, Marc Adored wrote: >> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not >> using it as a lib its a network connection between each other so none >> of that matters. >> > Ok, so maybe one thing that might be considered for a 64 bit build is to > build the core client 64bit but do the voice and SLPlugin stuff as > 32bit. ?Can the build scripts be taught to do that? It seems building > standalone with such a config would produce a fully functional client > (all the pieces would work). > > Mike I personally would also be interested in the opposite as well. I hate building standalone (Come on LL, why can't you provide 64bit prebuilds? It's not like 64bit OSes are exotic anymore), so on my 64bit Debian system, I build a 32bit client with the necessary libs installed in /*/lib32/ (as opposed to, say, a pure chroot) Naturally this makes media playback fail due to there being no 32bit gstreamer libs installed, and getting those properly setup with all dependencies can be a nightmare. A 32bit SLPlugin build communicating with the 64bit client would solve that. From chaosstar at gmail.com Mon Dec 13 01:29:58 2010 From: chaosstar at gmail.com (Ambrosia) Date: Mon, 13 Dec 2010 10:29:58 +0100 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> <4D057EE1.5090009@alternatemetaverse.com> <4D05A0B9.4030306@alternatemetaverse.com> Message-ID: On Mon, Dec 13, 2010 at 10:28, Ambrosia wrote: > On Mon, Dec 13, 2010 at 05:27, Mike Chase > wrote: >> On 12/12/2010 10:48 PM, Marc Adored wrote: >>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not >>> using it as a lib its a network connection between each other so none >>> of that matters. >>> >> Ok, so maybe one thing that might be considered for a 64 bit build is to >> build the core client 64bit but do the voice and SLPlugin stuff as >> 32bit. ?Can the build scripts be taught to do that? It seems building >> standalone with such a config would produce a fully functional client >> (all the pieces would work). >> >> Mike > > I personally would also be interested in the opposite as well. > I hate building standalone (Come on LL, why can't you provide 64bit > prebuilds? It's not like 64bit OSes are exotic anymore), so on my > 64bit Debian system, I build a 32bit client with the necessary libs > installed in /*/lib32/ (as opposed to, say, a pure chroot) > > Naturally this makes media playback fail due to there being no 32bit > gstreamer libs installed, and getting those properly setup with all > dependencies can be a nightmare. A 32bit SLPlugin build communicating > with the 64bit client would solve that. Er, I meant a 64bit SLPlugin communicating with the 32bit client, in my case, of course. :3 From makosoft at gmail.com Mon Dec 13 06:32:03 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Mon, 13 Dec 2010 14:32:03 +0000 Subject: [opensource-dev] Linux 64bit and gstreamer In-Reply-To: <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> References: <4D0268BA.2060409@alternatemetaverse.com> <20101210213336.65db7c5f.sythos@gmail.com> <20101211010621.GA10916@alinoe.com> <4D02F407.5000603@alternatemetaverse.com> <4D042F8D.5000208@boroon.dasgupta.ch> <264DB8E3-3E9D-4273-BE6C-C41125F5B3DD@gmail.com> Message-ID: On 12/12/10, Argent Stonecutter wrote: > You know what would really help people get over the hump of setting up for > building SL? > > A VMware appliance containing a working SL build environment, for 32 and 64 > bit Linux. It's sort of vaguely on my TODO list, possibly including a way of creating all the prebuilt library bundles needed to make an actual SL release. There are certain practical and licensing issues, though. Also, being able to actually run Second Life within the VM could be fun... From vsavchuk at productengine.com Mon Dec 13 07:08:29 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 13 Dec 2010 15:08:29 -0000 Subject: [opensource-dev] Review Request: STORM-702 Make it possible to wear partial outfits Message-ID: <20101213150829.18768.63543@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/14/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. those that don't contain full set of body parts). This addresses bug STORM-702. http://jira.secondlife.com/browse/STORM-702 Diffs ----- indra/newview/llappearancemgr.cpp 3d2e71443c58 indra/newview/llinventoryfunctions.cpp 3d2e71443c58 Diff: http://codereview.secondlife.com/r/14/diff Testing ------- Thanks, Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101213/229da202/attachment-0001.htm From laurent.bechir at madonie.org Mon Dec 13 08:21:29 2010 From: laurent.bechir at madonie.org (Laurent Rathle) Date: Mon, 13 Dec 2010 17:21:29 +0100 Subject: [opensource-dev] Error building second life on a mac Message-ID: <4D064809.6090006@madonie.org> Hello, I'm trying to build Second Life viewer on my Mac, and I get a md5sum filed message on linden/scripts/messages/message_template.msg with 3f19d130400c547de36278a6b6f9b028 as value. How can I fix that, please ? Thank you From jhwelch at gmail.com Mon Dec 13 10:05:35 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Mon, 13 Dec 2010 18:05:35 -0000 Subject: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter Message-ID: <20101213180535.18781.88299@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/ ----------------------------------------------------------- Review request for Viewer. Summary ------- You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. Diffs ----- indra/newview/llagentcamera.cpp 3d2e71443c58 Diff: http://codereview.secondlife.com/r/16/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101213/a3f8c2e3/attachment.htm From akanevsky at productengine.com Mon Dec 13 13:03:40 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 13 Dec 2010 15:03:40 -0600 Subject: [opensource-dev] Daily Scrum Summary - Monday, December 13 Message-ID: Monday, December 13, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov - all issues should be going to v-d at this point - PE reports will be up to now instead of last day?s. Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-524 : L$ balance display : Took Vadim's feedback into account again. Moved to Review again (assigned to Vadim). - STORM-453 : libcurl 7.21: Moved up to the point of trying to build a viewer. Link issues as new libs seems required (OpenLDAP, new OpenSSL). - STORM-780 : Skylight : massive merge in viewer-development - Merge Monkeying: see above *FUTURE* - Merge Monkeying - STORM-453 : libcurl - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Before vacation... who remembers? - Catching up on email and other goings-on *FUTURE* - Better documentation of code review system on wiki - more internal stuff... *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Beta / release discussions - decisions on various JIRAs - internal process - meetings - triage *FUTURE* - release - Triage *IMPEDIMENTS* - none Esbee Linden ------------------------------ *PAST* - OOO - Vacation *FUTURE* - Catching up - Meetings - Snowstorm and Viewer presentations prep - Upload sketches of saved layouts - Review integration queue list and made sure "target viewer version" is updated for merge monkey - Snowstorm Triage w/Q - Design work for Sprint 9 - Prep for Viewer 2.4 release *IMPEDIMENTS* - None Paul ProductEngine ------------------------------ *PAST* - BUG STORM-625 (Multiple cut-offs in the Preferances floater if UI size differs from 1.0) - While working on this bug found out that this bug is a particular case of more obvious problem VWR-21493. So resolved it as duplicate of VWR-21493. - TASK STORM-622 (Texture picker screws up when multiple textures are opened) - Commited to the bibucket - BUG STORM-713 (XML/UI issues in llTextBox) - WIP. 95%. Everything work fine. Will adjust submit button in XML and disable "Submit" button when text box is empty. Will test and send for review. *FUTURE* - BUG STORM-713 (XML/UI issues in llTextBox) *IMPEDIMENTS* - VWR-21493 is assigned to Richard and doesn?t seem to be getting love anytime soon. Seth Productengine ------------------------------ *PAST* - TASK (STORM-693) Preview thumbnails in the Edit Wearable and Edit Body Parts panels do not honor opacity settings - Fixed. Sent for review. - BUG (STORM-378) Snapshot animation should be played when snapshot is actually taken, not sent - Reverted previous fix. - BUG (STORM-703) while opening a few purchases the folders went above the "my inventory" line and they cant be moved, when I try I crash - Investigating. Could not reproduce for now. *FUTURE* - BUG (STORM-703) while opening a few purchases the folders went above the "my inventory" line and they cant be moved, when I try I crash *IMPEDIMENTS* - none Andrew Productengine ------------------------------ *PAST* - Normal task 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). - Discussed with Vadim. Sent Q a letter with proposition of design of for STORM-777 (Design the file format for layout information and discuss it) - Finished investigating. Investigated existing system of storing floaters visibility and dimensions hoping to reuse it in implementation of this ticket, but after investigation decided that it will be not very good for it. Started implementing the first raw version of the fix. *FUTURE* - STORM-2 *IMPEDIMENTS* - Couldn't stay in parcel from STORM-525's comments, because it has access restrictions and ejected me. Perhaps to reproduce it I will need access. - STORM-777 (Design the file format for layout information and discuss it). - No reply from Q to letter regarding this issue. - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Though it's not an impediment for me, this ticket is still not reviewed by Esbee and therefore is stuck on bitbucket. Vadim Productengine ------------------------------ *PAST* - Bug STORM-431 (Hot keys don't work while use autocomplete in search field): - Fixed. - Bug STORM-636 (Pulseaudio support is crashing web media on some new Linux distros): - Reviewed Tofu's fix. - Bug STORM-395 (IM toasts disappear without fading): - Resolved as not reproducible. - Bug STORM-332 (ABOUT SECOND LIFE window text too dark): - Resolved as not reproducible. - Discussed view storage format (STORM-2) with Andrew. - Helped Seth with Edit Wearable panel transparency issue. - Task STORM-766 (Day cycling image doesn't follow opacity settings): - Made an additional fix. - Bug STORM-391 (Newer notification toasts appear over older messages): - Fixed. - Bug STORM-529 (Undo feature missing from BUILD menu in VIEWER SL2.1): - Re-resolved as not reproducible. - Task STORM-765 (llDialog, llGiveInventory, llGotoURL messages are opaque on first open): - Re-resolved as not reproducible. - Severe bug STORM-702 (Make it possible to wear partial outfits): - Posted a fix for review. - Bug STORM-781 ("ExternalEditor" cannot handle multiple scripts opened at the same time): - Fixed. - Bug STORM-401 (People to whom the user has sent a teleport offer are not added to Recent Tab): - Fixed. - Bug STORM-767 (Media Settings Preview doesn't follow opacity settings): - Resolved as expected behavior. - Bug STORM-605 (Value of Cache size doesn't change if you try to enter a new value higher than 2048): ** Resolved as expected behavior. - Code review. *FUTURE* - Submit the fix for STORM-702 if it passes review. - Bug STORM-494 (Message Well window is undocked while opening Side bar). - Pick more bugs from the bug queues. *IMPEDIMENTS* - Need Esbee to review STORM-529 - Is it ok to add Undo/Redo items to the Build menu? - My permission to share JIRA filters has been revoked. - Question: Shouldn't the tickets from the viewer-beta bug queue be moved to the v-d bug queue? - Question: We've seen numerous critical issues lately caused by PE making changes in viewer without understanding all consequences (see STORM-702 for example). Do we need to alter the process somehow to avoid such issues? - Need Esbee to review STORM-34. Andrey Productengine ------------------------------ *PAST* - picked up v-d build r216547 - verified about ~15 integrated tickets - refactored the Preferences test plan in order to match STORM-31 changes - started design of Object Perms test plan and revision of Snapshot, Worldmap TPs *FUTURE* - pick up 2.4.0 Release build (?) *IMPEDIMENTS* - None Jonathan Yap ------------------------------ *PAST* - Fixed bugs. Found a bug. - Sent "my long project list (updated)" to Esbee and Oz. - Wrote jira on object notification toasts workflow/design flaw. - After much struggling used codereview for the first time. *FUTURE* - [long range] Update lsl wiki - Change Unsupported icon next to llTextBox to New Feature. - As this is a locked page a Linden will have to do this. *IMPEDIMENTS* - Would like to have VWR-16569 brought into STORM and assigned to me. - vwr-24155 for your & Products consideration Wolfpup Lowenhar ------------------------------ *PAST* - STORM-765 : Re-Opened and updated to include images showing issue is still present. (left this unassigned as I did not know who best to assign it to.) - Attended Scrum meeting. - STORM-776 : Imported by Merov at my request as this is a bug fix and began work. - Posted email to opensource-dev concerning STORM-776 . *FUTURE* - STORM-776 : estimating 7 days total time maybe even longer. - (need to talk to Esbee and Q concerning this) *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand (it is slowly healing but will take time since it is the tip of middle finger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101213/93d51b2e/attachment-0001.htm From vsavchuk at productengine.com Tue Dec 14 01:23:22 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 14 Dec 2010 09:23:22 -0000 Subject: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter In-Reply-To: <20101213180535.18781.88299@domU-12-31-38-00-90-68.compute-1.internal> References: <20101213180535.18781.88299@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101214092322.18771.70302@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/#review23 ----------------------------------------------------------- Ship it! Looks plausible and works for me. - Vadim On 2010-12-13 10:05:35, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/16/ > ----------------------------------------------------------- > > (Updated 2010-12-13 10:05:35) > > > Review request for Viewer. > > > Summary > ------- > > You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. > > > Diffs > ----- > > indra/newview/llagentcamera.cpp 3d2e71443c58 > > Diff: http://codereview.secondlife.com/r/16/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101214/b5ca4764/attachment.htm From oz at lindenlab.com Tue Dec 14 07:03:25 2010 From: oz at lindenlab.com (Oz Linden) Date: Tue, 14 Dec 2010 15:03:25 -0000 Subject: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter In-Reply-To: <20101213180535.18781.88299@domU-12-31-38-00-90-68.compute-1.internal> References: <20101213180535.18781.88299@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101214150325.18777.52120@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/ ----------------------------------------------------------- (Updated 2010-12-14 07:03:25.753345) Review request for Viewer. Changes ------- added jira link Summary ------- You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. This addresses bug vwr-20962. http://jira.secondlife.com/browse/vwr-20962 Diffs ----- indra/newview/llagentcamera.cpp 3d2e71443c58 Diff: http://codereview.secondlife.com/r/16/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101214/857bf858/attachment.htm From jhwelch at gmail.com Tue Dec 14 12:39:34 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Tue, 14 Dec 2010 20:39:34 -0000 Subject: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag Message-ID: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/ ----------------------------------------------------------- Review request for Viewer. Summary ------- I wrote two programs that use settings.xml to produce this massive table: http://wiki.secondlife.com/wiki/Debug_Settings While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. Having these cleaned out would make running my program, and thus updating the wiki table, easier. I've erased all but the last entry for these redundant debug settings. This addresses bug vwr-24100. http://jira.secondlife.com/browse/vwr-24100 Diffs ----- indra/newview/app_settings/settings.xml 46a990f8296f Diff: http://codereview.secondlife.com/r/18/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101214/002681d1/attachment.htm From oz at lindenlab.com Tue Dec 14 12:47:06 2010 From: oz at lindenlab.com (Oz Linden) Date: Tue, 14 Dec 2010 20:47:06 -0000 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available In-Reply-To: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> References: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101214204706.18775.90974@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/3/#review24 ----------------------------------------------------------- Minor cosmetic comments only.... great work, Merov. indra/llkdu/llimagej2ckdu.cpp It's confusing to leave in code that's commented out like this... especially when it includes nested // style comments. indra/llkdu/llkdumem.h More commented out code.... indra/llkdu/llkdumem.cpp Just delete this... ? - Oz On 2010-12-03 17:17:14, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/3/ > ----------------------------------------------------------- > > (Updated 2010-12-03 17:17:14) > > > Review request for Viewer. > > > Summary > ------- > > This rather big patch accomplish the following: > - makes llkdu public and open source: this contains decompression and compression implementations using the KDU API > - links the viewer to KDU v6.4.1 statically if USE_KDU set at build time (and assuming you do have a licensed version of Kakadu) > - links statically to OpenJpeg otherwise > > > This addresses bug STORM-151. > http://jira.secondlife.com/browse/STORM-151 > > > Diffs > ----- > > indra/CMakeLists.txt d94b8cf6891f > indra/cmake/Copy3rdPartyLibs.cmake d94b8cf6891f > indra/cmake/LLKDU.cmake d94b8cf6891f > indra/integration_tests/llui_libtest/CMakeLists.txt d94b8cf6891f > indra/llimage/CMakeLists.txt d94b8cf6891f > indra/llimage/llimage.cpp d94b8cf6891f > indra/llimage/llimagej2c.h d94b8cf6891f > indra/llimage/llimagej2c.cpp d94b8cf6891f > indra/llkdu/CMakeLists.txt PRE-CREATION > indra/llkdu/llimagej2ckdu.h PRE-CREATION > indra/llkdu/llimagej2ckdu.cpp PRE-CREATION > indra/llkdu/llkdumem.h PRE-CREATION > indra/llkdu/llkdumem.cpp PRE-CREATION > indra/newview/CMakeLists.txt d94b8cf6891f > indra/newview/viewer_manifest.py d94b8cf6891f > install.xml d94b8cf6891f > > Diff: http://codereview.secondlife.com/r/3/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101214/9f1e9dc4/attachment-0001.htm From akanevsky at productengine.com Tue Dec 14 12:53:47 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 14 Dec 2010 14:53:47 -0600 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, December 14 Message-ID: Tuesday, December 14, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-453 : libcurl 7.21: Build viewer on Windows successfully! Yay! Needs to tweak Mac and Linux build of libcurl so to build the viewer. - Merge Monkeying - Quite a few internal meetings... *FUTURE* - STORM-786 : release blocker: investigate with crew - STORM-453 : libcurl: Fix the Mac and Linux builds, ask Robin to pull the dev repo and test the Windows version - OH - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Catching up on email and other goings-on - Documenting code review system on wiki - Try again to get signoff for WEB- *FUTURE* - Documenting code review system on wiki - Merge Monkey *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - STORM-786 and STORM-689 - Release work - 2011 planning and meetings *FUTURE* - release - Triage -- really this time *IMPEDIMENTS* - none Esbee Linden ------------------------------ *PAST* - Meetings - Catch up on emails - Prep for Viewer/Snowstorm meeting - Review integration queue - Prep for Viewer 2.4 release - Reviewed STORM-34 and gave additional feedback this morning. I'm not comfortable shipping this feature as it's been implemented so far. *FUTURE* - Lots of meetings - Write Viewer 2.4 release blog post - Review integration queue list and made sure "target viewer version" is updated for merge monkey - Upload sketches of saved layouts - Snowstorm Triage w/Q - VWRs to check on (from PE) - VWR-21493 - STORM-525 - STORM-529. It was re-resolved as no repro. - STORM-702. Caused issues based on fix. Let's chat more with PE about this. - Review VWR-16569 - Will review. Jonathan wants this one. - Review Jonathan's work list - Send STORM-398 to Taka for Communications tools input - See comments on STORM-713 - Review STORM-24155 for backlog consideration *IMPEDIMENTS* - Time Paul ProductEngine ------------------------------ *PAST* - BUG STORM-713 (XML/UI issues in llTextBox) - Finished and pushed to the bitbucket - BUG STORM-434 (Tooltips don't appear on Mini-Location bar.) - Fixed and pushed to the bitbucket - BUG STORM-352 (Vertical scrollbar isn't reshaped in resident profile panel after decreasing panel height) - Fixed and pushed to the bitbucket *FUTURE* - BUG STORM-508 (Teleport history entries from "2 days ago", "3 days ago", etc. lists are moved into "Today" list on teleport) *IMPEDIMENTS* - VWR-21493 is assigned to Richard and doesn?t seem to be getting love anytime soon. - Got a cold, not feeling very good. Going home a little bit earlier. Seth Productengine ------------------------------ *PAST* - BUG (STORM-703) while opening a few purchases the folders went above the "my inventory" line and they cant be moved, when I try I crash - Could not repro with any given scenario. - BUG (STORM-398) Message from nearby chat appears for avatar in Busy mode. - Fixed. Sent for review. - BUG (STORM-711) Filtering broken in My Outfits - Looks like expected behavior. Waiting for Esbee's reply. *FUTURE* Back to: - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Estimated: 2 days - or pick some tasks from Sprint 9. *IMPEDIMENTS* - STORM-711 - Waiting for Esbee?s reply. Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Discussed with Vadim. Left a comment in ticket regarding contradiction between initial design of the feature and per-account saving. - Normal task STORM-2 (UI Layout Views) - WIP. Implementing saving of layout. *FUTURE* - STORM-2. Finish implementing saving. Proceed to implementation of loading. Estimate - 3 days to: finish save/load, make temporary UI for testing the first version of implementation and test it. - Critical bug STORM-525 (Runtime Error message from the Microsoft Visual C++ Runtime Library eventually leads to Crash) - Try reproducing this crash on regions listed by Mairead Fitzgerald. *IMPEDIMENTS* - Major bug STORM-229 (Loading Scripts takes a long time and stalls Viewer) - Though it's not an impediment, I suppose it's worth mentioning in report: In comment to STORM-229 Satomi Ahn listed tickets, fixes of which are important for scripters. And though internal script editor now has external alternatives, perhaps this list should be taken into account - STORM-777 (Design the file format for layout information and discuss it). - No reply from Q to letter regarding this issue. Vadim Productengine ------------------------------ *PAST* - Moved tickets from the viewer-beta bug queue be moved to the v-d bug queue (Esbee agreed yesterday). - Bug STORM-494 (Message Well window is undocked while opening Side bar): - Investigated, reassigned to Andrew. - Master task STORM-684 (Floater transparency settings aren't applied for some floaters and/or controls inside them): - Resolved as fixed (all child tasks have been implemented). - Bug STORM-409 (Offer text isn't copied to clipboard): - Resolved as not reproducible. - Bug STORM-410 (Region and parcel SLApps are displayed in non-human readable format): - WIP, 40% complete. - Showstopper bug STORM-786 (Back button, Username and Display Name are missing in Resident profile tab): - WIP. *FUTURE* - Fix STORM-786. - Complete the fix for STORM-410 if time allows. *IMPEDIMENTS* - Need Esbee's answer in STORM-529 (Undo feature missing from BUILD menu). - Need Esbee's answer in STORM-711 (Filtering broken in My Outfits). - Need feedback from Nyx/Esbee in STORM-702 (Make it possible to wear partial outfits). Questions: - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - picked up v-d build 216577 - verified bunch of integrated tickets - verified ~30 "cannot reproduce" and "expected behavior" tickets - 2 have been reopened - continued test plans update - snapshot tools, obj permissions and worldmap *FUTURE* - pickup Release build (?) *IMPEDIMENTS* - None Jonathan Yap ------------------------------ *PAST* - STORM-784 Missing character, adjusted wording for llTextBox tooltip -- done - STORM-785 Last chatter needs CTRL-\ to be pushed twice to work -- done *FUTURE* - Need to meet with Oz re: llTextBox new feature issue that I was in touch with Simon about. - ~2 weeks travel - [long range] Update lsl wiki - Change Unsupported icon next to llTextBox to New Feature. - As this is a locked page a Linden will have to do this. *IMPEDIMENTS* - STORM-785 -- I cannot get at the jira field to set the location of the bitbucket repo - Need to know from Oz if SignpostMarv Martin has a CA. There is a patch he is about to develop that I would like to help take into the system. Wolfpup Lowenhar ------------------------------ *PAST* - Worked in world and RL. *FUTURE* - STORM-776 : Study bug fix in STORM-288 and see if maybe it sould be applied in a broader way to fix both. Apply bugfix to local repos and make similar changes in functions that control the permision updating in the Item Information side pannel then build and test these changes. Building of local repository will be done while @ Doc's as it takes a while to run localy. - Work in world and RL. - Doc appointmant. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand (it is slowly healing but will take time since it is the tip of middle finger.) - Doc app (will be out half the day) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101214/3032836c/attachment-0001.htm From malachi at tamzap.com Tue Dec 14 19:23:09 2010 From: malachi at tamzap.com (Malachi Prophit) Date: Tue, 14 Dec 2010 22:23:09 -0500 Subject: [opensource-dev] Can anyone tell me how to get rid of these lol... Message-ID: i get hundreds of these stupid errors. And i have since i compiled the first client back on 1.18. They are harmless but very annoying. they always look like this..... Warning 3 warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\Documents and Settings\Owner\Desktop\linden\indra\build-VC90\media_plugins\quicktime\Release\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib I have no clue what they are or where to start ... thanks in advance. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From wolfpup67 at earthlink.net Tue Dec 14 19:45:22 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 14 Dec 2010 22:45:22 -0500 Subject: [opensource-dev] Can anyone tell me how to get rid of these lol... In-Reply-To: References: Message-ID: <000001cb9c0a$804d59b0$80e80d10$@net> Actualy in an open source environment you cannot get rid of those link warnings they are the linker complaining about the fact that the debug information for those files is missing and you will see those messages for any lib files you get from LL when running in non-standalone build mode From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Malachi Prophit Sent: Tuesday, December 14, 2010 10:23 PM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Can anyone tell me how to get rid of these lol... i get hundreds of these stupid errors. And i have since i compiled the first client back on 1.18. They are harmless but very annoying. they always look like this..... Warning 3 warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with '..\..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at 'C:\Documents and Settings\Owner\Desktop\linden\indra\build-VC90\media_plugins\quicktime\Relea se\apr-1_ib_1.pdb'; linking object as if no debug info apr-1.lib I have no clue what they are or where to start ... thanks in advance. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ _______________________________________________ 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3316 - Release Date: 12/14/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101214/1c297fa5/attachment.htm From hitomi.tiponi at yahoo.co.uk Wed Dec 15 03:00:17 2010 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Wed, 15 Dec 2010 11:00:17 +0000 (GMT) Subject: [opensource-dev] opensource-dev Digest, Vol 11, Issue 36 In-Reply-To: References: Message-ID: <626424.52024.qm@web23901.mail.ird.yahoo.com> >Jonathan Yap wrote: > >I wrote two programs that use settings.xml to produce this massive table: >http://wiki.secondlife.com/wiki/Debug_Settings > >While doing this I found 4 places with duplicate entries and 1 entry that is >repeated 4 times. There is also a pair of unnecessary tags. Thanks Jonathan - that is very useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/178cd318/attachment.htm From opensourceobscure at gmail.com Wed Dec 15 05:55:48 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Wed, 15 Dec 2010 14:55:48 +0100 Subject: [opensource-dev] opensource-dev Digest, Vol 11, Issue 36 In-Reply-To: <626424.52024.qm@web23901.mail.ird.yahoo.com> References: <626424.52024.qm@web23901.mail.ird.yahoo.com> Message-ID: On Wed, Dec 15, 2010 at 12:00, Hitomi Tiponi wrote: > >>Jonathan Yap wrote: >> >>I wrote two programs that use settings.xml to produce this massive table: >>http://wiki.secondlife.com/wiki/Debug_Settings >> >>While doing this I found 4 places with duplicate entries and 1 entry that >> is repeated 4 times.? There is also a pair of unnecessary tags. > > Thanks Jonathan - that is very useful. f**ing awesome! THANKS :) I hold in-world lessons where I teach advanced use of the SL viewer, and people really love explanations and details about Debug Settings. This new list will be very useful indeed. Jonathan, would you like to share some further details about what you did to produce the list from the viewer code? Maybe share the programs themselves? A few months ago I managed to do something similar but I remember I had to manually check each entry and do some correction because my scripts weren't precise enough. It was quite tedious, and still not very efficient: this list is bound to get quickly outdated as soon as new features/settings get added to the viewer. For example the current version doesn't include the Debug Settings about Depth of Field (that's ok, since IIRC that feature is only present in the last Mesh dev. builds). I guess it would be good if many of us were able to create new, up-to-date versions of the list. -- Opensource Obscure From wolfpup67 at earthlink.net Wed Dec 15 06:46:37 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Wed, 15 Dec 2010 14:46:37 -0000 Subject: [opensource-dev] Review Request: Bug Fix for STORM-776 and STORM-288 Message-ID: <20101215144637.18766.77585@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/21/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This is actually Kitty's patch for STORM-288 but it also corrects the issue listed in STORM-776 as well. This addresses bug STORM-776. http://jira.secondlife.com/browse/STORM-776 Diffs ----- doc/contributions.txt b0689af42a71 indra/newview/llsidepaneliteminfo.h b0689af42a71 indra/newview/llsidepaneliteminfo.cpp b0689af42a71 Diff: http://codereview.secondlife.com/r/21/diff Testing ------- I have built and tested this locally and was able to fully modify the next person permissions on object that i had full permissions also tested to see if I could set item in inventory for sale and I could. Thanks, Wolfpup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/033ed623/attachment.htm From vsavchuk at productengine.com Wed Dec 15 09:30:33 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Wed, 15 Dec 2010 17:30:33 -0000 Subject: [opensource-dev] Review Request: (STORM-771) As someone working with outfits, copy/paste in Current Outfit Folder should paste links (which are supported) rather than objects (which are not) In-Reply-To: <20101214205617.18766.25092@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214205617.18766.25092@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101215173033.18709.24327@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/20/#review26 ----------------------------------------------------------- Ship it! Looks fine. I'm only not sure about forcing links in outfits other than the COF: outfit vendors won't be able to create an outfit (i.e. a folder of type FT_OUTFIT) for sale, consisting of original items. But this seems to be expected because even stock outfits in Library are actually normal folders. - Vadim On 2010-12-14 12:56:16, Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/20/ > ----------------------------------------------------------- > > (Updated 2010-12-14 12:56:16) > > > Review request for Viewer. > > > Summary > ------- > > Pasting wearable items from clipboard to Current Outfit or an outfit folder now creates links to these items. > > > This addresses bug STORM-771. > http://jira.secondlife.com/browse/STORM-771 > > > Diffs > ----- > > indra/newview/llinventorybridge.cpp 46a990f8296f > > Diff: http://codereview.secondlife.com/r/20/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/bd182667/attachment-0001.htm From yoz at lindenlab.com Wed Dec 15 09:47:25 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Wed, 15 Dec 2010 09:47:25 -0800 Subject: [opensource-dev] opensource-dev Digest, Vol 11, Issue 36 In-Reply-To: <626424.52024.qm@web23901.mail.ird.yahoo.com> References: <626424.52024.qm@web23901.mail.ird.yahoo.com> Message-ID: > >Jonathan Yap wrote: > > > >I wrote two programs that use settings.xml to produce this massive table: > >http://wiki.secondlife.com/wiki/Debug_Settings > > > >While doing this I found 4 places with duplicate entries and 1 entry that > is repeated 4 times. There is also a pair of unnecessary tags. > *WILD APPLAUSE* Thank you, Jonathan! That's fantastic! -- Yoz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/c4a64bd8/attachment.htm From angel_of_crimson at hotmail.com Wed Dec 15 10:23:25 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Wed, 15 Dec 2010 13:23:25 -0500 Subject: [opensource-dev] Proposal for alternative outfit editing system Message-ID: As a user/tester/etc, I have been talking to allot of users and content creators. one of the things that I kept hearing over and over is how hard the outfit editor is to use and that you can't just easily arrange all clothing/tat sublayers from the inventory screen. to that affect I have been busy colelcting and compiling ideas and here is the result that I and others have come up with: 1) have an optional way to replace the wear and take off menus on the avatar and inventory with menus that that have the specific sublayer. 2) move the wearing panel to the inventory tab 3) introduce a new panel with both a simple and advanced view that would completely replace the currant outfit editor. (see attachment for example mock up of advanced panel.) This panel would be: a) consist of drag and drop slots that would allow you to drag any item, skin, shape, tattoo, clothing, etc, for fast intuitive equipping b) allow rapid rearrangement of sub layers by simple dragging from one slot to another c) have its own panel for previewing the avatar with eventual selection of preview poses, zooming, rotation, etc, for easy outfit previewing d) eventually be totally customizable. e) panel would NOT be docked but would be resizeable (and if need be scrollable) to allow for flexibility and accessibility. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/c6fceace/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: proposed editor.jpg Type: image/jpeg Size: 131123 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/c6fceace/attachment-0001.jpg From sldev at catznip.com Wed Dec 15 11:27:50 2010 From: sldev at catznip.com (Kitty Barnett) Date: Wed, 15 Dec 2010 19:27:50 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() Message-ID: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/ ----------------------------------------------------------- Review request for Viewer. Summary ------- erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. This addresses bug VWR-24207. http://jira.secondlife.com/browse/VWR-24207 Diffs ----- indra/newview/llremoteparcelrequest.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/24/diff Testing ------- Thanks, Kitty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/c45534c7/attachment.htm From sldev at catznip.com Wed Dec 15 11:48:39 2010 From: sldev at catznip.com (Kitty Barnett) Date: Wed, 15 Dec 2010 19:48:39 -0000 Subject: [opensource-dev] Review Request: Crash in LLVivoxVoiceClient::notifyStatusObservers() Message-ID: <20101215194839.18775.7087@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/25/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Moved removeObserver() out of the "if(getAvatarId().notNull()) { }" block since "getAvatarId()" can return the NULL UUID (i.e. if the panel hasn't been opened), matching the addObserver() without condition in postBuild. This addresses bug VWR-24209. http://jira.secondlife.com/browse/VWR-24209 Diffs ----- indra/newview/llpanelavatar.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/25/diff Testing ------- Thanks, Kitty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/ea43a047/attachment.htm From trilobyte550m at gmail.com Wed Dec 15 12:31:14 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 15 Dec 2010 12:31:14 -0800 Subject: [opensource-dev] Display Name should show when using actions (/me) in Group Chat Message-ID: <9EEF2A67-F0F5-45C9-A0A2-B4CEBFDF2EDF@gmail.com> As a resident, I would like to see Display Names show correctly when they use actions in Group Chat. I'd mentioned this in this morning's meeting (on behalf of a couple communities who'd asked about it recently). Esbee asked if I had a JIRA issue handy. After some looking around, I couldn't find anything that quite matched, so I created: https://jira.secondlife.com/browse/VWR-24211 Cheers TriloByte Zanzibar From trilobyte550m at gmail.com Wed Dec 15 12:58:56 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 15 Dec 2010 12:58:56 -0800 Subject: [opensource-dev] [Idea] Display Notifications as a scrollable feed (instead of series of popups) Message-ID: <13F1E105-575E-42F0-B043-AFD23CFC4D7F@gmail.com> As a user, I would like to see notifications displayed as a scrollable feed (similar to a twitter client on desktop/smartphone) instead of as a series of popup boxes. More info (and mockup pic) here -> https://jira.secondlife.com/browse/VWR-24213 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/56e3c88e/attachment.htm From akanevsky at productengine.com Wed Dec 15 12:59:00 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Wed, 15 Dec 2010 14:59:00 -0600 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, December 15 Message-ID: Wednesday, December 15, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-453 : libcurl 7.21: Tweaked Mac and Linux build of libcurl and pushed changes on brad's repo. Built the viewer but was thrown on a wild goose chase courtesy of a mac-updater build issue. Eventually built a Mac viewer using libcurl 7.21. - OH : Interesting conversation on use of alpha channels and sculpties with. Lots of information for me. Thanks to folks showing up. *FUTURE* - STORM-453 : libcurl: Finished cleaning up the Mac and Linux builds. Build on TC for all platforms. - STORM-151: kdu compression: Clean up. Test other settings (use of precincts, check premultiplication for alpha). Compare perf to baseline. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Documented posting code reviews - Triggered a bug that exposed my Bitbucket password (now changed) - Started TeamCity build for Wolfpup on STORM-776 (still running) - Merge Monkey - merged several fixes - pulled all changes back from beta *FUTURE* - Merge Monkey - Autobbuild audits so we can publish it as open source *IMPEDIMENTS* - none Q Linden ------------------------------ - OOO - medical Esbee Linden ------------------------------ - OOO Paul ProductEngine ------------------------------ - OOO - sick Seth Productengine ------------------------------ *PAST* - Story (STORM-771) As someone working with outfits, copy/paste in Current Outfit Folder should paste links (which are supported) rather than objects (which are not) - Fixed. Posted for review. - Story (STORM-28) As a User, I want the ability to send my calling card to others. - Investigated. Asked for more details. *FUTURE* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Estimated: 2 days - or pick some tasks from Sprint 9. *IMPEDIMENTS* - Story (STORM-28) As a User, I want the ability to send my calling card to others. - Waiting for more details. Andrew Productengine ------------------------------ *PAST* - Normal task STORM-2 (UI layout saving) - WIP. Implemented plain version of saving and started implementing loading. While implementing loading found problems in saving. In process of changing it. - Critical bug STORM-525 (Runtime Error message from the Microsoft Visual C++ Runtime Library eventually leads to Crash) - - Tried to reproduce on different locations where Mairead Fitzgerald but had no luck- teleported, waited and moved for some time, but didn't experience any cracks or even memory leaks. Maybe testers could try to find some stable steps to reproduce this issue and than it would be assigned back to me? - Critical bug STORM-786 (Back button, Username and Display Name are missing in Resident profile tab) - Helped Vadim at pre-review stage of the ticket. *FUTURE* - STORM-2. Hope to finish implementation of save and load tomorrow. - Estimate - 2-2,5 days. *IMPEDIMENTS* - STORM-777 (Design the file format for layout information and discuss it). - No reply from Q to letter regarding this issue. Vadim Productengine ------------------------------ *PAST* - Moved tickets from the viewer-beta bug queue be moved to the v-d bug queue (Esbee agreed yesterday). - Bug STORM-494 (Message Well window is undocked while opening Side bar): - Investigated, reassigned to Andrew. - Master task STORM-684 (Floater transparency settings aren't applied for some floaters and/or controls inside them): - Resolved as fixed (all child tasks have been implemented). - Bug STORM-409 (Offer text isn't copied to clipboard): - Resolved as not reproducible. - Showstopper bug STORM-786 (Back button, Username and Display Name are missing in Resident profile tab): - Fixed. - Bug STORM-410 (Region and parcel SLApps are displayed in non-human readable format): - WIP 70%. *FUTURE* - Complete the fix for STORM-410. - Bug STORM-446 (CLicking on /app/classified SLapp does not open the classified details). - Bug STORM-511 (User is not able to view full name of group in title of group notification). *IMPEDIMENTS* - Need Esbee's answer in STORM-529 (Undo feature missing from BUILD menu). - Need feedback from Nyx/Esbee in STORM-702 (Make it possible to wear partial outfits). Questions: - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - picked up release build 216507 - smoke & integrity tests against Windows, OSX and Linux - smoke has been failed by STORM-786 - verified changes since Beta2 build (4 L10N tickets) - exploratory testing of 2.4.0 interim release build r216842 - ToS testing (failed by the minor issue STORM-789) - tested fix for STORM-786 on a private build *FUTURE* - pickup final 2.4.0 release build and re-run smoke & integrity tests *IMPEDIMENTS* - None Wolfpup Lowenhar ------------------------------ *PAST* - Worked in world. - Doc appointmant. (was released back to full duty just have to be careful with it for a while till it is fully healed) - STORM-776 : Posted change to code review board and commited to my online repository. - Changed status to in Review and left assigned to me per Oz and did the same with related STORM-288. - Asked OZ to do a TC build run of online repository to make test viewer for others to check it out and verify fix. - Attended Esbee's OH. *FUTURE* - Work in world and RL. - STORM-776 and Storm-288 if needed. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand (it is slowly healing but will take time since it is the tip of middle finger.) - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/f6a3ff9e/attachment-0001.htm From suezanne at gmail.com Wed Dec 15 18:32:45 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Wed, 15 Dec 2010 20:32:45 -0600 Subject: [opensource-dev] "Changes since the last good build" part of "Build Results from snowstorm_viewer-development" Message-ID: The "Changes since the last good build at " part of the "Build Results" page at http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/latest.html seems to have a problem. At the bottom, instead of a list of changes, like it used to have, it has a link, and the link doesn't work. Changes since the last good build(2010-12-15T04:14:49.000Z): click here -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/4c5f760b/attachment.htm From cg at lindenlab.com Wed Dec 15 19:40:29 2010 From: cg at lindenlab.com (CG Linden) Date: Wed, 15 Dec 2010 19:40:29 -0800 Subject: [opensource-dev] "Changes since the last good build" part of "Build Results from snowstorm_viewer-development" In-Reply-To: References: Message-ID: Yeah, this is now compiled via a different process... I really would like to redo the build results page. -- cg On Wed, Dec 15, 2010 at 6:32 PM, SuezanneC Baskerville wrote: > The "Changes since the last good build at " part of the "Build Results" > page at > > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/latest.html > seems to have a problem. > > At the bottom, instead of a list of changes, like it used to have, it has a > link, and the link doesn't work. > Changes since the last good build(2010-12-15T04:14:49.000Z): click > here > > > > > -- > v i r t u a l w o r l d e n t h u s i a s t > -- http://www.google.com/profiles/s u e z a n n e -- > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/3eb8c98c/attachment.htm From wolfpup67 at earthlink.net Wed Dec 15 19:59:24 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 16 Dec 2010 03:59:24 -0000 Subject: [opensource-dev] Review Request: Bug Fix for STORM-776 and STORM-288 In-Reply-To: <20101215144637.18766.77585@domU-12-31-38-00-90-68.compute-1.internal> References: <20101215144637.18766.77585@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216035924.18742.17143@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/21/ ----------------------------------------------------------- (Updated 2010-12-15 19:59:24.512762) Review request for Viewer. Changes ------- add link to TC builds Oz did of online repository so others can test this fix. Summary ------- This is actually Kitty's patch for STORM-288 but it also corrects the issue listed in STORM-776 as well. This addresses bug STORM-776. http://jira.secondlife.com/browse/STORM-776 Diffs ----- doc/contributions.txt b0689af42a71 indra/newview/llsidepaneliteminfo.h b0689af42a71 indra/newview/llsidepaneliteminfo.cpp b0689af42a71 Diff: http://codereview.secondlife.com/r/21/diff Testing (updated) ------- I have built and tested this locally and was able to fully modify the next person permissions on object that i had full permissions also tested to see if I could set item in inventory for sale and I could. Test Viewers for this issue are available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/216992/index.html please test this on mac and linux to verify fix works on all platforms. Thanks, Wolfpup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/7c9def38/attachment.htm From cg at lindenlab.com Wed Dec 15 20:04:00 2010 From: cg at lindenlab.com (CG Linden) Date: Wed, 15 Dec 2010 20:04:00 -0800 Subject: [opensource-dev] "Changes since the last good build" part of "Build Results from snowstorm_viewer-development" In-Reply-To: References: Message-ID: I restored the old code path for changes since last good build for now... Maybe there is a way to make the new service public someday. -- cg On Wed, Dec 15, 2010 at 7:40 PM, CG Linden wrote: > Yeah, this is now compiled via a different process... > > I really would like to redo the build results page. > -- > cg > > On Wed, Dec 15, 2010 at 6:32 PM, SuezanneC Baskerville > wrote: > >> The "Changes since the last good build at " part of the "Build Results" >> page at >> >> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/snowstorm_viewer-development/latest.html >> seems to have a problem. >> >> At the bottom, instead of a list of changes, like it used to have, it has >> a link, and the link doesn't work. >> Changes since the last good build(2010-12-15T04:14:49.000Z): click >> here >> >> >> >> >> -- >> v i r t u a l w o r l d e n t h u s i a s t >> -- http://www.google.com/profiles/s u e z a n n e -- >> >> _______________________________________________ >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/c53d869e/attachment.htm From kf6kjg at gmail.com Wed Dec 15 20:04:52 2010 From: kf6kjg at gmail.com (Ricky) Date: Wed, 15 Dec 2010 20:04:52 -0800 Subject: [opensource-dev] [WEB] Some Wiki pages unreadable when not logged in Message-ID: I was just looking up a reference in the wiki ( http://wiki.secondlife.com/wiki/LlKey2Name ) and found it to be largely empty! I then check history and source, all looked good. So I browsed other functions, some were visible, some not. Then I logged in, and viola all were visible. Logged back out, empty again. Maybe some common template was messed up for anon users? Ricky Crons Stardust PS: Yes, this isn't a viewer issue, but that's why I marked it [WEB]. However, I figure someone with more knowledge of the LL wiki template architecture might be able to shed some light/fix it. From wolfpup67 at earthlink.net Wed Dec 15 20:07:46 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Wed, 15 Dec 2010 23:07:46 -0500 Subject: [opensource-dev] FW: Review Request: Bug Fix for STORM-776 and STORM-288 Message-ID: <003901cb9cd6$cbb56bf0$632043d0$@net> For some reason this review request did not get posted to opensource-dev so I?m sending this copy. From: Wolfpup Lowenhar [mailto:wolfpup67 at earthlink.net] Sent: Wednesday, December 15, 2010 10:59 PM To: Wolfpup Lowenhar; Viewer Subject: Re: Review Request: Bug Fix for STORM-776 and STORM-288 This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/21/ Review request for Viewer. By Wolfpup Lowenhar. Updated 2010-12-15 19:59:24.512762 Changes add link to TC builds Oz did of online repository so others can test this fix. Description This is actually Kitty's patch for STORM-288 but it also corrects the issue listed in STORM-776 as well. Testing (updated) I have built and tested this locally and was able to fully modify the next person permissions on object that i had full permissions also tested to see if I could set item in inventory for sale and I could. Test Viewers for this issue are available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/216992/index.html please test this on mac and linux to verify fix works on all platforms. Bugs: STORM-776 Diffs * doc/contributions.txt (b0689af42a71) * indra/newview/llsidepaneliteminfo.h (b0689af42a71) * indra/newview/llsidepaneliteminfo.cpp (b0689af42a71) View Diff _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 426/3318 - Release Date: 12/15/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/69d0b541/attachment-0001.htm From techiedavid at gmail.com Wed Dec 15 20:13:28 2010 From: techiedavid at gmail.com (David Simmons) Date: Wed, 15 Dec 2010 20:13:28 -0800 Subject: [opensource-dev] [WEB] Some Wiki pages unreadable when not logged in In-Reply-To: References: Message-ID: Confirmed. While looking at the page not logged in, it was empty. The Nov 24 version is fine, but the Dec 10 is messed up. On Wed, Dec 15, 2010 at 8:04 PM, Ricky wrote: > I was just looking up a reference in the wiki ( > http://wiki.secondlife.com/wiki/LlKey2Name ) and found it to be > largely empty! ?I then check history and source, all looked good. So I > browsed other functions, some were visible, some not. ?Then I logged > in, and viola all were visible. Logged back out, empty again. ?Maybe > some common template was messed up for anon users? > > Ricky > Crons Stardust > > PS: Yes, this isn't a viewer issue, but that's why I marked it [WEB]. > However, I figure someone with more knowledge of the LL wiki template > architecture might be able to shed some light/fix it. > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From techiedavid at gmail.com Wed Dec 15 20:16:10 2010 From: techiedavid at gmail.com (David Simmons) Date: Wed, 15 Dec 2010 20:16:10 -0800 Subject: [opensource-dev] [WEB] Some Wiki pages unreadable when not logged in In-Reply-To: References: Message-ID: Seem that the string "SSL" caused the problem. On Wed, Dec 15, 2010 at 8:04 PM, Ricky wrote: > I was just looking up a reference in the wiki ( > http://wiki.secondlife.com/wiki/LlKey2Name ) and found it to be > largely empty! ?I then check history and source, all looked good. So I > browsed other functions, some were visible, some not. ?Then I logged > in, and viola all were visible. Logged back out, empty again. ?Maybe > some common template was messed up for anon users? > > Ricky > Crons Stardust > > PS: Yes, this isn't a viewer issue, but that's why I marked it [WEB]. > However, I figure someone with more knowledge of the LL wiki template > architecture might be able to shed some light/fix it. > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From merov at lindenlab.com Wed Dec 15 21:57:00 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 15 Dec 2010 21:57:00 -0800 Subject: [opensource-dev] Test request for STORM-453 (update libcurl 7.21.1) Message-ID: Hi, I've been working on this which is blocking Robin to complete the rest of the work for VWR-20801 (Implement socks5 proxy). I think I'm done but, since lots of things can go wrong when changing such a library, I'd like to get some folks banging on the executables before moving that to "review". Binaries can be found at: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217039/index.html Please let me know which platform you test on and what the overall result. Feedback of people building from source would also be great (see JIRA for link to the hg repo with the changes). Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/f4dc7c10/attachment.htm From merov at lindenlab.com Wed Dec 15 22:21:41 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 16 Dec 2010 06:21:41 -0000 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available In-Reply-To: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> References: <20101204011714.2974.76642@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216062141.18751.24541@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/3/ ----------------------------------------------------------- (Updated 2010-12-15 22:21:41.258325) Review request for Viewer. Changes ------- Took Oz's comment into account (suppressed unused code) + code formatting Summary ------- This rather big patch accomplish the following: - makes llkdu public and open source: this contains decompression and compression implementations using the KDU API - links the viewer to KDU v6.4.1 statically if USE_KDU set at build time (and assuming you do have a licensed version of Kakadu) - links statically to OpenJpeg otherwise This addresses bug STORM-151. http://jira.secondlife.com/browse/STORM-151 Diffs (updated) ----- indra/CMakeLists.txt 22c757e8246b indra/cmake/Copy3rdPartyLibs.cmake 22c757e8246b indra/cmake/LLKDU.cmake 22c757e8246b indra/integration_tests/llui_libtest/CMakeLists.txt 22c757e8246b indra/llimage/CMakeLists.txt 22c757e8246b indra/llimage/llimage.cpp 22c757e8246b indra/llimage/llimagej2c.h 22c757e8246b indra/llimage/llimagej2c.cpp 22c757e8246b indra/llkdu/CMakeLists.txt PRE-CREATION indra/llkdu/llimagej2ckdu.h PRE-CREATION indra/llkdu/llimagej2ckdu.cpp PRE-CREATION indra/llkdu/llkdumem.h PRE-CREATION indra/llkdu/llkdumem.cpp PRE-CREATION indra/newview/CMakeLists.txt 22c757e8246b indra/newview/viewer_manifest.py 22c757e8246b install.xml 22c757e8246b Diff: http://codereview.secondlife.com/r/3/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/2d78f4f6/attachment.htm From yoz at lindenlab.com Wed Dec 15 23:56:47 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Wed, 15 Dec 2010 23:56:47 -0800 Subject: [opensource-dev] [WEB] Some Wiki pages unreadable when not logged in In-Reply-To: References: Message-ID: Could you go into more detail about the "SSL" thing? I'm still seeing this problem. As of Wednesday morning (Pacific), the wiki has been thoroughly rebuilt, upgraded and moved to new hosting. (It's *much* faster now, and should be more stable.) However, clearly we have some teething issues. This is one the team may already be aware of, but I'll send it their way anyway. If you find any more problems, please file a WEB issue with " wiki.secondlife.com" component. The new infrastructure should allow us to iterate faster on bugfixes and upgrades, so I'm hoping we can get this one nailed quickly (as soon as we diagnose it). Thanks for raising it! On 15 December 2010 20:16, David Simmons wrote: > Seem that the string "SSL" caused the problem. > > On Wed, Dec 15, 2010 at 8:04 PM, Ricky wrote: > > I was just looking up a reference in the wiki ( > > http://wiki.secondlife.com/wiki/LlKey2Name ) and found it to be > > largely empty! I then check history and source, all looked good. So I > > browsed other functions, some were visible, some not. Then I logged > > in, and viola all were visible. Logged back out, empty again. Maybe > > some common template was messed up for anon users? > > > > Ricky > > Crons Stardust > > > > PS: Yes, this isn't a viewer issue, but that's why I marked it [WEB]. > > However, I figure someone with more knowledge of the LL wiki template > > architecture might be able to shed some light/fix it. > > _______________________________________________ > > 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 > > > > > > -- > ?The greatest danger in modern technology isn't that machines will > begin to think like people, but that people will begin to think like > machines? Unknown > > http://www.google.com/profiles/techiedavid > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101215/c79e5adc/attachment.htm From sldev at catznip.com Thu Dec 16 03:04:28 2010 From: sldev at catznip.com (Kitty Barnett) Date: Thu, 16 Dec 2010 11:04:28 -0000 Subject: [opensource-dev] Review Request: Dragging the "Contents" folder from object inventory to agent inventory shows the "prohibited" cursor Message-ID: <20101216110428.18707.87130@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/26/ ----------------------------------------------------------- Review request for Viewer. Summary ------- The "Contents" folder is an LLInventoryObject instance, and failed the dynamic cast to LLInventoryItem. The permission logic didn't apply since it's a category (which has no permissions) and was changed to use the same function that will do the actual copying so that drop behaviour should always match the "can drop" result. This addresses bug VWR-24217. http://jira.secondlife.com/browse/VWR-24217 Diffs ----- indra/newview/llpanelobjectinventory.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/26/diff Testing ------- Thanks, Kitty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/2274f65f/attachment.htm From sldev at catznip.com Thu Dec 16 03:33:51 2010 From: sldev at catznip.com (Kitty Barnett) Date: Thu, 16 Dec 2010 11:33:51 -0000 Subject: [opensource-dev] Review Request: STORM-316 Add missing "sort by name" and "sort by recent" options for folders Message-ID: <20101216113351.18778.57078@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/27/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Changes the UI (and needs additional translation), but it's a viewer 1 option that was missed by STORM-316. Existing "Sort by (Name|Most Recent)" => "Sort Items by (Name|Most Recent)" Split "Folders always by name" in two options to match what was done for inventory items and added "Sort Folders by (Name|Most Recent)" menu options. This addresses bug STORM-316. http://jira.secondlife.com/browse/STORM-316 Diffs ----- indra/newview/llpanelmaininventory.cpp UNKNOWN indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml UNKNOWN Diff: http://codereview.secondlife.com/r/27/diff Testing ------- Thanks, Kitty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/358ef352/attachment-0001.htm From vsavchuk at productengine.com Thu Dec 16 05:56:19 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 16 Dec 2010 13:56:19 -0000 Subject: [opensource-dev] Review Request: Bug Fix for STORM-776 and STORM-288 In-Reply-To: <20101216035924.18742.17143@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216035924.18742.17143@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216135619.18707.35374@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/21/#review28 ----------------------------------------------------------- Ship it! Looks plausible and works for me. - Vadim On 2010-12-15 19:59:24, Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/21/ > ----------------------------------------------------------- > > (Updated 2010-12-15 19:59:24) > > > Review request for Viewer. > > > Summary > ------- > > This is actually Kitty's patch for STORM-288 but it also corrects the issue listed in STORM-776 as well. > > > This addresses bug STORM-776. > http://jira.secondlife.com/browse/STORM-776 > > > Diffs > ----- > > doc/contributions.txt b0689af42a71 > indra/newview/llsidepaneliteminfo.h b0689af42a71 > indra/newview/llsidepaneliteminfo.cpp b0689af42a71 > > Diff: http://codereview.secondlife.com/r/21/diff > > > Testing > ------- > > I have built and tested this locally and was able to fully modify the next person permissions on object that i had full permissions also tested to see if I could set item in inventory for sale and I could. > > Test Viewers for this issue are available here: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/216992/index.html > > please test this on mac and linux to verify fix works on all platforms. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/23c5fad5/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 16 06:17:35 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 16 Dec 2010 14:17:35 -0000 Subject: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216141735.18742.9006@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review29 ----------------------------------------------------------- Ship it! looks good - Boroondas On 2010-12-14 12:39:34, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated 2010-12-14 12:39:34) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/a239531a/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 16 06:53:02 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 16 Dec 2010 14:53:02 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> References: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216145302.18768.35103@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review30 ----------------------------------------------------------- indra/newview/llremoteparcelrequest.cpp post-increments are subtle ... please include some comment in the code that points out what's going on. (Can be short) indra/newview/llremoteparcelrequest.cpp Please also comment in the code why cur_oi may not be oi when calling this, so we don't risk someone reverting your fix by accident. - Boroondas On 2010-12-15 11:27:50, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > ----------------------------------------------------------- > > (Updated 2010-12-15 11:27:50) > > > Review request for Viewer. > > > Summary > ------- > > erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > ----- > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/9b793ba2/attachment.htm From wolfpup67 at earthlink.net Thu Dec 16 06:53:48 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Thu, 16 Dec 2010 14:53:48 -0000 Subject: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216145348.18778.42497@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review31 ----------------------------------------------------------- Ship it! any code or xml clean up is a good thing i think. - Wolfpup On 2010-12-14 12:39:34, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated 2010-12-14 12:39:34) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/1fb1c689/attachment-0001.htm From Aleric.Inglewood at gmail.com Thu Dec 16 07:34:22 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 16 Dec 2010 15:34:22 -0000 Subject: [opensource-dev] Review Request: scripts/install.py --uninstall does not always remove symbolic links. Message-ID: <20101216153422.18703.61217@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/29/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Packages (tar balls) installed with scripts/install.py do contain symbolic links. Everything that they contain is written to the file installed.xml, and upon uninstall attempted to remove. However, the python script first tests if a file exists before it removes it and uses os.path.exists for this, which only returns true when the target is a file, or a symbolic link *pointing* to an existing file. Since the removal of the tar ball elements is arbitrary, it is possible (and often the case) that the file the symbolic link points to is removed before the symbolic link itself is removed, causing the test to fail and the symbolic link not to be removed. This patch solves this bug by using os.path.lexists which returns true for normal files when they exist, and true for symbolic links if they exist, whether or not the file they point to exists, exactly what we want. os.path.lexists was added to python 2.4, so that should not be problem. This addresses bug SNOW-744. http://jira.secondlife.com/browse/SNOW-744 Diffs ----- scripts/install.py b0689af42a71 Diff: http://codereview.secondlife.com/r/29/diff Testing ------- This patch was originally tested to work several months ago, and has been in use by the Imprudence TPV for a while now. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/bee8ab61/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 16 07:58:25 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 16 Dec 2010 15:58:25 -0000 Subject: [opensource-dev] Review Request: scripts/install.py --uninstall does not always remove symbolic links. In-Reply-To: <20101216153422.18703.61217@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216153422.18703.61217@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216155825.18705.5883@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/29/#review33 ----------------------------------------------------------- Ship it! Your explanation is consistent with python's documentation and the change looks simple and sane. The change won't have any effect on platforms that don't have os.lstat(), but those seem to be the ones that don't have symlinks in the first place. - Boroondas On 2010-12-16 07:34:22, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/29/ > ----------------------------------------------------------- > > (Updated 2010-12-16 07:34:22) > > > Review request for Viewer. > > > Summary > ------- > > Packages (tar balls) installed with scripts/install.py do contain symbolic links. > Everything that they contain is written to the file installed.xml, and upon > uninstall attempted to remove. > > However, the python script first tests if a file exists before it removes it > and uses os.path.exists for this, which only returns true when the target > is a file, or a symbolic link *pointing* to an existing file. > > Since the removal of the tar ball elements is arbitrary, it is possible (and > often the case) that the file the symbolic link points to is removed before > the symbolic link itself is removed, causing the test to fail and the symbolic > link not to be removed. > > This patch solves this bug by using os.path.lexists which returns true for > normal files when they exist, and true for symbolic links if they exist, > whether or not the file they point to exists, exactly what we want. > > os.path.lexists was added to python 2.4, so that should not be problem. > > > This addresses bug SNOW-744. > http://jira.secondlife.com/browse/SNOW-744 > > > Diffs > ----- > > scripts/install.py b0689af42a71 > > Diff: http://codereview.secondlife.com/r/29/diff > > > Testing > ------- > > This patch was originally tested to work several months ago, and has been in > use by the Imprudence TPV for a while now. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/06d53a0d/attachment.htm From Aleric.Inglewood at gmail.com Thu Dec 16 08:04:13 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 16 Dec 2010 16:04:13 -0000 Subject: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216160413.18774.96246@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review32 ----------------------------------------------------------- ..testing the review system (hi mom!).. indra/newview/app_settings/settings.xml Considering the setting name (CacheLocationTopFolder), isn't the deleted Comment string better than the one you left in? Thus, Controls the top folder location of the the local disk cache, rather than Controls the location of the local disk cache. Diff is ok with me, I just wondered if you saw that it wasn't an exact duplicate. indra/newview/app_settings/settings.xml This deletes the entry with 60 seconds between printing the FPS and leaves the one that has 10 seconds between printing. Which is the correct one? indra/newview/app_settings/settings.xml This really looks wrong. The first OutBandwidth has Comment that has nothing to do with OutBandwidth and a Type Boolean. The one that was left in seem to be the real OutBandwidth looking at the Comment, and has Type F32. My guess is that the deleted entry should not have been deleted, but that the key of this entry is wrong, and that the correct way to fix this is to change the key into whatever it was intended to be. - Aleric On 2010-12-14 12:39:34, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated 2010-12-14 12:39:34) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/b8d35c8b/attachment.htm From merov at lindenlab.com Thu Dec 16 08:29:40 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 16 Dec 2010 16:29:40 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> References: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216162940.18704.89355@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review35 ----------------------------------------------------------- Putting the "oi++" in the same line as the affectation is unclear. Please put that on the next line and write a comment as to why this increment must happen as soon as the affectation to cur_oi is done (the whole point of the patch). I'm afraid that someone reviewing casually the code would "simplify" this by putting the increment back in the "for" statement. - Merov On 2010-12-15 11:27:50, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > ----------------------------------------------------------- > > (Updated 2010-12-15 11:27:50) > > > Review request for Viewer. > > > Summary > ------- > > erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > ----- > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/ac12754d/attachment-0001.htm From q at lindenlab.com Thu Dec 16 08:31:53 2010 From: q at lindenlab.com (Kent Quirk) Date: Thu, 16 Dec 2010 16:31:53 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> References: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216163153.18724.51675@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review36 ----------------------------------------------------------- Ship it! Wow, nice catch. I was looking for this bug earlier and didn't dream that a function like processParcelInfo would attempt to erase an entity. - Kent On 2010-12-15 11:27:50, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > ----------------------------------------------------------- > > (Updated 2010-12-15 11:27:50) > > > Review request for Viewer. > > > Summary > ------- > > erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > ----- > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/b56645a0/attachment.htm From malachi at tamzap.com Thu Dec 16 08:43:03 2010 From: malachi at tamzap.com (Malachi Prophit) Date: Thu, 16 Dec 2010 11:43:03 -0500 Subject: [opensource-dev] [TOS]Question about TOS Message-ID: We all had to accept a new TOS stating that the teen grid and the main grid were now one grid. However after having my son log into his teen grid account we found that he is not on the main grid, instead he is trapped on the teen grid. He has no access to the main grid and we have no access to him. Not even the ability to see his profile or he see ours. My question is this, If we had to accept a new TOS that integrated the merger of the two grids and the two grids WERE NOT merged, what hidden take our souls clause has LL added to the TOS, and shoved down our throats this time? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ From techiedavid at gmail.com Thu Dec 16 08:50:34 2010 From: techiedavid at gmail.com (David Simmons) Date: Thu, 16 Dec 2010 08:50:34 -0800 Subject: [opensource-dev] [TOS]Question about TOS In-Reply-To: References: Message-ID: The actual merger is not until January 2011. On Thu, Dec 16, 2010 at 8:43 AM, Malachi Prophit wrote: > We all had to accept a new TOS stating that the teen grid and the main > grid were now one grid. However after having my son log into his teen grid > account we found that he is not on the main grid, instead he is trapped on > the teen grid. He has no access to the main grid and we have no access to > him. Not even the ability to see his profile or he see ours. > > My question is this, If we had to accept a new TOS that integrated the > merger of the two grids and the two grids WERE NOT merged, what hidden > take our souls clause has LL added to the TOS, and shoved down our throats > this time? > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > _______________________________________________ > 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 > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From Aleric.Inglewood at gmail.com Thu Dec 16 09:11:38 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 16 Dec 2010 17:11:38 -0000 Subject: [opensource-dev] Review Request: STORM-524 : Refresh L$ balance In-Reply-To: <20101211002157.15582.47710@domU-12-31-38-00-90-68.compute-1.internal> References: <20101211002157.15582.47710@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216171138.18705.54477@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/6/#review37 ----------------------------------------------------------- Ship it! > 99% chance that this is correct (not counting the added line with trailing white space ;). Something that can impossibly be harmful, but what made me wonder, is that before getChild("balance") never has setVisible called in the old code, but in the new code apparently needs it (definitely looking logical from the context where it is added). But I suppose that it's irrelevant. - Aleric On 2010-12-10 16:21:57, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/6/ > ----------------------------------------------------------- > > (Updated 2010-12-10 16:21:57) > > > Review request for Viewer. > > > Summary > ------- > > Since the L$ balance can be updated by events outside the viewer entirely (purchase of L$ on web) and since we do not pool or receive notifications for this, I implemented a simple "click to refresh" event on the LLTextBox holding the L$ balance value (proposed by Q in JIRA). > I modified the tooltip to reflect this new functionality. > > > This addresses bug STORM-524. > http://jira.secondlife.com/browse/STORM-524 > > > Diffs > ----- > > indra/newview/llbuycurrencyhtml.cpp 8668b574c1f3 > indra/newview/llfloaterbuycurrency.cpp 8668b574c1f3 > indra/newview/llfloaterbuycurrencyhtml.cpp 8668b574c1f3 > indra/newview/llstatusbar.h 8668b574c1f3 > indra/newview/llstatusbar.cpp 8668b574c1f3 > indra/newview/skins/default/xui/en/panel_status_bar.xml 8668b574c1f3 > > Diff: http://codereview.secondlife.com/r/6/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/ef95916e/attachment.htm From merov at lindenlab.com Thu Dec 16 09:29:28 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 16 Dec 2010 17:29:28 -0000 Subject: [opensource-dev] Review Request: Crash in LLVivoxVoiceClient::notifyStatusObservers() In-Reply-To: <20101215194839.18775.7087@domU-12-31-38-00-90-68.compute-1.internal> References: <20101215194839.18775.7087@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216172928.18766.89615@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/25/#review38 ----------------------------------------------------------- Ship it! This looks correct to me and should fix the observed crasher. - Merov On 2010-12-15 11:48:39, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/25/ > ----------------------------------------------------------- > > (Updated 2010-12-15 11:48:39) > > > Review request for Viewer. > > > Summary > ------- > > Moved removeObserver() out of the "if(getAvatarId().notNull()) { }" block since "getAvatarId()" can return the NULL UUID (i.e. if the panel hasn't been opened), matching the addObserver() without condition in postBuild. > > > This addresses bug VWR-24209. > http://jira.secondlife.com/browse/VWR-24209 > > > Diffs > ----- > > indra/newview/llpanelavatar.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/25/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/104cf2cf/attachment.htm From Aleric.Inglewood at gmail.com Thu Dec 16 09:32:54 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 16 Dec 2010 17:32:54 -0000 Subject: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter In-Reply-To: <20101214150325.18777.52120@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214150325.18777.52120@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216173254.18777.6113@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/#review39 ----------------------------------------------------------- I suppose that there is a problem with the API, as that seems to dictate that the correct way to fix this is to first call setFocusOnAvatar(FALSE, FALSE) to unlock(?) or at least to stop the second call from calling setFocusGlobal, then to call setFocusGlobal and finally calling startCameraAnimation() to start the animation. Or maybe the last call isn't even needed since LLAgentCamera::setFocusGlobal also calls it. I'm not sure, but it would be my guess that calling setFocusOnAvatar(FALSE, FALSE) (in the same place as you do now, before calling setFocusGlobal) is the more correct solution: you don't want to start an animation at this point, you just want to stop focussing on the avatar. Can you try if that works too (Change the last TRUE into a FALSE)? - Aleric On 2010-12-14 07:03:25, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/16/ > ----------------------------------------------------------- > > (Updated 2010-12-14 07:03:25) > > > Review request for Viewer. > > > Summary > ------- > > You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. > > > This addresses bug vwr-20962. > http://jira.secondlife.com/browse/vwr-20962 > > > Diffs > ----- > > indra/newview/llagentcamera.cpp 3d2e71443c58 > > Diff: http://codereview.secondlife.com/r/16/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/0b661caa/attachment-0001.htm From merov at lindenlab.com Thu Dec 16 10:13:29 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 16 Dec 2010 18:13:29 -0000 Subject: [opensource-dev] Review Request: Dragging the "Contents" folder from object inventory to agent inventory shows the "prohibited" cursor In-Reply-To: <20101216110428.18707.87130@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216110428.18707.87130@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216181329.18768.5609@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/26/#review41 ----------------------------------------------------------- Ship it! I think this is correct though I haven't tried the code. Good use of move_inv_category_world_to_agent() that does all the right perm checking. - Merov On 2010-12-16 03:04:28, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/26/ > ----------------------------------------------------------- > > (Updated 2010-12-16 03:04:28) > > > Review request for Viewer. > > > Summary > ------- > > The "Contents" folder is an LLInventoryObject instance, and failed the dynamic cast to LLInventoryItem. > > The permission logic didn't apply since it's a category (which has no permissions) and was changed to use the same function that will do the actual copying so that drop behaviour should always match the "can drop" result. > > > This addresses bug VWR-24217. > http://jira.secondlife.com/browse/VWR-24217 > > > Diffs > ----- > > indra/newview/llpanelobjectinventory.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/26/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/462b0693/attachment.htm From jhwelch at gmail.com Thu Dec 16 10:18:53 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 16 Dec 2010 18:18:53 -0000 Subject: [opensource-dev] Review Request: Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216181853.18704.1356@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/#review40 ----------------------------------------------------------- indra/newview/app_settings/settings.xml I agree with your observation that the first (and deleted) record has a better Comment string. But without looking at the code I do not want to go making changes to the wording--my goal was just to eliminate obvious duplicates. indra/newview/app_settings/settings.xml The viewer uses the last record of a repeated group, so it in this case it is using 10.0 (just to be sure I started the viewer and looked). indra/newview/app_settings/settings.xml If I had to make a guess I would say that the 2nd entry for Outbandwidth was the original and that someone copied it up 1 level and put in a comment "Expand render stats display" but forgot to change the associated key. One could argue that having a F32 is wrong and that it should be an unsigned integer, depending on what units are being used (i.e. a limit of 3.25 makes sense if you are using kb/sec). - Jonathan On 2010-12-14 12:39:34, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/18/ > ----------------------------------------------------------- > > (Updated 2010-12-14 12:39:34) > > > Review request for Viewer. > > > Summary > ------- > > I wrote two programs that use settings.xml to produce this massive table: > http://wiki.secondlife.com/wiki/Debug_Settings > > While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. > > Having these cleaned out would make running my program, and thus updating the wiki table, easier. > > I've erased all but the last entry for these redundant debug settings. > > > This addresses bug vwr-24100. > http://jira.secondlife.com/browse/vwr-24100 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 46a990f8296f > > Diff: http://codereview.secondlife.com/r/18/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/8df83639/attachment.htm From trilobyte550m at gmail.com Thu Dec 16 10:35:51 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Thu, 16 Dec 2010 10:35:51 -0800 Subject: [opensource-dev] [TOS]Question about TOS In-Reply-To: References: Message-ID: <1E6418E3-98A3-4F5E-9D5B-3499E47CBD7C@gmail.com> As the header of the TOS indicated, the changes were in preparation for the coming changes. As per the published info (which was linked in the terms), that isn't due to happen until January. If you're concerned about a company or organization sneaking in clauses or rules that you wouldn't agree with, you should probably read the document more carefully before checking the box to indicate that you accept the terms. On Dec 16, 2010, at 8:43 AM, Malachi Prophit wrote: > We all had to accept a new TOS stating that the teen grid and the main > grid were now one grid. However after having my son log into his teen grid > account we found that he is not on the main grid, instead he is trapped on > the teen grid. He has no access to the main grid and we have no access to > him. Not even the ability to see his profile or he see ours. > > My question is this, If we had to accept a new TOS that integrated the > merger of the two grids and the two grids WERE NOT merged, what hidden > take our souls clause has LL added to the TOS, and shoved down our throats > this time? > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > _______________________________________________ > 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 From sldev at catznip.com Thu Dec 16 11:06:45 2010 From: sldev at catznip.com (Kitty Barnett) Date: Thu, 16 Dec 2010 19:06:45 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> References: <20101215192750.18709.45455@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216190645.18704.95220@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/ ----------------------------------------------------------- (Updated 2010-12-16 11:06:44.936367) Review request for Viewer. Changes ------- Added comments. I'm wondering if there is still a reason for the deadlist_t related code now? If that was "inlined" into the loop it would become: while (oi != end) { // increment the loop iterator now since it may become invalid below observer_multimap_t::iterator cur_oi = oi++; LLRemoteParcelInfoObserver * observer = cur_oi->second.get(); if(observer) { // may invalidate cur_oi if the observer removes itself observer->processParcelInfo(parcel_data); } else { // the handle points to an expired observer, so don't keep it // around anymore (invalidates cur_oi) observers.erase(cur_oi); } } That might decrease the chance of the fix being reverted since even if the comment on "processParcelInfo" is missed, then "observers.erase()" would still make the need for two iterators ("oi" and "cur_oi") clear? Summary ------- erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. This addresses bug VWR-24207. http://jira.secondlife.com/browse/VWR-24207 Diffs (updated) ----- indra/newview/llremoteparcelrequest.cpp UNKNOWN Diff: http://codereview.secondlife.com/r/24/diff Testing ------- Thanks, Kitty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/948e66f9/attachment-0001.htm From sldev at catznip.com Thu Dec 16 11:11:33 2010 From: sldev at catznip.com (Kitty Barnett) Date: Thu, 16 Dec 2010 19:11:33 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101216190645.18704.95220@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216190645.18704.95220@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216191133.18736.61116@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review42 ----------------------------------------------------------- *confuzzled* Does it want an incremental change starting at the previous diff? Or a diff that includes the original diff (starting from viewer-dev)? - Kitty On 2010-12-16 11:06:44, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > ----------------------------------------------------------- > > (Updated 2010-12-16 11:06:44) > > > Review request for Viewer. > > > Summary > ------- > > erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > ----- > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/b98909c1/attachment.htm From brad at lindenlab.com Thu Dec 16 11:53:26 2010 From: brad at lindenlab.com (Brad Kittenbrink) Date: Thu, 16 Dec 2010 19:53:26 -0000 Subject: [opensource-dev] Review Request: scripts/install.py --uninstall does not always remove symbolic links. In-Reply-To: <20101216153422.18703.61217@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216153422.18703.61217@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216195326.18778.82755@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/29/#review43 ----------------------------------------------------------- Ship it! Looks like a safe and sensible change to me. - Brad On 2010-12-16 07:34:22, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/29/ > ----------------------------------------------------------- > > (Updated 2010-12-16 07:34:22) > > > Review request for Viewer. > > > Summary > ------- > > Packages (tar balls) installed with scripts/install.py do contain symbolic links. > Everything that they contain is written to the file installed.xml, and upon > uninstall attempted to remove. > > However, the python script first tests if a file exists before it removes it > and uses os.path.exists for this, which only returns true when the target > is a file, or a symbolic link *pointing* to an existing file. > > Since the removal of the tar ball elements is arbitrary, it is possible (and > often the case) that the file the symbolic link points to is removed before > the symbolic link itself is removed, causing the test to fail and the symbolic > link not to be removed. > > This patch solves this bug by using os.path.lexists which returns true for > normal files when they exist, and true for symbolic links if they exist, > whether or not the file they point to exists, exactly what we want. > > os.path.lexists was added to python 2.4, so that should not be problem. > > > This addresses bug SNOW-744. > http://jira.secondlife.com/browse/SNOW-744 > > > Diffs > ----- > > scripts/install.py b0689af42a71 > > Diff: http://codereview.secondlife.com/r/29/diff > > > Testing > ------- > > This patch was originally tested to work several months ago, and has been in > use by the Imprudence TPV for a while now. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/d52de48d/attachment.htm From slitovchuk at productengine.com Thu Dec 16 14:06:32 2010 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 16 Dec 2010 22:06:32 -0000 Subject: [opensource-dev] Review Request: STORM-316 Add missing "sort by name" and "sort by recent" options for folders In-Reply-To: <20101216113351.18778.57078@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216113351.18778.57078@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216220632.18768.13189@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/27/#review44 ----------------------------------------------------------- For me 'Sort Folders by Most Recent' works only when 'Sort Items by Most Recent' is checked. Though I can't figure out what's wrong with this patch. - Seth On 2010-12-16 03:33:51, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/27/ > ----------------------------------------------------------- > > (Updated 2010-12-16 03:33:51) > > > Review request for Viewer. > > > Summary > ------- > > Changes the UI (and needs additional translation), but it's a viewer 1 option that was missed by STORM-316. > > Existing "Sort by (Name|Most Recent)" => "Sort Items by (Name|Most Recent)" > > Split "Folders always by name" in two options to match what was done for inventory items and added "Sort Folders by (Name|Most Recent)" menu options. > > > This addresses bug STORM-316. > http://jira.secondlife.com/browse/STORM-316 > > > Diffs > ----- > > indra/newview/llpanelmaininventory.cpp UNKNOWN > indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml UNKNOWN > > Diff: http://codereview.secondlife.com/r/27/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/4db37e86/attachment.htm From techiedavid at gmail.com Thu Dec 16 14:36:09 2010 From: techiedavid at gmail.com (David Simmons) Date: Thu, 16 Dec 2010 14:36:09 -0800 Subject: [opensource-dev] Fwd: [sldev] Anyone here with OpenCV experience? In-Reply-To: References: <4A15AEBC.7070800@lindenlab.com> Message-ID: With all the work done on the MS Kinect it seems like a good time to revisit this issue. On Thu, May 21, 2009 at 12:42 PM, Philip Rosedale wrote: > Has anyone here worked with camera-based gesture recognition before? > How about OpenCV? ?Is OpenCV the best package for extracting basic head > position/gesture information from a camera image stream? ?Merov and I > are pondering a Snowglobe project to detect head motion from simple > cameras and connect it to the SL Viewer. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid -- ?The greatest danger in modern technology isn't that machines will begin to think like people, but that people will begin to think like machines? Unknown http://www.google.com/profiles/techiedavid From lee.ponzu at gmail.com Thu Dec 16 15:01:46 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Thu, 16 Dec 2010 18:01:46 -0500 Subject: [opensource-dev] Can anyone tell me how to get rid of these lol... In-Reply-To: References: Message-ID: I am not a windows guy...but I would look for an option for the linker that suppresses errors. Then maybe set that in your environment, or figure out how to add it to the CMake files. ponzu On Tue, Dec 14, 2010 at 10:23 PM, Malachi Prophit wrote: > i get hundreds of these stupid errors. And i have since i compiled the > first client back on 1.18. They are harmless but very annoying. > > they always look like this..... > Warning 3 warning LNK4099: PDB 'apr-1_ib_1.pdb' was not found with > '..\..\..\..\libraries\i686-win32\lib\release\apr-1.lib' or at > 'C:\Documents and > > Settings\Owner\Desktop\linden\indra\build-VC90\media_plugins\quicktime\Release\apr-1_ib_1.pdb'; > linking object as if no debug info apr-1.lib > > I have no clue what they are or where to start ... thanks in advance. > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/ef7047e5/attachment.htm From sldev at catznip.com Thu Dec 16 15:11:48 2010 From: sldev at catznip.com (Kitty Barnett) Date: Thu, 16 Dec 2010 23:11:48 -0000 Subject: [opensource-dev] Review Request: STORM-316 Add missing "sort by name" and "sort by recent" options for folders In-Reply-To: <20101216220632.18768.13189@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216220632.18768.13189@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101216231148.18724.20743@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-16 14:06:33, Seth ProductEngine wrote: > > For me 'Sort Folders by Most Recent' works only when 'Sort Items by Most Recent' is checked. Though I can't figure out what's wrong with this patch. I'm seeing it too... I *think* (part of) the cause may be in LLFolderViewFolder::sortBy(U32 order): if (order & LLInventoryFilter::SO_DATE) { time_t latest = 0; if (!mItems.empty()) { LLFolderViewItem* item = *(mItems.begin()); latest = item->getCreationDate(); } if (!mFolders.empty()) { LLFolderViewFolder* folder = *(mFolders.begin()); if (folder->getCreationDate() > latest) { latest = folder->getCreationDate(); } } mSubtreeCreationDate = latest; } It looks like in the case of a folder the creation date is always mSubtreeCreationDate and if the items aren't sorted by date, then mSubtreeCreationDate will never set for the folder. I'll peek at it some more over the weekend, thankies for the feedback, Seth :). - Kitty ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/27/#review44 ----------------------------------------------------------- On 2010-12-16 03:33:51, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/27/ > ----------------------------------------------------------- > > (Updated 2010-12-16 03:33:51) > > > Review request for Viewer. > > > Summary > ------- > > Changes the UI (and needs additional translation), but it's a viewer 1 option that was missed by STORM-316. > > Existing "Sort by (Name|Most Recent)" => "Sort Items by (Name|Most Recent)" > > Split "Folders always by name" in two options to match what was done for inventory items and added "Sort Folders by (Name|Most Recent)" menu options. > > > This addresses bug STORM-316. > http://jira.secondlife.com/browse/STORM-316 > > > Diffs > ----- > > indra/newview/llpanelmaininventory.cpp UNKNOWN > indra/newview/skins/default/xui/en/menu_inventory_gear_default.xml UNKNOWN > > Diff: http://codereview.secondlife.com/r/27/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/2e6fd488/attachment.htm From akanevsky at productengine.com Thu Dec 16 15:22:42 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 16 Dec 2010 17:22:42 -0600 Subject: [opensource-dev] Daily Scrum Summary - Thursday, December 16 Message-ID: Thursday, December 16, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-453 : libcurl 7.21: Finished cleaning up the Mac and Linux builds. Built on TC for all platforms. W00t! Requested tests on opensource-dev before moving this to review. - STORM-151: kdu compression: Clean up code. Posted new diff to RB. Waiting for reviews (pretty please...). *FUTURE* - STORM-745 : Produce comprehensive perf baseline - STORM-744 : Add unit tests to llkdu *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Office Hour - Responded to code review posts - Merge Monkey - merged some fixes - Fixed some internal wiki documentation *FUTURE* - libcurl test - Merge Monkey - Autobbuild audits so we can publish it as open source - Pull crash fixes from Kitty *IMPEDIMENTS* - none Q Linden ------------------------------ - OOO - medical Esbee Linden ------------------------------ *PAST* - Meetings - Catch up on emails - Snowstorm team meeting - Review integration queue - Prep for Viewer 2.4 release *FUTURE* - Lots of meetings - Release Viewer 2.4 - Post Viewer 2.4 release blog post - Review integration queue list and made sure "target viewer version" is updated for merge monkey - Upload sketches of saved layouts - VWRs to check on - VWR-21493 - STORM-525 - STORM-529. It was re-resolved as no repro. - STORM-702. Caused issues based on fix. Let's chat more with PE about this. - Review VWR-16569 - Will review. Jonathan wants this one. - Review Jonathan's work list - Send STORM-398 to Taka for Communications tools input - See comments on STORM-713 *IMPEDIMENTS* - Time Paul ProductEngine ------------------------------ - OOO - sick Seth Productengine ------------------------------ *PAST* - Story (STORM-771) As someone working with outfits, copy/paste in Current Outfit Folder should paste links (which are supported) rather than objects (which are not) - Pushed fix after review. - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - WIP. Found a problem with converting wildcard patterns into regexps. *FUTURE* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations *IMPEDIMENTS* - Story (STORM-28) As a User, I want the ability to send my calling card to others. - Waiting for more details. Andrew Productengine ------------------------------ *PAST* - Normal task STORM-2 (UI layout saving) - WIP. Implemented plain version of saving and started implementing loading. While implementing loading found problems in saving. In process of changing it. - Critical bug STORM-525 (Runtime Error message from the Microsoft Visual C++ Runtime Library eventually leads to Crash) - - Tried to reproduce on different locations where Mairead Fitzgerald but had no luck- teleported, waited and moved for some time, but didn't experience any cracks or even memory leaks. Maybe testers could try to find some stable steps to reproduce this issue and than it would be assigned back to me? - Critical bug STORM-786 (Back button, Username and Display Name are missing in Resident profile tab) - Helped Vadim at pre-review stage of the ticket. *FUTURE* - STORM-2. Hope to finish implementation of save and load tomorrow. - Estimate - 2-2,5 days. *IMPEDIMENTS* - STORM-777 (Design the file format for layout information and discuss it). - No reply from Q to letter regarding this issue. Vadim Productengine ------------------------------ *PAST* - Showstopper bug STORM-786 (Back button, Username and Display Name are missing in Resident profile tab): - Fixed. - Bug STORM-410 (Region and parcel SLApps are displayed in non-human readable format): - WIP 70%. *FUTURE* - Complete the fix for STORM-410. - Bug STORM-446 (CLicking on /app/classified SLapp does not open the classified details). - Bug STORM-511 (User is not able to view full name of group in title of group notification). *IMPEDIMENTS* - Need Esbee's answer in STORM-529 (Undo feature missing from BUILD menu). - Need feedback from Nyx/Esbee in STORM-702 (Make it possible to wear partial outfits). Questions: - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - exploratory testing of 2.4.0 interim release build r216842 - ToS testing (failed by the minor issue STORM-789) - tested fix for STORM-786 on a private build *FUTURE* - pickup final 2.4.0 release build and re-run smoke & integrity tests *IMPEDIMENTS* - None Wolfpup Lowenhar ------------------------------ *PAST* - Worked in world and RL. - STORM-776 : STORM-288 : waiting for intergration. - Vadim @ PE aproved on both RB and in JIRA. *FUTURE* - Work in world and RL. - May see if mesh will build locally for me as it is still borked in OS enviornment(wonders if Merov's redo of the windows 7.21.1 curl libs might work to fix build, would need a copy of tar to unpack in local repository ). *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand(it is slowly healing but will take time since it is the tip of middle finger.) - Trying to Figure out what to work on and still waiting on answer for STORM-236. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101216/9bbd030c/attachment-0001.htm From trilobyte550m at gmail.com Thu Dec 16 16:09:46 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Thu, 16 Dec 2010 16:09:46 -0800 Subject: [opensource-dev] [HELP] How can I find/copy GPU settings? Message-ID: I'm having some difficulty with the Second Life Viewer and my shiny new GPU (nVidia Quadro 4000). The Mac client doesn't recognize it, and gives me an error when I launch the Viewer app. What's worse, dynamic shadows and deferred rendering are completely broken (I get the same complete system crash that ATI users get). However, the Windows client does not appear to have a problem recognizing the card. I get no error, and I have no problem with the deferred renderer or with any of the shadow settings. I've checked against release Viewers, Snowstorm snapshots, and the Mesh Project snapshots all with the same result. Mac clients can't ID or support the card, Windows clients can. Is there someplace I can go looking around within the Windows client (and support files) to try and find what's needed to detect my GPU so I can rig up Mac support? I'd appreciate any help/ideas Cheers TriloByte Zanzibar From Aleric.Inglewood at gmail.com Thu Dec 16 16:11:12 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 17 Dec 2010 00:11:12 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101216191133.18736.61116@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216191133.18736.61116@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101217001112.18781.71036@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-16 11:11:33, Kitty Barnett wrote: > > *confuzzled* Does it want an incremental change starting at the previous diff? Or a diff that includes the original diff (starting from viewer-dev)? When I click on the link 'Diff r2', I don't get a diff - I get an error message that 2 our of 5 hunks failed to apply. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review42 ----------------------------------------------------------- On 2010-12-16 11:06:44, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > ----------------------------------------------------------- > > (Updated 2010-12-16 11:06:44) > > > Review request for Viewer. > > > Summary > ------- > > erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > ----- > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101217/55c52c59/attachment.htm From aleric.inglewood at gmail.com Thu Dec 16 17:48:07 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Fri, 17 Dec 2010 02:48:07 +0100 Subject: [opensource-dev] [HELP] How can I find/copy GPU settings? In-Reply-To: References: Message-ID: In indra/newview/llfeaturemanager.cpp LLFeatureManager::loadGPUClass reads the file GPU_TABLE_FILENAME and LLFeatureManager::parseGPUTable matches the string 'renderer' with it. You could start with printing 'renderer' and see if it's the same on windows and Mac and if not find out why not. If on Mac it makes sense nevertheless, you'd have to find out why gGLManager.getRawGLString() isn't returning the right thing. As a work around you could hardcode the correct string into your viewer. On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte wrote: > I'm having some difficulty with the Second Life Viewer and my shiny > new GPU (nVidia Quadro 4000). ?The Mac client doesn't recognize it, > and gives me an error when I launch the Viewer app. > > What's worse, dynamic shadows and deferred rendering are completely > broken (I get the same complete system crash that ATI users get). > > However, the Windows client does not appear to have a problem > recognizing the card. ?I get no error, and I have no problem with the > deferred renderer or with any of the shadow settings. > > I've checked against release Viewers, Snowstorm snapshots, and the > Mesh Project snapshots all with the same result. ?Mac clients can't ID > or support the card, Windows clients can. > > Is there someplace I can go looking around within the Windows > client (and support files) to try and find what's needed to detect my > GPU so I can rig up Mac support? > > I'd appreciate any help/ideas > > Cheers > > TriloByte Zanzibar > _______________________________________________ > 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 > From aleric.inglewood at gmail.com Thu Dec 16 17:51:15 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Fri, 17 Dec 2010 02:51:15 +0100 Subject: [opensource-dev] [HELP] How can I find/copy GPU settings? In-Reply-To: References: Message-ID: On Fri, Dec 17, 2010 at 2:48 AM, Aleric Inglewood wrote: > In indra/newview/llfeaturemanager.cpp ?LLFeatureManager::loadGPUClass > reads the file GPU_TABLE_FILENAME > and LLFeatureManager::parseGPUTable matches > the string 'renderer' with it. > You could start with printing 'renderer' > and see if it's the same on windows > and Mac and if not find out why not. > If on Mac it makes sense nevertheless, > you'd have to find out why gGLManager.getRawGLString() > isn't returning the right thing. As a work around I meant.. if it makes sense, you could add a line to gpu_table.txt Also, if this fails you should get a warning in the debug output that prints renderer: LL_WARNS("RenderInit") << "Couldn't match GPU to a class: " << gGLManager.getRawGLString() << LL_ENDL; > you could hardcode the correct string into your viewer. > > On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte wrote: >> I'm having some difficulty with the Second Life Viewer and my shiny >> new GPU (nVidia Quadro 4000). ?The Mac client doesn't recognize it, >> and gives me an error when I launch the Viewer app. >> >> What's worse, dynamic shadows and deferred rendering are completely >> broken (I get the same complete system crash that ATI users get). >> >> However, the Windows client does not appear to have a problem >> recognizing the card. ?I get no error, and I have no problem with the >> deferred renderer or with any of the shadow settings. >> >> I've checked against release Viewers, Snowstorm snapshots, and the >> Mesh Project snapshots all with the same result. ?Mac clients can't ID >> or support the card, Windows clients can. >> >> Is there someplace I can go looking around within the Windows >> client (and support files) to try and find what's needed to detect my >> GPU so I can rig up Mac support? >> >> I'd appreciate any help/ideas >> >> Cheers >> >> TriloByte Zanzibar >> _______________________________________________ >> 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 >> > From sldev at catznip.com Fri Dec 17 01:38:19 2010 From: sldev at catznip.com (Kitty Barnett) Date: Fri, 17 Dec 2010 09:38:19 -0000 Subject: [opensource-dev] Review Request: Crash in LLRemoteParcelInfoProcessor::processParcelInfoReply() In-Reply-To: <20101216191133.18736.61116@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216191133.18736.61116@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101217093819.18703.11516@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-16 11:11:33, Kitty Barnett wrote: > > *confuzzled* Does it want an incremental change starting at the previous diff? Or a diff that includes the original diff (starting from viewer-dev)? > > Aleric Inglewood wrote: > When I click on the link 'Diff r2', I don't get a diff - I get an error message that 2 our of 5 hunks failed to apply. > I know :|. That's why I asked if "update diff" wants an incremental diff (changes against the original diff), or a full diff (changes against viewer-development), or something else entirely? - Kitty ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/24/#review42 ----------------------------------------------------------- On 2010-12-16 11:06:44, Kitty Barnett wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/24/ > ----------------------------------------------------------- > > (Updated 2010-12-16 11:06:44) > > > Review request for Viewer. > > > Summary > ------- > > erase() on a multimap will only invalidate iterators that point to the element being erased so pre-incrementing the loop iterator should prevent it from getting invalidated when an observer calls removeObserver() as part of its processParcelInfo() implementation. > > > This addresses bug VWR-24207. > http://jira.secondlife.com/browse/VWR-24207 > > > Diffs > ----- > > indra/newview/llremoteparcelrequest.cpp UNKNOWN > > Diff: http://codereview.secondlife.com/r/24/diff > > > Testing > ------- > > > Thanks, > > Kitty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101217/b2868250/attachment.htm From slitovchuk at productengine.com Fri Dec 17 12:46:52 2010 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Fri, 17 Dec 2010 20:46:52 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations Message-ID: <20101217204652.18774.85725@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Fixed LLDir unit test which failed for some complex wildcard combinations. Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. This addresses bug STORM-550. http://jira.secondlife.com/browse/STORM-550 Diffs ----- indra/cmake/Boost.cmake 794ad1fc71d1 indra/llvfs/CMakeLists.txt 794ad1fc71d1 indra/llvfs/lldiriterator.h PRE-CREATION indra/llvfs/lldiriterator.cpp PRE-CREATION indra/llvfs/tests/lldir_test.cpp 794ad1fc71d1 Diff: http://codereview.secondlife.com/r/32/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101217/23eef602/attachment.htm From oz at lindenlab.com Fri Dec 17 13:21:59 2010 From: oz at lindenlab.com (Oz Linden) Date: Fri, 17 Dec 2010 21:21:59 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20101217204652.18774.85725@domU-12-31-38-00-90-68.compute-1.internal> References: <20101217204652.18774.85725@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101217212159.18736.976@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review48 ----------------------------------------------------------- indra/llvfs/lldiriterator.h This documentation is pretty good; it would be better if it were done in a way that was more doxygen compatible (putting the documentation of the methods on the methods). The class should have a definition of the glob syntax and matching rules. indra/llvfs/lldiriterator.cpp The translation from glob to regex does not allow for escaped glob characters. Suppose I wanted to find a set of file names that contained a '?' character - the glob would need to escape that character as in "*\?*". I don't know if we actually care passionately about that case, but... indra/llvfs/lldiriterator.cpp This translation of the '*' glob character may be too general. Most globbing will not match a leading '.' character in the file name (so the glob "*foo" will match the files "afoo" and "bfoo", but not ".foo"). This has the nice side effect of preventing any glob from matching the '.' and '..' directory links in unix-like file systems (which the iterator user should not have to deal with). indra/llvfs/lldiriterator.cpp What happens here if braces are not matched? I believe what you'll get is an invalid regexp that will fail later. Probably better to catch it here where a reasonable diagnostic can be produced. If braces != 0 at the bottom (or if it becomes < 0 the '}' case), then the input glob expression was invalid. indra/llvfs/tests/lldir_test.cpp If we're going to support the braces matching, test cases should be added for them. - Oz On 2010-12-17 12:46:52, Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated 2010-12-17 12:46:52) > > > Review request for Viewer. > > > Summary > ------- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. > > > This addresses bug STORM-550. > http://jira.secondlife.com/browse/STORM-550 > > > Diffs > ----- > > indra/cmake/Boost.cmake 794ad1fc71d1 > indra/llvfs/CMakeLists.txt 794ad1fc71d1 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 794ad1fc71d1 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101217/4279430c/attachment-0001.htm From trilobyte550m at gmail.com Fri Dec 17 18:07:04 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Fri, 17 Dec 2010 18:07:04 -0800 Subject: [opensource-dev] [HELP] LLFeaturemanager.cpp question In-Reply-To: References: Message-ID: In the indra/newview/llfeaturemanager.cpp file, it references a featuretable text file. Is this still in use? As I peruse the featuretable_mac.txt file, it appears that no machine/gpu-specific information exists not only for the current lineup, but for any Mac made in 2 1/2 years. If it is still used, I can try to work on getting the list updated to include settings for recent gpu's. (the featuretable.txt file for PC's looks similarly outdated, but I'm not familiar enough with that platform to be of much help in updating that list). Also, I'm unclear on what the renderer listings (in lines 720-755 and other places) refers to. Are those external driver file names, or are there renderer files someplace within the viewer codebase repository that I'm not seeing? TriloByte Zanzibar On Dec 16, 2010, at 5:48 PM, Aleric Inglewood wrote: > In indra/newview/llfeaturemanager.cpp LLFeatureManager::loadGPUClass > reads the file GPU_TABLE_FILENAME > and LLFeatureManager::parseGPUTable matches > the string 'renderer' with it. > You could start with printing 'renderer' > and see if it's the same on windows > and Mac and if not find out why not. > If on Mac it makes sense nevertheless, > you'd have to find out why gGLManager.getRawGLString() > isn't returning the right thing. As a work around > you could hardcode the correct string into your viewer. > > On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte wrote: >> I'm having some difficulty with the Second Life Viewer and my shiny >> new GPU (nVidia Quadro 4000). The Mac client doesn't recognize it, >> and gives me an error when I launch the Viewer app. >> >> What's worse, dynamic shadows and deferred rendering are completely >> broken (I get the same complete system crash that ATI users get). >> >> However, the Windows client does not appear to have a problem >> recognizing the card. I get no error, and I have no problem with the >> deferred renderer or with any of the shadow settings. >> >> I've checked against release Viewers, Snowstorm snapshots, and the >> Mesh Project snapshots all with the same result. Mac clients can't ID >> or support the card, Windows clients can. >> >> Is there someplace I can go looking around within the Windows >> client (and support files) to try and find what's needed to detect my >> GPU so I can rig up Mac support? >> >> I'd appreciate any help/ideas >> >> Cheers >> >> TriloByte Zanzibar >> _______________________________________________ >> 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 >> From q at lindenlab.com Fri Dec 17 20:38:17 2010 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri, 17 Dec 2010 23:38:17 -0500 Subject: [opensource-dev] [HELP] LLFeaturemanager.cpp question In-Reply-To: References: Message-ID: <9944459B-48C6-4F21-8FD3-907B28FA8FDE@lindenlab.com> I haven't delved into this code recently, but the featuretable is now downloaded from our servers each time (so we can adjust without having to re-release the software). It does lag by one iteration, though (we've already set up the video by the time it's downloaded, so it affects the NEXT run). The online version of the table is kept pretty current. Q On Dec 17, 2010, at 9:07 PM, Trilo Byte wrote: > In the indra/newview/llfeaturemanager.cpp file, it references a featuretable text file. > > Is this still in use? As I peruse the featuretable_mac.txt file, it appears that no > machine/gpu-specific information exists not only for the current lineup, but for any > Mac made in 2 1/2 years. If it is still used, I can try to work on getting the list updated > to include settings for recent gpu's. > > (the featuretable.txt file for PC's looks similarly outdated, but I'm not familiar enough > with that platform to be of much help in updating that list). > > Also, I'm unclear on what the renderer listings (in lines 720-755 and other places) > refers to. Are those external driver file names, or are there renderer files > someplace within the viewer codebase repository that I'm not seeing? > > > TriloByte Zanzibar > > > On Dec 16, 2010, at 5:48 PM, Aleric Inglewood wrote: > >> In indra/newview/llfeaturemanager.cpp LLFeatureManager::loadGPUClass >> reads the file GPU_TABLE_FILENAME >> and LLFeatureManager::parseGPUTable matches >> the string 'renderer' with it. >> You could start with printing 'renderer' >> and see if it's the same on windows >> and Mac and if not find out why not. >> If on Mac it makes sense nevertheless, >> you'd have to find out why gGLManager.getRawGLString() >> isn't returning the right thing. As a work around >> you could hardcode the correct string into your viewer. >> >> On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte wrote: >>> I'm having some difficulty with the Second Life Viewer and my shiny >>> new GPU (nVidia Quadro 4000). The Mac client doesn't recognize it, >>> and gives me an error when I launch the Viewer app. >>> >>> What's worse, dynamic shadows and deferred rendering are completely >>> broken (I get the same complete system crash that ATI users get). >>> >>> However, the Windows client does not appear to have a problem >>> recognizing the card. I get no error, and I have no problem with the >>> deferred renderer or with any of the shadow settings. >>> >>> I've checked against release Viewers, Snowstorm snapshots, and the >>> Mesh Project snapshots all with the same result. Mac clients can't ID >>> or support the card, Windows clients can. >>> >>> Is there someplace I can go looking around within the Windows >>> client (and support files) to try and find what's needed to detect my >>> GPU so I can rig up Mac support? >>> >>> I'd appreciate any help/ideas >>> >>> Cheers >>> >>> TriloByte Zanzibar >>> _______________________________________________ >>> 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 From trilobyte550m at gmail.com Fri Dec 17 21:35:46 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Fri, 17 Dec 2010 21:35:46 -0800 Subject: [opensource-dev] [HELP] LLFeaturemanager.cpp question In-Reply-To: <9944459B-48C6-4F21-8FD3-907B28FA8FDE@lindenlab.com> References: <9944459B-48C6-4F21-8FD3-907B28FA8FDE@lindenlab.com> Message-ID: <54185FC2-5C98-4BC9-9170-79B9D0A06CA0@gmail.com> Is there a way, then, to add support for a newly released GPU (Quadro 4000) for the Mac client? If there is some specific info that's need, I'd be happy to track it down. On Dec 17, 2010, at 8:38 PM, Kent Quirk (Q Linden) wrote: > I haven't delved into this code recently, but the featuretable is now downloaded from our servers each time (so we can adjust without having to re-release the software). It does lag by one iteration, though (we've already set up the video by the time it's downloaded, so it affects the NEXT run). The online version of the table is kept pretty current. > > Q > > On Dec 17, 2010, at 9:07 PM, Trilo Byte wrote: > >> In the indra/newview/llfeaturemanager.cpp file, it references a featuretable text file. >> >> Is this still in use? As I peruse the featuretable_mac.txt file, it appears that no >> machine/gpu-specific information exists not only for the current lineup, but for any >> Mac made in 2 1/2 years. If it is still used, I can try to work on getting the list updated >> to include settings for recent gpu's. >> >> (the featuretable.txt file for PC's looks similarly outdated, but I'm not familiar enough >> with that platform to be of much help in updating that list). >> >> Also, I'm unclear on what the renderer listings (in lines 720-755 and other places) >> refers to. Are those external driver file names, or are there renderer files >> someplace within the viewer codebase repository that I'm not seeing? >> >> >> TriloByte Zanzibar >> >> >> On Dec 16, 2010, at 5:48 PM, Aleric Inglewood wrote: >> >>> In indra/newview/llfeaturemanager.cpp LLFeatureManager::loadGPUClass >>> reads the file GPU_TABLE_FILENAME >>> and LLFeatureManager::parseGPUTable matches >>> the string 'renderer' with it. >>> You could start with printing 'renderer' >>> and see if it's the same on windows >>> and Mac and if not find out why not. >>> If on Mac it makes sense nevertheless, >>> you'd have to find out why gGLManager.getRawGLString() >>> isn't returning the right thing. As a work around >>> you could hardcode the correct string into your viewer. >>> >>> On Fri, Dec 17, 2010 at 1:09 AM, Trilo Byte wrote: >>>> I'm having some difficulty with the Second Life Viewer and my shiny >>>> new GPU (nVidia Quadro 4000). The Mac client doesn't recognize it, >>>> and gives me an error when I launch the Viewer app. >>>> >>>> What's worse, dynamic shadows and deferred rendering are completely >>>> broken (I get the same complete system crash that ATI users get). >>>> >>>> However, the Windows client does not appear to have a problem >>>> recognizing the card. I get no error, and I have no problem with the >>>> deferred renderer or with any of the shadow settings. >>>> >>>> I've checked against release Viewers, Snowstorm snapshots, and the >>>> Mesh Project snapshots all with the same result. Mac clients can't ID >>>> or support the card, Windows clients can. >>>> >>>> Is there someplace I can go looking around within the Windows >>>> client (and support files) to try and find what's needed to detect my >>>> GPU so I can rig up Mac support? >>>> >>>> I'd appreciate any help/ideas >>>> >>>> Cheers >>>> >>>> TriloByte Zanzibar >>>> _______________________________________________ >>>> 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 > From twisted_laws at hotmail.com Sat Dec 18 06:20:58 2010 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sat, 18 Dec 2010 09:20:58 -0500 Subject: [opensource-dev] STORM-467 In-Reply-To: <54185FC2-5C98-4BC9-9170-79B9D0A06CA0@gmail.com> References: , , , <9944459B-48C6-4F21-8FD3-907B28FA8FDE@lindenlab.com>, <54185FC2-5C98-4BC9-9170-79B9D0A06CA0@gmail.com> Message-ID: Added a patch for STORM-467 2.x minimap zoom does not persist to the next session thats needs review and to be applied. Note that I mistakenly added this same patch to STORM-466 (too early in the morning) and I'm not sure how to remove it from there. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101218/689a98e3/attachment.htm From twisted_laws at hotmail.com Sat Dec 18 07:23:56 2010 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sat, 18 Dec 2010 10:23:56 -0500 Subject: [opensource-dev] STORM-466 Message-ID: Ok, figured out how to get rid of the bad attachment from 467 and created a patch for Storm-466 as well to add a zoom default to the minimap menu in english. from my understanding this should not break other languages, the menu option just won't appear. So if theres interest in fixing 466, theres a patch available now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101218/43158009/attachment.htm From trilobyte550m at gmail.com Sat Dec 18 07:55:55 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Sat, 18 Dec 2010 07:55:55 -0800 Subject: [opensource-dev] VWR-24172 (tab key not working) Message-ID: <775EF585-4D7B-4E2B-A7D2-3675C3CDBDE5@gmail.com> Back in build 216577, the tab key stopped working to jump between fields (in the build window, debugged settings window, etc). A couple builds later it was fixed, but then in build 217184 it stopped working again. It's still not working properly in 217291 - anybody else experiencing this? Trilo From sllists at boroon.dasgupta.ch Sat Dec 18 08:02:10 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 18 Dec 2010 17:02:10 +0100 Subject: [opensource-dev] VWR-24172 (tab key not working) In-Reply-To: <775EF585-4D7B-4E2B-A7D2-3675C3CDBDE5@gmail.com> References: <775EF585-4D7B-4E2B-A7D2-3675C3CDBDE5@gmail.com> Message-ID: <4D0CDB02.2060703@boroon.dasgupta.ch> On 12/18/2010 04:55 PM, Trilo Byte wrote: > [...] tab key stopped working to jump between fields (in the build window, debugged settings window, etc). [...] anybody else experiencing this? Yes, me. Boroondas From Aleric.Inglewood at gmail.com Sat Dec 18 09:01:35 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sat, 18 Dec 2010 17:01:35 -0000 Subject: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut Message-ID: <20101218170135.18775.20847@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/ ----------------------------------------------------------- Review request for Viewer. Summary ------- There is no #include "tut.h" anywhere. The only includes are #include "tut/tut.hpp" (which is correct). Tut installs in /include/tut/* among which the headerfile tut.hpp. The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: CMake Error at cmake/FindTut.cmake:26 (message): Could not find Tut Call Stack (most recent call first): cmake/Tut.cmake:8 (include) llmessage/CMakeLists.txt:13 (include) With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to "/usr/local/include", and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting TUT_INCLUDE_DIR to "/usr/src/secondlife/viewers/snowstorm/viewer-development/include", since I have a symbolic link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH set to "/usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include". In other words, this allows developers to install headers whereever they want and use the API of cmake as it is intended, to find those headers. This addresses bug VWR-24247. http://jira.secondlife.com/browse/VWR-24247 Diffs ----- indra/cmake/FindTut.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/39/diff Testing ------- Tested to see if it finds the header when installed in /usr/local/include as well in a path specified with CMAKE_INCLUDE_PATH. Note that you need to configure with --standalone in order to test this. Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, it still won't compile because of another bug. I will submit a patch for that separately. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101218/96d904ff/attachment-0001.htm From bunny at bunnynet.org Sat Dec 18 10:03:47 2010 From: bunny at bunnynet.org (Bunny Halberd) Date: Sat, 18 Dec 2010 12:03:47 -0600 Subject: [opensource-dev] Memory Leak in Recent Builds (STORM-336?) Message-ID: Hey Everyone - The recent builds of 2.5 have been leaking memory so bad on my machine that it renders the viewer unusable after an hour or so. I'll start the session at 600MB of RAM, and it'll balloon up to over 1GB before the viewer gets so slow that I have to relog. (Framerates drop over time to the point that it's impossible to type.) Since I seem to be able to reproduce this at will, is there anything I can do to help track this down? I found an open JIRA that seemed to be along those lines so I added as much information there as I could: https://jira.secondlife.com/browse/STORM-336 I try hard to stay current with the builds so I can report issues as I find them, but this one is so severe that it's sent me scrambling back to the release client so I'm actually able to enjoy my time in world. Thanks! - Bunny From angel_of_crimson at hotmail.com Sat Dec 18 18:08:26 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Sat, 18 Dec 2010 21:08:26 -0500 Subject: [opensource-dev] Memory Leak in Recent Builds (STORM-336?) In-Reply-To: References: Message-ID: Im seeing the same thing. my memory actually topped out at 2 gig ram and 2 gig more virtual before it crashed taking my system with it. I can repo consistently on windows seven and on windows vista.. will try to repo on xp as well.. > From: bunny at bunnynet.org > Date: Sat, 18 Dec 2010 12:03:47 -0600 > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Memory Leak in Recent Builds (STORM-336?) > > Hey Everyone - > > The recent builds of 2.5 have been leaking memory so bad on my machine > that it renders the viewer unusable after an hour or so. I'll start > the session at 600MB of RAM, and it'll balloon up to over 1GB before > the viewer gets so slow that I have to relog. (Framerates drop over > time to the point that it's impossible to type.) > > Since I seem to be able to reproduce this at will, is there anything I > can do to help track this down? > > I found an open JIRA that seemed to be along those lines so I added as > much information there as I could: > > https://jira.secondlife.com/browse/STORM-336 > > I try hard to stay current with the builds so I can report issues as I > find them, but this one is so severe that it's sent me scrambling back > to the release client so I'm actually able to enjoy my time in world. > > Thanks! > > - Bunny > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101218/266d15d4/attachment.htm From Lance.Corrimal at eregion.de Sun Dec 19 01:52:42 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 19 Dec 2010 10:52:42 +0100 Subject: [opensource-dev] any chance for storm-323? Message-ID: <201012191052.43269.Lance.Corrimal@eregion.de> Hi there, is there any chance that storm-323 gets some attention? I just logged in after a day, and roughly 30 subscribo messages made me first click "accept" or "decline" 30 times, and then made me click "ok" on the "you have accepted.." resp. "You have declined..." popup. Whoever first thought of that second popup should be forced to spend not less than 10000L$ for stuff that doesn't cost more than 1L$. If nothing else, I'd be happy with a few pointers on where to look, and I'll do it myself. From sllists at boroon.dasgupta.ch Sun Dec 19 04:03:39 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 19 Dec 2010 12:03:39 -0000 Subject: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut In-Reply-To: <20101218170135.18775.20847@domU-12-31-38-00-90-68.compute-1.internal> References: <20101218170135.18775.20847@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219120339.3435.90043@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/#review49 ----------------------------------------------------------- indra/cmake/FindTut.cmake According to the CMake 2.8.1 man page, NO_SYSTEM_ENVIRONMENT_PATH makes find_path not only skip $PATH but also $INCLUDE. I think we should respect the latter when looking for headers. - Boroondas On 2010-12-18 09:01:35, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/39/ > ----------------------------------------------------------- > > (Updated 2010-12-18 09:01:35) > > > Review request for Viewer. > > > Summary > ------- > > There is no #include "tut.h" anywhere. > The only includes are #include "tut/tut.hpp" (which is correct). > Tut installs in /include/tut/* among which the headerfile tut.hpp. > The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). > find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. > Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking > for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. > > Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: > CMake Error at cmake/FindTut.cmake:26 (message): > Could not find Tut > Call Stack (most recent call first): > cmake/Tut.cmake:8 (include) > llmessage/CMakeLists.txt:13 (include) > > With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to "/usr/local/include", > and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting > TUT_INCLUDE_DIR to "/usr/src/secondlife/viewers/snowstorm/viewer-development/include", since I have a symbolic > link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut > (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH > set to "/usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include". > In other words, this allows developers to install headers whereever they want and use the API of cmake as it is > intended, to find those headers. > > > This addresses bug VWR-24247. > http://jira.secondlife.com/browse/VWR-24247 > > > Diffs > ----- > > indra/cmake/FindTut.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/39/diff > > > Testing > ------- > > Tested to see if it finds the header when installed in /usr/local/include as well in a path specified > with CMAKE_INCLUDE_PATH. > > Note that you need to configure with --standalone in order to test this. > Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, > it still won't compile because of another bug. I will submit a patch for that separately. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/8f34eda7/attachment.htm From Aleric.Inglewood at gmail.com Sun Dec 19 05:03:14 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 19 Dec 2010 13:03:14 -0000 Subject: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut In-Reply-To: <20101219120339.3435.90043@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219120339.3435.90043@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219130314.3541.68779@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-19 04:03:39, Boroondas Gupte wrote: > > indra/cmake/FindTut.cmake, line 10 > > > > > > According to the CMake 2.8.1 man page, NO_SYSTEM_ENVIRONMENT_PATH makes find_path not only skip $PATH but also $INCLUDE. I think we should respect the latter when looking for headers. I was aware of that, but I don't think that INCLUDE is ever used on linux. Not only not for any existing project, but also gcc doesn't honor it. It can hardly be considered to be a 'standard' (useful) search path for *system* header files when the default compiler isn't even using that environment variable. My guess was that this is more of a Windows(tm) thing. And indeed, Michelle just told me that on windows the command line compiler needs %INCLUDE% to function. So, I think that cmake searches PATH and INCLUDE because of Windows(tm). For example, Windows(tm) sets INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio 8\VC\INCLUDE";"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include". However, this code is only run on linux, where INCLUDE is not used, and it might even be harmful to search in PATH for header files. Like I said before, it probably won't hurt in this case (it's unlikely that anyone has an executable installed in their PATH called 'tut/tut.hpp') but I don't consider it to be the right thing for linux. That being said - in this particular case (for tut/tut.hpp) it will work just as fine with or without, so if that is a showstopper for Oz (or whoever has to add this patch) than I'd be ok with removing NO_SYSTEM_ENVIRONMENT_PATH and gambling that nothing will be found in PATH, instead of using the patch as-is: ignoring the "windows" INCLUDE on linux just like gcc ignores it. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/#review49 ----------------------------------------------------------- On 2010-12-18 09:01:35, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/39/ > ----------------------------------------------------------- > > (Updated 2010-12-18 09:01:35) > > > Review request for Viewer. > > > Summary > ------- > > There is no #include "tut.h" anywhere. > The only includes are #include "tut/tut.hpp" (which is correct). > Tut installs in /include/tut/* among which the headerfile tut.hpp. > The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). > find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. > Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking > for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. > > Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: > CMake Error at cmake/FindTut.cmake:26 (message): > Could not find Tut > Call Stack (most recent call first): > cmake/Tut.cmake:8 (include) > llmessage/CMakeLists.txt:13 (include) > > With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to "/usr/local/include", > and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting > TUT_INCLUDE_DIR to "/usr/src/secondlife/viewers/snowstorm/viewer-development/include", since I have a symbolic > link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut > (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH > set to "/usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include". > In other words, this allows developers to install headers whereever they want and use the API of cmake as it is > intended, to find those headers. > > > This addresses bug VWR-24247. > http://jira.secondlife.com/browse/VWR-24247 > > > Diffs > ----- > > indra/cmake/FindTut.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/39/diff > > > Testing > ------- > > Tested to see if it finds the header when installed in /usr/local/include as well in a path specified > with CMAKE_INCLUDE_PATH. > > Note that you need to configure with --standalone in order to test this. > Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, > it still won't compile because of another bug. I will submit a patch for that separately. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/7e35d996/attachment-0001.htm From sllists at boroon.dasgupta.ch Sun Dec 19 05:41:54 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 19 Dec 2010 13:41:54 -0000 Subject: [opensource-dev] Review Request: VWR-24247: develop.py configure still searches for the wrong header file when checking for Tut In-Reply-To: <20101218170135.18775.20847@domU-12-31-38-00-90-68.compute-1.internal> References: <20101218170135.18775.20847@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219134154.3434.58077@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/39/#review51 ----------------------------------------------------------- Ship it! Ah, I wasn't aware gcc ignores INCLUDE. In that case, the change is good as-is. - Boroondas On 2010-12-18 09:01:35, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/39/ > ----------------------------------------------------------- > > (Updated 2010-12-18 09:01:35) > > > Review request for Viewer. > > > Summary > ------- > > There is no #include "tut.h" anywhere. > The only includes are #include "tut/tut.hpp" (which is correct). > Tut installs in /include/tut/* among which the headerfile tut.hpp. > The changed file, indra/cmake/FindTut.cmake, is only included when configured with --standalone (and thus only on linux). > find_path searches in /usr/include and /usr/local/include anyway, so there is no way to add that. > Adding the NO_SYSTEM_ENVIRONMENT_PATH stops it from reading the PATH environment variable and looking > for tut/tut.hpp, which probably won't harm, but it simply makes no sense: we're looking for a headerfile, not an executable. > > Without this patch (and without creating a fake /usr/local/include/tut.h), I get the error: > CMake Error at cmake/FindTut.cmake:26 (message): > Could not find Tut > Call Stack (most recent call first): > cmake/Tut.cmake:8 (include) > llmessage/CMakeLists.txt:13 (include) > > With the patch, it finds /usr/local/include/tut/tut.hpp as expected, setting TUT_INCLUDE_DIR to "/usr/local/include", > and it also finds (in my case) /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut/tut.hpp, setting > TUT_INCLUDE_DIR to "/usr/src/secondlife/viewers/snowstorm/viewer-development/include", since I have a symbolic > link from /usr/src/secondlife/viewers/snowstorm/viewer-development/include/tut to ../linden/libraries/include/tut > (which was installed manually with ./scripts/install.py tut) and I have the environment variable CMAKE_INCLUDE_PATH > set to "/usr/src/secondlife/llqtwebkit/install-imprudence/include:/usr/src/secondlife/viewers/snowstorm/viewer-development/include:/sl/usr/include". > In other words, this allows developers to install headers whereever they want and use the API of cmake as it is > intended, to find those headers. > > > This addresses bug VWR-24247. > http://jira.secondlife.com/browse/VWR-24247 > > > Diffs > ----- > > indra/cmake/FindTut.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/39/diff > > > Testing > ------- > > Tested to see if it finds the header when installed in /usr/local/include as well in a path specified > with CMAKE_INCLUDE_PATH. > > Note that you need to configure with --standalone in order to test this. > Also note that unless tut is installed in /usr/local, and when you configure with -DLL_TESTS:BOOL=ON, > it still won't compile because of another bug. I will submit a patch for that separately. > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/d6089c4f/attachment.htm From Aleric.Inglewood at gmail.com Sun Dec 19 07:18:51 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 19 Dec 2010 15:18:51 -0000 Subject: [opensource-dev] Review Request: VWR-24251: Fix -DLL_TESTS:BOOL=ON on standalone when Tut is installed in a non-standard directory. Message-ID: <20101219151851.3437.4152@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/44/ ----------------------------------------------------------- Review request for Viewer. Summary ------- If tut/tut.hpp isn't installed in a standard include directory all tests fail because the found include directory for tut isn't passed to the compiler. This patch fixes this by passing it. Note that using include_directories() in a Find*.cmake file is bad practise. The correct way is to set an include dir variable and call include_directories() once. It certainly doesn't work for the tests anyway because the tests are all over the place and include_directories is on a per folder basis. What is needed is to set it for each (test) target. However, there is no TARGET_INCLUDE_DIRECTORIES. The closest thing that we have is to set the COMPILE_FLAGS property for a target. Fortunately, standalone is only used for linux, so we can just use -I${TUT_INCLUDE_DIR} to get the effect we want. This addresses bug VWR-24251. http://jira.secondlife.com/browse/VWR-24251 Diffs ----- indra/cmake/LLAddBuildTest.cmake b0689af42a71 indra/cmake/Tut.cmake b0689af42a71 indra/test/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/44/diff Testing ------- Tested with standalone and tut.hpp installed in a non-standard place *after applying VWR-24247* of course. All tests compile and pass (on linux 64bit). Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/d3e0746f/attachment.htm From Aleric.Inglewood at gmail.com Sun Dec 19 07:54:19 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 19 Dec 2010 15:54:19 -0000 Subject: [opensource-dev] Review Request: VWR-10579: Fix NDOF.cmake to do the right thing on standalone. Message-ID: <20101219155419.3541.60659@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/45/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Only define -DLIB_NDOF=1 when NDOF is actually found, on standalone. While FindNDOF.cmake was added to the repository, it wasn't used. This addresses bug VWR-10579. http://jira.secondlife.com/browse/VWR-10579 Diffs ----- indra/cmake/NDOF.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/45/diff Testing ------- I can't remember when I started using this, but it was long ago. I don't have libndofdev installed. I just installed Michelle's debian package libndofdev-dev and then it found it: -- Found NDOF: Library in '/usr/lib/libndofdev.so' and header in '/usr/include' Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/8c214093/attachment.htm From Aleric.Inglewood at gmail.com Sun Dec 19 08:56:31 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 19 Dec 2010 16:56:31 -0000 Subject: [opensource-dev] Review Request: VWR-24252: Find Qt4 with find_package on STANDALONE. Message-ID: <20101219165631.3439.60782@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/46/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This patch has only effect on standalone. It searches for the Qt libs using the cmake provided FindQt4.cmake. I added an explicit test to check if QTDIR is set, it is set to the correct value (even LL got this wrong on their wiki, so it's apparently not obvious): As of Qt 4, Qt is found by calling qmake, NOT by looking at QTDIR. So, if you set QTDIR then it better be set to whatever qmake was "found" (using PATH as usual). While FindLLQtWebkit.cmake was added to the repository, it wasn't used for some reason... but it works perfectly. This patch uses it to find LLQtWebkit and then uses the resulting LLQTWEBKIT_LIBRARY and LLQTWEBKIT_INCLUDE_DIR in the right places. Finally, we also need to explicitly pass the Qt plugin libraries in order to link with them, so part of this patch adds the rules to do that (the foreach). This addresses bug VWR-24252. http://jira.secondlife.com/browse/VWR-24252 Diffs ----- indra/cmake/WebKitLibPlugin.cmake b0689af42a71 indra/llplugin/CMakeLists.txt b0689af42a71 indra/media_plugins/webkit/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/46/diff Testing ------- I used this while working on adding plugin support to Imprudence, needing to debug into the Qt libs and llqtwebkit. I added support for multiple versions of llqtwebkit to imprudence (not just the one needed, but also newer versions of llqtwebkit). Needless to say that I needed this patch to work to find my (several) installations of Qt and llqtwebkit. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/85bd018c/attachment-0001.htm From Aleric.Inglewood at gmail.com Sun Dec 19 09:19:37 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 19 Dec 2010 17:19:37 -0000 Subject: [opensource-dev] Review Request: SNOW-240: Fix libjson naming madness, for standalone. Message-ID: <20101219171937.3433.57444@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/47/ ----------------------------------------------------------- Review request for Viewer. Summary ------- On linux (and remember this is about standalone) the libjson packages of distributions don't have this complex compiler version baked into their name. This patch fixes this issue by first searching for libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so and when that fails search for the system package library file libjson.so. This addresses bug SNOW-240. http://jira.secondlife.com/browse/SNOW-240 Diffs ----- indra/cmake/FindJsonCpp.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/47/diff Testing ------- It works :p (I have Michelle's debian package libjsoncpp0 installed, which provides /usr/lib/libjson.so). Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/c36c7eaa/attachment.htm From Aleric.Inglewood at gmail.com Sun Dec 19 09:42:53 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Sun, 19 Dec 2010 17:42:53 -0000 Subject: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux. Message-ID: <20101219174253.3437.88790@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/ ----------------------------------------------------------- Review request for Viewer. Summary ------- To use ld.gold configure with: -DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold". See VWR-24254 for more details. This addresses bug VWR-24254. http://jira.secondlife.com/browse/VWR-24254 Diffs ----- indra/cmake/BerkeleyDB.cmake b0689af42a71 indra/cmake/LLCommon.cmake b0689af42a71 indra/cmake/LLPlugin.cmake b0689af42a71 indra/llwindow/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/48/diff Testing ------- ld.gold links the viewer on my machine in 8 seconds, as opposed to 19 seconds with ld.bfd. Moreover, it uses a LOT less memory during linking (about 750 MB instead of 2.5 GB! (for viewer 1)). Since my machine locked up hard when I run out of memory (something with using an encrypted RAID for my swap), and compiling viewer 2 uses more than 3 GB, I couldn't compile viewer 2 at all anymore without this patch (and using ld.gold). And OMG this is fast! Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/a709d0a6/attachment.htm From sllists at boroon.dasgupta.ch Sun Dec 19 11:07:56 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 19 Dec 2010 19:07:56 -0000 Subject: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux. In-Reply-To: <20101219174253.3437.88790@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219174253.3437.88790@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219190756.3434.31534@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/#review52 ----------------------------------------------------------- indra/cmake/LLCommon.cmake Is this removal related to ld.gold, too, or just general cleanup? - Boroondas On 2010-12-19 09:42:53, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/48/ > ----------------------------------------------------------- > > (Updated 2010-12-19 09:42:53) > > > Review request for Viewer. > > > Summary > ------- > > To use ld.gold configure with: > -DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold". > > See VWR-24254 for more details. > > > This addresses bug VWR-24254. > http://jira.secondlife.com/browse/VWR-24254 > > > Diffs > ----- > > indra/cmake/BerkeleyDB.cmake b0689af42a71 > indra/cmake/LLCommon.cmake b0689af42a71 > indra/cmake/LLPlugin.cmake b0689af42a71 > indra/llwindow/CMakeLists.txt b0689af42a71 > > Diff: http://codereview.secondlife.com/r/48/diff > > > Testing > ------- > > ld.gold links the viewer on my machine in 8 seconds, as > opposed to 19 seconds with ld.bfd. Moreover, it uses a > LOT less memory during linking (about 750 MB instead of > 2.5 GB! (for viewer 1)). > > Since my machine locked up hard when I run out of memory > (something with using an encrypted RAID for my swap), > and compiling viewer 2 uses more than 3 GB, I couldn't > compile viewer 2 at all anymore without this patch (and > using ld.gold). And OMG this is fast! > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/38001f48/attachment.htm From sllists at boroon.dasgupta.ch Sun Dec 19 12:34:25 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 19 Dec 2010 20:34:25 -0000 Subject: [opensource-dev] Review Request: VWR-10579: Fix NDOF.cmake to do the right thing on standalone. In-Reply-To: <20101219155419.3541.60659@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219155419.3541.60659@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219203425.3436.10118@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/45/#review53 ----------------------------------------------------------- I'd prefer the following behavior: Let the user specify whether to use libndofdev or not. (Of course we'd have to agree on a default if nothing was specified). Then ... ... if libndofdev use has been enabled and libndofdev can be found, --> build with libndofdev support, thus with the joystick/spacenavigator features. ... if libndofdev use has been enabled but libndofdev can not be found, --> error out. (With some meaningful message) ... if libndofdev use has been disabled, --> don't build with libndofdev support, even if libndofdev is present. Rationale: If I *want* spacenavigator or joystick support, but libndofdev cannot be found (e.g. because I forgot to install it or because it was installed to a location that isn't searched), I'll get a heads-up at build time rather than having to figure out why stuff doesn't behave the way I want at runtime. Note: This would be analogous to how we currently handle FMOD, even although disabling FMOD -- other than disabling libndofdev -- doesn't result in unavailable viewer features. - Boroondas On 2010-12-19 07:54:19, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/45/ > ----------------------------------------------------------- > > (Updated 2010-12-19 07:54:19) > > > Review request for Viewer. > > > Summary > ------- > > Only define -DLIB_NDOF=1 when NDOF is actually found, on standalone. While FindNDOF.cmake was added to the repository, it wasn't used. > > > This addresses bug VWR-10579. > http://jira.secondlife.com/browse/VWR-10579 > > > Diffs > ----- > > indra/cmake/NDOF.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/45/diff > > > Testing > ------- > > I can't remember when I started using this, but it was long ago. I don't have libndofdev installed. > I just installed Michelle's debian package libndofdev-dev and then it found it: > -- Found NDOF: Library in '/usr/lib/libndofdev.so' and header in '/usr/include' > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/836629df/attachment.htm From sllists at boroon.dasgupta.ch Sun Dec 19 12:48:34 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 19 Dec 2010 20:48:34 -0000 Subject: [opensource-dev] Review Request: SNOW-240: Fix libjson naming madness, for standalone. In-Reply-To: <20101219171937.3433.57444@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219171937.3433.57444@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219204834.3434.69838@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/47/#review54 ----------------------------------------------------------- Ship it! Looks good. Like this, it should continue working even if a system-wide installed libjson uses the compiler-version-specific filename, like the gentoo ebuild from Techwolf's portage overlay currently does. I guess all other distributions use the plain name, so once this ebuild has been updated, we can even drop looking for the compiler version specific filename in the standalone case completely. - Boroondas On 2010-12-19 09:19:37, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/47/ > ----------------------------------------------------------- > > (Updated 2010-12-19 09:19:37) > > > Review request for Viewer. > > > Summary > ------- > > On linux (and remember this is about standalone) > the libjson packages of distributions don't have this > complex compiler version baked into their name. > > This patch fixes this issue by first searching for > libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so > and when that fails search for the system package > library file libjson.so. > > > This addresses bug SNOW-240. > http://jira.secondlife.com/browse/SNOW-240 > > > Diffs > ----- > > indra/cmake/FindJsonCpp.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/47/diff > > > Testing > ------- > > It works :p (I have Michelle's debian package libjsoncpp0 installed, which provides /usr/lib/libjson.so). > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/f83474d3/attachment.htm From sllists at boroon.dasgupta.ch Sun Dec 19 12:51:19 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 19 Dec 2010 20:51:19 -0000 Subject: [opensource-dev] Review Request: SNOW-240: Fix libjson naming madness, for standalone. In-Reply-To: <20101219204834.3434.69838@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219204834.3434.69838@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101219205119.3433.97422@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-19 12:48:35, Boroondas Gupte wrote: > > Looks good. > > > > Like this, it should continue working even if a system-wide installed libjson uses the compiler-version-specific filename, like the gentoo ebuild from Techwolf's portage overlay currently does. I guess all other distributions use the plain name, so once this ebuild has been updated, we can even drop looking for the compiler version specific filename in the standalone case completely. Just wondering: Is there some reason behind the search order (libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so first, then libjson.so) or is that arbitrary? (I guess the systems where both are present are rare.) - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/47/#review54 ----------------------------------------------------------- On 2010-12-19 09:19:37, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/47/ > ----------------------------------------------------------- > > (Updated 2010-12-19 09:19:37) > > > Review request for Viewer. > > > Summary > ------- > > On linux (and remember this is about standalone) > the libjson packages of distributions don't have this > complex compiler version baked into their name. > > This patch fixes this issue by first searching for > libjson_linux-gcc-${_gcc_COMPILER_VERSION}_libmt.so > and when that fails search for the system package > library file libjson.so. > > > This addresses bug SNOW-240. > http://jira.secondlife.com/browse/SNOW-240 > > > Diffs > ----- > > indra/cmake/FindJsonCpp.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/47/diff > > > Testing > ------- > > It works :p (I have Michelle's debian package libjsoncpp0 installed, which provides /usr/lib/libjson.so). > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101219/0b253669/attachment.htm From Aleric.Inglewood at gmail.com Sun Dec 19 18:38:47 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 20 Dec 2010 02:38:47 -0000 Subject: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux. In-Reply-To: <20101219190756.3434.31534@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219190756.3434.31534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220023847.3437.90673@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-19 11:07:57, Boroondas Gupte wrote: > > indra/cmake/LLCommon.cmake, line 11 > > > > > > Is this removal related to ld.gold, too, or just general cleanup? Oops. That was supposed to be a general cleanup, inspired by the fact that llcommon isn't including apu.h (the header that is being looked for for APRUTIL_INCLUDE_DIR). But because of your question I double checked, and although /usr/include/apr-1.0 contains apr_*.h files and apu_*.h files, about half of the apr_*.h files belong to aprutil! And we DO use those (ie, apr_base64.h). I'll change the patch to not remove that tomorrow. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/#review52 ----------------------------------------------------------- On 2010-12-19 09:42:53, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/48/ > ----------------------------------------------------------- > > (Updated 2010-12-19 09:42:53) > > > Review request for Viewer. > > > Summary > ------- > > To use ld.gold configure with: > -DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold". > > See VWR-24254 for more details. > > > This addresses bug VWR-24254. > http://jira.secondlife.com/browse/VWR-24254 > > > Diffs > ----- > > indra/cmake/BerkeleyDB.cmake b0689af42a71 > indra/cmake/LLCommon.cmake b0689af42a71 > indra/cmake/LLPlugin.cmake b0689af42a71 > indra/llwindow/CMakeLists.txt b0689af42a71 > > Diff: http://codereview.secondlife.com/r/48/diff > > > Testing > ------- > > ld.gold links the viewer on my machine in 8 seconds, as > opposed to 19 seconds with ld.bfd. Moreover, it uses a > LOT less memory during linking (about 750 MB instead of > 2.5 GB! (for viewer 1)). > > Since my machine locked up hard when I run out of memory > (something with using an encrypted RAID for my swap), > and compiling viewer 2 uses more than 3 GB, I couldn't > compile viewer 2 at all anymore without this patch (and > using ld.gold). And OMG this is fast! > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/47e4968b/attachment-0001.htm From akanevsky at productengine.com Sun Dec 19 23:00:26 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 20 Dec 2010 01:00:26 -0600 Subject: [opensource-dev] Daily Scrum Summary - Friday, December 17 Message-ID: Whoops, sorry this is late! Friday, December 17, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz - Merov needs review in STORM-151! Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-745 : Produce comprehensive perf baseline: Created a set of images to compress and a huge baseline for Mac. - STORM-744 : Add unit tests to llkdu: Reactivated the broken llimage/tests/llimageworker_test.cpp unit tests and fixed it. *FUTURE* - STORM-745 : Produce comprehensive perf baseline: Complete that work for Mac. - STORM-744 : Add unit tests to llkdu: Finish fixing the llimage test and add new ones to llkdu. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - Merge Monkey - merged some fixes, created a couple of MM tools - Learning corner cases in codereview - Lindens vs Residents snowball fight - Fixing more internal documentation *FUTURE* - libcurl test - Merge Monkey - Autobbuild audits so we can publish it as open source *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Reviewed several items in CR tool and other JIRAs and commented on one, but merov beat me to most of them - Reviewed wiki for Merov - Several meetings - Ship 2.4 - A lot of OOO medical; sorry. *FUTURE* - OOO and some triage, maybe - Meetings - OOO next Mon for PGI hackathon *IMPEDIMENTS* - holiday and medical OOO will limit my productivity through New Year Esbee Linden ------------------------------ *PAST* - Lots of meetings - Snowstorm team meeting - Review integration queue - Viewer 2.4 release stuff - Finalize Viewer 2.4 blog post and publish *FUTURE* - Lots of meetings - Review integration queue - Upload sketches of saved layouts - VWRs to check on - VWR-21493 - STORM-525 - STORM-529. It was re-resolved as no repro. - STORM-702. Caused issues based on fix. Let's chat more with PE about this. (Nyx is going to take a look at this) - Review VWR-16569 - Will review. Jonathan wants this one. - Review Jonathan's work list - Touch base w/Taka on STORM-398 - See comments on STORM-713 - Think about what to do with VWR tickets assigned to ProductEngine (I'm thinking we just un-assign these - need to review the tickets first though) *IMPEDIMENTS* - Time Paul ProductEngine ------------------------------ - OOO - sick Seth Productengine ------------------------------ *PAST* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - WIP. Got unit tests working with new directory iterator. The iterator doesn't handle changes in directory contents for now. *FUTURE* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations *IMPEDIMENTS* - Story (STORM-28) As a User, I want the ability to send my calling card to others. - Waiting for more details. Andrew Productengine ------------------------------ *PAST* - Normal task 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). - Completed first raw implementation of save and load. Will prettify it a little tomorrow, test and make some temporary simple UI for it. *FUTURE* - STORM-2. Finish first raw version of the fix. Estimate - 1 day. So it would be good to have design of UI and answer from Q about files (STORM-777) as soon as possible to implement the final version next week. - - Estimate - 1 day. *IMPEDIMENTS* - STORM-2 - No design for UI ( STORM-753 (Design the UI for viewer saved layouts)) - No reply from Q to letter regarding STORM-777 (Design the file format for layout information and discuss it). Vadim Productengine ------------------------------ *PAST* - Bug STORM-529 (Undo feature missing from BUILD menu): - Fixed. - Bug STORM-776 (unable to change permissions to "no trans" on item in avatar inventory): - Reviewed and tested Wolfpup's patch. - Bug STORM-410 (Region and parcel SLApps are displayed in non-human readable format): - Created two subtasks. Implemented the first one and assigned the second one to Esbee. *FUTURE* - Bug STORM-446 (CLicking on the secondlife:///app/classified/{UUID}/about SLapp does not display the details for the specified classified in the People side tray). - Bug STORM-511 (User is not able to view full name of group in title of group notification). *IMPEDIMENTS* - Need feedback from Esbee in: - STORM-702 (Make it possible to wear partial outfits). - STORM-797 (Parcel SLURL rendering). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - picked up v-d build r217184 - verified 16 integrated tickets - verified six cannot repro & expected behavior tickets - completed design & review of test plans: Object Permissions, Snapshots, World Map, World MiniMap *FUTURE* - pick up next v-d build - run regression suite in scope of recent changes *IMPEDIMENTS* - None Wolfpup Lowenhar ------------------------------ *PAST* - Worked in world - replied to Oz's email. - looked @ Bug Queue : viewer-development to see if could find some thing else to work on. *FUTURE* - Work @ RL and in world. - Check Bug Queue : viewer-development some more. *IMPEDIMENTS* - Not enough time between working in-world and at real job to actually work on code. - Right Hand(it is slowly healing but will take time since it is the tip of middle finger.) - Trying to Figure out what to work on and still waiting on answer for STORM-236. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/84611b96/attachment-0001.htm From Aleric.Inglewood at gmail.com Mon Dec 20 06:04:05 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 20 Dec 2010 14:04:05 -0000 Subject: [opensource-dev] Review Request: VWR-10579: Fix NDOF.cmake to do the right thing on standalone. In-Reply-To: <20101219155419.3541.60659@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219155419.3541.60659@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220140405.3541.74820@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/45/ ----------------------------------------------------------- (Updated 2010-12-20 06:04:05.704478) Review request for Viewer. Changes ------- This new patch addresses Boroondas -heh- preferences ;) it tries to find NDOF and when not found prints an error and the instructions to configure with -DNDOF:BOOL=OFF if you really don't want space navigator joystick support. This is indeed very simular to how FMOD works currently. This new patch also adds indra/cmake/FindNDOF.cmake, which was erroneously missing from the first patch, oops! Summary (updated) ------- On standalone, only define -DLIB_NDOF=1 when NDOF can be found. This addresses bug VWR-10579. http://jira.secondlife.com/browse/VWR-10579 Diffs (updated) ----- indra/cmake/FindNDOF.cmake PRE-CREATION indra/cmake/NDOF.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/45/diff Testing ------- I can't remember when I started using this, but it was long ago. I don't have libndofdev installed. I just installed Michelle's debian package libndofdev-dev and then it found it: -- Found NDOF: Library in '/usr/lib/libndofdev.so' and header in '/usr/include' Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/466cc67f/attachment.htm From Aleric.Inglewood at gmail.com Mon Dec 20 06:19:05 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 20 Dec 2010 14:19:05 -0000 Subject: [opensource-dev] Review Request: VWR-24252: Find Qt4 with find_package on STANDALONE. In-Reply-To: <20101219165631.3439.60782@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219165631.3439.60782@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220141905.3440.70652@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/46/ ----------------------------------------------------------- (Updated 2010-12-20 06:19:04.960312) Review request for Viewer. Changes ------- The new version is the same as the previous one, but it adds indra/cmake/FindLLQtWebkit.cmake that was erroneously missing in the previous patch. Summary (updated) ------- This patch has only effect on standalone. It searches for the Qt libs using the cmake provided FindQt4.cmake and search for llqtwekbit using the new FindLLQtWebkit.cmake and then uses the resulting LLQTWEBKIT_LIBRARY and LLQTWEBKIT_INCLUDE_DIR in the right places. I added an explicit test to check if QTDIR is set, it is set to the correct value (even LL got this wrong on their wiki, so it's apparently not obvious): As of Qt 4, Qt is found by calling qmake, NOT by looking at QTDIR. So, if you set QTDIR then it better be set to whatever qmake was "found" (using PATH as usual). Finally, we also need to explicitly pass the Qt plugin libraries in order to link with them, so part of this patch adds the rules to do that (the foreach). Note that if you installed your libs in a non-standard place, then of course you still have to set LD_LIBRARY_PATH yourself before running the viewer ;) This addresses bug VWR-24252. http://jira.secondlife.com/browse/VWR-24252 Diffs (updated) ----- indra/cmake/FindLLQtWebkit.cmake PRE-CREATION indra/cmake/WebKitLibPlugin.cmake b0689af42a71 indra/llplugin/CMakeLists.txt b0689af42a71 indra/media_plugins/webkit/CMakeLists.txt b0689af42a71 Diff: http://codereview.secondlife.com/r/46/diff Testing ------- I used this while working on adding plugin support to Imprudence, needing to debug into the Qt libs and llqtwebkit. I added support for multiple versions of llqtwebkit to imprudence (not just the one needed, but also newer versions of llqtwebkit). Needless to say that I needed this patch to work to find my (several) installations of Qt and llqtwebkit. Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/89abbec3/attachment.htm From Aleric.Inglewood at gmail.com Mon Dec 20 07:06:50 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Mon, 20 Dec 2010 15:06:50 -0000 Subject: [opensource-dev] Review Request: VWR-24261: Configuration with cmake 2.8 is extremely slow Message-ID: <20101220150650.3433.32462@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/49/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Work around for bug in cmake 2.8+ that causes the time to (re)configure the viewer to become 43 times slower. This patch adds a FindZLIB.cmake that doesn't have the bug added in 2.8 (cmake is aware of it and will fix it in a future release, although there is no reason to stop using our own in the future). This FindZLIB is linux specific (we only need it for standalone), see the discussion in SNOW-751. This addresses bug VWR-24261. http://jira.secondlife.com/browse/VWR-24261 Diffs ----- indra/cmake/CMakeLists.txt b0689af42a71 indra/cmake/FindZLIB.cmake PRE-CREATION Diff: http://codereview.secondlife.com/r/49/diff Testing ------- Already added to Snowglobe 1.4 and 1.5. See http://jira.secondlife.com/browse/SNOW-751 Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/3c8d36a1/attachment.htm From vsavchuk at productengine.com Mon Dec 20 09:40:48 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 20 Dec 2010 17:40:48 -0000 Subject: [opensource-dev] Review Request: Modify Viewer to statically link to KDU v6.4.1 if available In-Reply-To: <20101216062141.18751.24541@domU-12-31-38-00-90-68.compute-1.internal> References: <20101216062141.18751.24541@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220174048.4669.27616@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/3/#review57 ----------------------------------------------------------- Ship it! No significant objections. (I didn't actually review llimagej2c.cpp: it would take forever :-)) Tested x86 Linux build with USE_KDU set to ON and OFF. Works fine with the patch I attached to the ticket. indra/cmake/Copy3rdPartyLibs.cmake I didn't quite get why there are FMOD-related changes in this patch. indra/llkdu/llkdumem.h CS: mFirstCompIdx, mNumComponents, etc. - Vadim On 2010-12-15 22:21:41, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/3/ > ----------------------------------------------------------- > > (Updated 2010-12-15 22:21:41) > > > Review request for Viewer. > > > Summary > ------- > > This rather big patch accomplish the following: > - makes llkdu public and open source: this contains decompression and compression implementations using the KDU API > - links the viewer to KDU v6.4.1 statically if USE_KDU set at build time (and assuming you do have a licensed version of Kakadu) > - links statically to OpenJpeg otherwise > > > This addresses bug STORM-151. > http://jira.secondlife.com/browse/STORM-151 > > > Diffs > ----- > > indra/CMakeLists.txt 22c757e8246b > indra/cmake/Copy3rdPartyLibs.cmake 22c757e8246b > indra/cmake/LLKDU.cmake 22c757e8246b > indra/integration_tests/llui_libtest/CMakeLists.txt 22c757e8246b > indra/llimage/CMakeLists.txt 22c757e8246b > indra/llimage/llimage.cpp 22c757e8246b > indra/llimage/llimagej2c.h 22c757e8246b > indra/llimage/llimagej2c.cpp 22c757e8246b > indra/llkdu/CMakeLists.txt PRE-CREATION > indra/llkdu/llimagej2ckdu.h PRE-CREATION > indra/llkdu/llimagej2ckdu.cpp PRE-CREATION > indra/llkdu/llkdumem.h PRE-CREATION > indra/llkdu/llkdumem.cpp PRE-CREATION > indra/newview/CMakeLists.txt 22c757e8246b > indra/newview/viewer_manifest.py 22c757e8246b > install.xml 22c757e8246b > > Diff: http://codereview.secondlife.com/r/3/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/32af6ee9/attachment-0001.htm From brad at lindenlab.com Mon Dec 20 11:29:32 2010 From: brad at lindenlab.com (Brad Kittenbrink) Date: Mon, 20 Dec 2010 19:29:32 -0000 Subject: [opensource-dev] Review Request: VWR-24251: Fix -DLL_TESTS:BOOL=ON on standalone when Tut is installed in a non-standard directory. In-Reply-To: <20101219151851.3437.4152@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219151851.3437.4152@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220192932.4492.30448@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/44/#review58 ----------------------------------------------------------- Ship it! Looks good to me - Brad On 2010-12-19 07:18:51, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/44/ > ----------------------------------------------------------- > > (Updated 2010-12-19 07:18:51) > > > Review request for Viewer. > > > Summary > ------- > > If tut/tut.hpp isn't installed in a standard include directory all tests > fail because the found include directory for tut isn't passed to the compiler. > > This patch fixes this by passing it. > Note that using include_directories() in a Find*.cmake file is bad practise. > The correct way is to set an include dir variable and call > include_directories() once. It certainly doesn't work for the tests anyway > because the tests are all over the place and include_directories is on a > per folder basis. What is needed is to set it for each (test) target. > > However, there is no TARGET_INCLUDE_DIRECTORIES. The closest thing that we > have is to set the COMPILE_FLAGS property for a target. > > Fortunately, standalone is only used for linux, so we can just use > -I${TUT_INCLUDE_DIR} to get the effect we want. > > > This addresses bug VWR-24251. > http://jira.secondlife.com/browse/VWR-24251 > > > Diffs > ----- > > indra/cmake/LLAddBuildTest.cmake b0689af42a71 > indra/cmake/Tut.cmake b0689af42a71 > indra/test/CMakeLists.txt b0689af42a71 > > Diff: http://codereview.secondlife.com/r/44/diff > > > Testing > ------- > > Tested with standalone and tut.hpp installed in a non-standard place *after applying VWR-24247* of course. > All tests compile and pass (on linux 64bit). > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/8139c610/attachment.htm From akanevsky at productengine.com Mon Dec 20 12:48:05 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Mon, 20 Dec 2010 14:48:05 -0600 Subject: [opensource-dev] Daily Scrum Summary - Monday, December 20 Message-ID: Monday, December 20, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - STORM-744 : Add unit tests to llkdu: Finished fixing the llimage test. Added tests for llkdu. Also reactivated and fixed llworldmap and llworldmipmap tests in newview while I was at it. *FUTURE* - LL Hackaton today all day (mapserver and mapgen) - STORM-745 : Produce comprehensive perf baseline: Complete that work. - STORM-744 : Add unit tests to llkdu: Move to review. *IMPEDIMENTS* - STORM-151 : I need to get a review on this and get it integrated to make progress on my other KDU related tasks... I need to integrate this week. Oz Linden ------------------------------ *PAST* - Merge Monkey - pulled several fixes (had to reject one) - Fixing wiki documentation re: bitbucket - Jira workflow changes for reviews & approvals - Setting up build fixes repo w/ Aleric - Office Hour - Autobuild audits... *FUTURE* - Merge Monkey - Investigate workflow issues... - Autobbuild audits ... *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Meetings - Work on STORM-28 but not finished *FUTURE* - More storm-28 - Hackathon *IMPEDIMENTS* - Hackathon will keep me from doing anything today. Esbee Linden ------------------------------ *PAST* - Lots of meetings - Review integration queue - Viewer 2.4 release stuff *FUTURE* - Lots of meetings - Review integration queue - Upload sketches of saved layouts (STORM-753) - VWRs to check on - VWR-21493 - STORM-702. Caused issues based on fix. Let's chat more with PE about this. (Nyx is going to take a look at this) - Review VWR-16569 - Will review. Jonathan wants this one. - Review Jonathan's work list - Think about what to do with VWR tickets assigned to ProductEngine (I'm thinking we just un-assign these - need to review the tickets first though) - STORM-410, -236, -28, -34, -797, -525, -529, -398, -713 *IMPEDIMENTS* - Time Paul ProductEngine ------------------------------ *PAST* - BUG STORM-508 (Teleport history entries from "2 days ago", "3 days ago", etc. lists are moved into "Today" list on teleport) - Worked on this bug but after discussion with Vadim closed as expected behavior. - BUG STORM- 669 (Security browsing' icon is overlapped by 'More' button in object info mini-inspector) - Fixed and sent for review. - BUG STORM-801 (Wrong checkbox label in panel preferences, advanced tab) - Created and fixed. Tomorrow will send for review - BUG STORM-411 (The most of additional options in the Teleport History profile are always disabled) - Fixed and sent for review - BUG STORM-412 (Resident profile controls aren't reshaped on changing panel width) - Fixed and sent for review - BUG STORM-460 ("Go" button is cropped from right in the Media Browser) - Fixed and sent for review - BUG STORM-388 ("Bottom button is cropped in the IM, Group and Add-hoc chat floaters") - WIP. Investigated. Estimate ~ 1 hour. *FUTURE* - BUG STORM-388 ("Bottom button is cropped in the IM, Group and Add-hoc chat floaters") - Other tickets by priority *IMPEDIMENTS* - None Seth Productengine ------------------------------ *PAST* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Completed directory iterator first version implementation, posted it for review. *FUTURE* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Continue with the issue if got some feedback on implementation. - Or pick some issues from Sprint 9. *IMPEDIMENTS* - Story (STORM-28) As a User, I want the ability to send my calling card to others. - Waiting for more details. Andrew Productengine ------------------------------ *PAST* - Normal task 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). - Attached temporary UI to the fix. Started testing the fix and found problems with loading of some of the floaters- undocked sidetray tabs and floater inventory. Working on found issues. - Fixed the problem with inventory floater (it turned out to be not inventory floater-specific as I thought, and could affect other floaters). Investigated how to solve problem with undocked tabs floaters, and it seems that saving and loading multiple instances of the same floaters should use the same info that is needed for saving sidetray floaters. So though I planned to implement this feature later, I'll do it now to kill two birds with one stone. Working according to results of this investigation. - Implemeted saving of bottomtray state. Working on sidetray floaters. - Need design. *FUTURE* - STORM-2. Estimate - 1 day. - Need design. *IMPEDIMENTS* - STORM-2 - No design for UI ( STORM-753 (Design the UI for viewer saved layouts)) - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Need Esbee to approve (or disapprove) changing setting to per-account with losing ability to change it before login. Vadim Productengine ------------------------------ *PAST* - Bug STORM-446 (CLicking on the secondlife:///app/classified/{UUID}/about SLapp does not display the details for the specified classified in the People side tray): - Investigated, resolved as not reproducible. - Bug STORM-511 (User is not able to view full name of group in title of group notification): - WIP, ETA 1d. - Investigate STORM-796 (Region SLURL rendering): - Investigated TeamCity, created a Mac build configuration, fixed Mac build. - Bug STORM-511 (User is not able to view full name of group in title of group notification): - Fixed. - Bug STORM-384 (Text overlaying appears after resizing Statistics bar floater): - Resolved as won't finish. *FUTURE* - Review Merov's fix for STORM-151 (Modify viewer so that we link statically with kdu or openjpeg). - Pick something from the bug queues. *IMPEDIMENTS* - Need feedback from Esbee in: - STORM-702 (Make it possible to wear partial outfits). - STORM-797 (Parcel SLURL rendering). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - picked up v-d build r217184 - verified 16 integrated tickets - verified six cannot repro & expected behavior tickets - completed design & review of test plans: Object Permissions, Snapshots, World Map, World MiniMap *FUTURE* - pick up next v-d build - run regression suite in scope of recent changes *IMPEDIMENTS* - None Jonathan Yap ------------------------------ *PAST* - Applied two patch files by Twisted Laws, compiled, tested, and uploaded to bitbucket. One each for: - STORM-466 minimap cannot be reset to default zoom - STORM-467 minimap zoom does not persist to the next session *FUTURE* - [long range] Update lsl wiki - Change Unsupported icon next to llTextBox to New Feature. As this is a locked page a Linden will have to do this. *IMPEDIMENTS* - None -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/54cb6d24/attachment-0001.htm From slitovchuk at productengine.com Mon Dec 20 13:47:20 2010 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Mon, 20 Dec 2010 21:47:20 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20101217204652.18774.85725@domU-12-31-38-00-90-68.compute-1.internal> References: <20101217204652.18774.85725@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220214720.4669.56543@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/ ----------------------------------------------------------- (Updated 2010-12-20 13:47:20.663157) Review request for Viewer. Changes ------- - Added supported glob wildcards matching description. - Fixed leading '*' translation to regex to avoid matching leading '.' in file names. - Fixed '?' escaping. - Added incorrect braces usage handling. Added related test cases. - Fixed character ranges complementation with '!'. Added related test cases. Summary ------- Fixed LLDir unit test which failed for some complex wildcard combinations. Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. This addresses bug STORM-550. http://jira.secondlife.com/browse/STORM-550 Diffs (updated) ----- indra/cmake/Boost.cmake 794ad1fc71d1 indra/llvfs/CMakeLists.txt 794ad1fc71d1 indra/llvfs/lldiriterator.h PRE-CREATION indra/llvfs/lldiriterator.cpp PRE-CREATION indra/llvfs/tests/lldir_test.cpp 794ad1fc71d1 Diff: http://codereview.secondlife.com/r/32/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/f116e6e8/attachment.htm From nyx at lindenlab.com Mon Dec 20 14:40:41 2010 From: nyx at lindenlab.com (Nyx Linden) Date: Mon, 20 Dec 2010 22:40:41 -0000 Subject: [opensource-dev] Review Request: STORM-702 Make it possible to wear partial outfits In-Reply-To: <20101213150829.18768.63543@domU-12-31-38-00-90-68.compute-1.internal> References: <20101213150829.18768.63543@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101220224041.3725.19437@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/14/#review59 ----------------------------------------------------------- I have no technical objections to the code provided. And in fact, the code provided *should* change the functionality back to what the users are reporting is their expectation of what the behavior should be. The part that makes me nervous is that this enables an outfit operation for a class of folders that we have not allowed with the new outfit system previously. Based on other pieces on the code that would get called by this operation, I believe that the result will be that of the resident request to "revert" behavior (namely remove all clothing, remove body parts that are replaced by the new folder, leave old body parts that are necessary to display the avatar). That being said, we need a more comprehensive review of the role of incomplete outfits and how it fits with our technical architecture we've built up in our current outfits system. The code here should implement the correct behavior and I have no technical issues with it. But I want to make sure that we are aware of the risk of edge cases as we have not considered possibly popping up as a result of this patch. - Nyx On 2010-12-13 07:08:28, Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/14/ > ----------------------------------------------------------- > > (Updated 2010-12-13 07:08:28) > > > Review request for Viewer. > > > Summary > ------- > > Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. those that don't contain full set of body parts). > > > This addresses bug STORM-702. > http://jira.secondlife.com/browse/STORM-702 > > > Diffs > ----- > > indra/newview/llappearancemgr.cpp 3d2e71443c58 > indra/newview/llinventoryfunctions.cpp 3d2e71443c58 > > Diff: http://codereview.secondlife.com/r/14/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/53789b67/attachment.htm From yoz at lindenlab.com Mon Dec 20 16:04:35 2010 From: yoz at lindenlab.com (Yoz Grahame) Date: Mon, 20 Dec 2010 16:04:35 -0800 Subject: [opensource-dev] LSL function wiki update (was Re: Daily Scrum Summary - Monday, December 20) Message-ID: > *FUTURE* > > - [long range] > > Update lsl wiki - Change Unsupported icon next to llTextBox to New Feature. > As this is a locked page a Linden will have to do this. > Done - sorry about the delay here. -- Yoz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101220/7144266e/attachment.htm From gcanaday at gmail.com Mon Dec 20 17:57:53 2010 From: gcanaday at gmail.com (Glen Canaday) Date: Mon, 20 Dec 2010 20:57:53 -0500 Subject: [opensource-dev] grid-wide banners Message-ID: <201012202057.53710.gcanaday@gmail.com> zFire Xue's device has now identified linden build 2.4.0 (216989) for Linux as a copybot client. I know this is not the correct forum, but I need a hotline to get rid of this guy and this product. It has seriously messed with my enjoyment of SL by banning me from EVERY one of his customer's sims. ALL of them. That includes normally quiet public places, such as the Shelman Sandbox. Now I have no idea where I can go and cannot go - and my partner is now similarly affected. I simply want rid of this guy and his "product." Does anyone know the proper forum for this? Does anyone know if an AR will ever cut it in this situation? --GC From blindwanderer at gmail.com Mon Dec 20 21:37:10 2010 From: blindwanderer at gmail.com (Strife Onizuka) Date: Tue, 21 Dec 2010 00:37:10 -0500 Subject: [opensource-dev] LSL function wiki update (was Re: Daily Scrum Summary - Monday, December 20) In-Reply-To: References: Message-ID: The contents of those lists can be found on https://wiki.secondlife.com/wiki/Template:LSL_All_Functions/Name and https://wiki.secondlife.com/wiki/Template:LSL_All_Functions/Number. To aid in keeping them up to date, there is the template https://wiki.secondlife.com/wiki/Template:LSL_All_Functions/Generate which produces the code for both templates. The two templates exist to simplify localization, they contain nothing really language specific (except for the "New") and the hovertext can be customized. It means all localizations of the Portal are synced in this regard and provides a list of articles in need of translation. On Mon, Dec 20, 2010 at 7:04 PM, Yoz Grahame wrote: > > *FUTURE* >> >> - [long range] >> >> Update lsl wiki - Change Unsupported icon next to llTextBox to New >> Feature. As this is a locked page a Linden will have to do this. >> > > Done - sorry about the delay here. > > -- Yoz > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/012cc890/attachment.htm From merov at lindenlab.com Mon Dec 20 22:29:35 2010 From: merov at lindenlab.com (Merov Linden) Date: Tue, 21 Dec 2010 06:29:35 -0000 Subject: [opensource-dev] Review Request: Upgrade libcurl to 7.21.1 Message-ID: <20101221062935.7878.57888@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/52/ ----------------------------------------------------------- Review request for Viewer. Summary ------- - Points the install.xml viewer to new libcurl binaries (7.21.1) - Fixes cmake files so that it builds on all platforms This addresses bug STORM-453. http://jira.secondlife.com/browse/STORM-453 Diffs ----- indra/cmake/CURL.cmake 0d2b3d8256a9 indra/mac_updater/CMakeLists.txt 0d2b3d8256a9 install.xml 0d2b3d8256a9 Diff: http://codereview.secondlife.com/r/52/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/8b6ecf6e/attachment-0001.htm From vsavchuk at productengine.com Tue Dec 21 07:03:43 2010 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Tue, 21 Dec 2010 17:03:43 +0200 Subject: [opensource-dev] Test request for STORM-453 (update libcurl 7.21.1) In-Reply-To: References: Message-ID: <4D10C1CF.6010502@productengine.com> On 12/16/2010 07:57 AM, Philippe (Merov) Bossut wrote: > I've been working on this which is blocking Robin to complete the rest > of the work for VWR-20801 (Implement socks5 proxy). > > I think I'm done but, since lots of things can go wrong when changing > such a library, I'd like to get some folks banging on the executables > before moving that to "review". > > Binaries can be found at: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217039/index.html > > Please let me know which platform you test on and what the overall result. Tested with the prebuilt binary on Linux/x86 according to the ticket acceptance criteria. Everything worked well. -- Vadim From vsavchuk at productengine.com Tue Dec 21 07:32:08 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 21 Dec 2010 15:32:08 -0000 Subject: [opensource-dev] Review Request: Upgrade libcurl to 7.21.1 In-Reply-To: <20101221062935.7878.57888@domU-12-31-38-00-90-68.compute-1.internal> References: <20101221062935.7878.57888@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101221153208.7885.48388@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/52/#review60 ----------------------------------------------------------- Ship it! Builds and works fine on Linux/x86. - Vadim On 2010-12-20 22:29:35, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/52/ > ----------------------------------------------------------- > > (Updated 2010-12-20 22:29:35) > > > Review request for Viewer. > > > Summary > ------- > > - Points the install.xml viewer to new libcurl binaries (7.21.1) > - Fixes cmake files so that it builds on all platforms > > > This addresses bug STORM-453. > http://jira.secondlife.com/browse/STORM-453 > > > Diffs > ----- > > indra/cmake/CURL.cmake 0d2b3d8256a9 > indra/mac_updater/CMakeLists.txt 0d2b3d8256a9 > install.xml 0d2b3d8256a9 > > Diff: http://codereview.secondlife.com/r/52/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/d2eb1c2c/attachment.htm From Aleric.Inglewood at gmail.com Tue Dec 21 07:59:33 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 21 Dec 2010 15:59:33 -0000 Subject: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux. In-Reply-To: <20101219174253.3437.88790@domU-12-31-38-00-90-68.compute-1.internal> References: <20101219174253.3437.88790@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101221155933.7886.25251@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/ ----------------------------------------------------------- (Updated 2010-12-21 07:59:33.568556) Review request for Viewer. Changes ------- Attached an incremental diff that reverts the removal of APRUTIL_INCLUDE_DIR Summary ------- To use ld.gold configure with: -DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold". See VWR-24254 for more details. This addresses bug VWR-24254. http://jira.secondlife.com/browse/VWR-24254 Diffs (updated) ----- indra/cmake/LLCommon.cmake b0689af42a71 Diff: http://codereview.secondlife.com/r/48/diff Testing ------- ld.gold links the viewer on my machine in 8 seconds, as opposed to 19 seconds with ld.bfd. Moreover, it uses a LOT less memory during linking (about 750 MB instead of 2.5 GB! (for viewer 1)). Since my machine locked up hard when I run out of memory (something with using an encrypted RAID for my swap), and compiling viewer 2 uses more than 3 GB, I couldn't compile viewer 2 at all anymore without this patch (and using ld.gold). And OMG this is fast! Thanks, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/fc9a915d/attachment.htm From merov at lindenlab.com Tue Dec 21 10:21:44 2010 From: merov at lindenlab.com (Merov Linden) Date: Tue, 21 Dec 2010 18:21:44 -0000 Subject: [opensource-dev] Review Request: VWR-24254: Add support for using ld.gold on linux. In-Reply-To: <20101221155933.7886.25251@domU-12-31-38-00-90-68.compute-1.internal> References: <20101221155933.7886.25251@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101221182144.7890.33321@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/48/#review62 ----------------------------------------------------------- Ship it! I haven't tried building on LINUX (I recommend whoever does the integration to run a TC build on a test repo for safety before merging in lindenlab/viewer-development) but everything seems sound to me. Ship it! - Merov On 2010-12-21 07:59:33, Aleric Inglewood wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/48/ > ----------------------------------------------------------- > > (Updated 2010-12-21 07:59:33) > > > Review request for Viewer. > > > Summary > ------- > > To use ld.gold configure with: > -DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,-use-gold". > > See VWR-24254 for more details. > > > This addresses bug VWR-24254. > http://jira.secondlife.com/browse/VWR-24254 > > > Diffs > ----- > > indra/cmake/LLCommon.cmake b0689af42a71 > > Diff: http://codereview.secondlife.com/r/48/diff > > > Testing > ------- > > ld.gold links the viewer on my machine in 8 seconds, as > opposed to 19 seconds with ld.bfd. Moreover, it uses a > LOT less memory during linking (about 750 MB instead of > 2.5 GB! (for viewer 1)). > > Since my machine locked up hard when I run out of memory > (something with using an encrypted RAID for my swap), > and compiling viewer 2 uses more than 3 GB, I couldn't > compile viewer 2 at all anymore without this patch (and > using ld.gold). And OMG this is fast! > > > Thanks, > > Aleric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/ba09b16e/attachment.htm From merov at lindenlab.com Tue Dec 21 11:31:33 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 21 Dec 2010 11:31:33 -0800 Subject: [opensource-dev] No OH this afternoon Message-ID: Hi guys, Sorry for the late notice today but between Hack-a-thon yesterday and various duties today related to the coming holiday, I'm going to stay focused on getting things moving on Snowstorm today and will not held my regular OH this afternoon. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/1de25bf1/attachment.htm From merov at lindenlab.com Tue Dec 21 13:34:14 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 21 Dec 2010 13:34:14 -0800 Subject: [opensource-dev] Test build for a bunch of proposed patches Message-ID: Hi guys, Quite a few proposed changesets required a test build to be reviewedand approved by Esbee and others. I created such a build and it's available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217627/index.html This merges the following patches on top of the current viewer-development: ** STORM-785 ** STORM-737 ** STORM-723 ** STORM-669 ** STORM-387 ** STORM-615 ** STORM-411 Enjoy! - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/47b6a461/attachment.htm From akanevsky at productengine.com Tue Dec 21 14:18:17 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Tue, 21 Dec 2010 16:18:17 -0600 Subject: [opensource-dev] Daily Scrum Summary - Tuesday, December 21 Message-ID: Tuesday, December 21, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Merov - Merov will make a build for all changes Esbee requested. - Merov gives special thanks to Vadim for review Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - Hackathon: Found a bug in the viewer while doing this (STORM-805). Various mapserver related hacks with Lindens. - STORM-805 : Wrong map URL : Logged, posted a patch. Ready for review. - STORM-453 : libcurl upgrade: Received a good review from Robin. Created an RB record and moved the JIRA to Review state. - STORM-151 : kdu upgrade: Integrated Vadim's feedback. Ready for integration. *FUTURE* - Do MM today, no OH as I'm swamped... - STORM-745 : Produce comprehensive perf baseline: Complete that work. - STORM-744 : Add unit tests to llkdu: Move to review once STORM-151 is integrated *IMPEDIMENTS* - STORM-524 : Waiting for Esbee to review the behavior change before integrating that fix. Please, pretty please :) Oz Linden ------------------------------ *PAST* - Merge Monkey - New Jira filters for reviews (on Snowstorm Dashboard) - Fixed workflow changes for approvals - Autobuild audits... (making progress!) *FUTURE* - Autobbuild audits ... *IMPEDIMENTS* - none Q Linden ------------------------------ *PAST* - Hackathon (working on Python tools) - Reading over reviews queue and talking about various issues *FUTURE* - More storm-28 *IMPEDIMENTS* - Holidays and PT Esbee Linden ------------------------------ *PAST* - Review integration queue - Uploaded design detail for STORM-753 - Closed VWR-21493 as cannot repro - Reviewed STORM-702, -713, - Gave feedback on STORM-797 - Reviewed and added PO approval for STORM-805, -803, -784, -523 - Added target viewer versions and PO approvals for STORM-460, -453, 151. - Added comment to STORM-525 asking for clear repro steps. - Added a comment to STORM-34 asking for clarification. - Approved STORM-524. *FUTURE* - OOO this afternoon. - Review integration queue - Review Jonathan's work list - Think about what to do with VWR tickets assigned to ProductEngine (I'm thinking we just un-assign these - need to review the tickets first though) - Review proposed change for STORM-398, see if I can get input from Communications PO. - Check on feedback for STORM-236 - Need to think about STORM-28 before responding. - Take a look at STORM-529 in viewer-development. *IMPEDIMENTS* - Would like to see Viewers built to check the following tickets: - STORM-785 - STORM-737 - STORM-723 - STORM-669 - STORM-387 - Would like to see a screenshot of the object context menu change in STORM-615 before I approve. - Need clarification about what has been changed in STORM-411. - STORM-713 was added to my list to review, but it looks like it's already been integrated and passed QA. What do you want me to do with it? - STORM-529 was added to my list to review, but it's already been integrated and passed QA. Will have a look on a recent viewer-development build to test. Paul ProductEngine ------------------------------ *PAST* - BUG STORM-388 (Bottom button is cropped in the IM, Group and Add-hoc chat floaters) - Resolved as cannot reproduce. - BUG STORM-370 (Human-readable name of region disappears from Location Bar after pressing ESC) - Resolved as cannot reproduce. - BUG STORM-387 (Part of the table is hided after increasing firsts column width in the floater and then dock it to the SP) - Fixed and sent for review - BUG STORM-411 (The most of additional options in the Teleport History profile are always disabled) - Re-fixed according to Vadim's commentaries - BUG STORM-372 ("Start at" values are not identical in the Preference and in the bottom drop down menu) - WIP. Estimate ~ 1 hour. *FUTURE* - BUG STORM-372 ("Start at" values are not identical in the Preference and in the bottom drop down menu) - Other tickets by priority *IMPEDIMENTS* - None Seth Productengine ------------------------------ *PAST* - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Fixes for the first version of the patch according to feedback from Oz. *FUTURE* - Pick some issues from Sprint 9. *IMPEDIMENTS* - Story (STORM-28) As a User, I want the ability to send my calling card to others. - Waiting for more details. Andrew Productengine ------------------------------ *PAST* - OOO - sick *FUTURE* - STORM-2. Estimate - 1 day. *IMPEDIMENTS* - Normal task STORM-34 - Need Esbee to approve (or disapprove) changing setting to per-account with losing ability to change it before login. Vadim Productengine ------------------------------ *PAST* - Helped Andrew to answer Q's mail about file format for viewer layouts. - Reviewed Merov's fix for STORM-151, by the way resolved a unit test linking failure on Linux. - Other code reviews. - Story STORM-453 (Upgrade libcurl to 7.21.1): - Reviewed and tested Merov's patch. - Bug STORM-806 (External script editor doesn't work for inventory scripts): - Posted and started working on. *FUTURE* - Bug STORM-806: ETA 1d. *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - integrated tickets verification - test plans update - movement & camera controls, alerts & notifications, bottom bar *FUTURE* - build tools test plan design *IMPEDIMENTS* - None Jonathan Yap ------------------------------ *PAST* - Sent email to Yoz to also adjust "U" to "New" for llTextBox in http://wiki.secondlife.com/wiki/Category:LSL_Functions *FUTURE* *IMPEDIMENTS* - Am I supposed to check the jira for things that might be reassigned to me? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/9207f9fe/attachment-0001.htm From andrew at lindenlab.com Tue Dec 21 17:49:52 2010 From: andrew at lindenlab.com (Andrew Meadows) Date: Tue, 21 Dec 2010 17:49:52 -0800 Subject: [opensource-dev] Review Request: STORM-807 update returnability of objects based on new encroachment rules In-Reply-To: References: Message-ID: <4D115940.9040001@lindenlab.com> I've added a feature to the SL simulator that allows encroaching (*) objects to be returned. The ETA for this is sometime in early 2011 (probably January) and I'll be adding some wiki documentation about the returnability of encroaching objects soon. In the meantime I've added viewer-side UI support for returning encroaching objects. It should not hurt the viewer to add these changes before the server stuff is deployed. Here is the merge-request jira: https://jira.secondlife.com/browse/STORM-807 The changes can be pulled from here: http://bitbucket.org/andrew_linden/viewer-development The diff is attached. - Andrew (*) Encroaching objects are "positioned" on one person's land parcel but nevertheless extend part of themselves into a neighbor's parcel. -------------- next part -------------- A non-text attachment was scrubbed... Name: encroachment-viewer.patch Type: text/x-diff Size: 2645788 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/5ba53d27/attachment-0001.patch From angel_of_crimson at hotmail.com Tue Dec 21 20:24:25 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Tue, 21 Dec 2010 23:24:25 -0500 Subject: [opensource-dev] Test build for a bunch of proposed patches In-Reply-To: References: Message-ID: fix for storm 737 seems to work without breaking anything. On the contrary it is a wonderful little fix. 723 has issues please see my comments on the jira 669 looks good 387 looks good. 615 will take some getting used to simply because its a change, but looks very useful. 411 seems good to me. the only issue i see so far is 723... From: merov at lindenlab.com Date: Tue, 21 Dec 2010 13:34:14 -0800 To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Test build for a bunch of proposed patches Hi guys, Quite a few proposed changesets required a test build to be reviewedand approved by Esbee and others. I created such a build and it's available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217627/index.html This merges the following patches on top of the current viewer-development: ** STORM-785 ** STORM-737 ** STORM-723 ** STORM-669 ** STORM-387 ** STORM-615 ** STORM-411 Enjoy! - 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/62ec9464/attachment.htm From merov at lindenlab.com Tue Dec 21 22:26:32 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 21 Dec 2010 22:26:32 -0800 Subject: [opensource-dev] Review Request: STORM-807 update returnability of objects based on new encroachment rules In-Reply-To: <4D115940.9040001@lindenlab.com> References: <4D115940.9040001@lindenlab.com> Message-ID: Hi Andrew, Thanks for the heads up. The repo looks good except for a couple of files it touches that it shouldn't (like Info-SecondLife.plist) and changes that seem unrelated to the feature. I'll comment in JIRA. It merges fine with viewer-development. The attached diff though is a bit mind boggling. I'm not sure how you produced it but I certainly would discourage anyone trying to apply it. Devs willing to test encroaching then should pull from your repo and ignore that diff. Cheers, - Merov On Tue, Dec 21, 2010 at 5:49 PM, Andrew Meadows wrote: > I've added a feature to the SL simulator that allows encroaching (*) > objects > to be returned. The ETA for this is sometime in early 2011 (probably > January) > and I'll be adding some wiki documentation about the returnability of > encroaching > objects soon. In the meantime I've added viewer-side UI support for > returning > encroaching objects. It should not hurt the viewer to add these changes > before > the server stuff is deployed. > > Here is the merge-request jira: > > https://jira.secondlife.com/browse/STORM-807 > > The changes can be pulled from here: > > http://bitbucket.org/andrew_linden/viewer-development > > The diff is attached. > > - Andrew > > (*) Encroaching objects are "positioned" on one person's land parcel > but nevertheless extend part of themselves into a neighbor's parcel. > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101221/2f455dd1/attachment.htm From opensourceobscure at gmail.com Wed Dec 22 03:43:46 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Wed, 22 Dec 2010 12:43:46 +0100 Subject: [opensource-dev] grid-wide banners In-Reply-To: <201012202057.53710.gcanaday@gmail.com> References: <201012202057.53710.gcanaday@gmail.com> Message-ID: I assume you already sent messages, notecards, emails and whatever to the creator of that device. I think nobody can tell you if that will work, but nonetheless I would file at least a detailed Abuse Report. That said: I'm a Linux user and I can take SL videos. Let me know if you want me to help - we may create a video that shows what happens - that is, being banned while using a legit official SL viewer. Spreading such a video may seriously damage the device creator's reputation, raising the chance he will fix his product. Also, you could use the video it as a proof when you will contact sim owners, in order to show them they're using (and I guess paying for) a device that prevents legit users from visiting their lands. Please note I don't and can't access to Adult areas - so I couldn't help if we're talking about Zindra regions. Opensource Obscure On Tue, Dec 21, 2010 at 02:57, Glen Canaday wrote: > zFire Xue's device has now identified linden build 2.4.0 (216989) for Linux as > a copybot client. I know this is not the correct forum, but I need a hotline > to get rid of this guy and this product. It has seriously messed with my > enjoyment of SL by banning me from EVERY one of his customer's sims. ALL of > them. That includes normally quiet public places, such as the Shelman Sandbox. > Now I have no idea where I can go and cannot go - and my partner is now > similarly affected. > > I simply want rid of this guy and his "product." Does anyone know the proper > forum for this? Does anyone know if an AR will ever cut it in this situation? > > --GC > _______________________________________________ > 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 Obscure Twitter?[EN] -?Twitter?[IT] -?Blog?[IT] -?YouTube?-?Photos?-?Second Life From Aleric.Inglewood at gmail.com Wed Dec 22 05:39:17 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Wed, 22 Dec 2010 13:39:17 -0000 Subject: [opensource-dev] Review Request: STORM-702 Make it possible to wear partial outfits In-Reply-To: <20101220224041.3725.19437@domU-12-31-38-00-90-68.compute-1.internal> References: <20101220224041.3725.19437@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101222133917.7891.36660@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-20 14:40:41, Nyx Linden wrote: > > I have no technical objections to the code provided. > > And in fact, the code provided *should* change the functionality back to what the users are reporting is their expectation of what the behavior should be. > > > > The part that makes me nervous is that this enables an outfit operation for a class of folders that we have not allowed with the new outfit system previously. Based on other pieces on the code that would get called by this operation, I believe that the result will be that of the resident request to "revert" behavior (namely remove all clothing, remove body parts that are replaced by the new folder, leave old body parts that are necessary to display the avatar). > > > > That being said, we need a more comprehensive review of the role of incomplete outfits and how it fits with our technical architecture we've built up in our current outfits system. The code here should implement the correct behavior and I have no technical issues with it. But I want to make sure that we are aware of the risk of edge cases as we have not considered possibly popping up as a result of this patch. My (mathematical) analysis of the "outfit system" ================================================= - The outfit system exists of sets and operators. - Each operator works on two sets, where both sets are an input and one of the sets is used as output; this would be irrelevant for what the operators do except when those operators are not commutative (which is be Bad Thing, but unfortunately they are not). If one of those operators is written as '+' (whatever that does), then for now we can speak about a + b, which doesn't imply that this is the same as b + a and which intuitively extends to the definition a += b ==> a = a + b. Note that the '+' operator is abritrary, replace + with - and the same story holds. - The elements of each set do not have the same type, and if they don't then an operator can't work on them. Therefore, the correct way to look at these sets is as vectors where an absent type will be represented by '0' (zero). That is an arbitrary choice, but intuitive because our operators will be a lot more like groups than like fields. Of course, this implies that a + 0 = 0 + a = a. - Our vector (V) has one element per type. The types are: shape, (Linden) hair, (Linden) shoes, eyes, skin, alpha, tatoes, undershirts, shirts, jackets, gloves, undies, pants, socks, skull attachments, nose attachments, etc (one type for each different attachment point). - The elements of this vector are sets: for some types it is possible to wear multiple of the same type at the same time. Note that these are sets, not vectors: the order in which these wearables are added SHOULD be irrelevant (at the moment it isn't; for example, old viewers only show the first attachment that was attached, so the order is important). - Some types may only have a single element (in their set) at a time. As a result their operators are clearly not commutative, that is impossible. These types are: shape, hair, shoes, eyes, skin and alpha (I think; the exact list is irrelevant at this point). Lets call this class of types: S (of 'Single'). - The other types can be divided into two classes: wearables (tatoes, (under)shirts, jackets, gloves, pants, socks) and attachments (skull, nose, ...). For an intuitive functioning of the outfit system these SHOULD behave the same mathematically, but at this point we can't be certain if they do. However, it will be clear that all wearables and all attachments respectively behave the same. Lets call these classes W and A. [Note that V doesn't have to be implemented as a linear vector, I think it would be better to implement it as a vector of three vectors: one vector for elements of class S, one for elements of class W and one for elements of class A.] - For the S class we CAN have the following operations. Let x and y be two distinct elements of the same type, where the type is of class S. [Note that for the Current Outfit the empty set is not allowed.] Picking two arbitrary characters (+ and -) we can write for the possible operators: x + y = y, x - y = x. Other operators do not exist, but if they do out of necessity (namely, these are elements of a vector and we will need to define operators of the vector, which then in turn work on all types), then we can choose to let them be equivalent to either + or -. Also note that this choice defines our extended operators += and -= as: x += y ==> x = y, and x -= y ==> nul operator. - For the A class we CAN have the following operations. Let a and b be sets. Note that any distinct element can only be once in a set: { e1 } + { e1 } = { e1 }, but { e1 } - { e1 } = { 0 }. Hence, also this class is not a group, but so far the operators are commutative: a + b = b + a, etc, but there is no well defined inverse for this operation. This leads us to define the operators of A as '+' and '-' in the following sense: a + b = c, where a, b and c can be implemented as the C++ std::set, where T is capable of uniquely identifying equality (ie, if i1 and i2 are two distinct objects in your inventory, than, expressed as T it holds that i1 == i1, and i1 != i2. Ordering can be allowed to be arbitrary (i1 < i2 ==> i1 != i2). Then, adding b to a can be implemented by adding the elements of b to a one by one. Likewise, a - b can be implemented by trying to find and erase all elements of b one by one from a. - For the W class the order DOES matter. If you put on two shirts, the result should be different if you first put on shirt u and then v, or the other way around: u + v != v + u. Hence, in this case, on top of the above (for class A) we need to exactly describe operator< so that the ordering is a well known function of the order in which these wearables were put on. Baking can then be performed by running over all elements of a set in order. Clearly, the above has naturally led us to two operators: + and - to be defined for the complete outfit vector. While we can easily map these two operators on the operators of class W, which naturally maps to the operators of class A. [Note that we do not necessarily have to map them also to the same + and - as defined above for class S. For example, it is possible to define the vector operator + and - both as being the operator + for class S.] Also clearly, we can map the mathematically found operators (+ and -) to the already existing intuitive phrases in-world as follows: operator+ : Add to outfit operator- : Remove from outfit operator= : Replace outfit (define as: x -= x; x += y) [Note: this is NOT the same as the '=' that used everywhere else, which indeed just completely replaces as usual. I will write explicit operator= to mean this operator, and just '=' everywhere else] The notion "Incomplete Outfits" now, simply means that we allow the right-hand terms of each operator to have elements of class S that ARE empty. As a result we just have to refine the operators of class S, as follows: x + 0 = x and x - 0 = x. Note this makes operator= semi-non intuitive (note that x - x = x, as per our definition x - y = x): If y is empty, then x 'operator=' 0 ==> x -= x ; x += 0 ==> x = x - x ; x = x + 0 ==> x = x ; x = x ==> nul operator. In other words, assigning a 0 to an element of class S with operator= has no effect. I believe that the above definitions, which arise from a mathematical point of view and not from in-world experience, is sufficient to write a good C++ implementation, define the right classes and operators for those classes. Hopefully this analysis was helpful for your cause, Aleric - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/14/#review59 ----------------------------------------------------------- On 2010-12-13 07:08:28, Vadim ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/14/ > ----------------------------------------------------------- > > (Updated 2010-12-13 07:08:28) > > > Review request for Viewer. > > > Summary > ------- > > Enabled the "Replace Current Outfit" option for incomplete outfits (i.e. those that don't contain full set of body parts). > > > This addresses bug STORM-702. > http://jira.secondlife.com/browse/STORM-702 > > > Diffs > ----- > > indra/newview/llappearancemgr.cpp 3d2e71443c58 > indra/newview/llinventoryfunctions.cpp 3d2e71443c58 > > Diff: http://codereview.secondlife.com/r/14/diff > > > Testing > ------- > > > Thanks, > > Vadim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/34addd5b/attachment-0001.htm From oz at lindenlab.com Wed Dec 22 07:27:25 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 22 Dec 2010 10:27:25 -0500 Subject: [opensource-dev] Need test of (32bit) linux build Message-ID: <4D1218DD.8020106@lindenlab.com> Aleric has got a collection of proposed build system improvements that are under review. I've done a test build of them, and have already confirmed that the resulting viewers work fine on the Mac and on Windows (thank you, Wolfpup). Would someone who's got a handy Linux system please download the installer from http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_project-2/rev/217631/index.html and let me know if you run into any issues? From merov at lindenlab.com Wed Dec 22 07:34:12 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Wed, 22 Dec 2010 07:34:12 -0800 Subject: [opensource-dev] Test build for a bunch of proposed patches In-Reply-To: References: Message-ID: Hi, Thanks Trilo for the tests. Forwarding to the list as it is of interest to all. Cheers, - Merov On Tue, Dec 21, 2010 at 10:32 PM, Trilo Byte wrote: > I commented in the JIRA issues as well. > > ** STORM-785 - works well > > ** STORM-737 - works beautifully, thank you! > > ** STORM-723 - works, except there is a problem if single prim object has > contents in it. > > ** STORM-669 - looks good > > ** STORM-387 - Works as expected > > ** STORM-615 - Excellent, all menus look/work as expected, no more nested > delete button! > ** STORM-411 - looks great! > > Side note... tab key's broken on this build too. You had previously taken > a quick look at VWR-24172 back when it had been fixed in Viewer Development > (and couldn't repro), but it was broken again in 217184 and has been since. > :-( > > Trilo > > > On Dec 21, 2010, at 1:34 PM, Philippe (Merov) Bossut wrote: > > Hi guys, > > Quite a few proposed changesets required a test build to be reviewedand > approved by Esbee and others. I created such a build and it's available > here: > > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217627/index.html > > This merges the following patches on top of the current viewer-development: > ** STORM-785 > ** STORM-737 > ** STORM-723 > ** STORM-669 > ** STORM-387 > ** STORM-615 > ** STORM-411 > > Enjoy! > - 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/4fdc5fd2/attachment.htm From angel_of_crimson at hotmail.com Wed Dec 22 08:17:30 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Wed, 22 Dec 2010 11:17:30 -0500 Subject: [opensource-dev] Test build for a bunch of proposed patches In-Reply-To: References: , Message-ID: since i sent this last night and it doesnt seem to have hit the list... im resending it From: angel_of_crimson at hotmail.com To: merov at lindenlab.com; opensource-dev at lists.secondlife.com Date: Tue, 21 Dec 2010 23:24:25 -0500 Subject: Re: [opensource-dev] Test build for a bunch of proposed patches fix for storm 737 seems to work without breaking anything. On the contrary it is a wonderful little fix. 723 has issues please see my comments on the jira 669 looks good 387 looks good. 615 will take some getting used to simply because its a change, but looks very useful. 411 seems good to me. the only issue i see so far is 723... From: merov at lindenlab.com Date: Tue, 21 Dec 2010 13:34:14 -0800 To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Test build for a bunch of proposed patches Hi guys, Quite a few proposed changesets required a test build to be reviewedand approved by Esbee and others. I created such a build and it's available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217627/index.html This merges the following patches on top of the current viewer-development: ** STORM-785 ** STORM-737 ** STORM-723 ** STORM-669 ** STORM-387 ** STORM-615 ** STORM-411 Enjoy! - 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 _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/4b8d67fe/attachment.htm From wolfpup67 at earthlink.net Wed Dec 22 08:20:15 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Wed, 22 Dec 2010 11:20:15 -0500 Subject: [opensource-dev] Odd issue in build 217714 Message-ID: <001b01cba1f4$1e853690$5b8fa3b0$@net> There is an odd issue in Build 217714 of viewer-development. I noticed it this morning while helping to test a build for Oz. Issue is occurring in all three viewers I tested it in. I need help verifying if it is occurring in other OS's. TO repro: 1. Goto Esbees in world office. 2. Right click on the sand castle and slect object profile.(this item generates the hight rate of this issue) 3. Look at the avatar icons next to each person's name and watch them jump down and to the left ~10 pixiels. My system information: Second Life 2.5.0 (0) Dec 22 2010 01:37:19 (Second Life Developer) Release Notes You are at 238,528.0, 244,842.0, 21.7 in Hippotropolis located at sim4038.agni.lindenlab.com (216.82.18.81:13002) Second Life Server 10.11.30.215699 Release Notes CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2800.12 MHz) Memory: 2046 MB OS Version: Microsoft Windows 7 32-bit (Build 7600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8500 GT/PCI/SSE2 Windows Graphics Driver Version: 8.17.0012.5896 OpenGL Version: 3.3.0 libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8j zlib/1.2.3 c-ares/1.7.1 J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.6 (version number hard-coded) Voice Server Version: Vivox 3.2.0002.9361 Built with MSVC version 1400 Packets Lost: 0/98,428 (0.0%) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/b9d56fa2/attachment.htm From oz at lindenlab.com Wed Dec 22 08:28:37 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 22 Dec 2010 11:28:37 -0500 Subject: [opensource-dev] Odd issue in build 217714 In-Reply-To: <001b01cba1f4$1e853690$5b8fa3b0$@net> References: <001b01cba1f4$1e853690$5b8fa3b0$@net> Message-ID: <4D122735.7040705@lindenlab.com> On 2010-12-22 11:20, WolfPup Lowenhar wrote: > > There is an odd issue in Build 217714 of viewer-development. I noticed > it this morning while helping to test a build for Oz. Issue is > occurring in all three viewers I tested it in. I need help verifying > if it is occurring in other OS's. > > TO repro: > > 1.Goto Esbees in world office. > > 2.Right click on the sand castle and slect object profile.(this item > generates the hight rate of this issue) > > 3.Look at the avatar icons next to each person's name and watch them > jump down and to the left ~10 pixiels. > > I'm seeing that on Second Life 2.5.0 (217108) Dec 16 on a Mac, too... I guess we need an issue on it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/9b987908/attachment-0001.htm From merov at lindenlab.com Wed Dec 22 09:37:08 2010 From: merov at lindenlab.com (Merov Linden) Date: Wed, 22 Dec 2010 17:37:08 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules Message-ID: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/ ----------------------------------------------------------- Review request for Viewer and Andrew Meadows. Summary ------- The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. This addresses bug STORM-807. http://jira.secondlife.com/browse/STORM-807 Diffs ----- indra/llcommon/llversionserver.h fc82190a3f0c indra/llcommon/llversionviewer.h fc82190a3f0c indra/llmath/llbbox.h fc82190a3f0c indra/llmath/llbbox.cpp fc82190a3f0c indra/llmessage/llregionflags.h fc82190a3f0c indra/newview/English.lproj/InfoPlist.strings fc82190a3f0c indra/newview/Info-SecondLife.plist fc82190a3f0c indra/newview/llviewermenu.cpp fc82190a3f0c indra/newview/llviewerobject.h fc82190a3f0c indra/newview/llviewerobject.cpp fc82190a3f0c indra/newview/llviewerparceloverlay.h fc82190a3f0c indra/newview/llviewerparceloverlay.cpp fc82190a3f0c indra/newview/llviewerregion.h fc82190a3f0c indra/newview/llviewerregion.cpp fc82190a3f0c indra/newview/res/viewerRes.rc fc82190a3f0c indra/newview/skins/default/xui/en/menu_viewer.xml fc82190a3f0c Diff: http://codereview.secondlife.com/r/56/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/e62ec141/attachment.htm From merov at lindenlab.com Wed Dec 22 09:42:29 2010 From: merov at lindenlab.com (Merov Linden) Date: Wed, 22 Dec 2010 17:42:29 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101222174229.7875.42718@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/#review64 ----------------------------------------------------------- Few things I'd like to see fixed before moving to integration: llversionserver.h : this change is irrelevant to the issue, take out. llversionviewer.h : same llregionflags.h : are all those changes relevant to the issue? I can see the interest of REGION_FLAGS_ALLOW_RETURN_ENCROACHING_OBJECT but what about all the other flags suppressed or commented out? Anything in there changed that shouldn't? InfoPlist.strings : don't change that, let release do this when it's necessary to release a version Info-SecondLife.plist : same viewerRes.rc : same - Merov On 2010-12-22 09:37:08, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/56/ > ----------------------------------------------------------- > > (Updated 2010-12-22 09:37:08) > > > Review request for Viewer and Andrew Meadows. > > > Summary > ------- > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > > This addresses bug STORM-807. > http://jira.secondlife.com/browse/STORM-807 > > > Diffs > ----- > > indra/llcommon/llversionserver.h fc82190a3f0c > indra/llcommon/llversionviewer.h fc82190a3f0c > indra/llmath/llbbox.h fc82190a3f0c > indra/llmath/llbbox.cpp fc82190a3f0c > indra/llmessage/llregionflags.h fc82190a3f0c > indra/newview/English.lproj/InfoPlist.strings fc82190a3f0c > indra/newview/Info-SecondLife.plist fc82190a3f0c > indra/newview/llviewermenu.cpp fc82190a3f0c > indra/newview/llviewerobject.h fc82190a3f0c > indra/newview/llviewerobject.cpp fc82190a3f0c > indra/newview/llviewerparceloverlay.h fc82190a3f0c > indra/newview/llviewerparceloverlay.cpp fc82190a3f0c > indra/newview/llviewerregion.h fc82190a3f0c > indra/newview/llviewerregion.cpp fc82190a3f0c > indra/newview/res/viewerRes.rc fc82190a3f0c > indra/newview/skins/default/xui/en/menu_viewer.xml fc82190a3f0c > > Diff: http://codereview.secondlife.com/r/56/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/78b91164/attachment.htm From Aleric.Inglewood at gmail.com Wed Dec 22 10:45:54 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Wed, 22 Dec 2010 18:45:54 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101222184554.7883.22752@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/#review65 ----------------------------------------------------------- I have the feeling that this notion of 'encroachesOwned' is going to cause a lot of trouble in the case of sculptures. At the very least you should use use an aligned bb that is the minimal bb for anything *visible* of a prim. In the case of the sculptures this requires a special function to find the min/max coordinates of all the points used. The same story holds for path cut-off (mega) prims. Ie, if I resize a megaprim (the ONLY way to resize a mega prim is by using one of those prim torture tricks) then it's very possible one ends up with a prim that is just 1/3 of it's "size". It wouldn't be fair when a house that clearly ends on ones own parcel is "detected" to encroach another parcel, just because the viewer code is too lame to take path cutting and sphere dimples etc into account. - Aleric On 2010-12-22 09:37:08, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/56/ > ----------------------------------------------------------- > > (Updated 2010-12-22 09:37:08) > > > Review request for Viewer and Andrew Meadows. > > > Summary > ------- > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > > This addresses bug STORM-807. > http://jira.secondlife.com/browse/STORM-807 > > > Diffs > ----- > > indra/llcommon/llversionserver.h fc82190a3f0c > indra/llcommon/llversionviewer.h fc82190a3f0c > indra/llmath/llbbox.h fc82190a3f0c > indra/llmath/llbbox.cpp fc82190a3f0c > indra/llmessage/llregionflags.h fc82190a3f0c > indra/newview/English.lproj/InfoPlist.strings fc82190a3f0c > indra/newview/Info-SecondLife.plist fc82190a3f0c > indra/newview/llviewermenu.cpp fc82190a3f0c > indra/newview/llviewerobject.h fc82190a3f0c > indra/newview/llviewerobject.cpp fc82190a3f0c > indra/newview/llviewerparceloverlay.h fc82190a3f0c > indra/newview/llviewerparceloverlay.cpp fc82190a3f0c > indra/newview/llviewerregion.h fc82190a3f0c > indra/newview/llviewerregion.cpp fc82190a3f0c > indra/newview/res/viewerRes.rc fc82190a3f0c > indra/newview/skins/default/xui/en/menu_viewer.xml fc82190a3f0c > > Diff: http://codereview.secondlife.com/r/56/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/8900192e/attachment.htm From liny.odell at phoenixviewer.com Wed Dec 22 10:57:08 2010 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Wed, 22 Dec 2010 10:57:08 -0800 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101222184554.7883.22752@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> <20101222184554.7883.22752@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: Another key point is "simscapes" that use megaprims that obviously covers all parcels but is only visible along the outside of the region along the void. Also, what about prims that are centered in a neiboring region? Are thous detected as encroaching? On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood < Aleric.Inglewood at gmail.com> wrote: > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/56/ > > I have the feeling that this notion of 'encroachesOwned' is going to cause a lot of trouble in the case of sculptures. > At the very least you should use use an aligned bb that is the minimal bb for anything *visible* of a prim. In the case > of the sculptures this requires a special function to find the min/max coordinates of all the points used. The same > story holds for path cut-off (mega) prims. Ie, if I resize a megaprim (the ONLY way to resize a mega prim is > by using one of those prim torture tricks) then it's very possible one ends up with a prim that is just 1/3 of it's "size". > It wouldn't be fair when a house that clearly ends on ones own parcel is "detected" to encroach another parcel, just > because the viewer code is too lame to take path cutting and sphere dimples etc into account. > > > - Aleric > > On December 22nd, 2010, 9:37 a.m., Merov Linden wrote: > Review request for Viewer and Andrew Meadows. > By Merov Linden. > > *Updated 2010-12-22 09:37:08* > Description > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > *Bugs: * STORM-807 > Diffs > > - indra/llcommon/llversionserver.h (fc82190a3f0c) > - indra/llcommon/llversionviewer.h (fc82190a3f0c) > - indra/llmath/llbbox.h (fc82190a3f0c) > - indra/llmath/llbbox.cpp (fc82190a3f0c) > - indra/llmessage/llregionflags.h (fc82190a3f0c) > - indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c) > - indra/newview/Info-SecondLife.plist (fc82190a3f0c) > - indra/newview/llviewermenu.cpp (fc82190a3f0c) > - indra/newview/llviewerobject.h (fc82190a3f0c) > - indra/newview/llviewerobject.cpp (fc82190a3f0c) > - indra/newview/llviewerparceloverlay.h (fc82190a3f0c) > - indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c) > - indra/newview/llviewerregion.h (fc82190a3f0c) > - indra/newview/llviewerregion.cpp (fc82190a3f0c) > - indra/newview/res/viewerRes.rc (fc82190a3f0c) > - indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c) > > View Diff > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/0139b230/attachment-0001.htm From jhwelch at gmail.com Wed Dec 22 11:18:29 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 22 Dec 2010 19:18:29 -0000 Subject: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter In-Reply-To: <20101214150325.18777.52120@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214150325.18777.52120@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101222191829.7889.33025@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/ ----------------------------------------------------------- (Updated 2010-12-22 11:18:28.916125) Review request for Viewer. Changes ------- Aleric showed me a slight optimization in the two function calls I moved to fix this issue. In llagentcamera.cpp: setFocusoOnAvatar(FALSE, FALSE) (was FALSE, TRUE) Summary ------- You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. This addresses bug vwr-20962. http://jira.secondlife.com/browse/vwr-20962 Diffs (updated) ----- indra/newview/llagentcamera.cpp 0a1d00f86446 Diff: http://codereview.secondlife.com/r/16/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/c490d595/attachment.htm From jhwelch at gmail.com Wed Dec 22 11:18:46 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 22 Dec 2010 19:18:46 -0000 Subject: [opensource-dev] Review Request: VWR-20962 CTRL-\ Last chatter In-Reply-To: <20101222191829.7889.33025@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222191829.7889.33025@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101222191846.7891.99533@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/ ----------------------------------------------------------- (Updated 2010-12-22 11:18:45.942539) Review request for Viewer. Summary ------- You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. This addresses bug STORM-785. http://jira.secondlife.com/browse/STORM-785 Diffs ----- indra/newview/llagentcamera.cpp 0a1d00f86446 Diff: http://codereview.secondlife.com/r/16/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/e6cf827a/attachment.htm From andrew at lindenlab.com Wed Dec 22 11:19:49 2010 From: andrew at lindenlab.com (Andrew Meadows) Date: Wed, 22 Dec 2010 11:19:49 -0800 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101222174229.7875.42718@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> <20101222174229.7875.42718@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4D124F55.8010503@lindenlab.com> Merov - Thanks for the review. When I got your email this morning I was in the middle of tracing back those version number changes and fixing them. I picked them up in the very first merge of my outstanding changes, which was just to get my branch up to date before starting work. Both parents of that merge were in the log history, so it isn't clear what happened to the version numbers I picked up. I guess they must have been cleared by by another merge down the line. As to the llregionflags.h changes... In short: yes these are the changes you want. The longer story: The change there reflects the change that has happened in the server version of that file since the two projects split. Most of the change is the cleanup that I did for this project. On the server side we've split the "region flags" into "public" (that get used by both the viewer and server) and "internal" that are only used by the server. Most of the lines that were changed or commented out in llregionflags.h was to to remove unused or "internal" flags. Otherwise I added a couple new public flags that communicate the state of the region's "allow return of encroaching object" feature. I've fixed things. Try again from this repo: http://bitbucket.org/andrew_linden/viewer-development revision = ba6d29a97383 - Andrew On 12/22/2010 09:42 AM, Merov Linden wrote: > This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/ > > > Few things I'd like to see fixed before moving to integration: > llversionserver.h : this change is irrelevant to the issue, take out. > llversionviewer.h : same > llregionflags.h : are all those changes relevant to the issue? I can see the interest of REGION_FLAGS_ALLOW_RETURN_ENCROACHING_OBJECT but what about all the other flags suppressed or commented out? Anything in there changed that shouldn't? > InfoPlist.strings : don't change that, let release do this when it's necessary to release a version > Info-SecondLife.plist : same > viewerRes.rc : same > > > - Merov > > > On December 22nd, 2010, 9:37 a.m., Merov Linden wrote: > > Review request for Viewer and Andrew Meadows. > By Merov Linden. > > /Updated 2010-12-22 09:37:08/ > > > Description > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > *Bugs: * STORM-807 > > > Diffs > > * indra/llcommon/llversionserver.h (fc82190a3f0c) > * indra/llcommon/llversionviewer.h (fc82190a3f0c) > * indra/llmath/llbbox.h (fc82190a3f0c) > * indra/llmath/llbbox.cpp (fc82190a3f0c) > * indra/llmessage/llregionflags.h (fc82190a3f0c) > * indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c) > * indra/newview/Info-SecondLife.plist (fc82190a3f0c) > * indra/newview/llviewermenu.cpp (fc82190a3f0c) > * indra/newview/llviewerobject.h (fc82190a3f0c) > * indra/newview/llviewerobject.cpp (fc82190a3f0c) > * indra/newview/llviewerparceloverlay.h (fc82190a3f0c) > * indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c) > * indra/newview/llviewerregion.h (fc82190a3f0c) > * indra/newview/llviewerregion.cpp (fc82190a3f0c) > * indra/newview/res/viewerRes.rc (fc82190a3f0c) > * indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c) > > View Diff > From jhwelch at gmail.com Wed Dec 22 11:21:04 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 22 Dec 2010 19:21:04 -0000 Subject: [opensource-dev] Review Request: STORM-785 CTRL-\ Last chatter In-Reply-To: <20101222191846.7891.99533@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222191846.7891.99533@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101222192104.7880.25831@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/ ----------------------------------------------------------- (Updated 2010-12-22 11:21:04.403780) Review request for Viewer. Summary (updated) ------- You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. This addresses bug STORM-785. http://jira.secondlife.com/browse/STORM-785 Diffs ----- indra/newview/llagentcamera.cpp 0a1d00f86446 Diff: http://codereview.secondlife.com/r/16/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/9f44aa0a/attachment.htm From andrew at lindenlab.com Wed Dec 22 11:51:17 2010 From: andrew at lindenlab.com (Andrew Meadows) Date: Wed, 22 Dec 2010 11:51:17 -0800 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> <20101222184554.7883.22752@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <4D1256B5.90206@lindenlab.com> A note about the returnable encroachment feature... It introduces a new definition I'm calling "Estate Content". Estate content is stuff owned by the Estate Owner, or an Estate Manager. It is treated differently by the "returnable encroachment" feature, namely in order for Estate Content to be returned there is a special per-region setting that mus be enabled. That is, each region will have two independent settings: allow_return_encroaching_object = true/false allow_return_encroaching_estate_object = true/false The reason for this split is that some estates already use encroachment as a feature, where there are some encroaching content that is considered "public content" such as roads and communal buildings. As to encroaching objects on the mainland... We'll eventually enable return of encroaching objects on the mainland after some private estates have been using it for a while. I expect we'll enable it on a few mainland regions and see how things go, then expand. Some mainland regions use encroachment as a feature and I think we should move a little slowly there until we have a good understanding of how things should be configured for the least damage. After that I suspect we'll enable encroachment return across all of mainland. As to cross-region encroachment, where an object is on one region but sticks into the parcel of another region... Return of cross-region encroaching objects is not supported yet, but we plan to implement it before mesh ships (early 2011). This means "simscape" megaprims will be at risk for encroachment return via neighboring regions. Estate owners can always disable encroachment return if they prefer to protect their simscapes, or they can just make sure their simscapes fall into the Estate Content category. Meanwhile on the mainland I think the returnable encroachment outweighs the simscape megaprim hack so I will push to make the demise of this hack a non-blocker. Eventually I'm sure we can come up with a solution and I hope it is a "real" simscape feature that doesn't rely on really really big megaprims. - Andrew On 12/22/2010 10:57 AM, Liny Odell wrote: > Another key point is "simscapes" that use megaprims that obviously covers all parcels but is only visible along the outside of the region along the void. Also, what about prims that are centered in a neiboring region? Are thous detected as encroaching? > > On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood > wrote: > > This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/ > > > I have the feeling that this notion of'encroachesOwned' is going to cause a lot of trouble in the case of sculptures. > At the very least you should use use an aligned bb that is the minimal bb for anything *visible* of a prim. In the case > of the sculptures this requires a special function to find the min/max coordinates of all the points used. The same > story holds for path cut-off (mega) prims. Ie, if I resize a megaprim (the ONLY way to resize a mega prim is > by using one of those prim torture tricks) then it's very possible one ends up with a prim that is just 1/3 of it's"size". > It wouldn't be fair when a house that clearly ends on ones own parcel is"detected" to encroach another parcel, just > because the viewer code is too lame to take path cutting and sphere dimples etc into account. > > > - Aleric > > > On December 22nd, 2010, 9:37 a.m., Merov Linden wrote: > > Review request for Viewer and Andrew Meadows. > By Merov Linden. > > /Updated 2010-12-22 09:37:08/ > > > Description > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > *Bugs: * STORM-807 > > > Diffs > > * indra/llcommon/llversionserver.h (fc82190a3f0c) > * indra/llcommon/llversionviewer.h (fc82190a3f0c) > * indra/llmath/llbbox.h (fc82190a3f0c) > * indra/llmath/llbbox.cpp (fc82190a3f0c) > * indra/llmessage/llregionflags.h (fc82190a3f0c) > * indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c) > * indra/newview/Info-SecondLife.plist (fc82190a3f0c) > * indra/newview/llviewermenu.cpp (fc82190a3f0c) > * indra/newview/llviewerobject.h (fc82190a3f0c) > * indra/newview/llviewerobject.cpp (fc82190a3f0c) > * indra/newview/llviewerparceloverlay.h (fc82190a3f0c) > * indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c) > * indra/newview/llviewerregion.h (fc82190a3f0c) > * indra/newview/llviewerregion.cpp (fc82190a3f0c) > * indra/newview/res/viewerRes.rc (fc82190a3f0c) > * indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c) > > View Diff > > > _______________________________________________ > 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 > > From stickman at gmail.com Wed Dec 22 11:59:46 2010 From: stickman at gmail.com (Stickman) Date: Wed, 22 Dec 2010 11:59:46 -0800 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <4D1256B5.90206@lindenlab.com> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> <20101222184554.7883.22752@domU-12-31-38-00-90-68.compute-1.internal> <4D1256B5.90206@lindenlab.com> Message-ID: Glad to hear the encroachment issue will be resolved in the near future. I know a lot of people, LL included, have been waiting for this. > Eventually I'm sure we can come up with a solution and I hope it is a "real" > simscape feature that doesn't rely on really really big megaprims. 3D skybox support, perhaps? https://jira.secondlife.com/browse/SVC-4118 Stickman From danielravennest at gmail.com Wed Dec 22 14:08:19 2010 From: danielravennest at gmail.com (Daniel) Date: Wed, 22 Dec 2010 16:08:19 -0600 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: References: Message-ID: <4D1276D3.1080808@gmail.com> Linden Homes intentionally use off-parcel placement of the homes themselves, so that the tenants can use the full 117 prims for their furniture. Have you checked that this encroachment check will not break that setup? On 12/22/2010 12:57 PM, "Merov Linden" wrote: > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. Daniel From andrew at lindenlab.com Wed Dec 22 14:44:29 2010 From: andrew at lindenlab.com (Andrew Meadows) Date: Wed, 22 Dec 2010 14:44:29 -0800 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <4D1276D3.1080808@gmail.com> References: <4D1276D3.1080808@gmail.com> Message-ID: <4D127F4D.40802@lindenlab.com> I don't know the Linden Home stuff well, but it sounds like you're saying that the homes aren't actually owned by the parcel owners themselves. Or else they are self owned but are "placed" in public parcels that are owned by Governor Linden or whoever is the manager of the region/estate. If either of those are true then I think we'll be able to enable the returnable encroachment feature... as long as no homesteader's home encroaches upon a second homesteader's parcel. In short... If a mainland region's content is not compatible with returnable encroachment then I think we'll leave the feature disabled there until the content is made compatible. The simple way to make it compatible is to make sure the stuff that we want to save is owned by Estate Managers, and then only enable return of regular content (not "Estate Content"). - Andrew On 12/22/2010 02:08 PM, Daniel wrote: > Linden Homes intentionally use off-parcel placement of the homes > themselves, so that the tenants can use the full 117 prims for their > furniture. Have you checked that this encroachment check will not break > that setup? > From twisted_laws at hotmail.com Wed Dec 22 16:41:13 2010 From: twisted_laws at hotmail.com (Twisted Laws) Date: Wed, 22 Dec 2010 19:41:13 -0500 Subject: [opensource-dev] cmake issues with latest pull 12/22 - r14261:5d69e36a53ee Message-ID: after pulling these changes, cmake . seems to go into a loop or something and never does anything and never exits on windows 7 (64), vc 2005. is it just me? this is after the social fixes and a lot of checkins from callum if you break it... $ Traceback (most recent call last): File "install.py", line 1150, in sys.exit(main()) File "install.py", line 1142, in main options.scp) File "install.py", line 636, in do_install cache_dir) File "install.py", line 595, in install ifile.fetch_local() File "install.py", line 135, in fetch_local file(self.filename, 'wb').write(urllib2.urlopen(self.url).read()) File "C:\Python26\Lib\socket.py", line 327, in read data = self._sock.recv(rbufsize) File "C:\Python26\lib\httplib.py", line 537, in read s = self.fp.read(amt) File "C:\Python26\Lib\socket.py", line 351, in read data = self._sock.recv(left) KeyboardInterrupt close failed in file object destructor: Error in sys.excepthook: Original exception was: Note there is nothing further printed... so i don't know what the original exception was -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/1396ed20/attachment.htm From Aleric.Inglewood at gmail.com Wed Dec 22 16:47:28 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Thu, 23 Dec 2010 00:47:28 -0000 Subject: [opensource-dev] Review Request: STORM-785 CTRL-\ Last chatter In-Reply-To: <20101222192104.7880.25831@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222192104.7880.25831@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223004728.7870.11539@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/16/#review68 ----------------------------------------------------------- Ship it! I am all happy with it now. - Aleric On 2010-12-22 11:21:04, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/16/ > ----------------------------------------------------------- > > (Updated 2010-12-22 11:21:04) > > > Review request for Viewer. > > > Summary > ------- > > You have to push CTRL-\(there is a menu item for this too) twice to get the last chatter function to work. My fix unlocks the camera before moving it. > > > This addresses bug STORM-785. > http://jira.secondlife.com/browse/STORM-785 > > > Diffs > ----- > > indra/newview/llagentcamera.cpp 0a1d00f86446 > > Diff: http://codereview.secondlife.com/r/16/diff > > > Testing > ------- > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/019b8aed/attachment.htm From aleric.inglewood at gmail.com Wed Dec 22 16:58:15 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Thu, 23 Dec 2010 01:58:15 +0100 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <4D1256B5.90206@lindenlab.com> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> <20101222184554.7883.22752@domU-12-31-38-00-90-68.compute-1.internal> <4D1256B5.90206@lindenlab.com> Message-ID: I have no problems with the intent of returning encroaching objects, but I do with the way encroaching is detected: You should not add this feature when it is in a broken state, and I think it is broken when it will think that objects are encroaching when not even the minimal aligned bounding box of the object is encroaching. I'm not speaking about a mostly transparent tree even, or a L-shaped object at the corner of a parcel. But even, just the simplest and most OBVIOUS ways to drastically decrease the size of mega prims - or just the using cut path on a box. That should be detected - as should the minimal bb for sculpties be more accurately determined imho. On Wed, Dec 22, 2010 at 8:51 PM, Andrew Meadows wrote: > A note about the returnable encroachment feature... > > It introduces a new definition I'm calling "Estate Content". > Estate content is stuff owned by the Estate Owner, or an Estate Manager. > It is treated differently by the "returnable encroachment" feature, > namely in order for Estate Content to be returned there is a special > per-region setting that mus be enabled. > > That is, each region will have two independent settings: > > allow_return_encroaching_object = true/false > allow_return_encroaching_estate_object = true/false > > The reason for this split is that some estates already use encroachment > as a feature, where there are some encroaching content that is considered > "public content" such as roads and communal buildings. > > As to encroaching objects on the mainland... > > We'll eventually enable return of encroaching objects on the mainland > after some private estates have been using it for a while. ?I expect we'll > enable it on a few mainland regions and see how things go, then expand. > > Some mainland regions use encroachment as a feature and I think we should > move a little slowly there until we have a good understanding of how things > should be configured for the least damage. ?After that I suspect we'll > enable encroachment return across all of mainland. > > As to cross-region encroachment, where an object is on one region but sticks > into the parcel of another region... > > Return of cross-region encroaching objects is not supported yet, but we plan > to implement it before mesh ships (early 2011). ?This means "simscape" > megaprims will be at risk for encroachment return via neighboring regions. > > Estate owners can always disable encroachment return if they prefer to > protect > their simscapes, or they can just make sure their simscapes fall into the > Estate Content category. ?Meanwhile on the mainland I think the returnable > encroachment outweighs the simscape megaprim hack so I will push to make the > demise of this hack a non-blocker. > > Eventually I'm sure we can come up with a solution and I hope it is a "real" > simscape feature that doesn't rely on really really big megaprims. > > - Andrew > > > On 12/22/2010 10:57 AM, Liny Odell wrote: >> >> Another key point is "simscapes" that use megaprims that obviously covers >> all parcels but is only visible along the outside of the region along the >> void. Also, what about prims that are centered in a neiboring region? Are >> thous detected as encroaching? >> >> On Wed, Dec 22, 2010 at 10:45 AM, Aleric Inglewood >> > wrote: >> >> ? ?This is an automatically generated e-mail. To reply, visit: >> http://codereview.secondlife.com/r/56/ >> >> >> ? ?I have the feeling that this notion of'encroachesOwned' ?is going to >> cause a lot of trouble in the case of sculptures. >> ? ?At the very least you should use use an aligned bb that is the minimal >> bb for anything *visible* of a prim. In the case >> ? ?of the sculptures this requires a special function to find the min/max >> coordinates of all the points used. The same >> ? ?story holds for path cut-off (mega) prims. Ie, if I resize a megaprim >> (the ONLY way to resize a mega prim is >> ? ?by using one of those prim torture tricks) then it's very possible one >> ends up with a prim that is just 1/3 of it's"size". >> ? ?It wouldn't be fair when a house that clearly ends on ones own parcel >> is"detected" ?to encroach another parcel, just >> ? ?because the viewer code is too lame to take path cutting and sphere >> dimples etc into account. >> >> >> ? ?- Aleric >> >> >> ? ?On December 22nd, 2010, 9:37 a.m., Merov Linden wrote: >> >> ? ?Review request for Viewer and Andrew Meadows. >> ? ?By Merov Linden. >> >> ? ?/Updated 2010-12-22 09:37:08/ >> >> >> ? ? ?Description >> >> ? ?The object-vs-parcel overlap test is done by building axis-aligned >> bounding boxes (AABB) about each prim of the selected objects and then >> checking for overlap between those boxes and self- and group-owned parcels. >> >> ? ?*Bugs: * STORM-807 >> >> >> ? ? ?Diffs >> >> ? ? ? ?* indra/llcommon/llversionserver.h (fc82190a3f0c) >> ? ? ? ?* indra/llcommon/llversionviewer.h (fc82190a3f0c) >> ? ? ? ?* indra/llmath/llbbox.h (fc82190a3f0c) >> ? ? ? ?* indra/llmath/llbbox.cpp (fc82190a3f0c) >> ? ? ? ?* indra/llmessage/llregionflags.h (fc82190a3f0c) >> ? ? ? ?* indra/newview/English.lproj/InfoPlist.strings (fc82190a3f0c) >> ? ? ? ?* indra/newview/Info-SecondLife.plist (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewermenu.cpp (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewerobject.h (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewerobject.cpp (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewerparceloverlay.h (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewerparceloverlay.cpp (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewerregion.h (fc82190a3f0c) >> ? ? ? ?* indra/newview/llviewerregion.cpp (fc82190a3f0c) >> ? ? ? ?* indra/newview/res/viewerRes.rc (fc82190a3f0c) >> ? ? ? ?* indra/newview/skins/default/xui/en/menu_viewer.xml (fc82190a3f0c) >> >> ? ?View Diff >> >> >> ? ?_______________________________________________ >> ? ?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 >> >> > From missannotoole at yahoo.com Wed Dec 22 21:47:39 2010 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 22 Dec 2010 21:47:39 -0800 (PST) Subject: [opensource-dev] What is with the cycling port connections on SLv2.4? In-Reply-To: <4D127F4D.40802@lindenlab.com> References: <4D1276D3.1080808@gmail.com> <4D127F4D.40802@lindenlab.com> Message-ID: <373495.21536.qm@web120514.mail.ne1.yahoo.com> connect disconnect connect 4 times at once disconnect 4 bang bang hammer hammer Dear Oz and Esbee: Run a port monitor and look at what your client is doing. Please. No don't just do it from the office LAN. Hire someone to travel around to different areas of the country to monitor what your client really does. Seriously. Crashiest client ever. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101222/8939cac4/attachment.htm From merov at lindenlab.com Wed Dec 22 22:15:00 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 06:15:00 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL Message-ID: <20101223061500.7865.9735@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). This addresses bug STORM-805. http://jira.secondlife.com/browse/STORM-805 Diffs ----- indra/newview/app_settings/settings.xml 5d69e36a53ee indra/newview/llstartup.cpp 5d69e36a53ee indra/newview/llworldmipmap.cpp 5d69e36a53ee Diff: http://codereview.secondlife.com/r/61/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/4574286d/attachment-0001.htm From merov at lindenlab.com Wed Dec 22 22:43:07 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 06:43:07 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu Message-ID: <20101223064307.7888.97741@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/62/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Unit tests addition: - add tests for llkdu - turned back on and fix unit tests for llimage - turned back on and fix unit tests for llworldmap and llworldmipmap This addresses bug STORM-744. http://jira.secondlife.com/browse/STORM-744 Diffs ----- indra/llimage/CMakeLists.txt 5d69e36a53ee indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee indra/llkdu/CMakeLists.txt 5d69e36a53ee indra/llkdu/llimagej2ckdu.h 5d69e36a53ee indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION indra/newview/CMakeLists.txt 5d69e36a53ee indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee Diff: http://codereview.secondlife.com/r/62/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/c34b16d6/attachment.htm From merov at lindenlab.com Wed Dec 22 23:45:57 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 07:45:57 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223064307.7888.97741@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223064307.7888.97741@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223074557.7875.72371@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/62/ ----------------------------------------------------------- (Updated 2010-12-22 23:45:57.202290) Review request for Viewer. Changes ------- Update from Andrew taking Merov's comments into account Summary ------- Unit tests addition: - add tests for llkdu - turned back on and fix unit tests for llimage - turned back on and fix unit tests for llworldmap and llworldmipmap This addresses bug STORM-744. http://jira.secondlife.com/browse/STORM-744 Diffs (updated) ----- indra/llcommon/llversionviewer.h d8fef72af99e indra/llmath/llbbox.h d8fef72af99e indra/llmath/llbbox.cpp d8fef72af99e indra/llmessage/llregionflags.h d8fef72af99e indra/newview/llviewermenu.cpp d8fef72af99e indra/newview/llviewerobject.h d8fef72af99e indra/newview/llviewerobject.cpp d8fef72af99e indra/newview/llviewerparceloverlay.h d8fef72af99e indra/newview/llviewerparceloverlay.cpp d8fef72af99e indra/newview/llviewerregion.h d8fef72af99e indra/newview/llviewerregion.cpp d8fef72af99e indra/newview/llvoavatar.cpp d8fef72af99e Diff: http://codereview.secondlife.com/r/62/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/2c4f02d0/attachment.htm From merov at lindenlab.com Wed Dec 22 23:47:41 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 07:47:41 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223074557.7875.72371@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223074557.7875.72371@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223074741.7886.28249@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/62/#review70 ----------------------------------------------------------- I don't think there should be any change in indra/llcommon/llversionviewer.h, especially none to reference snowglobe... - Merov On 2010-12-22 23:45:57, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/62/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:45:57) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llcommon/llversionviewer.h d8fef72af99e > indra/llmath/llbbox.h d8fef72af99e > indra/llmath/llbbox.cpp d8fef72af99e > indra/llmessage/llregionflags.h d8fef72af99e > indra/newview/llviewermenu.cpp d8fef72af99e > indra/newview/llviewerobject.h d8fef72af99e > indra/newview/llviewerobject.cpp d8fef72af99e > indra/newview/llviewerparceloverlay.h d8fef72af99e > indra/newview/llviewerparceloverlay.cpp d8fef72af99e > indra/newview/llviewerregion.h d8fef72af99e > indra/newview/llviewerregion.cpp d8fef72af99e > indra/newview/llvoavatar.cpp d8fef72af99e > > Diff: http://codereview.secondlife.com/r/62/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/e9c3388e/attachment.htm From merov at lindenlab.com Wed Dec 22 23:51:18 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 07:51:18 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu Message-ID: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Unit tests addition: - add tests for llkdu - turned back on and fix unit tests for llimage - turned back on and fix unit tests for llworldmap and llworldmipmap This addresses bug STORM-744. http://jira.secondlife.com/browse/STORM-744 Diffs ----- indra/llimage/CMakeLists.txt 5d69e36a53ee indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee indra/llkdu/CMakeLists.txt 5d69e36a53ee indra/llkdu/llimagej2ckdu.h 5d69e36a53ee indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION indra/newview/CMakeLists.txt 5d69e36a53ee indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee Diff: http://codereview.secondlife.com/r/63/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/a3ed629e/attachment.htm From merov at lindenlab.com Wed Dec 22 23:54:01 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 07:54:01 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222173708.7867.87534@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/ ----------------------------------------------------------- (Updated 2010-12-22 23:54:00.934665) Review request for Viewer and Andrew Meadows. Changes ------- Andrew's update with comments from Merov's taken into account Summary ------- The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. This addresses bug STORM-807. http://jira.secondlife.com/browse/STORM-807 Diffs (updated) ----- indra/llcommon/llversionviewer.h d8fef72af99e indra/llmath/llbbox.h d8fef72af99e indra/llmath/llbbox.cpp d8fef72af99e indra/llmessage/llregionflags.h d8fef72af99e indra/newview/llviewermenu.cpp d8fef72af99e indra/newview/llviewerobject.h d8fef72af99e indra/newview/llviewerobject.cpp d8fef72af99e indra/newview/llviewerparceloverlay.h d8fef72af99e indra/newview/llviewerparceloverlay.cpp d8fef72af99e indra/newview/llviewerregion.h d8fef72af99e indra/newview/llviewerregion.cpp d8fef72af99e indra/newview/llvoavatar.cpp d8fef72af99e Diff: http://codereview.secondlife.com/r/56/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/59b50b6f/attachment-0001.htm From merov at lindenlab.com Wed Dec 22 23:54:58 2010 From: merov at lindenlab.com (Merov Linden) Date: Thu, 23 Dec 2010 07:54:58 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223075458.7875.31159@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/#review71 ----------------------------------------------------------- indra/llcommon/llversionviewer.h shouldn't be modified - Merov On 2010-12-22 23:54:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/56/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:54:00) > > > Review request for Viewer and Andrew Meadows. > > > Summary > ------- > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > > This addresses bug STORM-807. > http://jira.secondlife.com/browse/STORM-807 > > > Diffs > ----- > > indra/llcommon/llversionviewer.h d8fef72af99e > indra/llmath/llbbox.h d8fef72af99e > indra/llmath/llbbox.cpp d8fef72af99e > indra/llmessage/llregionflags.h d8fef72af99e > indra/newview/llviewermenu.cpp d8fef72af99e > indra/newview/llviewerobject.h d8fef72af99e > indra/newview/llviewerobject.cpp d8fef72af99e > indra/newview/llviewerparceloverlay.h d8fef72af99e > indra/newview/llviewerparceloverlay.cpp d8fef72af99e > indra/newview/llviewerregion.h d8fef72af99e > indra/newview/llviewerregion.cpp d8fef72af99e > indra/newview/llvoavatar.cpp d8fef72af99e > > Diff: http://codereview.secondlife.com/r/56/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/8cb0b435/attachment.htm From akanevsky at productengine.com Thu Dec 23 01:41:06 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 23 Dec 2010 03:41:06 -0600 Subject: [opensource-dev] Daily Scrum Summary - Wednesday, December 22 Message-ID: Wednesday, December 22, 2010 General Notes ------------------------------ - Merge Monkey of the Day: Oz Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - Merge Monkeying - Produced a test build for Esbee. Emailed opensource-dev about it. - Did quite a bit of code review as well - STORM-807 : enable return encroaching objects : reviewed code, punted back to Andrew for fixing *FUTURE* - STORM-745 : Produce comprehensive perf baseline: Complete that work. - STORM-744 : Add unit tests to llkdu: Create RB now that STORM-151 is integrated. Move to review. *IMPEDIMENTS* - STORM-524 : Waiting for Esbee to review the behavior change before integrating that fix. Please, pretty please :) Oz Linden ------------------------------ *PAST* - Autobuild audits... (almost done) - Wiki updates - Reviews & test builds for Alerics build changes - Office Hour *FUTURE* - Finish autobuild audit *IMPEDIMENTS* - python overdose Q Linden ------------------------------ - OOO - medical Esbee Linden ------------------------------ *PAST* - OOO - Review integration queue - Added a comment about localization to VWR-24275 - Added approval for STORM-785 - Added a comment/question to STORM-387 (haven't approved yet). - Added approval for STORM-411 - Rejected STORM-723 because Open/Details buttons overlap in Object profile - Rejected STORM-737 because you can't create a new folder from the plus button pop-up menu in the Recent tab. *FUTURE* - Review product owner and integration queues - Review Jonathan's work list - Think about what to do with VWR tickets assigned to ProductEngine (I'm thinking we just un-assign these - need to review the tickets first though) - Review proposed change for STORM-398, see if I can get input from Communications PO. - Check on feedback for STORM-236 - Take a look at STORM-529 in viewer-development. - Review STORM-702 *IMPEDIMENTS* - Would like to see a screenshot of the object context menu change in STORM-615 before I approve. - Need clarification about what has been changed in STORM-411. - STORM-713 was added to my list to review, but it looks like it's already been integrated and passed QA. What do you want me to do with it? - STORM-529 was added to my list to review, but it's already been integrated and passed QA. Will have a look on a recent viewer-development build to test. Paul ProductEngine ------------------------------ *PAST* - BUG STORM-372 ("Start at" values are not identical in the Preference and in the bottom drop down menu) - WIP. Faced with rather confusing logic used for implementing this behavior. I think tomorrow it'll take no more than 2 hours to finish. *FUTURE* - BUG STORM-372 ("Start at" values are not identical in the Preference and in the bottom drop down menu) - Other tickets by priority *IMPEDIMENTS* - None Seth Productengine ------------------------------ *PAST* - TASK (STORM-797) Parcel SLURL rendering - Investigating. Parcel name retrieving should be moved to llui or other library so that it can be used by SLURL rendering. Couldn't find a solution to resolve parcel names in llui library where no agent and region information is available. *FUTURE* - TASK (STORM-797) Parcel SLURL rendering - Investigate if there is a solution to implement this feature or a workaround, if not, moving to other issues. *IMPEDIMENTS* - None Andrew Productengine ------------------------------ - OOO - sick Vadim Productengine ------------------------------ *PAST* - Story STORM-453 (Upgrade libcurl to 7.21.1): - Reviewed and tested Merov's patch. - Bug STORM-806 (External script editor doesn't work for inventory scripts): - Posted and started working on. *FUTURE* - Bug STORM-806: ETA 1d. *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - test plans design & refactoring: - External Script Editor TP designed - Build Tools in progress - Gestures designed - Nearby Chat in progress - verified ten integrated tickets *FUTURE* - proceed with TP design *IMPEDIMENTS* - None Jonathan Yap ------------------------------ *PAST* - Read jira feedback on STORM-723 (Inspecting single prim objects doesn't work in Viewer 2) - To handle this issue of the Details button overlaying the Open button created VWR-24275 (Make bottom buttons in Object Profile identical for single and multi-prim objects) - I tried setting my viewer language to all the available ones and it looks like all 4 bottom buttons will fit. - Discussion of STORM-737 (Inventory Recent tab is missing "+" control at bottom of panel) at Esbee's OH. - Decision reached on how to proceed in the short term -- grey out New Folder option. - Applied and tested patch for STORM-466 (minimap cannot be reset to default zoom) and uploaded repo to https://bitbucket.org/JonathanYap/storm-466 - Uploaded better named screen shot for STORM-615 (Reorganize right click Build menu so Delete is at the top level) per Esbee's request. *FUTURE* - STORM - 723 (Inspecting single prim objects doesn't work in Viewer 2) - STORM - 737 (Inventory Recent tab) *IMPEDIMENTS* - none - -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/dc52ee64/attachment-0001.htm From zabb65 at gmail.com Thu Dec 23 04:09:14 2010 From: zabb65 at gmail.com (Zabb65) Date: Thu, 23 Dec 2010 07:09:14 -0500 Subject: [opensource-dev] What is with the cycling port connections on SLv2.4? In-Reply-To: <373495.21536.qm@web120514.mail.ne1.yahoo.com> References: <4D1276D3.1080808@gmail.com> <4D127F4D.40802@lindenlab.com> <373495.21536.qm@web120514.mail.ne1.yahoo.com> Message-ID: This is one of the most confusing posts I've seen in ages. Would you like to provide some technical detail of what you see happening, and what you EXPECT to happen? On Thu, Dec 23, 2010 at 00:47, Ann Otoole wrote: > connect disconnect connect 4 times at once disconnect 4 bang bang hammer > hammer > > Dear Oz and Esbee: Run a port monitor and look at what your client is doing. > > Please. No don't just do it from the office LAN. Hire someone to travel > around to different areas of the country to monitor what your client really > does. Seriously. Crashiest client ever. > > > _______________________________________________ > 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 > From oz at lindenlab.com Thu Dec 23 04:12:45 2010 From: oz at lindenlab.com (Oz Linden) Date: Thu, 23 Dec 2010 12:12:45 -0000 Subject: [opensource-dev] Review Request: Update returnability of objects based on new encroachment rules In-Reply-To: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223075401.7867.83626@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223121245.7868.8586@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/56/#review73 ----------------------------------------------------------- indra/llcommon/llversionviewer.h This is wrong - com.secondlife.indra.viewer is correct. indra/llmessage/llregionflags.h shouldn't these lines just be deleted? commented out code is confusing indra/llmessage/llregionflags.h delete? indra/llmessage/llregionflags.h delete indra/llmessage/llregionflags.h why add commented out code? indra/llmessage/llregionflags.h delete indra/newview/llviewerregion.h please add doxygen-style comments - Oz On 2010-12-22 23:54:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/56/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:54:00) > > > Review request for Viewer and Andrew Meadows. > > > Summary > ------- > > The object-vs-parcel overlap test is done by building axis-aligned bounding boxes (AABB) about each prim of the selected objects and then checking for overlap between those boxes and self- and group-owned parcels. > > > This addresses bug STORM-807. > http://jira.secondlife.com/browse/STORM-807 > > > Diffs > ----- > > indra/llcommon/llversionviewer.h d8fef72af99e > indra/llmath/llbbox.h d8fef72af99e > indra/llmath/llbbox.cpp d8fef72af99e > indra/llmessage/llregionflags.h d8fef72af99e > indra/newview/llviewermenu.cpp d8fef72af99e > indra/newview/llviewerobject.h d8fef72af99e > indra/newview/llviewerobject.cpp d8fef72af99e > indra/newview/llviewerparceloverlay.h d8fef72af99e > indra/newview/llviewerparceloverlay.cpp d8fef72af99e > indra/newview/llviewerregion.h d8fef72af99e > indra/newview/llviewerregion.cpp d8fef72af99e > indra/newview/llvoavatar.cpp d8fef72af99e > > Diff: http://codereview.secondlife.com/r/56/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/70da4c9e/attachment.htm From aleric.inglewood at gmail.com Thu Dec 23 04:13:56 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Thu, 23 Dec 2010 13:13:56 +0100 Subject: [opensource-dev] Review Request: STORM-807 update returnability of objects based on new encroachment rules In-Reply-To: <4D115940.9040001@lindenlab.com> References: <4D115940.9040001@lindenlab.com> Message-ID: The attachment to this post, of > 2.5 MB, caused my firewall PC to overload while trying to determine if it is spam, spamd to time out and "temporarily" reject the mail, which caused google to try to deliver it over and over again (27 times so far). I'd like to request that large attachments are not attached, but instead just provide a link to them (upload them to the jira, say). On Wed, Dec 22, 2010 at 2:49 AM, Andrew Meadows wrote: > I've added a feature to the SL simulator that allows encroaching (*) objects > to be returned. ?The ETA for this is sometime in early 2011 (probably > January) > and I'll be adding some wiki documentation about the returnability of > encroaching > objects soon. ?In the meantime I've added viewer-side UI support for > returning > encroaching objects. ?It should not hurt the viewer to add these changes > before > the server stuff is deployed. > > Here is the merge-request jira: > > ?https://jira.secondlife.com/browse/STORM-807 > > The changes can be pulled from here: > > ?http://bitbucket.org/andrew_linden/viewer-development > > The diff is attached. > > - Andrew > > (*) Encroaching objects are "positioned" on one person's land parcel > but nevertheless extend part of themselves into a neighbor's parcel. > > _______________________________________________ > 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 > From wolfpup67 at earthlink.net Thu Dec 23 04:42:19 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 23 Dec 2010 07:42:19 -0500 Subject: [opensource-dev] Review Request: STORM-807 update returnability of objects based on new encroachment rules In-Reply-To: References: <4D115940.9040001@lindenlab.com> Message-ID: <003c01cba29e$d66c5ef0$83451cd0$@net> I wondered about that myself, although I was not going to say a thing since it was a Linden that did it. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Aleric Inglewood Sent: Thursday, December 23, 2010 7:14 AM To: Andrew Meadows Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Review Request: STORM-807 update returnability of objects based on new encroachment rules The attachment to this post, of > 2.5 MB, caused my firewall PC to overload while trying to determine if it is spam, spamd to time out and "temporarily" reject the mail, which caused google to try to deliver it over and over again (27 times so far). I'd like to request that large attachments are not attached, but instead just provide a link to them (upload them to the jira, say). On Wed, Dec 22, 2010 at 2:49 AM, Andrew Meadows wrote: > I've added a feature to the SL simulator that allows encroaching (*) objects > to be returned. The ETA for this is sometime in early 2011 (probably > January) > and I'll be adding some wiki documentation about the returnability of > encroaching > objects soon. In the meantime I've added viewer-side UI support for > returning > encroaching objects. It should not hurt the viewer to add these changes > before > the server stuff is deployed. > > Here is the merge-request jira: > > https://jira.secondlife.com/browse/STORM-807 > > The changes can be pulled from here: > > http://bitbucket.org/andrew_linden/viewer-development > > The diff is attached. > > - Andrew > > (*) Encroaching objects are "positioned" on one person's land parcel > but nevertheless extend part of themselves into a neighbor's parcel. > > _______________________________________________ > 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1170 / Virus Database: 1435/3332 - Release Date: 12/22/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/3b23bd66/attachment.htm From vsavchuk at productengine.com Thu Dec 23 05:16:08 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 23 Dec 2010 13:16:08 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL In-Reply-To: <20101223061500.7865.9735@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223061500.7865.9735@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/#review76 ----------------------------------------------------------- Looks good overall, I only have a minor point. indra/newview/llstartup.cpp Frankly speaking, I'm not a fan of adding another setting to only use it as a global variable. I would search for a more proper way, maybe adding get/setMapServerURL() methods to LLWorldMap. Perhaps a person more familiar with the world map code than me would suggest a better approach. - Vadim On 2010-12-22 22:15:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/61/ > ----------------------------------------------------------- > > (Updated 2010-12-22 22:15:00) > > > Review request for Viewer. > > > Summary > ------- > > Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). > > > This addresses bug STORM-805. > http://jira.secondlife.com/browse/STORM-805 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 5d69e36a53ee > indra/newview/llstartup.cpp 5d69e36a53ee > indra/newview/llworldmipmap.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/61/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/1d967d91/attachment.htm From vsavchuk at productengine.com Thu Dec 23 06:46:09 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Thu, 23 Dec 2010 14:46:09 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223144609.7882.38745@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/#review79 ----------------------------------------------------------- Ship it! No reason not to submit. :-) indra/llkdu/llimagej2ckdu.h Please add a comment that these methods aren't actually public, i.e. were made public only to be called from unit tests. indra/llkdu/tests/llimagej2ckdu_test.cpp What about calling protected methods via inheritance? indra/llkdu/tests/llimagej2ckdu_test.cpp I suppose unit tests should verify something more substantial than not raising exceptions for empty data. - Vadim On 2010-12-22 23:51:18, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/63/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:51:18) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llimage/CMakeLists.txt 5d69e36a53ee > indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee > indra/llkdu/CMakeLists.txt 5d69e36a53ee > indra/llkdu/llimagej2ckdu.h 5d69e36a53ee > indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION > indra/newview/CMakeLists.txt 5d69e36a53ee > indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee > indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/63/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/c0b68988/attachment-0001.htm From oz at lindenlab.com Thu Dec 23 07:21:36 2010 From: oz at lindenlab.com (Oz Linden) Date: Thu, 23 Dec 2010 15:21:36 -0000 Subject: [opensource-dev] Review Request: (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations In-Reply-To: <20101220214720.4669.56543@domU-12-31-38-00-90-68.compute-1.internal> References: <20101220214720.4669.56543@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223152136.7885.63565@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/32/#review80 ----------------------------------------------------------- As noted below, it would be more efficient to do the translation from the glob expression just once in the constructor rather than on each call to the next method. The constructor should then throw an exception for an invalid glob expression. indra/llvfs/lldiriterator.h Why not use '^' for the negation qualifier here? It's more familiar (at least to unix users) indra/llvfs/lldiriterator.cpp It would be better to make the boost::regex a member variable - rather than translate the mask to a regex on every call to next, translate it once in the constructor. indra/llvfs/lldiriterator.cpp There should be a unit test for this translation. indra/llvfs/lldiriterator.cpp This method of tracking escapes and brackets isn't quite correct, I think... consider translating a string input containing an escaped backslash or an escaped bracket. - Oz On 2010-12-20 13:47:20, Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/32/ > ----------------------------------------------------------- > > (Updated 2010-12-20 13:47:20) > > > Review request for Viewer. > > > Summary > ------- > > Fixed LLDir unit test which failed for some complex wildcard combinations. > Added a class implementing directory entries iteration with pattern matching which is used in unit tests instead of LLDir::getNextFileInDir. > > This code has been run on Linux only. It should be tested under other platforms and more test cases should be provided. For example changing directory contents while iterating through it. > > > This addresses bug STORM-550. > http://jira.secondlife.com/browse/STORM-550 > > > Diffs > ----- > > indra/cmake/Boost.cmake 794ad1fc71d1 > indra/llvfs/CMakeLists.txt 794ad1fc71d1 > indra/llvfs/lldiriterator.h PRE-CREATION > indra/llvfs/lldiriterator.cpp PRE-CREATION > indra/llvfs/tests/lldir_test.cpp 794ad1fc71d1 > > Diff: http://codereview.secondlife.com/r/32/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/c41b3fc2/attachment.htm From oz at lindenlab.com Thu Dec 23 07:46:15 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 23 Dec 2010 10:46:15 -0500 Subject: [opensource-dev] What is with the cycling port connections on SLv2.4? In-Reply-To: References: <4D1276D3.1080808@gmail.com> <4D127F4D.40802@lindenlab.com> <373495.21536.qm@web120514.mail.ne1.yahoo.com> Message-ID: <4D136EC7.3020000@lindenlab.com> On 2010-12-23 7:09, Zabb65 wrote: > This is one of the most confusing posts I've seen in ages. Would you > like to provide some technical detail of what you see happening, and > what you EXPECT to happen? But it does serve as an excellent example of a problem report that's high on emotional content and almost completely lacking in actionable data. For others that might be tempted to imitate this style of problem report either here or elsewhere: be aware that a typical developer might finish reading it (this one was at least short), but will almost certainly just ignore it. In particular, taunting the developer to "do this and see what happens" almost never gets useful results. If you want a developer to actually act on a problem report, specific information is key. I highly recommend this essay on the subject: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html From twisted_laws at hotmail.com Thu Dec 23 07:55:26 2010 From: twisted_laws at hotmail.com (Twisted Laws) Date: Thu, 23 Dec 2010 10:55:26 -0500 Subject: [opensource-dev] cmake issues with latest pull 12/22 - r14261:5d69e36a53ee In-Reply-To: References: Message-ID: i'm guessing the file it wanted to download (llqtwebkit) just wasn't available at the time and it blocked for some reason. works fine today. sorry for the interruption orig: after pulling these changes, cmake . seems to go into a loop or something and never does anything and never exits on windows 7 (64), vc 2005. is it just me? this is after the social fixes and a lot of checkins from callum -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/2faff30d/attachment-0001.htm From oz at lindenlab.com Thu Dec 23 12:01:27 2010 From: oz at lindenlab.com (Oz Linden) Date: Thu, 23 Dec 2010 20:01:27 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223144609.7882.38745@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223144609.7882.38745@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223200127.7889.51236@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 06:46:09, Vadim ProductEngine wrote: > > indra/llkdu/llimagej2ckdu.h, line 58 > > > > > > Please add a comment that these methods aren't actually public, i.e. were made public only to be called from unit tests. A better way to make internals available to a unit test is to make the unit test class a friend of the class it is testing. This makes the intent clear, and leaves object internals properly hidden. - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/#review79 ----------------------------------------------------------- On 2010-12-22 23:51:18, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/63/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:51:18) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llimage/CMakeLists.txt 5d69e36a53ee > indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee > indra/llkdu/CMakeLists.txt 5d69e36a53ee > indra/llkdu/llimagej2ckdu.h 5d69e36a53ee > indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION > indra/newview/CMakeLists.txt 5d69e36a53ee > indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee > indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/63/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/c7cd6216/attachment.htm From jhwelch at gmail.com Thu Dec 23 12:12:40 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 23 Dec 2010 20:12:40 -0000 Subject: [opensource-dev] Review Request: VWR-24100 Settings.xml: redundant entries and unnecessary tag In-Reply-To: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> References: <20101214203934.18743.48017@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101223201240.7867.22247@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/18/ ----------------------------------------------------------- (Updated 2010-12-23 12:12:39.928040) Review request for Viewer. Summary (updated) ------- I wrote two programs that use settings.xml to produce this massive table: http://wiki.secondlife.com/wiki/Debug_Settings While doing this I found 4 places with duplicate entries and 1 entry that is repeated 4 times. There is also a pair of unnecessary tags. Having these cleaned out would make running my program, and thus updating the wiki table, easier. I've erased all but the last entry for these redundant debug settings. This addresses bug vwr-24100. http://jira.secondlife.com/browse/vwr-24100 Diffs ----- indra/newview/app_settings/settings.xml 46a990f8296f Diff: http://codereview.secondlife.com/r/18/diff Testing ------- Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/5945eb8a/attachment.htm From akanevsky at productengine.com Thu Dec 23 12:22:38 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 23 Dec 2010 14:22:38 -0600 Subject: [opensource-dev] Daily Scrum Summary - Thursday, December 23 Message-ID: Thursday, December 23, 2010 General Notes ------------------------------ - Merry Christmas where applies! - Merge Monkey of the Day: Merov Team Status ------------------------------ Merov Linden ------------------------------ *PAST* - Merge Monkeying : Massive amount of new code coming from Linden teams: - STORM-808 : Upgrade Qt to 4.7.1 (integration request) : Worked with Callum on this. Code review, test builds, push. - STORM-810 : Auto update and related changes (integration request) : Code review, test builds, test locally, push. - STORM-807 : Allow return of encroaching objects : Back and forth with Andrew. Not ready for integration yet. - STORM-744 : Add unit tests to llkdu: Created RB, moved to review, tried TC cycle but failed. *FUTURE* - STORM-744 : Add unit tests to llkdu: Fix build - STORM-745 : Produce comprehensive perf baseline: Complete that work. *IMPEDIMENTS* - none Oz Linden ------------------------------ *PAST* - finished autobuild audit - several code reviews - Enhanced open douce contribution stats generator *FUTURE* - catch up on more reviews - improve review process docs on wiki *IMPEDIMENTS* - none Q Linden ------------------------------ - OOO Esbee Linden ------------------------------ - OOO Paul ProductEngine ------------------------------ *PAST* - BUG STORM-438 (My inventory floater is not restored if it was minimized and 'Open Attachment' button was pressed in the Group Profile.) - Fixed and pushed to the bitbucket. Found bug in yesterday's fix and re-fixed. - BUG STORM-372 ("Start at" values are not identical in the Preference and in the bottom drop down menu) - Worked on bug and after discussions was decided to resolve as Won't fix. Not sure that this is a bug. - BUG STORM-721 (Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs) - WIP. Investigating. Seems that the reason is in LLTextBase. If won't fix it in some hours will reassign to AD as he is more familiar with LLTextBase. *FUTURE* - BUG STORM-721 (Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs) - Other tickets by priority *IMPEDIMENTS* - None Seth Productengine ------------------------------ *PAST* - TASK (STORM-797) Parcel SLURL rendering - WIP. Temporary moved parcel name retrieving to llui. Should be moved to llmessage if dependencies could be resolved. Working on parcel SLURL class to handle parcel name resolving from parcel ID. *FUTURE* - TASK (STORM-797) Parcel SLURL rendering. Est - 1 day. *IMPEDIMENTS* - None Andrew Productengine ------------------------------ *PAST* - Normal task STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be). - Changed implementation according to Q's comment. I hope Esbee can take a look at it. It?s already codereviewed, and she?s looked at it before, so now only the small change remains to be reviewed. - Normal task 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). - Continuing work. Progress today is small, cause most of time was spent on STORM-34. *FUTURE* - STORM-2. Taking into account implementation of newly designed UI estimate is about 3-4 days. *IMPEDIMENTS* - None Vadim Productengine ------------------------------ *PAST* - Bug ST4ORM-806 (External script editor doesn't work for inventory scripts): - Fixed. *FUTURE* - Bug STORM-682 (IM and notification toasts appear in wrong position if switch on mouse look when sidetray is expanded). *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 Andrey Productengine ------------------------------ *PAST* - test plans design & refactoring: - External Script Editor TP designed - Build Tools in progress - Gestures designed - Nearby Chat in progress - verified ten integrated tickets *FUTURE* - proceed with TP design *IMPEDIMENTS* - None Jonathan Yap ------------------------------ *PAST* - VWR-24275 (Make bottom buttons in Object Profile identical for single and multi-prim objects) Work done, needs testing. You will now always see Open, Pay, Buy, and Details. Maybe this should be brought into STORM- too. [This is needed by STORM-723] - STORM-737 (Inventory Recent tab is missing "+" control at bottom of panel) *FUTURE* - STORM - 737 *IMPEDIMENTS* - VWR - 24275 needs to be assigned to me so I can update the jira. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/367370d2/attachment-0001.htm From jhwelch at gmail.com Thu Dec 23 13:25:31 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Thu, 23 Dec 2010 21:25:31 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent Message-ID: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This change enables the "+" menu in Inventory/Recent It grays out "New Folder" in this menu It enables identical menu entries when you right click on an inventory item. Question: Is graying out "New Folder" best done where I am doing it now -- in llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() This addresses bug storm-737. http://jira.secondlife.com/browse/storm-737 Diffs ----- doc/contributions.txt e843e274fa58 indra/newview/llinventorybridge.cpp e843e274fa58 indra/newview/llpanelmaininventory.cpp e843e274fa58 Diff: http://codereview.secondlife.com/r/65/diff Testing ------- I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. I then changed to the Recent tab and performed the same steps. New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/a9edd358/attachment.htm From angel_of_crimson at hotmail.com Thu Dec 23 15:23:48 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Thu, 23 Dec 2010 18:23:48 -0500 Subject: [opensource-dev] Christmas wishes and thank yous Message-ID: I hope you all will forgive me for going off topic for two minutes. First I want to say Thank You to everyone who is a part in one way or another of the Opensource/Snowstorm community. Ive seen amazing things happen this year as a result of your hard work, and while not everything I hoped to see accomplished has been or will be, I can still look back on the past several months and say what was accomplished is amazing. Secondly, and perhaps most importantly, for those of you that Celebrate Christmas I pray yours is blessed, safe, and joyous. For those that don't celebrate Christmas, I hope whatever holidays you do celebrate this season are equally joyous, safe, and blessed. See you all after the holidays if not before. Erin aka Cummere (the brat) Mayo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101223/8e29cabe/attachment.htm From merov at lindenlab.com Thu Dec 23 16:23:35 2010 From: merov at lindenlab.com (Merov Linden) Date: Fri, 24 Dec 2010 00:23:35 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223144609.7882.38745@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223144609.7882.38745@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224002335.7870.65877@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 06:46:09, Vadim ProductEngine wrote: > > indra/llkdu/tests/llimagej2ckdu_test.cpp, line 193 > > > > > > What about calling protected methods via inheritance? IIRC the tut framework (used to create unit tests) prevents that to be done. > On 2010-12-23 06:46:09, Vadim ProductEngine wrote: > > indra/llkdu/tests/llimagej2ckdu_test.cpp, lines 200-203 > > > > > > I suppose unit tests should verify something more substantial than not raising exceptions for empty data. Frustrating I know and not enough to truly test the implementation. Unit tests though are supposed to stay "pure" and test only that the public API calls are always safe even in an "empty" environment. To do more, I should be creating "Integration tests". We also use tut for that and I'm planning to do that next. > On 2010-12-23 06:46:09, Vadim ProductEngine wrote: > > indra/llkdu/llimagej2ckdu.h, line 58 > > > > > > Please add a comment that these methods aren't actually public, i.e. were made public only to be called from unit tests. > > Oz Linden wrote: > A better way to make internals available to a unit test is to make the unit test class a friend of the class it is testing. This makes the intent clear, and leaves object internals properly hidden. I don't like this too much for 2 reasons: 1. It requires to forward declare the test classes and makes them a special class having access to all the internal machinery of the tested class. One can argue that it is a good thing but I find this a bit unclean. The unit tests is an opportunity to test the public API of a class in a "context free" way and should stay that way. With that in mind, revisiting a class to put "public" what should be its API with the world is not bad, in that case at least. 2. The whole tut templating machinery makes that declaration actually pretty hard. In truth, I haven't been able to identify one existing unit test doing this. - Merov ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/#review79 ----------------------------------------------------------- On 2010-12-22 23:51:18, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/63/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:51:18) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llimage/CMakeLists.txt 5d69e36a53ee > indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee > indra/llkdu/CMakeLists.txt 5d69e36a53ee > indra/llkdu/llimagej2ckdu.h 5d69e36a53ee > indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION > indra/newview/CMakeLists.txt 5d69e36a53ee > indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee > indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/63/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/61e2b260/attachment.htm From Aleric.Inglewood at gmail.com Thu Dec 23 17:29:10 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 24 Dec 2010 01:29:10 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224012910.7887.87696@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/#review78 ----------------------------------------------------------- Huh - I wrote this a long time ago (before the others commented)... apparently I forgot to click on "Publish Review"! indra/llkdu/llimagej2ckdu.h This feels wrong. Those functions are implementations of the base class interface, they are called by the base class: if they need to be called directly, something is wrong. If this is made public because the unit test needs access, then instead add a friend for the unit test class. - Aleric On 2010-12-22 23:51:18, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/63/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:51:18) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llimage/CMakeLists.txt 5d69e36a53ee > indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee > indra/llkdu/CMakeLists.txt 5d69e36a53ee > indra/llkdu/llimagej2ckdu.h 5d69e36a53ee > indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION > indra/newview/CMakeLists.txt 5d69e36a53ee > indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee > indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/63/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/3898267b/attachment-0001.htm From Aleric.Inglewood at gmail.com Thu Dec 23 17:30:55 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 24 Dec 2010 01:30:55 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101224012910.7887.87696@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224012910.7887.87696@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224013055.7891.26399@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 17:29:10, Aleric Inglewood wrote: > > indra/llkdu/llimagej2ckdu.h, line 58 > > > > > > This feels wrong. Those functions are implementations of the base class interface, they are called by the base class: if they need to be called directly, something is wrong. > > > > If this is made public because the unit test needs access, then instead add a friend for the unit test class. > > After reading the other comments, I had to add that accessing them by inheritance would definitely be more clean. - Aleric ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/#review78 ----------------------------------------------------------- On 2010-12-22 23:51:18, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/63/ > ----------------------------------------------------------- > > (Updated 2010-12-22 23:51:18) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llimage/CMakeLists.txt 5d69e36a53ee > indra/llimage/tests/llimageworker_test.cpp 5d69e36a53ee > indra/llkdu/CMakeLists.txt 5d69e36a53ee > indra/llkdu/llimagej2ckdu.h 5d69e36a53ee > indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION > indra/newview/CMakeLists.txt 5d69e36a53ee > indra/newview/tests/llworldmap_test.cpp 5d69e36a53ee > indra/newview/tests/llworldmipmap_test.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/63/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/fd5659d0/attachment.htm From kow at sapinski.com Thu Dec 23 22:16:30 2010 From: kow at sapinski.com (k\o\w) Date: Fri, 24 Dec 2010 01:16:30 -0500 Subject: [opensource-dev] What happened to Joe Linden? Message-ID: <4D143ABE.80106@sapinski.com> I just noticed that Joe Miller was stealthily removed from the Linden Management page within the last week. Anyone know what happened to Joe? Who is the new/interim VP of Technology & Platform development? If Joe has indeed left the lab, he'll be greatly missed! He was one of the few managers at Linden who really understood the technology and would reignite my confidence in the company when he participated in the sl dev discussions. From tateru at taterunino.net Thu Dec 23 23:20:50 2010 From: tateru at taterunino.net (Tateru Nino) Date: Fri, 24 Dec 2010 18:20:50 +1100 Subject: [opensource-dev] What happened to Joe Linden? In-Reply-To: <4D143ABE.80106@sapinski.com> References: <4D143ABE.80106@sapinski.com> Message-ID: <4D1449D2.7080303@taterunino.net> Not the right place to ask. Joe's left, that's all I know at the moment: http://bit.ly/e3JsjY On 24/12/2010 5:16 PM, k\o\w wrote: > I just noticed that Joe Miller was stealthily removed from the Linden > Management page within the last week. > > Anyone know what happened to Joe? Who is the new/interim VP of > Technology& Platform development? > > If Joe has indeed left the lab, he'll be greatly missed! He was one of > the few managers at Linden who really understood the technology and > would reignite my confidence in the company when he participated in the > sl dev discussions. > _______________________________________________ > 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 > -- Tateru Nino http://dwellonit.taterunino.net/ From opensourceobscure at gmail.com Fri Dec 24 00:53:40 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Fri, 24 Dec 2010 09:53:40 +0100 Subject: [opensource-dev] Daily Scrum Summary - Thursday, December 23 In-Reply-To: References: Message-ID: On Thu, Dec 23, 2010 at 21:22, Anya Kanevsky wrote: > Thursday, December 23, 2010 > TASK (STORM-797) Parcel SLURL rendering > > WIP. Temporary moved parcel name retrieving to llui. Should be moved to > llmessage if dependencies could be resolved. Working on parcel SLURL class > to handle parcel name resolving from parcel ID. > > FUTURE > > TASK (STORM-797) Parcel SLURL rendering. Est - 1 day. This sounds interesting. What would become possible if this will be implemented? Something that drives me crazy is I can't create a landmark of a place without going there. IIRC this behaviour can't be improved. It would be awesome if I could copy a SLURL from my web browser, then paste it into my Inventory and then (later) click it to teleport there. Opensource Obscure From vsavchuk at productengine.com Fri Dec 24 02:03:43 2010 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Fri, 24 Dec 2010 12:03:43 +0200 Subject: [opensource-dev] Daily Scrum Summary - Thursday, December 23 In-Reply-To: References: Message-ID: On Fri, Dec 24, 2010 at 10:53 AM, Opensource Obscure < opensourceobscure at gmail.com> wrote: > On Thu, Dec 23, 2010 at 21:22, Anya Kanevsky > wrote: > > Thursday, December 23, 2010 > > > TASK (STORM-797) Parcel SLURL rendering > > > > WIP. Temporary moved parcel name retrieving to llui. Should be moved to > > llmessage if dependencies could be resolved. Working on parcel SLURL > class > > to handle parcel name resolving from parcel ID. > > > > FUTURE > > > > TASK (STORM-797) Parcel SLURL rendering. Est - 1 day. > > This sounds interesting. What would become possible if this > will be implemented? > Rendering SLURLs like secondlife:///app/parcel/*UUID*/about into human-readable strings. See https://jira.secondlife.com/browse/STORM-797 > Something that drives me crazy is I can't create a landmark > of a place without going there. IIRC this behaviour can't be improved. > It would be awesome if I could copy a SLURL from my web browser, > then paste it into my Inventory and then (later) click it to teleport > there. > Do you mean creating a landmark in your inventory by pasting a SLURL? I'm not sure that's possible: AFAIR, to create a landmark we perform a request to the server, which creates landmark of the current location in our inventory. The protocol doesn't support remote locations. -- Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/99fed326/attachment.htm From opensourceobscure at gmail.com Fri Dec 24 03:17:21 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Fri, 24 Dec 2010 12:17:21 +0100 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") Message-ID: On Fri, Dec 24, 2010 at 11:03, Vadim Savchuk wrote: > Do you mean creating a landmark in your inventory by pasting a SLURL? > I'm not sure that's possible: AFAIR, to create a landmark we perform a > request to the server, which creates landmark of the current location in our > inventory. The protocol doesn't support remote locations. sorry, I was not clear (ouch, my English!) What you described is exactly the problem I have with landmarks. Having to teleport somewhere to get a landmark can be a PITA. I remember LL confirmed there are no workarounds for this (as you said, it's a protocol limitation). What I was thinking about was a new, different way to achieve something we usually achieve through landmarks.. (find a place in our Inventory + teleport there + optionally share that place reference with other users) ..a way that could avoid that very limitation you mentioned (the need to be in a place in order to create a landmark). In the past I often didn't use landmarks - instead I copied SLURLs from web pages and paste them into local chat, then click over the links, then teleport. Thanks to some new features, this is now less useful than in the past - but I think some 1.x viewers users still do this. Going through local chat is clearly lame, and confusing for people around you. That's why I said I would like to "copy/paste" a SLURL into Inventory, create (not a landmark) and then clickit to teleport. I'm thinking about management of Bookmarks in current main web browsers, where you're allowed to edit both name and destination of a bookmark, tag it, assign to multiple folders (or tags). Does this make sense to anyone here? Opensource Obscure From carlo at alinoe.com Fri Dec 24 04:49:11 2010 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 24 Dec 2010 13:49:11 +0100 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") In-Reply-To: References: Message-ID: <20101224124911.GA11590@alinoe.com> I can't believe that it isn't possible to create a LM without going there, precisely for this reason. What LL might really mean is that they can't check if it's allowed to *create* a LM without going there first. So, it's a permission problem. But, since there clearly is a way to attempt to go anywhere (by using the map, or an slurl) that whole 'permission' thing is flawed. It's meaningless. I used to have a sim and I didn't allow people to create a LM (I only wanted them to there when I (or another resident) actually was there, and invited them over. However, once they got (group) access, they came anyway, without being invited... I asked how, and they said: simple, I clicked on the map. The problem here is therefore (imho): LL needs to understand it is impossible to control whether or not someone creates a LM and allow us to write code that creates arbitrary LM's for any place, without going there first. On Fri, Dec 24, 2010 at 12:17:21PM +0100, Opensource Obscure wrote: > On Fri, Dec 24, 2010 at 11:03, Vadim Savchuk wrote: > > > Do you mean creating a landmark in your inventory by pasting a SLURL? > > I'm not sure that's possible: AFAIR, to create a landmark we perform a > > request to the server, which creates landmark of the current location in our > > inventory. The protocol doesn't support remote locations. > > sorry, I was not clear (ouch, my English!) > > What you described is exactly the problem I have with landmarks. > Having to teleport somewhere to get a landmark can be a PITA. > I remember LL confirmed there are no workarounds for this > (as you said, it's a protocol limitation). > > What I was thinking about was a new, different way to achieve > something we usually achieve through landmarks.. > (find a place in our Inventory + teleport there + optionally > share that place reference with other users) > ..a way that could avoid that very limitation you mentioned > (the need to be in a place in order to create a landmark). > > In the past I often didn't use landmarks - instead I copied SLURLs > from web pages and paste them into local chat, then click over > the links, then teleport. > Thanks to some new features, this is now less useful than in > the past - but I think some 1.x viewers users still do this. > > Going through local chat is clearly lame, and confusing for > people around you. That's why I said I would like to > "copy/paste" a SLURL into Inventory, create > (not a landmark) and then clickit to teleport. > I'm thinking about management of Bookmarks in current > main web browsers, where you're allowed to edit > both name and destination of a bookmark, tag it, > assign to multiple folders (or tags). > > Does this make sense to anyone here? > > Opensource Obscure > _______________________________________________ > 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 -- Carlo Wood From vsavchuk at productengine.com Fri Dec 24 05:01:53 2010 From: vsavchuk at productengine.com (Vadim Savchuk) Date: Fri, 24 Dec 2010 15:01:53 +0200 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") In-Reply-To: References: Message-ID: <4D1499C1.8020002@productengine.com> On 12/24/2010 01:17 PM, Opensource Obscure wrote: > Going through local chat is clearly lame, and confusing for > people around you. That's why I said I would like to > "copy/paste" a SLURL into Inventory, create > (not a landmark) and then clickit to teleport. > I'm thinking about management of Bookmarks in current > main web browsers, where you're allowed to edit > both name and destination of a bookmark, tag it, > assign to multiple folders (or tags). > > Does this make sense to anyone here? Sounds like a hack to me: this is what landmarks were made for. I think the most proper solution would be to fix the above-mentioned protocol limitation and maybe extend functionality of landmarks (e.g., as you said, add ability to edit the location) without inventing new inventory asset type. -- Vadim From merov at lindenlab.com Fri Dec 24 08:05:30 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Fri, 24 Dec 2010 08:05:30 -0800 Subject: [opensource-dev] STORM-34 Test Binaries Message-ID: Hi, For those interested by this upcoming functionality, a set of test binaries for STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be) is available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/index.html Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/f8002813/attachment.htm From garmin.kawaguichi at magalaxie.com Fri Dec 24 08:09:39 2010 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Fri, 24 Dec 2010 17:09:39 +0100 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") References: Message-ID: <220D6985B3084D74BBE6D5D523154EAA@Deimos> ----- Original Message ----- From: "Opensource Obscure" To: "OpenSource Mailing List" Sent: Friday, December 24, 2010 12:17 PM Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > What I was thinking about was a new, different way to achieve > something we usually achieve through landmarks.. ... > I'm thinking about management of Bookmarks in current > main web browsers,... Something like : secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct teleport when clicked) but stored in the inventory as a new asset item different from asset item #3 (INVENTORY_LANDMARK) and defined as a web link directly usable in the viewer. This link can be created in the inventory with a right click New Link and can be edited. GCI From adyukov at productengine.com Fri Dec 24 08:14:11 2010 From: adyukov at productengine.com (Andrew Dyukov) Date: Fri, 24 Dec 2010 18:14:11 +0200 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: Message-ID: Thanks, Merov! :) 2010/12/24 Philippe (Merov) Bossut : > Hi, > > For those interested by this upcoming functionality, a set of test binaries > for STORM-34 (As a User, I want a list of my favorite locations available on > the login screen so i can log in to SL right where I want to be) is > available here: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/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 > From angel_of_crimson at hotmail.com Fri Dec 24 08:27:30 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Fri, 24 Dec 2010 11:27:30 -0500 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") In-Reply-To: <220D6985B3084D74BBE6D5D523154EAA@Deimos> References: , <220D6985B3084D74BBE6D5D523154EAA@Deimos> Message-ID: Since thee ahs been the ability for over a year now to make a landmark anywhere you visit, I simply don't see the need for a new asset type. From what I understand from Lindens in all parts of the LL it takes an ungodly amount of work to create a new asset, which is part of why the new presets for the viewer are not going to be shareable via asset. Also, I really don't want two assets that do essentially the same thing. You can already manage landmarks like bookmarks, and v2 now has the viewer bar. I agree totally with the idea of removing the protocal that prevents you from being able to create/edit landmarks, and put in a way to create one via surl/maplink. I think it should be able to be created in each of the following methods. 1) when a surl is clicked in world or on a webpage and pops up the place profile, I think a create landmark button should appear on the place profile page. 2) via right click in the inventory AND landmarks tab and selecting "create landmark via SURL" which would open a text box you could type the surl/maplink into. 3) On teleport offers a new option "create landmark" which would neither accept nor cancel the tp. Useful if you can't accept right then, or if you're having teleporting failures. > From: garmin.kawaguichi at magalaxie.com > To: opensource-dev at lists.secondlife.com > Date: Fri, 24 Dec 2010 17:09:39 +0100 > Subject: Re: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > > > ----- Original Message ----- > From: "Opensource Obscure" > To: "OpenSource Mailing List" > Sent: Friday, December 24, 2010 12:17 PM > Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS > (was "Daily Scrum Summary - dec. 23") > > > > What I was thinking about was a new, different way to achieve > > something we usually achieve through landmarks.. > ... > > I'm thinking about management of Bookmarks in current > > main web browsers,... > > Something like : > secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct > teleport when clicked) > > but > > stored in the inventory as a new asset item different from asset item #3 > (INVENTORY_LANDMARK) and defined as a web link directly usable in the > viewer. This link can be created in the inventory with a right click New > Link and can be edited. > > GCI > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2feb591f/attachment.htm From jhwelch at gmail.com Fri Dec 24 08:49:32 2010 From: jhwelch at gmail.com (Jonathan Welch) Date: Fri, 24 Dec 2010 11:49:32 -0500 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") In-Reply-To: References: <220D6985B3084D74BBE6D5D523154EAA@Deimos> Message-ID: I've always wanted to be able to take a LM from someone's picks I am currently viewing and store it. It's often the case that I want to go to some interesting place but can't jaunt off immediately. From vsavchuk at productengine.com Fri Dec 24 10:55:28 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Fri, 24 Dec 2010 18:55:28 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224185528.7881.16731@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review85 ----------------------------------------------------------- Seems plausible. indra/newview/llpanelmaininventory.cpp This line can now be removed at all. indra/newview/llpanelmaininventory.cpp redundant line - Vadim On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2ba2d10a/attachment-0001.htm From vsavchuk at productengine.com Fri Dec 24 11:06:43 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Fri, 24 Dec 2010 19:06:43 -0000 Subject: [opensource-dev] Review Request: Constraints in XUI files don't match the constraints imposed elsewhere in the viewer/server code. In-Reply-To: <20101222201710.7875.13802@domU-12-31-38-00-90-68.compute-1.internal> References: <20101222201710.7875.13802@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224190643.7868.40610@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/57/#review86 ----------------------------------------------------------- How do you know the server constraints? - Vadim On 2010-12-22 12:17:10, SignpostMarv Martin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/57/ > ----------------------------------------------------------- > > (Updated 2010-12-22 12:17:10) > > > Review request for Viewer. > > > Summary > ------- > > Constraints in XUI files don't match the constraints imposed elsewhere in the viewer/server code. > > Don't know where the constraints are specified, but this XUI mod lets the user play within the full range of the actual constraints. > > JIRA page has screenshots of before & after. > > > This addresses bug VWR-24197. > http://jira.secondlife.com/browse/VWR-24197 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/floater_tools.xml UNKNOWN > > Diff: http://codereview.secondlife.com/r/57/diff > > > Testing > ------- > > > Thanks, > > SignpostMarv > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2f99dfd8/attachment.htm From trilobyte550m at gmail.com Fri Dec 24 11:38:10 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Fri, 24 Dec 2010 11:38:10 -0800 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: Message-ID: Testing developer build 217857, works great. Took some digging around in the JIRA to figure out that a preferences switch had to be activated first, and where that preference was, but once I enabled it on the Mac client it worked perfectly. Great - can't wait to see this in the main Viewer! TriloByte Zanzibar On Dec 24, 2010, at 8:05 AM, Philippe (Merov) Bossut wrote: > Hi, > > For those interested by this upcoming functionality, a set of test binaries for STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be) is available here: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/5f585d60/attachment.htm From merov at lindenlab.com Fri Dec 24 11:46:22 2010 From: merov at lindenlab.com (Merov Linden) Date: Fri, 24 Dec 2010 19:46:22 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223075118.7880.59457@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224194622.7891.93749@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/ ----------------------------------------------------------- (Updated 2010-12-24 11:46:22.693285) Review request for Viewer. Changes ------- Took comments into account and some more: - Reverted making methods public to protected. Actually, I even made some methods private as they should. - Declared some public methods in the derived test class to test the protected methods - Fixed code so assert() work in debug mode (stub empty class was too inconsistent) - Moved one generic function out of llimagej2coj to clean things up there Summary ------- Unit tests addition: - add tests for llkdu - turned back on and fix unit tests for llimage - turned back on and fix unit tests for llworldmap and llworldmipmap This addresses bug STORM-744. http://jira.secondlife.com/browse/STORM-744 Diffs (updated) ----- indra/llimage/CMakeLists.txt 279f35982a1a indra/llimage/tests/llimageworker_test.cpp 279f35982a1a indra/llimagej2coj/llimagej2coj.h 279f35982a1a indra/llimagej2coj/llimagej2coj.cpp 279f35982a1a indra/llkdu/CMakeLists.txt 279f35982a1a indra/llkdu/llimagej2ckdu.h 279f35982a1a indra/llkdu/llimagej2ckdu.cpp 279f35982a1a indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION indra/newview/CMakeLists.txt 279f35982a1a indra/newview/tests/llworldmap_test.cpp 279f35982a1a indra/newview/tests/llworldmipmap_test.cpp 279f35982a1a Diff: http://codereview.secondlife.com/r/63/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/bc6ebb13/attachment.htm From jhwelch at gmail.com Fri Dec 24 12:36:34 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 24 Dec 2010 20:36:34 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101224185528.7881.16731@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224185528.7881.16731@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224203634.7881.42518@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-24 10:55:28, Vadim ProductEngine wrote: > > indra/newview/llpanelmaininventory.cpp, line 509 > > > > > > This line can now be removed at all. Line 509 on the left is removed; it might be that the diff display is slightly confused about this matter. Not sure what a lighter color of pink means. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review85 ----------------------------------------------------------- On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/4f4d19ec/attachment.htm From Aleric.Inglewood at gmail.com Fri Dec 24 13:25:16 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Fri, 24 Dec 2010 21:25:16 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224212516.7867.7634@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review88 ----------------------------------------------------------- indra/newview/llpanelmaininventory.cpp While you're removing that empty line anyway, I thought I'd help you to not learn the bad coding habbits of whoever wrote the original code ;). operator== returns a bool, might as well do the conversions one step later (if at all) and use a bool here. Using 'bool' always has the preference (BOOL is ugly window-ism). Certainly in this case since !recent_active converts it to a bool again! (bool --> BOOL -> bool -> BOOL now). Secondly, when testing if a variable is equal to a literal/constant, I think that's better readable to put the variable up front, thus: mActivePanel()->getName() == "Recent Items". Finally, although you may choose to leave it like it is, be aware that the extra 'variable' recent_active here was only added as pseudo 'comment' and to because the monitor of the original coder wasn't wide enough. If you have a normal 22" inch like all devs, you might also consider the more professional looking: // "New Folder" is broken for the Recent Items tab. Do not enable it for that case. mMenuAdd->getChild("New Folder")->setEnabled(mActivePanel->getName() != "Recent Items"); - Aleric On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/9b635442/attachment.htm From jhwelch at gmail.com Fri Dec 24 15:30:54 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Fri, 24 Dec 2010 23:30:54 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101224233054.7887.83445@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review89 ----------------------------------------------------------- indra/newview/llpanelmaininventory.cpp I updated the code per Aleric's suggestion but the 2nd diff failed to upload. There must be some unusual hg command to generate follow-up diffs in a format RB will be happy with. You can see the change on bitbucket though. - Jonathan On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/de463092/attachment-0001.htm From aleric.inglewood at gmail.com Fri Dec 24 17:27:14 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sat, 25 Dec 2010 02:27:14 +0100 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101224233054.7887.83445@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223212531.7885.50841@domU-12-31-38-00-90-68.compute-1.internal> <20101224233054.7887.83445@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: I still not sure about this myself, but I believe the magic is as follows: The diff file has the format: diff -r b0689af42a71 indra/cmake/LLAddBuildTest.cmake --- a/indra/cmake/LLAddBuildTest.cmake Wed Dec 15 22:44:21 2010 +0100 +++ b/indra/cmake/LLAddBuildTest.cmake Sun Dec 19 16:06:01 2010 +0100 etc, where the "b0689af42a71" must be the parent already in viewer-development that you based your diff on. Took me a while to figure that out and then I thought 'screw this check' and wrote a script that just forges that ID, using the following magic: UPSTREAMID="$(hg log -r 'max(not outgoing())' | grep '^changeset' | sed -e 's/.*://')" If you have a clean clone with a single patch, then that is the parent of your patch, and you can generate the diff with 'hg export'. Now,.. if you upload a patch on top of another patch (for the same RB issue) it asks you for an optional parent diff. You leave that empty when the new diff replaces the old one, but if it's an incremental diff, you just put there whatever diff needs to be applied before applying this new upload. Hope that helps, Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101225/4c4d22ac/attachment.htm From hitomi.tiponi at yahoo.co.uk Fri Dec 24 19:10:01 2010 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Sat, 25 Dec 2010 03:10:01 +0000 (GMT) Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: Message-ID: <285058.60774.qm@web23905.mail.ird.yahoo.com> That looks great Merov. Would suggest that the option for displaying them moves alongside the other login options in the 'General' Preferences panel as 'Privacy' was not an obvious place to look. ________________________________ From: "opensource-dev-request at lists.secondlife.com" To: opensource-dev at lists.secondlife.com Sent: Sat, 25 December, 2010 5:55:29 Subject: opensource-dev Digest, Vol 11, Issue 79 Send opensource-dev mailing list submissions to opensource-dev at lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev or, via email, send a message with subject or body 'help' to opensource-dev-request at lists.secondlife.com You can reach the person managing the list at opensource-dev-owner at lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of opensource-dev digest..." Today's Topics: 1. Re: STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") (Vadim Savchuk) 2. STORM-34 Test Binaries (Philippe (Merov) Bossut) 3. Re: STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") (Garmin Kawaguichi) 4. Re: STORM-34 Test Binaries (Andrew Dyukov) 5. Re: STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") (Erin Mallory) 6. Re: STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") (Jonathan Welch) 7. Re: Review Request: STORM-737 Add "+" menu to Inventory/Recent (Vadim ProductEngine) ---------------------------------------------------------------------- Message: 1 Date: Fri, 24 Dec 2010 15:01:53 +0200 From: Vadim Savchuk Subject: Re: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") To: Opensource Obscure Cc: OpenSource Mailing List Message-ID: <4D1499C1.8020002 at productengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 12/24/2010 01:17 PM, Opensource Obscure wrote: > Going through local chat is clearly lame, and confusing for > people around you. That's why I said I would like to > "copy/paste" a SLURL into Inventory, create > (not a landmark) and then clickit to teleport. > I'm thinking about management of Bookmarks in current > main web browsers, where you're allowed to edit > both name and destination of a bookmark, tag it, > assign to multiple folders (or tags). > > Does this make sense to anyone here? Sounds like a hack to me: this is what landmarks were made for. I think the most proper solution would be to fix the above-mentioned protocol limitation and maybe extend functionality of landmarks (e.g., as you said, add ability to edit the location) without inventing new inventory asset type. -- Vadim ------------------------------ Message: 2 Date: Fri, 24 Dec 2010 08:05:30 -0800 From: "Philippe (Merov) Bossut" Subject: [opensource-dev] STORM-34 Test Binaries To: opensource-dev at lists.secondlife.com, Sarah Hutchinson Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hi, For those interested by this upcoming functionality, a set of test binaries for STORM-34 (As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be) is available here: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/index.html Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/f8002813/attachment-0001.htm ------------------------------ Message: 3 Date: Fri, 24 Dec 2010 17:09:39 +0100 From: "Garmin Kawaguichi" Subject: Re: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") To: "OpenSource Mailing List" Message-ID: <220D6985B3084D74BBE6D5D523154EAA at Deimos> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original ----- Original Message ----- From: "Opensource Obscure" To: "OpenSource Mailing List" Sent: Friday, December 24, 2010 12:17 PM Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > What I was thinking about was a new, different way to achieve > something we usually achieve through landmarks.. ... > I'm thinking about management of Bookmarks in current > main web browsers,... Something like : secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct teleport when clicked) but stored in the inventory as a new asset item different from asset item #3 (INVENTORY_LANDMARK) and defined as a web link directly usable in the viewer. This link can be created in the inventory with a right click New Link and can be edited. GCI ------------------------------ Message: 4 Date: Fri, 24 Dec 2010 18:14:11 +0200 From: Andrew Dyukov Subject: Re: [opensource-dev] STORM-34 Test Binaries To: "Philippe (Merov) Bossut" Cc: opensource-dev at lists.secondlife.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Thanks, Merov! :) 2010/12/24 Philippe (Merov) Bossut : > Hi, > > For those interested by this upcoming functionality, a set of test binaries > for STORM-34 (As a User, I want a list of my favorite locations available on > the login screen so i can log in to SL right where I want to be) is > available here: >http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/index.html >l > > 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 > ------------------------------ Message: 5 Date: Fri, 24 Dec 2010 11:27:30 -0500 From: Erin Mallory Subject: Re: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") To: , Message-ID: Content-Type: text/plain; charset="iso-8859-1" Since thee ahs been the ability for over a year now to make a landmark anywhere you visit, I simply don't see the need for a new asset type. From what I understand from Lindens in all parts of the LL it takes an ungodly amount of work to create a new asset, which is part of why the new presets for the viewer are not going to be shareable via asset. Also, I really don't want two assets that do essentially the same thing. You can already manage landmarks like bookmarks, and v2 now has the viewer bar. I agree totally with the idea of removing the protocal that prevents you from being able to create/edit landmarks, and put in a way to create one via surl/maplink. I think it should be able to be created in each of the following methods. 1) when a surl is clicked in world or on a webpage and pops up the place profile, I think a create landmark button should appear on the place profile page. 2) via right click in the inventory AND landmarks tab and selecting "create landmark via SURL" which would open a text box you could type the surl/maplink into. 3) On teleport offers a new option "create landmark" which would neither accept nor cancel the tp. Useful if you can't accept right then, or if you're having teleporting failures. > From: garmin.kawaguichi at magalaxie.com > To: opensource-dev at lists.secondlife.com > Date: Fri, 24 Dec 2010 17:09:39 +0100 > Subject: Re: [opensource-dev] STORM-797 and other ideas about >Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > > > ----- Original Message ----- > From: "Opensource Obscure" > To: "OpenSource Mailing List" > Sent: Friday, December 24, 2010 12:17 PM > Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS > (was "Daily Scrum Summary - dec. 23") > > > > What I was thinking about was a new, different way to achieve > > something we usually achieve through landmarks.. > ... > > I'm thinking about management of Bookmarks in current > > main web browsers,... > > Something like : > secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct > teleport when clicked) > > but > > stored in the inventory as a new asset item different from asset item #3 > (INVENTORY_LANDMARK) and defined as a web link directly usable in the > viewer. This link can be created in the inventory with a right click New > Link and can be edited. > > GCI > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2feb591f/attachment-0001.htm ------------------------------ Message: 6 Date: Fri, 24 Dec 2010 11:49:32 -0500 From: Jonathan Welch Subject: Re: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") To: opensource-dev at lists.secondlife.com Message-ID: Content-Type: text/plain; charset=ISO-8859-1 I've always wanted to be able to take a LM from someone's picks I am currently viewing and store it. It's often the case that I want to go to some interesting place but can't jaunt off immediately. ------------------------------ Message: 7 Date: Fri, 24 Dec 2010 18:55:28 -0000 From: "Vadim ProductEngine" Subject: Re: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent To: "Vadim ProductEngine" , "Viewer" , "Jonathan Yap" Message-ID: <20101224185528.7881.16731 at domU-12-31-38-00-90-68.compute-1.internal> Content-Type: text/plain; charset="utf-8" ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review85 ----------------------------------------------------------- Seems plausible. indra/newview/llpanelmaininventory.cpp This line can now be removed at all. indra/newview/llpanelmaininventory.cpp redundant line - Vadim On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both >right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via >either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2ba2d10a/attachment.htm ------------------------------ _______________________________________________ opensource-dev mailing list opensource-dev at lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev End of opensource-dev Digest, Vol 11, Issue 79 ********************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101225/fc060fce/attachment-0001.htm From vsavchuk at productengine.com Mon Dec 27 04:15:42 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 27 Dec 2010 12:15:42 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101224185528.7881.16731@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224185528.7881.16731@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101227121542.20363.3946@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-24 10:55:28, Vadim ProductEngine wrote: > > indra/newview/llpanelmaininventory.cpp, line 509 > > > > > > This line can now be removed at all. > > Jonathan Yap wrote: > Line 509 on the left is removed; it might be that the diff display is slightly confused about this matter. Not sure what a lighter color of pink means. I meant the line on the right: no need to set visibility to true because it's the default value. (I tried removing that line and nothing changed) - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review85 ----------------------------------------------------------- On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/0850627d/attachment.htm From vsavchuk at productengine.com Mon Dec 27 04:19:02 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 27 Dec 2010 12:19:02 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101224233054.7887.83445@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224233054.7887.83445@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101227121902.20631.51625@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-24 15:30:55, Jonathan Yap wrote: > > indra/newview/llpanelmaininventory.cpp, line 948 > > > > > > I updated the code per Aleric's suggestion but the 2nd diff failed to upload. There must be some unusual hg command to generate follow-up diffs in a format RB will be happy with. You can see the change on bitbucket though. This change breaks indentation. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review89 ----------------------------------------------------------- On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/bde49347/attachment.htm From vsavchuk at productengine.com Mon Dec 27 04:31:08 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 27 Dec 2010 12:31:08 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101224212516.7867.7634@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224212516.7867.7634@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101227123108.20367.74641@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-24 13:25:16, Aleric Inglewood wrote: > > indra/newview/llpanelmaininventory.cpp, line 948 > > > > > > While you're removing that empty line anyway, I thought I'd help you to not learn the bad coding habbits of whoever wrote the original code ;). > > > > operator== returns a bool, might as well do the conversions one step later (if at all) and use a bool here. > > > > Using 'bool' always has the preference (BOOL is ugly window-ism). > > > > Certainly in this case since !recent_active converts it to a bool again! (bool --> BOOL -> bool -> BOOL now). > > > > Secondly, when testing if a variable is equal to a literal/constant, I think that's better readable to put the variable up front, thus: mActivePanel()->getName() == "Recent Items". > > > > Finally, although you may choose to leave it like it is, be aware that the extra 'variable' recent_active here was only added as pseudo 'comment' and to because the monitor of the original coder wasn't wide enough. If you have a normal 22" inch like all devs, you might also consider the more professional looking: > > > > // "New Folder" is broken for the Recent Items tab. Do not enable it for that case. > > mMenuAdd->getChild("New Folder")->setEnabled(mActivePanel->getName() != "Recent Items"); > > I tend to agree regarding the BOOL, but the other two issues are rather a matter of taste, which, IMHO, is not a subject of code review. Besides: * Putting a constant on the left of a comparison operator makes sure you won't get a hard-to-find bug if you accidentally write "=" instead of "==" (I don't like this habit either, but at least it makes sense). * Using reasonably named variables to make logic clearer is not a "bad coding habit" and doesn't look any less professional to me. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review88 ----------------------------------------------------------- On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/c643e9a4/attachment-0001.htm From robin.cornelius at gmail.com Mon Dec 27 04:32:59 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 27 Dec 2010 12:32:59 -0000 Subject: [opensource-dev] Review Request: VWR-20879 FTBFS: find_vc_dir() fails with Visual Studio Express Message-ID: <20101227123259.20369.9086@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/66/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Add VCExpress as a search option in find_vc_dir() to enable the build process to complete even when using Visual Studio Express This addresses bug VWR-20879. http://jira.secondlife.com/browse/VWR-20879 Diffs ----- indra/lib/python/indra/util/test_win32_manifest.py 279f35982a1a Diff: http://codereview.secondlife.com/r/66/diff Testing ------- Built viewer development using VCExpress 2005 to completion/installer generation sucessfully. Thanks, Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/df843d09/attachment.htm From adyukov at productengine.com Mon Dec 27 04:39:49 2010 From: adyukov at productengine.com (Andrew Dyukov) Date: Mon, 27 Dec 2010 14:39:49 +0200 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: <285058.60774.qm@web23905.mail.ird.yahoo.com> References: <285058.60774.qm@web23905.mail.ird.yahoo.com> Message-ID: This preference is in "Privacy", because enabling it allows other users who use your machine to see your favorites from login screen without using a password, so it lets you share your private information. 2010/12/25 Hitomi Tiponi : > That looks great Merov.? Would suggest that the option for displaying them > moves alongside the other login options in the 'General' Preferences panel > as 'Privacy' was not an obvious place to look. > > ________________________________ > From: "opensource-dev-request at lists.secondlife.com" > > To: opensource-dev at lists.secondlife.com > Sent: Sat, 25 December, 2010 5:55:29 > Subject: opensource-dev Digest, Vol 11, Issue 79 > > Send opensource-dev mailing list submissions to > ??? opensource-dev at lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > ??? https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > or, via email, send a message with subject or body 'help' to > ??? opensource-dev-request at lists.secondlife.com > > You can reach the person managing the list at > ??? opensource-dev-owner at lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opensource-dev digest..." > > > Today's Topics: > > ? 1. Re: STORM-797 and other ideas about Landmarks&SLURLS (was > ? ? ? "Daily Scrum Summary - dec. 23") (Vadim Savchuk) > ? 2. STORM-34 Test Binaries (Philippe (Merov) Bossut) > ? 3. Re: STORM-797 and other ideas about??? Landmarks&SLURLS (was > ? ? ? "Daily Scrum Summary - dec. 23") (Garmin Kawaguichi) > ? 4. Re: STORM-34 Test Binaries (Andrew Dyukov) > ? 5. Re: STORM-797 and other ideas about Landmarks&SLURLS (was > ? ? ? "Daily Scrum Summary - dec. 23") (Erin Mallory) > ? 6. Re: STORM-797 and other ideas about Landmarks&SLURLS (was > ? ? ? "Daily Scrum Summary - dec. 23") (Jonathan Welch) > ? 7. Re: Review Request: STORM-737 Add "+" menu to > ? ? ? Inventory/Recent (Vadim ProductEngine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 24 Dec 2010 15:01:53 +0200 > From: Vadim Savchuk > Subject: Re: [opensource-dev] STORM-797 and other ideas about > ??? Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > To: Opensource Obscure > Cc: OpenSource Mailing List > Message-ID: <4D1499C1.8020002 at productengine.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 12/24/2010 01:17 PM, Opensource Obscure wrote: >> Going through local chat is clearly lame, and confusing for >> people around you. That's why I said I would like to >> "copy/paste" a SLURL into Inventory, create >> (not a landmark) and then clickit? to teleport. >> I'm thinking about management of? Bookmarks in current >> main web browsers, where you're allowed to edit >> both name and destination of a bookmark, tag it, >> assign to multiple folders (or tags). >> >> Does this make sense to anyone here? > Sounds like a hack to me: this is what landmarks were made for. > I think the most proper solution would be to fix the above-mentioned > protocol limitation and maybe extend functionality of landmarks (e.g., > as you said, add ability to edit the location) without inventing new > inventory asset type. > > -- > Vadim > > > > ------------------------------ > > Message: 2 > Date: Fri, 24 Dec 2010 08:05:30 -0800 > From: "Philippe (Merov) Bossut" > Subject: [opensource-dev] STORM-34 Test Binaries > To: opensource-dev at lists.secondlife.com, ??? Sarah Hutchinson > ??? > Message-ID: > ??? > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > For those interested by this upcoming functionality, a set of test binaries > for STORM-34 (As a User, I want a list of my favorite locations available on > the login screen so i can log in to SL right where I want to be) is > available here: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/index.html > > Cheers, > - Merov > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/f8002813/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Fri, 24 Dec 2010 17:09:39 +0100 > From: "Garmin Kawaguichi" > Subject: Re: [opensource-dev] STORM-797 and other ideas about > ??? Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > To: "OpenSource Mailing List" > Message-ID: <220D6985B3084D74BBE6D5D523154EAA at Deimos> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > ??? reply-type=original > > > ----- Original Message ----- > From: "Opensource Obscure" > To: "OpenSource Mailing List" > Sent: Friday, December 24, 2010 12:17 PM > Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS > (was "Daily Scrum Summary - dec. 23") > > >> What I was thinking about was a new, different way to achieve >> something we usually achieve through landmarks.. > ... >> I'm thinking about management of? Bookmarks in current >> main web browsers,... > > Something like : > secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct > teleport when clicked) > > but > > stored in the inventory as a new asset item different from asset item #3 > (INVENTORY_LANDMARK) and defined as a web link directly usable in the > viewer. This link can be created in the inventory with a right click New > Link and can be edited. > > GCI > > > > ------------------------------ > > Message: 4 > Date: Fri, 24 Dec 2010 18:14:11 +0200 > From: Andrew Dyukov > Subject: Re: [opensource-dev] STORM-34 Test Binaries > To: "Philippe (Merov) Bossut" > Cc: opensource-dev at lists.secondlife.com > Message-ID: > ??? > Content-Type: text/plain; charset=ISO-8859-1 > > Thanks, Merov! :) > > 2010/12/24 Philippe (Merov) Bossut : >> Hi, >> >> For those interested by this upcoming functionality, a set of test >> binaries >> for STORM-34 (As a User, I want a list of my favorite locations available >> on >> the login screen so i can log in to SL right where I want to be) is >> available here: >> >> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217857/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 >> > > > ------------------------------ > > Message: 5 > Date: Fri, 24 Dec 2010 11:27:30 -0500 > From: Erin Mallory > Subject: Re: [opensource-dev] STORM-797 and other ideas about > ??? Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > To: , > ??? > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > Since thee ahs been the ability for over a year now to make a landmark > anywhere you visit, I simply don't see the need for a new asset type.? From > what I understand from Lindens in all parts of the LL it takes an ungodly > amount of work to create a new asset, which is part of why the new presets > for the viewer are not going to be shareable via asset.? Also, I really > don't want two assets that do essentially the same thing. You can already > manage landmarks like bookmarks, and v2 now has the viewer bar. > I agree totally with the idea of removing the protocal that prevents you > from being able to create/edit landmarks, and put in a way to create one via > surl/maplink. > I think it should be able to be created in each of the following methods. > 1) when a surl is clicked in world or on a webpage and pops up the place > profile, I think a create landmark button should appear on the place profile > page. > 2) via right click in the inventory AND landmarks tab and selecting "create > landmark via SURL" which would open a text box you could type the > surl/maplink into. > 3) On teleport offers a new option "create landmark" which would neither > accept nor cancel the tp.? Useful if you can't accept right then, or if > you're having teleporting failures. >> From: garmin.kawaguichi at magalaxie.com >> To: opensource-dev at lists.secondlife.com >> Date: Fri, 24 Dec 2010 17:09:39 +0100 >> Subject: Re: [opensource-dev] STORM-797 and other ideas about >> Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") >> >> >> ----- Original Message ----- >> From: "Opensource Obscure" >> To: "OpenSource Mailing List" >> Sent: Friday, December 24, 2010 12:17 PM >> Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS >> (was "Daily Scrum Summary - dec. 23") >> >> >> > What I was thinking about was a new, different way to achieve >> > something we usually achieve through landmarks.. >> ... >> > I'm thinking about management of? Bookmarks in current >> > main web browsers,... >> >> Something like : >>? secondlife:///app/teleport/furvata/132/126/96 (which can be used to >> direct >> teleport when clicked) >> >> but >> >> stored in the inventory as a new asset item different from asset item #3 >> (INVENTORY_LANDMARK) and defined as a web link directly usable in the >> viewer. This link can be created in the inventory with a right click New >> Link and can be edited. >> >> GCI >> >> _______________________________________________ >> 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 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2feb591f/attachment-0001.htm > > ------------------------------ > > Message: 6 > Date: Fri, 24 Dec 2010 11:49:32 -0500 > From: Jonathan Welch > Subject: Re: [opensource-dev] STORM-797 and other ideas about > ??? Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") > To: opensource-dev at lists.secondlife.com > Message-ID: > ??? > Content-Type: text/plain; charset=ISO-8859-1 > > I've always wanted to be able to take a LM from someone's picks I am > currently viewing and store it.? It's often the case that I want to go > to some interesting place but can't jaunt off immediately. > > > ------------------------------ > > Message: 7 > Date: Fri, 24 Dec 2010 18:55:28 -0000 > From: "Vadim ProductEngine" > Subject: Re: [opensource-dev] Review Request: STORM-737 Add "+" menu > ??? to??? Inventory/Recent > To: "Vadim ProductEngine" ,??? "Viewer" > ??? ,??? "Jonathan Yap" > ??? > Message-ID: > ??? <20101224185528.7881.16731 at domU-12-31-38-00-90-68.compute-1.internal> > Content-Type: text/plain; charset="utf-8" > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/#review85 > ----------------------------------------------------------- > > > Seems plausible. > > > indra/newview/llpanelmaininventory.cpp > > > ? ? This line can now be removed at all. > > > > indra/newview/llpanelmaininventory.cpp > > > ? ? redundant line > > > - Vadim > > > On 2010-12-23 13:25:31, Jonathan Yap wrote: >> >> ----------------------------------------------------------- >> This is an automatically generated e-mail. To reply, visit: >> http://codereview.secondlife.com/r/65/ >> ----------------------------------------------------------- >> >> (Updated 2010-12-23 13:25:31) >> >> >> Review request for Viewer. >> >> >> Summary >> ------- >> >> This change enables the "+" menu in Inventory/Recent >> It grays out "New Folder" in this menu >> It enables identical menu entries when you right click on an inventory >> item. >> >> Question: >>? Is graying out "New Folder" best done where I am doing it now -- in >> llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() >> >> >> This addresses bug storm-737. >>? ? http://jira.secondlife.com/browse/storm-737 >> >> >> Diffs >> ----- >> >>? doc/contributions.txt e843e274fa58 >>? indra/newview/llinventorybridge.cpp e843e274fa58 >>? indra/newview/llpanelmaininventory.cpp e843e274fa58 >> >> Diff: http://codereview.secondlife.com/r/65/diff >> >> >> Testing >> ------- >> >> I opened up Inventory/My Inventory and used all the "New xxx" options for >> both right clicking on an inventory item and also from the "+" menu. >> >> I then changed to the Recent tab and performed the same steps. >> >> New items were created as expected, except "New Folder" was not an option >> via either method when the Recent tab was active. >> >> >> Thanks, >> >> Jonathan >> >> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101224/2ba2d10a/attachment.htm > > ------------------------------ > > _______________________________________________ > opensource-dev mailing list > opensource-dev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > End of opensource-dev Digest, Vol 11, Issue 79 > ********************************************** > > > _______________________________________________ > 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 > From vsavchuk at productengine.com Mon Dec 27 05:35:40 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Mon, 27 Dec 2010 13:35:40 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101224194622.7891.93749@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224194622.7891.93749@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101227133540.20367.91210@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/#review94 ----------------------------------------------------------- Thanks, Merov. I have no more objections. indra/llimagej2coj/llimagej2coj.cpp Please add the "static" modifier to indicate that the function is not supposed to be used outside of the file. - Vadim On 2010-12-24 11:46:22, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/63/ > ----------------------------------------------------------- > > (Updated 2010-12-24 11:46:22) > > > Review request for Viewer. > > > Summary > ------- > > Unit tests addition: > - add tests for llkdu > - turned back on and fix unit tests for llimage > - turned back on and fix unit tests for llworldmap and llworldmipmap > > > This addresses bug STORM-744. > http://jira.secondlife.com/browse/STORM-744 > > > Diffs > ----- > > indra/llimage/CMakeLists.txt 279f35982a1a > indra/llimage/tests/llimageworker_test.cpp 279f35982a1a > indra/llimagej2coj/llimagej2coj.h 279f35982a1a > indra/llimagej2coj/llimagej2coj.cpp 279f35982a1a > indra/llkdu/CMakeLists.txt 279f35982a1a > indra/llkdu/llimagej2ckdu.h 279f35982a1a > indra/llkdu/llimagej2ckdu.cpp 279f35982a1a > indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION > indra/newview/CMakeLists.txt 279f35982a1a > indra/newview/tests/llworldmap_test.cpp 279f35982a1a > indra/newview/tests/llworldmipmap_test.cpp 279f35982a1a > > Diff: http://codereview.secondlife.com/r/63/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/195d3bb6/attachment-0001.htm From hitomi.tiponi at yahoo.co.uk Mon Dec 27 07:23:43 2010 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Mon, 27 Dec 2010 15:23:43 +0000 (GMT) Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: <285058.60774.qm@web23905.mail.ird.yahoo.com> Message-ID: <327279.85976.qm@web23904.mail.ird.yahoo.com> Fair point Andrew - but I was just thinking that from a resident's point-of-view it doesn't seem that obvious when you already have the other login options in 'General' ________________________________ >From: Andrew Dyukov >To: Hitomi Tiponi >Cc: opensource-dev at lists.secondlife.com >Sent: Mon, 27 December, 2010 23:39:49 >Subject: Re: [opensource-dev] STORM-34 Test Binaries > >This preference is in "Privacy", because enabling it allows other >users who use your machine to see your favorites from login screen >without using a password, so it lets you share your private >information. > >>2010/12/25 Hitomi Tiponi : >>That looks great Merov.? Would suggest that the option for displaying them >> moves alongside the other login options in the 'General' Preferences panel >> as 'Privacy' was not an obvious place to look. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/2393f99a/attachment.htm From angel_of_crimson at hotmail.com Mon Dec 27 07:56:51 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 27 Dec 2010 10:56:51 -0500 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: <327279.85976.qm@web23904.mail.ird.yahoo.com> References: , <285058.60774.qm@web23905.mail.ird.yahoo.com>, , <327279.85976.qm@web23904.mail.ird.yahoo.com> Message-ID: I kinda have to agree with hitomi. Date: Mon, 27 Dec 2010 15:23:43 +0000 From: hitomi.tiponi at yahoo.co.uk To: adyukov at productengine.com CC: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] STORM-34 Test Binaries Fair point Andrew - but I was just thinking that from a resident's point-of-view it doesn't seem that obvious when you already have the other login options in 'General' >From: Andrew Dyukov >To: Hitomi Tiponi >Cc: opensource-dev at lists.secondlife.com >Sent: Mon, 27 December, 2010 23:39:49 >Subject: Re: [opensource-dev] STORM-34 Test Binaries > >This preference is in "Privacy", because enabling it allows other >users who use your machine to see your favorites from login screen >without using a password, so it lets you share your private >information. > >>2010/12/25 Hitomi Tiponi : >>That looks great Merov.? Would suggest that the option for displaying them >> moves alongside the other login options in the 'General' Preferences panel >> as 'Privacy' was not an obvious place to look. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/cd5fd073/attachment.htm From trilobyte550m at gmail.com Mon Dec 27 08:23:28 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Mon, 27 Dec 2010 08:23:28 -0800 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: , <285058.60774.qm@web23905.mail.ird.yahoo.com>, , <327279.85976.qm@web23904.mail.ird.yahoo.com> Message-ID: I understand the rationale for putting it on the Privacy tab. But it still seems like something that should be grouped with the Start Location options on the general tab. Perhaps to make room, the 'Enable Viewer Hints' checkbox could be moved to the Notifications tab? On Dec 27, 2010, at 7:56 AM, Erin Mallory wrote: > I kinda have to agree with hitomi. > > Date: Mon, 27 Dec 2010 15:23:43 +0000 > From: hitomi.tiponi at yahoo.co.uk > To: adyukov at productengine.com > CC: opensource-dev at lists.secondlife.com > Subject: Re: [opensource-dev] STORM-34 Test Binaries > > Fair point Andrew - but I was just thinking that from a resident's point-of-view it doesn't seem that obvious when you already have the other login options in 'General' > > >From: Andrew Dyukov > >To: Hitomi Tiponi > >Cc: opensource-dev at lists.secondlife.com > >Sent: Mon, 27 December, 2010 23:39:49 > >Subject: Re: [opensource-dev] STORM-34 Test Binaries > > > >This preference is in "Privacy", because enabling it allows other > >users who use your machine to see your favorites from login screen > >without using a password, so it lets you share your private > >information. > > > >>2010/12/25 Hitomi Tiponi : > >>That looks great Merov.? Would suggest that the option for displaying them > >> moves alongside the other login options in the 'General' Preferences panel > >> as 'Privacy' was not an obvious place to look. > > > > _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/65035071/attachment.htm From carlo at alinoe.com Mon Dec 27 08:59:11 2010 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 27 Dec 2010 17:59:11 +0100 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: <285058.60774.qm@web23905.mail.ird.yahoo.com> <327279.85976.qm@web23904.mail.ird.yahoo.com> Message-ID: <20101227165911.GA22986@alinoe.com> > I kinda have to agree with hitomi. I agree with Andrew; it's a privacy sensitive thing and users shouldn't accidently flip it without thinking because it's on the normal 'General' page. If they need or want it, then I'm sure they'll find it, like they find everything else. Also, it will take a while before a user needs links to favourite places on their login page: those are not newbies. It's sufficient to put the option in a place that requires more knowledge (and exploration) of the viewer interface. -- Carlo Wood From oz at lindenlab.com Mon Dec 27 09:48:12 2010 From: oz at lindenlab.com (Oz Linden) Date: Mon, 27 Dec 2010 17:48:12 -0000 Subject: [opensource-dev] Review Request: STORM-737 Add "+" menu to Inventory/Recent In-Reply-To: <20101224212516.7867.7634@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224212516.7867.7634@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101227174812.20365.79926@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-24 13:25:16, Aleric Inglewood wrote: > > I'm going to respectfully disagree with Aleric on one minor style point. When comparing equality between a literal or constant and a variable, putting the constant value has an advantage: it avoids the "=" vs "==" error: if (FOO_LIMIT == foo_counter) works just fine, but produces a syntax error if you mistype and leave off one of the "=", where: if (foo_counter = FOO_LIMIT) compiles just fine because = is an operator that returns the assigned value, and C/C++ treats any value as valid for true/false. Occasionally, this is handy, but if what you wanted was comparison, it's a hard-to-spot bug. - Oz ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/65/#review88 ----------------------------------------------------------- On 2010-12-23 13:25:31, Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/65/ > ----------------------------------------------------------- > > (Updated 2010-12-23 13:25:31) > > > Review request for Viewer. > > > Summary > ------- > > This change enables the "+" menu in Inventory/Recent > It grays out "New Folder" in this menu > It enables identical menu entries when you right click on an inventory item. > > Question: > Is graying out "New Folder" best done where I am doing it now -- in > llpanelmaininventory.cpp / LLPanelMainInventory::onAddButtonClick() > > > This addresses bug storm-737. > http://jira.secondlife.com/browse/storm-737 > > > Diffs > ----- > > doc/contributions.txt e843e274fa58 > indra/newview/llinventorybridge.cpp e843e274fa58 > indra/newview/llpanelmaininventory.cpp e843e274fa58 > > Diff: http://codereview.secondlife.com/r/65/diff > > > Testing > ------- > > I opened up Inventory/My Inventory and used all the "New xxx" options for both right clicking on an inventory item and also from the "+" menu. > > I then changed to the Recent tab and performed the same steps. > > New items were created as expected, except "New Folder" was not an option via either method when the Recent tab was active. > > > Thanks, > > Jonathan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/e6cef185/attachment-0001.htm From angel_of_crimson at hotmail.com Mon Dec 27 10:36:27 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 27 Dec 2010 13:36:27 -0500 Subject: [opensource-dev] no snowstorm meetings today? Message-ID: Did i miss an announcement or have my times off? or did snowstorm meetings today just get quietly cancelled on account of weather? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/648fab6d/attachment.htm From oz at lindenlab.com Mon Dec 27 11:16:17 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 27 Dec 2010 14:16:17 -0500 Subject: [opensource-dev] no snowstorm meetings today? In-Reply-To: References: Message-ID: <4D18E601.7070208@lindenlab.com> On 2010-12-27 13:36, Erin Mallory wrote: > Did i miss an announcement or have my times off? or did snowstorm > meetings today just get quietly cancelled on account of weather? Today and the Monday after New Years next week are Linden Lab holidays. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/709b1807/attachment.htm From merov at lindenlab.com Mon Dec 27 11:24:24 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 27 Dec 2010 11:24:24 -0800 Subject: [opensource-dev] no snowstorm meetings today? In-Reply-To: References: Message-ID: Hi Erin, Sorry for the absence of notice: today is actually an official day off at LL as part of Xmas. Cheers, - Merov On Mon, Dec 27, 2010 at 10:36 AM, Erin Mallory wrote: > Did i miss an announcement or have my times off? or did snowstorm meetings > today just get quietly cancelled on account of weather? > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/838845cb/attachment.htm From angel_of_crimson at hotmail.com Mon Dec 27 11:24:49 2010 From: angel_of_crimson at hotmail.com (Erin Mallory) Date: Mon, 27 Dec 2010 14:24:49 -0500 Subject: [opensource-dev] no snowstorm meetings today? In-Reply-To: <4D18E601.7070208@lindenlab.com> References: , <4D18E601.7070208@lindenlab.com> Message-ID: ah. forgot that. forgot that grumpity is on vacation too. >< see you tommorrow I guess :) Date: Mon, 27 Dec 2010 14:16:17 -0500 From: oz at lindenlab.com To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] no snowstorm meetings today? On 2010-12-27 13:36, Erin Mallory wrote: Did i miss an announcement or have my times off? or did snowstorm meetings today just get quietly cancelled on account of weather? Today and the Monday after New Years next week are Linden Lab holidays. _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/6e83d93d/attachment.htm From aklo at skyhighway.com Mon Dec 27 11:35:17 2010 From: aklo at skyhighway.com (aklo at skyhighway.com) Date: Mon, 27 Dec 2010 11:35:17 -0800 (PST) Subject: [opensource-dev] no snowstorm meetings today Message-ID: Oz, Merov, &c., then, please, turn off your computers and have a day off! Y'all deserve it! Thx for all you do, Happy Holidays!! - AK On 2010-12-27 13:36, Erin Mallory wrote: > Did i miss an announcement or have my times off? or did snowstorm meetings today just get quietly cancelled on account of weather? Today and the Monday after New Years next week are Linden Lab holidays. _______________________________________________ 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 Hi Erin, Sorry for the absence of notice: today is actually an official day off at LL as part of Xmas. Cheers, - Merov On Mon, Dec 27, 2010 at 10:36 AM, Erin Mallory wrote: Did i miss an announcement or have my times off? or did snowstorm meetings today just get quietly cancelled on account of weather? _______________________________________________ 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 po From laurent.bechir at madonie.org Mon Dec 27 14:54:31 2010 From: laurent.bechir at madonie.org (Laurent Bechir) Date: Mon, 27 Dec 2010 23:54:31 +0100 Subject: [opensource-dev] Sky and water settings per parcel Message-ID: <4D191927.7030206@madonie.org> Hello, I've added a comment on this feature request about sky and water settings per parcel, if anyone is interested : https://jira.secondlife.com/browse/VWR-6463 From merov at lindenlab.com Mon Dec 27 20:53:15 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 27 Dec 2010 20:53:15 -0800 Subject: [opensource-dev] VWR-24172 (tab key not working) In-Reply-To: <4D0CDB02.2060703@boroon.dasgupta.ch> References: <775EF585-4D7B-4E2B-A7D2-3675C3CDBDE5@gmail.com> <4D0CDB02.2060703@boroon.dasgupta.ch> Message-ID: Hi, On Sat, Dec 18, 2010 at 8:02 AM, Boroondas Gupte wrote: > On 12/18/2010 04:55 PM, Trilo Byte wrote: > > [...] tab key stopped working to jump between fields (in the build > window, debugged settings window, etc). [...] anybody else experiencing > this? > Yes, me. > I can repro on Mac too and it's Snowstorm 2.5 specific. I moved the bug to STORM (STORM-823). Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/a7abebfa/attachment.htm From merov at lindenlab.com Mon Dec 27 21:41:29 2010 From: merov at lindenlab.com (Merov Linden) Date: Tue, 28 Dec 2010 05:41:29 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL In-Reply-To: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228054129.20365.23030@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 05:16:08, Vadim ProductEngine wrote: > > indra/newview/llstartup.cpp, lines 3098-3099 > > > > > > Frankly speaking, I'm not a fan of adding another setting to only use it as a global variable. > > > > I would search for a more proper way, maybe adding get/setMapServerURL() methods to LLWorldMap. > > Perhaps a person more familiar with the world map code than me would suggest a better approach. I don't like it either but, unfortunately, the LLWorldMap is lazy instantiated in LLFloaterWorldMap::createWorldMapView() and I can't guarantee that it exists at that point in llstartup.cpp. So I either store the map_server_url response in an ad-hoc global or, as I did, in a setting which a different sort of global when you think about it but somewhat cleaner (documented at least and with specific usage). I choose the second solution. - Merov ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/#review76 ----------------------------------------------------------- On 2010-12-22 22:15:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/61/ > ----------------------------------------------------------- > > (Updated 2010-12-22 22:15:00) > > > Review request for Viewer. > > > Summary > ------- > > Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). > > > This addresses bug STORM-805. > http://jira.secondlife.com/browse/STORM-805 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 5d69e36a53ee > indra/newview/llstartup.cpp 5d69e36a53ee > indra/newview/llworldmipmap.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/61/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/8803024c/attachment.htm From merov at lindenlab.com Mon Dec 27 22:23:31 2010 From: merov at lindenlab.com (Merov Linden) Date: Tue, 28 Dec 2010 06:23:31 -0000 Subject: [opensource-dev] Review Request: VWR-20879 FTBFS: find_vc_dir() fails with Visual Studio Express In-Reply-To: <20101227123259.20369.9086@domU-12-31-38-00-90-68.compute-1.internal> References: <20101227123259.20369.9086@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228062331.20631.27473@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/66/#review98 ----------------------------------------------------------- Ship it! Seems correct though I could test with Express. At least, that shouldn't change anything for VS. - Merov On 2010-12-27 04:32:58, Robin Cornelius wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/66/ > ----------------------------------------------------------- > > (Updated 2010-12-27 04:32:58) > > > Review request for Viewer. > > > Summary > ------- > > Add VCExpress as a search option in find_vc_dir() to enable the build process to complete even when using Visual Studio Express > > > This addresses bug VWR-20879. > http://jira.secondlife.com/browse/VWR-20879 > > > Diffs > ----- > > indra/lib/python/indra/util/test_win32_manifest.py 279f35982a1a > > Diff: http://codereview.secondlife.com/r/66/diff > > > Testing > ------- > > Built viewer development using VCExpress 2005 to completion/installer generation sucessfully. > > > Thanks, > > Robin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/b826b787/attachment.htm From merov at lindenlab.com Mon Dec 27 23:55:53 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Mon, 27 Dec 2010 23:55:53 -0800 Subject: [opensource-dev] Test binary for in review JIRAs Message-ID: Hi, We're having a lot of JIRAs in the "In Review" swim lane for sprint 9 waiting for reviews from PO and/or devs. I created a Mac binary (others building right now) for those: http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217880/arch/Darwin/index.html JIRAs merged in there: * STORM-34 : As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be. * STORM-242 : Server version dialog message has incorrect release notes link (modulo one build issue fixed...) * STORM-398 : Message from nearby chat appears for avatar in Busy mode * STORM-466 : 2.x minimap cannot be reset to default zoom. * STORM-467 : 2.x minimap zoom does not persist to the next session. * STORM-485 : 'Cancel' button exceed the bounds of 'Group Invitation' floater. * STORM-682 : IM and notification toasts appear in wrong position if switch on mouse look when side tray is expanded * STORM-737 : Inventory Recent tab is missing "+" control at bottom of panel * STORM-805 : The world map can point to the wrong URL Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101227/37b907a4/attachment.htm From vsavchuk at productengine.com Tue Dec 28 03:39:41 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 28 Dec 2010 11:39:41 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL In-Reply-To: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228113941.20369.48162@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 05:16:08, Vadim ProductEngine wrote: > > indra/newview/llstartup.cpp, lines 3098-3099 > > > > > > Frankly speaking, I'm not a fan of adding another setting to only use it as a global variable. > > > > I would search for a more proper way, maybe adding get/setMapServerURL() methods to LLWorldMap. > > Perhaps a person more familiar with the world map code than me would suggest a better approach. > > Merov Linden wrote: > I don't like it either but, unfortunately, the LLWorldMap is lazy instantiated in LLFloaterWorldMap::createWorldMapView() and I can't guarantee that it exists at that point in llstartup.cpp. So I either store the map_server_url response in an ad-hoc global or, as I did, in a setting which a different sort of global when you think about it but somewhat cleaner (documented at least and with specific usage). I choose the second solution. > > I see. Then what about storing the URL in a static member of LLWorldMap (and using static getter/setter), so we don't need it to be instantiated? Or even store in LLWorldMipmap? - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/#review76 ----------------------------------------------------------- On 2010-12-22 22:15:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/61/ > ----------------------------------------------------------- > > (Updated 2010-12-22 22:15:00) > > > Review request for Viewer. > > > Summary > ------- > > Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). > > > This addresses bug STORM-805. > http://jira.secondlife.com/browse/STORM-805 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 5d69e36a53ee > indra/newview/llstartup.cpp 5d69e36a53ee > indra/newview/llworldmipmap.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/61/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/133cafdf/attachment-0001.htm From robin.cornelius at gmail.com Tue Dec 28 06:44:30 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 28 Dec 2010 14:44:30 +0000 Subject: [opensource-dev] LLMatrix3::orthogonalize test (was: LL_TESTS for standalone out-of-source builds) In-Reply-To: <4CB599F3.6090807@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> <000001cb6a77$f7db0690$e79113b0$@net> <4CB599F3.6090807@boroon.dasgupta.ch> Message-ID: On Wed, Oct 13, 2010 at 12:37 PM, Boroondas Gupte wrote: > On 10/13/2010 03:42 AM, WolfPup Lowenhar wrote: > > On the subject of the reason for killing test here is another reason that I > have attached this is from a full build I did today. The error listed in the > file is actually coded around and in visual studio you have to set that test > to not treat warnings as errors so that it will not fail! > > I tried removing the skip line to re-enable the test, like so: > > diff -r 27535365bd4c indra/llmath/tests/m3math_test.cpp > --- a/indra/llmath/tests/m3math_test.cpp Fri Oct 08 01:13:23 2010 +0200 > +++ b/indra/llmath/tests/m3math_test.cpp Wed Oct 13 13:16:30 2010 +0200 > @@ -280,7 +280,6 @@ > llmat_obj.setRows(llvec1, llvec2, llvec3); > llmat_obj.orthogonalize(); > > - skip("Grr, LLMatrix3::orthogonalize test is failing. Has it ever > worked?"); > ensure("LLMatrix3::orthogonalize failed ", > is_approx_equal(0.19611613f, llmat_obj.mMatrix[0][0]) && > is_approx_equal(0.78446454f, llmat_obj.mMatrix[0][1]) && > > On my system that test seems to work fine after that: > > LD_LIBRARY_PATH += ['/home/das-g/slsrc/hg/build/build/llcommon', '/usr/lib', > '/usr/local/lib'] > LD_LIBRARY_PATH = > '/usr/local/lib:/home/das-g/slsrc/hg/build/build/llcommon:/usr/lib' > Running: /home/das-g/slsrc/hg/build/build/llmath/INTEGRATION_TEST_m3math > Unit test group_started name=m3math_h > Unit test group_completed name=m3math_h > Total Tests: 13 > Passed Tests: 13 YAY!! \o/ > > Maybe someone has fixed LLMatrix3::orthogonalize but forgot to re-enable the > test? Or is LLMatrix3::orthogonalize behaving differently on different > platforms? (That should affect quaternion calculations and auto-leveling in > Flycam mode, so it's unlikely to go unnoticed.) > > Anyway, would be good if others could re-enable the test, too, and see > whether it also passes for them. Bumping this as i've just looked at it myself, the test is working fine on windows for me too and it does not appear that it needs skipping and as noticed previously in this (old) thread that the skip() is causing a unreachable code error in the test. So any reason why the test cannot be reenabled? Robin From opensourceobscure at gmail.com Tue Dec 28 07:30:41 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Tue, 28 Dec 2010 16:30:41 +0100 Subject: [opensource-dev] Anyone playing with Android and Second Life? Message-ID: Anyone playing with the Android platform together with Second Life? I'm an Android newbie but I would be available to help (testing, feedback, marketing) anyone developing a solution for this platform. Until now I could only find a closed-source viewer that runs on Android, and it's not even included in the Third Party Viewer Directory. I ignore if they ever apply for it and got refused, or if they never applied for. http://www.mobilegridclient.com - you may also want to read a perplexed developer's opinion about them: http://t.co/wH0hYyu Hopefully they're actually not violating TPVP and could apply for inclusion in the Directory, but it's a bit hard to trust them right now. (what do you think?) bye, Opensource Obscure From robin.cornelius at gmail.com Tue Dec 28 07:55:16 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 28 Dec 2010 15:55:16 +0000 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: Message-ID: On Tue, Dec 28, 2010 at 3:30 PM, Opensource Obscure wrote: > Hopefully they're actually not violating TPVP and could apply for > inclusion in the Directory, but it's a bit hard to trust them right now. > (what do you think?) There is a stricter requirement to be listed in the Third Party Viewer list than to actually connect to the SL Grid, so the fact they are a closed source solution, whist fine with the TPVP in general, would not allow them to be listed due to clause 6.a.iv.B/C, but would allow them to be used to connect. The other issue is, if they are using a central server to perform the connection to SL then transmitting revelant data to your handset, unless they have been very clever to avoid TPV clause 2.e, and it seems to be this that is mentioned in the linked discussion, then that would be considered a serious issue by LL, even if they had all good intentions. Robin From robin.cornelius at gmail.com Tue Dec 28 07:57:25 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 28 Dec 2010 15:57:25 +0000 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: Message-ID: On Tue, Dec 28, 2010 at 3:55 PM, Robin Cornelius wrote: > The other issue is, if they are using a central server to perform the > connection to SL then transmitting revelant data to your handset, > unless they have been very clever to avoid TPV clause 2.e, and it > seems to be this that is mentioned in the linked discussion, then that > would be considered a serious issue by LL, even if they had all good > intentions. And in the worst possible email etiquette, replying to ones self.. Their changelog says 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 Robin From tateru.nino at gmail.com Tue Dec 28 08:05:04 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 29 Dec 2010 03:05:04 +1100 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: Message-ID: <4D1A0AB0.3000608@gmail.com> On 29/12/2010 2:57 AM, Robin Cornelius wrote: > On Tue, Dec 28, 2010 at 3:55 PM, Robin Cornelius > wrote: > >> The other issue is, if they are using a central server to perform the >> connection to SL then transmitting revelant data to your handset, >> unless they have been very clever to avoid TPV clause 2.e, and it >> seems to be this that is mentioned in the linked discussion, then that >> would be considered a serious issue by LL, even if they had all good >> intentions. > And in the worst possible email etiquette, replying to ones self.. > > Their changelog says > > 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. -- Tateru Nino http://dwellonit.taterunino.net/ From robin.cornelius at gmail.com Tue Dec 28 08:12:13 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 28 Dec 2010 16:12:13 +0000 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: <4D1A0AB0.3000608@gmail.com> References: <4D1A0AB0.3000608@gmail.com> Message-ID: On Tue, Dec 28, 2010 at 4:05 PM, Tateru Nino wrote: >> >> So that avoids 2.e > I'd be more concerned about capabilities URIs, myself. The login > credentials are only the front-gate. > Thats absolutly true, and it would be trivial to inject a pay packet or any other packet into the data stream. But its probably far far easier to place malicious code in a TVP binary. So unless you are going to download the source to a TPV and diff it against LL code base, then compile yourself (ensuring all dependencies are also provided by LL/built by yourself), are you really any more at risk? , i'm just being a bit of a devils advocate here, my first comments were a literal comparison of if they met the TPV rules for listing. Robin From tateru.nino at gmail.com Tue Dec 28 08:14:57 2010 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 29 Dec 2010 03:14:57 +1100 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: <4D1A0AB0.3000608@gmail.com> Message-ID: <4D1A0D01.3090707@gmail.com> On 29/12/2010 3:12 AM, Robin Cornelius wrote: > On Tue, Dec 28, 2010 at 4:05 PM, Tateru Nino wrote: > >>> So that avoids 2.e >> I'd be more concerned about capabilities URIs, myself. The login >> credentials are only the front-gate. >> > Thats absolutly true, and it would be trivial to inject a pay packet > or any other packet into the data stream. But its probably far far > easier to place malicious code in a TVP binary. So unless you are > going to download the source to a TPV and diff it against LL code > base, then compile yourself (ensuring all dependencies are also > provided by LL/built by yourself), are you really any more at risk? , > i'm just being a bit of a devils advocate here, my first comments were > a literal comparison of if they met the TPV rules for listing. Ultimately it all comes down to trust, yes - regardless of who provides the application. -- Tateru Nino http://dwellonit.taterunino.net/ From wolfpup67 at earthlink.net Tue Dec 28 09:29:22 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Tue, 28 Dec 2010 12:29:22 -0500 Subject: [opensource-dev] LLMatrix3::orthogonalize test (was: LL_TESTS for standalone out-of-source builds) In-Reply-To: References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> <000001cb6a77$f7db0690$e79113b0$@net> <4CB599F3.6090807@boroon.dasgupta.ch> Message-ID: <000901cba6b4$c48dc2e0$4da948a0$@net> Ever since I found that this test is working I have been having to change that one line in the test although TrotiosHG makes it easy to keep the change even though it is not committed (shelve changes) any time I create a new local repository I have to go in and edit that one file so that the test dose not fail building in visual studio as the test when building treats warnings as errors and thus fails to even build. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Robin Cornelius Sent: Tuesday, December 28, 2010 9:45 AM To: Boroondas Gupte Cc: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] LLMatrix3::orthogonalize test (was: LL_TESTS for standalone out-of-source builds) On Wed, Oct 13, 2010 at 12:37 PM, Boroondas Gupte wrote: > On 10/13/2010 03:42 AM, WolfPup Lowenhar wrote: > > On the subject of the reason for killing test here is another reason that I > have attached this is from a full build I did today. The error listed in the > file is actually coded around and in visual studio you have to set that test > to not treat warnings as errors so that it will not fail! > > I tried removing the skip line to re-enable the test, like so: > > diff -r 27535365bd4c indra/llmath/tests/m3math_test.cpp > --- a/indra/llmath/tests/m3math_test.cpp Fri Oct 08 01:13:23 2010 +0200 > +++ b/indra/llmath/tests/m3math_test.cpp Wed Oct 13 13:16:30 2010 +0200 > @@ -280,7 +280,6 @@ > llmat_obj.setRows(llvec1, llvec2, llvec3); > llmat_obj.orthogonalize(); > > - skip("Grr, LLMatrix3::orthogonalize test is failing. Has it ever > worked?"); > ensure("LLMatrix3::orthogonalize failed ", > is_approx_equal(0.19611613f, llmat_obj.mMatrix[0][0]) && > is_approx_equal(0.78446454f, llmat_obj.mMatrix[0][1]) && > > On my system that test seems to work fine after that: > > LD_LIBRARY_PATH += ['/home/das-g/slsrc/hg/build/build/llcommon', '/usr/lib', > '/usr/local/lib'] > LD_LIBRARY_PATH = > '/usr/local/lib:/home/das-g/slsrc/hg/build/build/llcommon:/usr/lib' > Running: /home/das-g/slsrc/hg/build/build/llmath/INTEGRATION_TEST_m3math > Unit test group_started name=m3math_h > Unit test group_completed name=m3math_h > Total Tests: 13 > Passed Tests: 13 YAY!! \o/ > > Maybe someone has fixed LLMatrix3::orthogonalize but forgot to re-enable the > test? Or is LLMatrix3::orthogonalize behaving differently on different > platforms? (That should affect quaternion calculations and auto-leveling in > Flycam mode, so it's unlikely to go unnoticed.) > > Anyway, would be good if others could re-enable the test, too, and see > whether it also passes for them. Bumping this as i've just looked at it myself, the test is working fine on windows for me too and it does not appear that it needs skipping and as noticed previously in this (old) thread that the skip() is causing a unreachable code error in the test. So any reason why the test cannot be reenabled? Robin _______________________________________________ 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 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3344 - Release Date: 12/28/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/8a1fd816/attachment-0001.htm From lee.ponzu at gmail.com Tue Dec 28 09:51:42 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Tue, 28 Dec 2010 12:51:42 -0500 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: <4D1A0D01.3090707@gmail.com> References: <4D1A0AB0.3000608@gmail.com> <4D1A0D01.3090707@gmail.com> Message-ID: You mean Android on a mobile device? Or Android on a powerful desktop. What about the LL browser effort? I did not get accepted, and know nothing more about it. Seems to me that would be a way to go. Also, the Chrome OS beta that is just starting. If the LL viewer for browsers will support Chrome, then maybe that is a decent mobile SL for the future. Lastly, maybe someday in the future, they will separate the rendering from the visual, ala X Windows. You could render on the powerhouse box in the garage, but display on the lightweight client on your lap. Then, all you would need is a mobile device with high powered haptics 8-) 8-) ponzu On Tue, Dec 28, 2010 at 11:14 AM, Tateru Nino wrote: > > > On 29/12/2010 3:12 AM, Robin Cornelius wrote: > > On Tue, Dec 28, 2010 at 4:05 PM, Tateru Nino > wrote: > > > >>> So that avoids 2.e > >> I'd be more concerned about capabilities URIs, myself. The login > >> credentials are only the front-gate. > >> > > Thats absolutly true, and it would be trivial to inject a pay packet > > or any other packet into the data stream. But its probably far far > > easier to place malicious code in a TVP binary. So unless you are > > going to download the source to a TPV and diff it against LL code > > base, then compile yourself (ensuring all dependencies are also > > provided by LL/built by yourself), are you really any more at risk? , > > i'm just being a bit of a devils advocate here, my first comments were > > a literal comparison of if they met the TPV rules for listing. > Ultimately it all comes down to trust, yes - regardless of who provides > the application. > > -- > Tateru Nino > http://dwellonit.taterunino.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/c2a55486/attachment.htm From wolfpup67 at earthlink.net Tue Dec 28 09:59:05 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Tue, 28 Dec 2010 17:59:05 -0000 Subject: [opensource-dev] Review Request: Reenable the LLMatrix3::orthogonalize test in llmath/tests/m3math_test.cpp Message-ID: <20101228175905.20445.48287@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/67/ ----------------------------------------------------------- Review request for Viewer. Summary ------- This patch is to fix https://jira.secondlife.com/browse/VWR-24332 this test is working in Windows environments Diffs ----- indra/llmath/tests/m3math_test.cpp 940cd25d4b78 Diff: http://codereview.secondlife.com/r/67/diff Testing ------- Re-enabled the test and built the viewer including all tests and have no errors and all of the test done in m3math_test are reporting that they all succeed. Thanks, Wolfpup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/7be28154/attachment.htm From wolfpup67 at earthlink.net Tue Dec 28 10:05:05 2010 From: wolfpup67 at earthlink.net (Wolfpup Lowenhar) Date: Tue, 28 Dec 2010 18:05:05 -0000 Subject: [opensource-dev] Review Request: Reenable the LLMatrix3::orthogonalize test in llmath/tests/m3math_test.cpp In-Reply-To: <20101228175905.20445.48287@domU-12-31-38-00-90-68.compute-1.internal> References: <20101228175905.20445.48287@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228180505.20621.62070@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/67/ ----------------------------------------------------------- (Updated 2010-12-28 10:05:04.987644) Review request for Viewer. Changes ------- move location of link to jira Summary (updated) ------- This patch is to fix this test is working in Windows environments This addresses bug https://jira.secondlife.com/browse/VWR-24332. http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/VWR-24332 Diffs ----- indra/llmath/tests/m3math_test.cpp 940cd25d4b78 Diff: http://codereview.secondlife.com/r/67/diff Testing ------- Re-enabled the test and built the viewer including all tests and have no errors and all of the test done in m3math_test are reporting that they all succeed. Thanks, Wolfpup -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/f4bba2bd/attachment.htm From Aleric.Inglewood at gmail.com Tue Dec 28 10:10:54 2010 From: Aleric.Inglewood at gmail.com (Aleric Inglewood) Date: Tue, 28 Dec 2010 18:10:54 -0000 Subject: [opensource-dev] Review Request: Reenable the LLMatrix3::orthogonalize test in llmath/tests/m3math_test.cpp In-Reply-To: <20101228180505.20621.62070@domU-12-31-38-00-90-68.compute-1.internal> References: <20101228180505.20621.62070@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228181054.22209.54104@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/67/#review101 ----------------------------------------------------------- I think this line should be deleted, not commented out. If there still is a reason to think that it might need to be uncommented later than apparently we aren't sure the test really works, in which case I think it should be skipped until we are certain and this is fixed on all platforms. - Aleric On 2010-12-28 10:05:04, Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/67/ > ----------------------------------------------------------- > > (Updated 2010-12-28 10:05:04) > > > Review request for Viewer. > > > Summary > ------- > > This patch is to fix this test is working in Windows environments > > > This addresses bug https://jira.secondlife.com/browse/VWR-24332. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/VWR-24332 > > > Diffs > ----- > > indra/llmath/tests/m3math_test.cpp 940cd25d4b78 > > Diff: http://codereview.secondlife.com/r/67/diff > > > Testing > ------- > > Re-enabled the test and built the viewer including all tests and have no errors and all of the test done in m3math_test are reporting that they all succeed. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/866442bb/attachment.htm From merov at lindenlab.com Tue Dec 28 10:12:40 2010 From: merov at lindenlab.com (Merov Linden) Date: Tue, 28 Dec 2010 18:12:40 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL In-Reply-To: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228181240.20370.93591@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 05:16:08, Vadim ProductEngine wrote: > > indra/newview/llstartup.cpp, lines 3098-3099 > > > > > > Frankly speaking, I'm not a fan of adding another setting to only use it as a global variable. > > > > I would search for a more proper way, maybe adding get/setMapServerURL() methods to LLWorldMap. > > Perhaps a person more familiar with the world map code than me would suggest a better approach. > > Merov Linden wrote: > I don't like it either but, unfortunately, the LLWorldMap is lazy instantiated in LLFloaterWorldMap::createWorldMapView() and I can't guarantee that it exists at that point in llstartup.cpp. So I either store the map_server_url response in an ad-hoc global or, as I did, in a setting which a different sort of global when you think about it but somewhat cleaner (documented at least and with specific usage). I choose the second solution. > > > > Vadim ProductEngine wrote: > I see. Then what about storing the URL in a static member of LLWorldMap (and using static getter/setter), so we don't need it to be instantiated? Or even store in LLWorldMipmap? Hmmm... That'll require to include llworldmipmap.h or llworldmap.h in llstartup.cpp, creating yet another dependency. It's possible but I don't like it. Hard coupling (explicit calls between object instances) can become issues later, with too many code snippets knowing too many objects by name just because they need one generic access to them. Here, llstartup shouldn't have any notion of the existence of a map. It just gets some data at login from the server and save them for whoever needs them later. I prefer soft coupling where a general context is created (here by settings) and have object instances checking this context when needed. That scheme has issues also but it's more flexible. Imagine for instance what we throw the map UI and use a web based panel to display the map in the viewer (likely scenario BTW). Whoever code that will simply get the root URL from the settings, ignoring when and how it got there and ignoring the old llworldmipmap. If we create a static in llworldmipmap, that devs will have to keep llworldmipmap around or relocate that static in a new object, therefore modifying llstartup. The bottom line I think is that llstartup shouldn't be concerned by the existence of a map object. It receives some info at login and should save them in a global context. May be we should have a global "grid" context/global but I don't think we have one and the closest thing to it is a set of data saved in settings. - Merov ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/#review76 ----------------------------------------------------------- On 2010-12-22 22:15:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/61/ > ----------------------------------------------------------- > > (Updated 2010-12-22 22:15:00) > > > Review request for Viewer. > > > Summary > ------- > > Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). > > > This addresses bug STORM-805. > http://jira.secondlife.com/browse/STORM-805 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 5d69e36a53ee > indra/newview/llstartup.cpp 5d69e36a53ee > indra/newview/llworldmipmap.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/61/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/74f34db3/attachment-0001.htm From merov at lindenlab.com Tue Dec 28 10:52:53 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 28 Dec 2010 10:52:53 -0800 Subject: [opensource-dev] LLMatrix3::orthogonalize test (was: LL_TESTS for standalone out-of-source builds) In-Reply-To: <4CB599F3.6090807@boroon.dasgupta.ch> References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> <000001cb6a77$f7db0690$e79113b0$@net> <4CB599F3.6090807@boroon.dasgupta.ch> Message-ID: Hi, I think that test works fine on all platforms now and should be re-enabled. Is there a JIRA for it? Cheers, - Merov On Wed, Oct 13, 2010 at 4:37 AM, Boroondas Gupte wrote: > On 10/13/2010 03:42 AM, WolfPup Lowenhar wrote: > > On the subject of the reason for killing test here is another reason that > I have attached this is from a full build I did today. The error listed in > the file is actually coded around and in visual studio you have to set that > test to not treat warnings as errors so that it will not fail! > > I tried removing the skip line to re-enable the test, like so: > > *diff -r 27535365bd4c indra/llmath/tests/m3math_test.cpp*--- a/indra/llmath/tests/m3math_test.cpp Fri Oct 08 01:13:23 2010 +0200+++ b/indra/llmath/tests/m3math_test.cpp Wed Oct 13 13:16:30 2010 +0200@@ -280,7 +280,6 @@ > llmat_obj.setRows(llvec1, llvec2, llvec3); > llmat_obj.orthogonalize(); > - skip("Grr, LLMatrix3::orthogonalize test is failing. Has it ever worked?"); > ensure("LLMatrix3::orthogonalize failed ", > is_approx_equal(0.19611613f, llmat_obj.mMatrix[0][0]) && > is_approx_equal(0.78446454f, llmat_obj.mMatrix[0][1]) && > > On my system that test seems to work fine after that: > > LD_LIBRARY_PATH += ['/home/das-g/slsrc/hg/build/build/llcommon', '/usr/lib', '/usr/local/lib'] > LD_LIBRARY_PATH = '/usr/local/lib:/home/das-g/slsrc/hg/build/build/llcommon:/usr/lib' > Running: /home/das-g/slsrc/hg/build/build/llmath/INTEGRATION_TEST_m3math > Unit test group_started name=m3math_h > Unit test group_completed name=m3math_h > Total Tests: 13 > Passed Tests: 13 YAY!! \o/ > > Maybe someone has fixed LLMatrix3::orthogonalize but forgot to re-enable > the test? Or is LLMatrix3::orthogonalize behaving differently on different > platforms? (That should affect quaternion calculations and auto-leveling in > Flycam mode, so it's unlikely to go unnoticed.) > > Anyway, would be good if others could re-enable the test, too, and see > whether it also passes for them. > > Cheers, > Boroondas > > PS: LLMatrix3::orthogonalize is a bit of a misnomer. Without having looked > at its code (just at input and desired output in the test) it seems to > orthogonalize *and* normalize (or "ortho*normalize*" for short). Should > the method be renamed to reflect this? > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/7ad57785/attachment.htm From merov at lindenlab.com Tue Dec 28 10:53:55 2010 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Tue, 28 Dec 2010 10:53:55 -0800 Subject: [opensource-dev] LLMatrix3::orthogonalize test (was: LL_TESTS for standalone out-of-source builds) In-Reply-To: References: <4C766008.1070001@boroon.dasgupta.ch> <4C78DB67.5040005@boroon.dasgupta.ch> <4C7D501C.5040709@boroon.dasgupta.ch> <4C7E37E7.5080105@boroon.dasgupta.ch> <4CACFB0C.2020808@boroon.dasgupta.ch> <4CB30B83.1070508@lindenlab.com> <4CB36FB2.4000102@boroon.dasgupta.ch> <4CB38B4D.80004@boroon.dasgupta.ch> <000001cb6a77$f7db0690$e79113b0$@net> <4CB599F3.6090807@boroon.dasgupta.ch> Message-ID: On Tue, Dec 28, 2010 at 10:52 AM, Philippe (Merov) Bossut < merov at lindenlab.com> wrote: > > I think that test works fine on all platforms now and should be re-enabled. > > Is there a JIRA for it? > Duh: https://jira.secondlife.com/browse/VWR-24332 Sorry about that. - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/dfe1ddfe/attachment.htm From vsavchuk at productengine.com Tue Dec 28 11:41:19 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 28 Dec 2010 19:41:19 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL In-Reply-To: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223131608.7882.641@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228194119.20369.96385@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-23 05:16:08, Vadim ProductEngine wrote: > > indra/newview/llstartup.cpp, lines 3098-3099 > > > > > > Frankly speaking, I'm not a fan of adding another setting to only use it as a global variable. > > > > I would search for a more proper way, maybe adding get/setMapServerURL() methods to LLWorldMap. > > Perhaps a person more familiar with the world map code than me would suggest a better approach. > > Merov Linden wrote: > I don't like it either but, unfortunately, the LLWorldMap is lazy instantiated in LLFloaterWorldMap::createWorldMapView() and I can't guarantee that it exists at that point in llstartup.cpp. So I either store the map_server_url response in an ad-hoc global or, as I did, in a setting which a different sort of global when you think about it but somewhat cleaner (documented at least and with specific usage). I choose the second solution. > > > > Vadim ProductEngine wrote: > I see. Then what about storing the URL in a static member of LLWorldMap (and using static getter/setter), so we don't need it to be instantiated? Or even store in LLWorldMipmap? > > Merov Linden wrote: > Hmmm... That'll require to include llworldmipmap.h or llworldmap.h in llstartup.cpp, creating yet another dependency. It's possible but I don't like it. Hard coupling (explicit calls between object instances) can become issues later, with too many code snippets knowing too many objects by name just because they need one generic access to them. Here, llstartup shouldn't have any notion of the existence of a map. It just gets some data at login from the server and save them for whoever needs them later. I prefer soft coupling where a general context is created (here by settings) and have object instances checking this context when needed. That scheme has issues also but it's more flexible. Imagine for instance what we throw the map UI and use a web based panel to display the map in the viewer (likely scenario BTW). Whoever code that will simply get the root URL from the settings, ignoring when and how it got there and ignoring the old llworldmipmap. If we create a static in llworldmipmap, that devs will have to keep llworldmipmap around or relocate that static in a new object, therefore modifying llstartup. > The bottom line I think is that llstartup shouldn't be concerned by the existence of a map object. It receives some info at login and should save them in a global context. May be we should have a global "grid" context/global but I don't think we have one and the closest thing to it is a set of data saved in settings. Right, sounds reasonable. - Vadim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/#review76 ----------------------------------------------------------- On 2010-12-22 22:15:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/61/ > ----------------------------------------------------------- > > (Updated 2010-12-22 22:15:00) > > > Review request for Viewer. > > > Summary > ------- > > Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). > > > This addresses bug STORM-805. > http://jira.secondlife.com/browse/STORM-805 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 5d69e36a53ee > indra/newview/llstartup.cpp 5d69e36a53ee > indra/newview/llworldmipmap.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/61/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/1752d78f/attachment.htm From vsavchuk at productengine.com Tue Dec 28 11:41:28 2010 From: vsavchuk at productengine.com (Vadim ProductEngine) Date: Tue, 28 Dec 2010 19:41:28 -0000 Subject: [opensource-dev] Review Request: The world map can point to the wrong URL In-Reply-To: <20101223061500.7865.9735@domU-12-31-38-00-90-68.compute-1.internal> References: <20101223061500.7865.9735@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101228194128.20367.31064@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/61/#review103 ----------------------------------------------------------- Ship it! - Vadim On 2010-12-22 22:15:00, Merov Linden wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/61/ > ----------------------------------------------------------- > > (Updated 2010-12-22 22:15:00) > > > Review request for Viewer. > > > Summary > ------- > > Implements the processing of map-server-url correctly so not to overwrite the default value (which can still be useful if a grid does not implement map-server-url). > > > This addresses bug STORM-805. > http://jira.secondlife.com/browse/STORM-805 > > > Diffs > ----- > > indra/newview/app_settings/settings.xml 5d69e36a53ee > indra/newview/llstartup.cpp 5d69e36a53ee > indra/newview/llworldmipmap.cpp 5d69e36a53ee > > Diff: http://codereview.secondlife.com/r/61/diff > > > Testing > ------- > > > Thanks, > > Merov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/1decfe52/attachment-0001.htm From Celierra at gmail.com Tue Dec 28 12:40:35 2010 From: Celierra at gmail.com (Celierra Darling) Date: Tue, 28 Dec 2010 15:40:35 -0500 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: <20101227165911.GA22986@alinoe.com> References: <285058.60774.qm@web23905.mail.ird.yahoo.com> <327279.85976.qm@web23904.mail.ird.yahoo.com> <20101227165911.GA22986@alinoe.com> Message-ID: It seems a little unclear to try to communicate "this can have privacy implications" by putting the setting on the privacy tab. It might be better to write the setting label so it's more explicit (i.e. something like "Show my favorites to anyone under 'Start At' before logging in" or "Show my favorites under 'Start At' on login (before authenticating)" or etc.). Celi On Mon, Dec 27, 2010 at 11:59 AM, Carlo Wood wrote: > > I kinda have to agree with hitomi. > > I agree with Andrew; it's a privacy sensitive thing > and users shouldn't accidently flip it without thinking > because it's on the normal 'General' page. > If they need or want it, then I'm sure they'll find it, > like they find everything else. Also, it will take a > while before a user needs links to favourite places > on their login page: those are not newbies. It's sufficient > to put the option in a place that requires more knowledge > (and exploration) of the viewer interface. > > -- > Carlo Wood > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/edc7a013/attachment.htm From trilobyte550m at gmail.com Tue Dec 28 12:46:54 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Tue, 28 Dec 2010 12:46:54 -0800 Subject: [opensource-dev] Test binary for in review JIRAs In-Reply-To: References: Message-ID: Great stuff! * STORM-34 : As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be. Works well in 217881, Mac client. Ghosted (and disabled) before login. Once enabled, favorites appear in drop-down, and logging in to a saved Favorite location works as expected. * STORM-242 : Server version dialog message has incorrect release notes link (modulo one build issue fixed...) Nice one! I've occasionally noticed incorrect release notes links in the past, but always chalked it up to incorrect link data coming from the server. Tested in developer build 217881, Mac client while flying around the multi-region Caledon community, and when crossing into regions on different versions the links worked correctly. * STORM-398 : Message from nearby chat appears for avatar in Busy mode Works well in build 217881, Mac client. * STORM-466 : 2.x minimap cannot be reset to default zoom. Works great in developer build 217881, Mac client. Woohoo for Default Zoom! * STORM-467 : 2.x minimap zoom does not persist to the next session. Works well in developer build 217881, Mac client. * STORM-485 : 'Cancel' button exceed the bounds of 'Group Invitation' floater. Works in developer build 217881. Mac client :) * STORM-682 : IM and notification toasts appear in wrong position if switch on mouse look when side tray is expanded In developer build 217881, Mac client, works well (but only after I remember to re-enable incoming IM popups haha) * STORM-737 : Inventory Recent tab is missing "+" control at bottom of panel Developer build 217881, Mac client. Only the New Folder option is grayed out when using the + menu on the recent tab. Works as I'd expect. On Dec 27, 2010, at 11:55 PM, Philippe (Merov) Bossut wrote: > Hi, > > We're having a lot of JIRAs in the "In Review" swim lane for sprint 9 waiting for reviews from PO and/or devs. I created a Mac binary (others building right now) for those: > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/217880/arch/Darwin/index.html > > JIRAs merged in there: > * STORM-34 : As a User, I want a list of my favorite locations available on the login screen so i can log in to SL right where I want to be. > * STORM-242 : Server version dialog message has incorrect release notes link (modulo one build issue fixed...) > * STORM-398 : Message from nearby chat appears for avatar in Busy mode > * STORM-466 : 2.x minimap cannot be reset to default zoom. > * STORM-467 : 2.x minimap zoom does not persist to the next session. > * STORM-485 : 'Cancel' button exceed the bounds of 'Group Invitation' floater. > * STORM-682 : IM and notification toasts appear in wrong position if switch on mouse look when side tray is expanded > * STORM-737 : Inventory Recent tab is missing "+" control at bottom of panel > * STORM-805 : The world map can point to the wrong URL > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/fe13ba46/attachment.htm From opensourceobscure at gmail.com Tue Dec 28 13:37:26 2010 From: opensourceobscure at gmail.com (Opensource Obscure) Date: Tue, 28 Dec 2010 22:37:26 +0100 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: <4D1A0AB0.3000608@gmail.com> <4D1A0D01.3090707@gmail.com> Message-ID: On Tue, Dec 28, 2010 at 18:51, Ponzu wrote: > You mean Android on a mobile device? Yeah - I'm looking for a text-only client that could run on existing low-end (non-rooted) mobile devices running Android. Opensource Obscure From sllists at boroon.dasgupta.ch Tue Dec 28 13:58:01 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 28 Dec 2010 22:58:01 +0100 Subject: [opensource-dev] Indicating privacy implications of preference settings (was: STORM-34 Test Binaries) In-Reply-To: References: <285058.60774.qm@web23905.mail.ird.yahoo.com> <327279.85976.qm@web23904.mail.ird.yahoo.com> <20101227165911.GA22986@alinoe.com> Message-ID: <4D1A5D69.8020504@boroon.dasgupta.ch> On 12/28/2010 09:40 PM, Celierra Darling wrote: > It seems a little unclear to try to communicate "this can have privacy > implications" by putting the setting on the privacy tab. It might be > better to write the setting label so it's more explicit (i.e. > something like "Show my favorites to anyone under 'Start At' before > logging in" or "Show my favorites under 'Start At' on login (before > authenticating)" or etc.). I have to agree that placing settings on the "privacy" tab is not a good way to indicate the fact that they have privacy implications. It goes against the principle that a setting should be placed where users expect it. I.e., if you know (or suspect) a setting exists, but don't know where to find it, where would you first look for it? Education about the consequences of changing the setting can be postponed until after you found it. Of course, besides looking at tab labels, placing similar or related settings together can help in finding them. But the common property "affects privacy" seems to me too week a reason for placing settings on the same tab, when that property is not the goal of a setting but rather a side effect (even although a side effect inherent to the goal itself, not just to the setting's implementation). Further, when a user finds a setting on the "privacy" tab *and* realizes this placement means the setting has privacy implications, how would she or he know whether enabling or disabling the setting grants higher privacy? Of course, if one can derive from the description of a setting what it actually does and then thinks it all through, one gets the answer as well as how one's privacy would be affected. While the users are probably well capable to do that, do they want to do that---when they could just as well be told openly about the setting's effect, e.g. like in Celierra's labeling proposals above? Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/d223f0f4/attachment.htm From Lance.Corrimal at eregion.de Tue Dec 28 14:16:51 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 28 Dec 2010 23:16:51 +0100 Subject: [opensource-dev] Indicating privacy implications of preference settings (was: STORM-34 Test Binaries) In-Reply-To: <4D1A5D69.8020504@boroon.dasgupta.ch> References: <4D1A5D69.8020504@boroon.dasgupta.ch> Message-ID: <201012282316.51613.Lance.Corrimal@eregion.de> Am Dienstag, 28. Dezember 2010 schrieb Boroondas Gupte: > On 12/28/2010 09:40 PM, Celierra Darling wrote: > > It seems a little unclear to try to communicate "this can have > > privacy implications" by putting the setting on the privacy tab. > > It might be better to write the setting label so it's more > > explicit (i.e. something like "Show my favorites to anyone under > > 'Start At' before logging in" or "Show my favorites under 'Start > > At' on login (before authenticating)" or etc.). > > I have to agree that placing settings on the "privacy" tab is not a > good way to indicate the fact that they have privacy implications. > It goes against the principle that a setting should be placed > where users expect it. I.e., if you know (or suspect) a setting > exists, but don't know where to find it, where would you first > look for it? Education about the consequences of changing the > setting can be postponed until after you found it. possible solution: "make it so" that enabling this displays a popup telling the user "this might disclose your favorite places to anyone who has physical access to your computer", similar to the "restart the viewer" popup that appears on changing some other settings. bye, LC From Lance.Corrimal at eregion.de Tue Dec 28 14:22:06 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 28 Dec 2010 23:22:06 +0100 Subject: [opensource-dev] saved logins (was: STORM-34 Test Binaries) In-Reply-To: <201012282316.51613.Lance.Corrimal@eregion.de> References: <4D1A5D69.8020504@boroon.dasgupta.ch> <201012282316.51613.Lance.Corrimal@eregion.de> Message-ID: <201012282322.06236.Lance.Corrimal@eregion.de> loosely related to storm-34: I would really see my saved logins back in 2.x, similar to snowglobe 1.5... and yes, i am aware of the fact that with that anyone with physical access to my computer can log in under my avatar, and pass all my money to someone, and delete all that i own, and pixelrape my pixelwife with noone the wiser. problem with that, that someone needs my cellphone within bluetooth reception range to unlock my screensaver. From lee.ponzu at gmail.com Tue Dec 28 14:24:45 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Tue, 28 Dec 2010 17:24:45 -0500 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: <4D1A0AB0.3000608@gmail.com> <4D1A0D01.3090707@gmail.com> Message-ID: /me imagines a viewer that uses various ascii characters to render the graphics... On Tue, Dec 28, 2010 at 4:37 PM, Opensource Obscure < opensourceobscure at gmail.com> wrote: > On Tue, Dec 28, 2010 at 18:51, Ponzu wrote: > > You mean Android on a mobile device? > > Yeah - I'm looking for a text-only client that could run on > existing low-end (non-rooted) mobile devices running Android. > > Opensource Obscure > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/a774eef9/attachment.htm From sllists at boroon.dasgupta.ch Tue Dec 28 16:01:05 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 29 Dec 2010 00:01:05 -0000 Subject: [opensource-dev] Review Request: Reenable the LLMatrix3::orthogonalize test in llmath/tests/m3math_test.cpp In-Reply-To: <20101228181054.22209.54104@domU-12-31-38-00-90-68.compute-1.internal> References: <20101228181054.22209.54104@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101229000105.20621.75667@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-28 10:10:54, Aleric Inglewood wrote: > > I think this line should be deleted, not commented out. If there still is a reason to think that it might need to be uncommented later than apparently we aren't sure the test really works, in which case I think it should be skipped until we are certain and this is fixed on all platforms. I agree: Delete the line, don't just comment it out. The fact that it was once there will be preserved in the revision history, which should be sufficient. - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/67/#review101 ----------------------------------------------------------- On 2010-12-28 10:05:04, Wolfpup Lowenhar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/67/ > ----------------------------------------------------------- > > (Updated 2010-12-28 10:05:04) > > > Review request for Viewer. > > > Summary > ------- > > This patch is to fix this test is working in Windows environments > > > This addresses bug https://jira.secondlife.com/browse/VWR-24332. > http://jira.secondlife.com/browse/https://jira.secondlife.com/browse/VWR-24332 > > > Diffs > ----- > > indra/llmath/tests/m3math_test.cpp 940cd25d4b78 > > Diff: http://codereview.secondlife.com/r/67/diff > > > Testing > ------- > > Re-enabled the test and built the viewer including all tests and have no errors and all of the test done in m3math_test are reporting that they all succeed. > > > Thanks, > > Wolfpup > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/06e1bdef/attachment.htm From suezanne at gmail.com Tue Dec 28 16:52:40 2010 From: suezanne at gmail.com (SuezanneC Baskerville) Date: Tue, 28 Dec 2010 18:52:40 -0600 Subject: [opensource-dev] Is there supposed to be a login web page for the development viewer? (An SL screenshot, maybe some text, like the regular viewer has) In-Reply-To: References: Message-ID: I'm getting that question mark with the development viewer. On Tue, Nov 23, 2010 at 12:45 PM, Joshua Bell wrote: > On Mon, Nov 22, 2010 at 4:58 PM, Chuck Baggett wrote: > >> When I log in with the development viewer there is no login web page, just >> a little question mark. The part at the bottom where you enter your >> username, password, etc. works fine. Is there supposed to be an SL >> screenshot, maybe some text, like the regular viewer has? >> > > This should be working now. Apparently we changed the channel name and/or > page logic at some point and didn't ensure all of the resources were in > place for the "Second Life Development" channel. > > > > > _______________________________________________ > 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 > -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101228/8690581c/attachment.htm From jamey at beau.org Tue Dec 28 17:00:36 2010 From: jamey at beau.org (Jamey Fletcher) Date: Tue, 28 Dec 2010 19:00:36 -0600 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: <4D1A0AB0.3000608@gmail.com> <4D1A0D01.3090707@gmail.com> Message-ID: <4D1A8834.7000407@beau.org> Ponzu wrote: > /me imagines a viewer that uses various ascii characters to render the > graphics... *COULD* someone be insane enough to hook up AAlib or libcaca to the viewer? What a scary thought! From carlo at alinoe.com Tue Dec 28 17:05:43 2010 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 29 Dec 2010 02:05:43 +0100 Subject: [opensource-dev] Indicating privacy implications of preference settings (was: STORM-34 Test Binaries) In-Reply-To: <4D1A5D69.8020504@boroon.dasgupta.ch> References: <285058.60774.qm@web23905.mail.ird.yahoo.com> <327279.85976.qm@web23904.mail.ird.yahoo.com> <20101227165911.GA22986@alinoe.com> <4D1A5D69.8020504@boroon.dasgupta.ch> Message-ID: <20101229010543.GA26672@alinoe.com> Ok, good points. I take back what I said :). The best way forward seems to put it where people might first look and then make clear that everyone can see them with text right there. On Tue, Dec 28, 2010 at 10:58:01PM +0100, Boroondas Gupte wrote: > On 12/28/2010 09:40 PM, Celierra Darling wrote: > > It seems a little unclear to try to communicate "this can have privacy > implications" by putting the setting on the privacy tab. It might be > better to write the setting label so it's more explicit (i.e. something > like "Show my favorites to anyone under 'Start At' before logging in" or > "Show my favorites under 'Start At' on login (before authenticating)" or > etc.). > > I have to agree that placing settings on the "privacy" tab is not a good way to > indicate the fact that they have privacy implications. It goes against the > principle that a setting should be placed where users expect it. I.e., if you > know (or suspect) a setting exists, but don't know where to find it, where > would you first look for it? Education about the consequences of changing the > setting can be postponed until after you found it. > > Of course, besides looking at tab labels, placing similar or related settings > together can help in finding them. But the common property "affects privacy" > seems to me too week a reason for placing settings on the same tab, when that > property is not the goal of a setting but rather a side effect (even although a > side effect inherent to the goal itself, not just to the setting's > implementation). > > Further, when a user finds a setting on the "privacy" tab and realizes this > placement means the setting has privacy implications, how would she or he know > whether enabling or disabling the setting grants higher privacy? Of course, if > one can derive from the description of a setting what it actually does and then > thinks it all through, one gets the answer as well as how one's privacy would > be affected. While the users are probably well capable to do that, do they want > to do that?when they could just as well be told openly about the setting's > effect, e.g. like in Celierra's labeling proposals above? > > 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 -- Carlo Wood From ibrew.meads at gmail.com Tue Dec 28 18:53:33 2010 From: ibrew.meads at gmail.com (Ibrew Meads) Date: Tue, 28 Dec 2010 18:53:33 -0800 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: <4D1A0AB0.3000608@gmail.com> <4D1A0D01.3090707@gmail.com> Message-ID: There are two mono implementations for Android (one open source in alpha and one soon to be released by Novell) and several text based clients that run on mono, so i expect that there will be one available very soon. Otherwise there's the pay-as-you-go Mobile Grid client discussed earlier. Or you could access via a browser by setting up a private server with ajaxlife on it, or use the soon to be released LL web interface. Ibrew On Tue, Dec 28, 2010 at 1:37 PM, Opensource Obscure wrote: > On Tue, Dec 28, 2010 at 18:51, Ponzu wrote: >> You mean Android on a mobile device? > > Yeah - I'm looking for a text-only client that could run on > existing low-end (non-rooted) mobile devices running Android. > > Opensource Obscure > _______________________________________________ > 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 > From merov at lindenlab.com Tue Dec 28 22:45:28 2010 From: merov at lindenlab.com (Merov Linden) Date: Wed, 29 Dec 2010 06:45:28 -0000 Subject: [opensource-dev] Review Request: KDU Improvements: add unit tests for llkdu In-Reply-To: <20101224194622.7891.93749@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224194622.7891.93749@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101229064528.20365.92053@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/63/ ----------------------------------------------------------- (Updated 2010-12-28 22:45:28.345670) Review request for Viewer. Changes ------- Here's a new diff that changes a bit the llimagej2ckdu.cpp code so that it works consistently for unit tests on all build options on all platforms. I added extra comments in the llimagej2ckdu_test.cpp to explain the result. Clearly, we also need to create integration tests for this but that should be another JIRA. Summary ------- Unit tests addition: - add tests for llkdu - turned back on and fix unit tests for llimage - turned back on and fix unit tests for llworldmap and llworldmipmap This addresses bug STORM-744. http://jira.secondlife.com/browse/STORM-744 Diffs (updated) ----- indra/llimage/CMakeLists.txt 43cf4a37774c indra/llimage/tests/llimageworker_test.cpp 43cf4a37774c indra/llimagej2coj/llimagej2coj.h 43cf4a37774c indra/llimagej2coj/llimagej2coj.cpp 43cf4a37774c indra/llkdu/CMakeLists.txt 43cf4a37774c indra/llkdu/llimagej2ckdu.h 43cf4a37774c indra/llkdu/llimagej2ckdu.cpp 43cf4a37774c indra/llkdu/tests/llimagej2ckdu_test.cpp PRE-CREATION indra/newview/CMakeLists.txt 43cf4a37774c indra/newview/tests/llworldmap_test.cpp 43cf4a37774c indra/newview/tests/llworldmipmap_test.cpp 43cf4a37774c Diff: http://codereview.secondlife.com/r/63/diff Testing ------- Thanks, Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/14403c09/attachment-0001.htm From sllists at boroon.dasgupta.ch Wed Dec 29 02:12:38 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 29 Dec 2010 10:12:38 -0000 Subject: [opensource-dev] Review Request: Constraints in XUI files don't match the constraints imposed elsewhere in the viewer/server code. In-Reply-To: <20101224190643.7868.40610@domU-12-31-38-00-90-68.compute-1.internal> References: <20101224190643.7868.40610@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101229101238.20364.45550@domU-12-31-38-00-90-68.compute-1.internal> > On 2010-12-24 11:06:43, Vadim ProductEngine wrote: > > How do you know the server constraints? Signpost already answered a similar question on jira: https://jira.secondlife.com/browse/VWR-24197?focusedCommentId=228070&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-228070 - Boroondas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/57/#review86 ----------------------------------------------------------- On 2010-12-22 12:17:10, SignpostMarv Martin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/57/ > ----------------------------------------------------------- > > (Updated 2010-12-22 12:17:10) > > > Review request for Viewer. > > > Summary > ------- > > Constraints in XUI files don't match the constraints imposed elsewhere in the viewer/server code. > > Don't know where the constraints are specified, but this XUI mod lets the user play within the full range of the actual constraints. > > JIRA page has screenshots of before & after. > > > This addresses bug VWR-24197. > http://jira.secondlife.com/browse/VWR-24197 > > > Diffs > ----- > > indra/newview/skins/default/xui/en/floater_tools.xml UNKNOWN > > Diff: http://codereview.secondlife.com/r/57/diff > > > Testing > ------- > > > Thanks, > > SignpostMarv > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/e9f2237b/attachment.htm From duncan.bradders at gmail.com Wed Dec 29 07:21:01 2010 From: duncan.bradders at gmail.com (Duncan Bradders) Date: Wed, 29 Dec 2010 10:51:01 -0430 Subject: [opensource-dev] Debian Squeeze compiling Message-ID: Hello, I'm trying to compile the latest viewer development on my distro, the envoronment it's the same for other viewers and usually I can compile TPV V1 viewers. dbradders at Casa:~/Src/viewer-development/indra$ ./develop.py --type=Release configure 2>&1 | tee build.log then: dbradders at Casa:~/Src/viewer-development/indra$ ./develop.py --type=Release build 2>&1 | tee -a build.log It tell me fmod.h is missing but it's not. Where I'm wrong? many thanks in advance for any hint... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/c41ba70b/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: build.log Type: text/x-log Size: 24970 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/c41ba70b/attachment-0001.bin From lee.ponzu at gmail.com Wed Dec 29 07:36:35 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 29 Dec 2010 10:36:35 -0500 Subject: [opensource-dev] Very Strange occurrence... Message-ID: ....Last night I was using the 2.5 beta I had just built from the weekend's changes, and this odd thing happened... I logged in. My friends list showed ???. (Odd, the pictures load OK, but not the names.) I had been logged in about 15 minutes. Then I got an IM from Grumpity Productengine. So far as I know, I don't know Grumpity. I assumed it was someone from this list. The text of the message was something like, "Hi. I was between Highland and La Brea on Franklin, so I thought of you." This message is significant to me, but I don't know how any Productengines would know that. So, I started having a conversation with Grumpity, trying to hide my embarrassment about not really knowing who it was. After two or three minutes, I noticed that Grumpity was now ???. After a bit of conversation, I finally figured out I was talking to a friend named Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite Tagore and all was more or less normal (snafu 8-). No, I do not have a repro. No, I was not stoned beyond oblivion. Just reporting on the off chance that someone will find the information useful for debugging some display name problem or something. regards, ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/668445f6/attachment.htm From soft at lindenlab.com Wed Dec 29 08:44:02 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Wed, 29 Dec 2010 08:44:02 -0800 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: Message-ID: On Wed, Dec 29, 2010 at 7:36 AM, Ponzu wrote: > ....Last night I was using the 2.5 beta I had just built from the weekend's > changes, and this odd thing happened... > > I logged in. My friends list showed ???. (Odd, the pictures load OK, but > not the names.) I had been logged in about 15 minutes. > > Then I got an IM from Grumpity Productengine. So far as I know, I don't > know Grumpity. I assumed it was someone from this list. The text of the > message was something like, "Hi. I was between Highland and La Brea on > Franklin, so I thought of you." This message is significant to me, but I > don't know how any Productengines would know that. > > So, I started having a conversation with Grumpity, trying to hide my > embarrassment about not really knowing who it was. > > After two or three minutes, I noticed that Grumpity was now ???. After a > bit of conversation, I finally figured out I was talking to a friend named > Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite > Tagore and all was more or less normal (snafu 8-). > > No, I do not have a repro. No, I was not stoned beyond oblivion. > > Just reporting on the off chance that someone will find the information > useful for debugging some display name problem or something. > That was the result of a brief load server configuration problem yesterday, and it shouldn't repeat. The message didn't come from Grumpity, and the response wouldn't have gone back to Grumpity either. The viewer simply didn't know which cached name to use. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/e04358fc/attachment.htm From trilobyte550m at gmail.com Wed Dec 29 08:46:52 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 29 Dec 2010 08:46:52 -0800 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: Message-ID: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> It's not you, it's been happening to others. A lot. Before Christmas it happened much less frequently, but since then the phenomenon's been occurring at least once a day. Sometimes they're ??? at login, sometimes they show properly at first and then flip to ??? on their own. Sometimes the ???'s remain throughout the session, and sometimes they flip back to show the correct names. It happens regardless of whether the user has a Display Name set or not. I've also noticed that if someone with a ??? name types an action in group chat (line starting with /me) it displays their user name. Also, sometimes, if you look up the profile of a person showing ??? it shows the correct name on the profile. As far as I can tell, it's a server-side condition that only appears to be happening on Display Names capable viewers. https://jira.secondlife.com/browse/DN-202 On Dec 29, 2010, at 7:36 AM, Ponzu wrote: > ....Last night I was using the 2.5 beta I had just built from the weekend's changes, and this odd thing happened... > > I logged in. My friends list showed ???. (Odd, the pictures load OK, but not the names.) I had been logged in about 15 minutes. > > Then I got an IM from Grumpity Productengine. So far as I know, I don't know Grumpity. I assumed it was someone from this list. The text of the message was something like, "Hi. I was between Highland and La Brea on Franklin, so I thought of you." This message is significant to me, but I don't know how any Productengines would know that. > > So, I started having a conversation with Grumpity, trying to hide my embarrassment about not really knowing who it was. > > After two or three minutes, I noticed that Grumpity was now ???. After a bit of conversation, I finally figured out I was talking to a friend named Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite Tagore and all was more or less normal (snafu 8-). > > No, I do not have a repro. No, I was not stoned beyond oblivion. > > Just reporting on the off chance that someone will find the information useful for debugging some display name problem or something. > > regards, > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/b9bebbd4/attachment.htm From soft at lindenlab.com Wed Dec 29 08:47:42 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Wed, 29 Dec 2010 08:47:42 -0800 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: References: Message-ID: On Tue, Dec 28, 2010 at 7:57 AM, Robin Cornelius wrote: > On Tue, Dec 28, 2010 at 3:55 PM, Robin Cornelius > wrote: > > > The other issue is, if they are using a central server to perform the > > connection to SL then transmitting revelant data to your handset, > > unless they have been very clever to avoid TPV clause 2.e, and it > > seems to be this that is mentioned in the linked discussion, then that > > would be considered a serious issue by LL, even if they had all good > > intentions. > > And in the worst possible email etiquette, replying to ones self.. > > Their changelog says > > 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 > That change was made at our request in order to come into compliance. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/c06f85df/attachment.htm From sl.nicky.ml at googlemail.com Wed Dec 29 08:51:43 2010 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Wed, 29 Dec 2010 17:51:43 +0100 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session Message-ID: Hello, did anyone ever have the following problem? I start snowstorm directly under gdb, run it. Then after a while (mostly after SL login) my machine GUI locks up. I cannot use any X programs anymore, if I run mplayer it will stop playing music. Neither can I kill the X server or switch session. But I can ssh into the machine. There I see the snowstorm binary taking all CPU time. Once I kill snowstorm and gdb via this ssh login everything will be good again. I get a hunch that this has to do with the threads snowstorm creates. As the last thing I usually see in the gdb output is a line 'Thread .... created'. Of course this could be a coincidence. This is a very annoying issue, as it makes debugging Snowstorm (actually it seems to affect all V2 based viewers) nearly impossible. The GDB version I use is 'GNU gdb (Gentoo 7.2 p1) 7.2'. Kernel is 2.6.36-gentoo-r3. Snowstorm is synced to the latest changes. For snowstorm and kernel I already tried different versions. It did not help at all. I even tried Phoenix-Firestorm, same result. Has anyone ever seen something like this, or got a slight idea what I might try? Can the threads in snowstorm be temporarily disabled to make sure they are either causing or not causing this? Cheers, Nicky From soft at lindenlab.com Wed Dec 29 09:04:00 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Wed, 29 Dec 2010 09:04:00 -0800 Subject: [opensource-dev] Anyone playing with Android and Second Life? In-Reply-To: <4D1A0AB0.3000608@gmail.com> References: <4D1A0AB0.3000608@gmail.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/832f1e71/attachment-0001.htm From lee.ponzu at gmail.com Wed Dec 29 09:56:42 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Wed, 29 Dec 2010 12:56:42 -0500 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> Message-ID: OK, thanks. Sort of like the good old days. 8-) BTW, if anyone wants to go to the Magic Castle in Hollywood, ever, I am a member and can send you an invitation good for 8 people. ponzu On Wed, Dec 29, 2010 at 11:46 AM, Trilo Byte wrote: > It's not you, it's been happening to others. A lot. > > Before Christmas it happened much less frequently, but since then the > phenomenon's been occurring at least once a day. Sometimes they're ??? at > login, sometimes they show properly at first and then flip to ??? on their > own. Sometimes the ???'s remain throughout the session, and sometimes they > flip back to show the correct names. It happens regardless of whether the > user has a Display Name set or not. > > I've also noticed that if someone with a ??? name types an action in group > chat (line starting with /me) it displays their user name. Also, sometimes, > if you look up the profile of a person showing ??? it shows the correct name > on the profile. As far as I can tell, it's a server-side condition that > only appears to be happening on Display Names capable viewers. > > https://jira.secondlife.com/browse/DN-202 > > On Dec 29, 2010, at 7:36 AM, Ponzu wrote: > > ....Last night I was using the 2.5 beta I had just built from the weekend's > changes, and this odd thing happened... > > I logged in. My friends list showed ???. (Odd, the pictures load OK, but > not the names.) I had been logged in about 15 minutes. > > Then I got an IM from Grumpity Productengine. So far as I know, I don't > know Grumpity. I assumed it was someone from this list. The text of the > message was something like, "Hi. I was between Highland and La Brea on > Franklin, so I thought of you." This message is significant to me, but I > don't know how any Productengines would know that. > > So, I started having a conversation with Grumpity, trying to hide my > embarrassment about not really knowing who it was. > > After two or three minutes, I noticed that Grumpity was now ???. After a > bit of conversation, I finally figured out I was talking to a friend named > Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite > Tagore and all was more or less normal (snafu 8-). > > No, I do not have a repro. No, I was not stoned beyond oblivion. > > Just reporting on the off chance that someone will find the information > useful for debugging some display name problem or something. > > regards, > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/78e726e8/attachment.htm From oz at lindenlab.com Wed Dec 29 10:02:20 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 29 Dec 2010 13:02:20 -0500 Subject: [opensource-dev] Snowstorm Scrum Cancelled today Message-ID: <4D1B77AC.208@lindenlab.com> I have an internal meeting conflict, and as far as I know am the only Linden on the team working today. I will be holding my OH as usual this afternoon... please bring any issues there. From carlo at alinoe.com Wed Dec 29 10:11:20 2010 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 29 Dec 2010 19:11:20 +0100 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: Message-ID: <20101229181120.GB26522@alinoe.com> It is still a (serious) bug. The viewer should have showed '???', not Grumpity. On Wed, Dec 29, 2010 at 08:44:02AM -0800, Brian McGroarty wrote: > That was the result of a brief load server configuration problem yesterday, and > it shouldn't repeat. The message didn't come from Grumpity, and the response > wouldn't have gone back to Grumpity either. The viewer simply didn't know which > cached name to use. -- Carlo Wood From aleric.inglewood at gmail.com Wed Dec 29 10:19:33 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 29 Dec 2010 19:19:33 +0100 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: References: Message-ID: Hi NickyP, yes, this is a "known" problem: the viewer sometimes locks the X display, if then you halt it in the debugger you're toast. I worked around this by running the debugger from different X display. That can be a second X running on the same PC (ie second video card) or just another PC with it's own videocard and X server. Assuming the latter, you'd open an xterm on the second PC, login (using ssh for example) to the PC running the viewer and then setting DISPLAY to the display of the PC running the viewer of course ;) (ie: export DISPLAY=hikaru:0.0, where hikaru is the name of my PC running the viewer). Then start gdb as usual. For this to work however, you must configure X to allow connections from that other PC. In order to test if that part works I'd first try running xterm instead of gdb+viewer ;). You probably need to change a configuration on the gdm login screen (sorry I forgot) to get X to listen on port 6000 at ALL (check with netstat) and then you need to give your other PC access by running xhost). On Wed, Dec 29, 2010 at 5:51 PM, Nicky D. wrote: > Hello, > > did anyone ever have the following problem? I start snowstorm directly > under gdb, run it. Then after a while (mostly after SL login) my > machine GUI locks up. > > I cannot use any X programs anymore, if I run mplayer it will stop > playing music. Neither can I kill the X server or switch session. But > I can ssh into the > machine. There I see the snowstorm binary taking all CPU time. Once I > kill snowstorm and gdb via this ssh login everything will be good > again. > > I get a hunch that this has to do with the threads snowstorm creates. > As the last thing I usually see in the gdb output is a line 'Thread > .... created'. Of course > this could be a coincidence. > > This is a very annoying issue, as it makes debugging Snowstorm > (actually it seems to affect all V2 based viewers) nearly impossible. > > The GDB version I use is 'GNU gdb (Gentoo 7.2 p1) 7.2'. Kernel is > 2.6.36-gentoo-r3. Snowstorm is synced to the latest changes. > > For snowstorm and kernel I already tried different versions. It did > not help at all. I even tried Phoenix-Firestorm, same result. > > Has anyone ever seen something like this, or got a slight idea what I might try? > Can the threads in snowstorm be temporarily disabled to make sure they > are either causing or not causing this? > > Cheers, > ? Nicky > _______________________________________________ > 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 > From bunny at bunnynet.org Wed Dec 29 10:42:18 2010 From: bunny at bunnynet.org (Bunny Halberd) Date: Wed, 29 Dec 2010 12:42:18 -0600 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> Message-ID: On Wed, Dec 29, 2010 at 10:46 AM, Trilo Byte wrote: > It's not you, it's been happening to others. ?A lot. It's really confusing the heck out of newbies. I've gotten to the point where I have to explain to people how to turn off Display Names a few times an hour. (Ctrl-P -> General -> Uncheck "View Display Names"... see? I'm at work and I still have the path memorized.) The viewer REALLY needs to fall back to showing a username rather than ??? ??? for the name. ??? ??? should never be shown, in my opinion. A username is a far, far better fallback. Or even their key -- anything other than ??? ???! - Bunny From trilobyte550m at gmail.com Wed Dec 29 10:43:15 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 29 Dec 2010 10:43:15 -0800 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: Message-ID: It's still happening (currently), in only some of my groups. On Dec 29, 2010, at 8:44 AM, Brian McGroarty wrote: > On Wed, Dec 29, 2010 at 7:36 AM, Ponzu wrote: > ....Last night I was using the 2.5 beta I had just built from the weekend's changes, and this odd thing happened... > > I logged in. My friends list showed ???. (Odd, the pictures load OK, but not the names.) I had been logged in about 15 minutes. > > Then I got an IM from Grumpity Productengine. So far as I know, I don't know Grumpity. I assumed it was someone from this list. The text of the message was something like, "Hi. I was between Highland and La Brea on Franklin, so I thought of you." This message is significant to me, but I don't know how any Productengines would know that. > > So, I started having a conversation with Grumpity, trying to hide my embarrassment about not really knowing who it was. > > After two or three minutes, I noticed that Grumpity was now ???. After a bit of conversation, I finally figured out I was talking to a friend named Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite Tagore and all was more or less normal (snafu 8-). > > No, I do not have a repro. No, I was not stoned beyond oblivion. > > Just reporting on the off chance that someone will find the information useful for debugging some display name problem or something. > > That was the result of a brief load server configuration problem yesterday, and it shouldn't repeat. The message didn't come from Grumpity, and the response wouldn't have gone back to Grumpity either. The viewer simply didn't know which cached name to use. > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/250316df/attachment.htm From oz at lindenlab.com Wed Dec 29 12:13:44 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 29 Dec 2010 15:13:44 -0500 Subject: [opensource-dev] saved logins In-Reply-To: <201012282322.06236.Lance.Corrimal@eregion.de> References: <4D1A5D69.8020504@boroon.dasgupta.ch> <201012282316.51613.Lance.Corrimal@eregion.de> <201012282322.06236.Lance.Corrimal@eregion.de> Message-ID: <4D1B9678.3050205@lindenlab.com> On 2010-12-28 17:22, Lance Corrimal wrote: > loosely related to storm-34: I would really see my saved logins back > in 2.x, similar to snowglobe 1.5... I'm not clear on what you think is missing... it remembers my username and password.... From monty at lindenlab.com Wed Dec 29 12:30:55 2010 From: monty at lindenlab.com (Monty Brandenberg) Date: Wed, 29 Dec 2010 15:30:55 -0500 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: References: Message-ID: <4D1B9A7F.8000809@lindenlab.com> On 12/29/2010 1:19 PM, Aleric Inglewood wrote: > yes, this is a "known" problem: the viewer sometimes locks the X display, > if then you halt it in the debugger you're toast. I only have creaky old Debians at hand but wondered if those with more modern distros with updated GTKs can work around it by changing the 'gtk_debug_flags'. There's now a GTK_DEBUG_NOGRABS flag (1 << 12, I think). Set that and play a bit. No guarantees, you'll need very recent libs and I don't know at what point in execution you'll need to set that flag. (The --gtk-debug and --gdk-debug cmd options also drive this.) But there it is... -- Monty Brandenberg 617.401.2384 monty at lindenlab.com From zabb65 at gmail.com Wed Dec 29 13:00:40 2010 From: zabb65 at gmail.com (Zabb65) Date: Wed, 29 Dec 2010 16:00:40 -0500 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: <4D1B9A7F.8000809@lindenlab.com> References: <4D1B9A7F.8000809@lindenlab.com> Message-ID: Reading through the documentation on this. It may be easier to just add "GDK_DEBUG=nograbs" to the shell script launcher when it uses GDB, and have it work on all distros, up to date or not? On Wed, Dec 29, 2010 at 15:30, Monty Brandenberg wrote: > On 12/29/2010 1:19 PM, Aleric Inglewood wrote: > >> yes, this is a "known" problem: the viewer sometimes locks the X display, >> if then you halt it in the debugger you're toast. > > I only have creaky old Debians at hand but wondered if those with > more modern distros with updated GTKs can work around it by > changing the 'gtk_debug_flags'. ?There's now a GTK_DEBUG_NOGRABS > flag (1 << 12, I think). ?Set that and play a bit. ?No guarantees, > you'll need very recent libs and I don't know at what point in > execution you'll need to set that flag. ?(The --gtk-debug and > --gdk-debug cmd options also drive this.) ?But there it is... > > -- > Monty Brandenberg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 617.401.2384 > monty at lindenlab.com > _______________________________________________ > 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 > From monty at lindenlab.com Wed Dec 29 13:04:38 2010 From: monty at lindenlab.com (Monty Brandenberg) Date: Wed, 29 Dec 2010 16:04:38 -0500 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: References: <4D1B9A7F.8000809@lindenlab.com> Message-ID: <4D1BA266.30800@lindenlab.com> On 12/29/2010 4:00 PM, Zabb65 wrote: > Reading through the documentation on this. It may be easier to just > add "GDK_DEBUG=nograbs" to the shell script launcher when it uses GDB, > and have it work on all distros, up to date or not? Yep, except for the attach-after-start case. (Wish I could test it.... *sigh*). -- Monty Brandenberg 617.401.2384 monty at lindenlab.com From sl.nicky.ml at googlemail.com Wed Dec 29 13:05:27 2010 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Wed, 29 Dec 2010 22:05:27 +0100 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: <4D1B9A7F.8000809@lindenlab.com> References: <4D1B9A7F.8000809@lindenlab.com> Message-ID: On Wed, Dec 29, 2010 at 9:30 PM, Monty Brandenberg wrote: > On 12/29/2010 1:19 PM, Aleric Inglewood wrote: > >> yes, this is a "known" problem: the viewer sometimes locks the X display, >> if then you halt it in the debugger you're toast. > > I only have creaky old Debians at hand but wondered if those with > more modern distros with updated GTKs can work around it by > changing the 'gtk_debug_flags'. ?There's now a GTK_DEBUG_NOGRABS > flag (1 << 12, I think). ?Set that and play a bit. ?No guarantees, > you'll need very recent libs and I don't know at what point in > execution you'll need to set that flag. ?(The --gtk-debug and > --gdk-debug cmd options also drive this.) ?But there it is... > Thank you two for you replies. I will try the gtk debug env later. Just to refine my original mail. I would understand if I hit a breakpoint and there is some graphics stuff going on. But I just *run* snowstorm under gdb by setting LL_WRAPPER. I have not one breakpoint set, neither do I interrupt the program at all. I just use the viewer and it will just lock up the whole X display sooner or later. When I use the viewer without gdb all is fine, no crashes, hang, all good. Cheers, Nicky P.S. I am not NickyP :) Not that I minded it Aleric, just to avoid confusion. or later. From trilobyte550m at gmail.com Wed Dec 29 14:09:41 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 29 Dec 2010 14:09:41 -0800 Subject: [opensource-dev] saved logins In-Reply-To: <4D1B9678.3050205@lindenlab.com> References: <4D1A5D69.8020504@boroon.dasgupta.ch> <201012282316.51613.Lance.Corrimal@eregion.de> <201012282322.06236.Lance.Corrimal@eregion.de> <4D1B9678.3050205@lindenlab.com> Message-ID: For a short time, the logon screen's user name field had a drop down that would let you select from the user names/passwords stored on that computer. Very handy in cases where you might log in with an alt from time to time. On Dec 29, 2010, at 12:13 PM, Oz Linden (Scott Lawrence) wrote: > On 2010-12-28 17:22, Lance Corrimal wrote: >> loosely related to storm-34: I would really see my saved logins back >> in 2.x, similar to snowglobe 1.5... > > I'm not clear on what you think is missing... it remembers my username > and password.... > > _______________________________________________ > 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 From andromedaquonset at gmail.com Wed Dec 29 14:25:23 2010 From: andromedaquonset at gmail.com (Andromeda Quonset) Date: Wed, 29 Dec 2010 15:25:23 -0700 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> Message-ID: <4d1bb543.d44de50a.7c11.ffff9abb@mx.google.com> Trilo, I had the ???'s displaying last night on my friends list for quite awhile, and I have never had a Display Names capable viewer even installed. The version 1.xx viewer I use predates by several months, and I am posting to let anyone know that the problem is not "only appears to be happening on Display Names capable viewers". Andro At 09:46 AM 12/29/2010, Trilo Byte wrote: >It's not you, it's been happening to others. A lot. > >Before Christmas it happened much less frequently, but since then >the phenomenon's been occurring at least once a day. Sometimes >they're ??? at login, sometimes they show properly at first and then >flip to ??? on their own. Sometimes the ???'s remain throughout the >session, and sometimes they flip back to show the correct names. It >happens regardless of whether the user has a Display Name set or not. > >I've also noticed that if someone with a ??? name types an action in >group chat (line starting with /me) it displays their user >name. Also, sometimes, if you look up the profile of a person >showing ??? it shows the correct name on the profile. As far as I >can tell, it's a server-side condition that only appears to be >happening on Display Names capable viewers. > >https://jira.secondlife.com/browse/DN-202 > >On Dec 29, 2010, at 7:36 AM, Ponzu wrote: > >>....Last night I was using the 2.5 beta I had just built from the >>weekend's changes, and this odd thing happened... >> >>I logged in. My friends list showed ???. (Odd, the pictures load >>OK, but not the names.) I had been logged in about 15 minutes. >> >>Then I got an IM from Grumpity Productengine. So far as I know, I >>don't know Grumpity. I assumed it was someone from this list. The >>text of the message was something like, "Hi. I was between >>Highland and La Brea on Franklin, so I thought of you." This >>message is significant to me, but I don't know how any >>Productengines would know that. >> >>So, I started having a conversation with Grumpity, trying to hide >>my embarrassment about not really knowing who it was. >> >>After two or three minutes, I noticed that Grumpity was now >>???. After a bit of conversation, I finally figured out I was >>talking to a friend named Aphrodite Tagore. After ten minutes >>more, the ??? changed to Aphrodite Tagore and all was more or less >>normal (snafu 8-). >> >>No, I do not have a repro. No, I was not stoned beyond oblivion. >> >>Just reporting on the off chance that someone will find the >>information useful for debugging some display name problem or something. >> >>regards, >>ponzu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/6b34a73c/attachment.htm From aleric.inglewood at gmail.com Wed Dec 29 14:34:01 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 29 Dec 2010 23:34:01 +0100 Subject: [opensource-dev] saved logins In-Reply-To: <4D1B9678.3050205@lindenlab.com> References: <4D1A5D69.8020504@boroon.dasgupta.ch> <201012282316.51613.Lance.Corrimal@eregion.de> <201012282322.06236.Lance.Corrimal@eregion.de> <4D1B9678.3050205@lindenlab.com> Message-ID: https://jira.secondlife.com/browse/SNOW-129 On Wed, Dec 29, 2010 at 9:13 PM, Oz Linden (Scott Lawrence) wrote: > On 2010-12-28 17:22, Lance Corrimal wrote: >> loosely related to storm-34: I would really see my saved logins back >> in 2.x, similar to snowglobe 1.5... > > I'm not clear on what you think is missing... it remembers my username > and password.... > > _______________________________________________ > 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 > From trilobyte550m at gmail.com Wed Dec 29 14:36:53 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Wed, 29 Dec 2010 14:36:53 -0800 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <4d1bb543.d44de50a.7c11.ffff9abb@mx.google.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <4d1bb543.d44de50a.7c11.ffff9abb@mx.google.com> Message-ID: <5F317FDE-697F-499C-B17F-E671ED4F769E@gmail.com> Very interesting - what specific Viewer & version are you running? The only 1.x Viewers I've heard of that are also experiencing the problem are recent builds of Phoenix (which are Display Names capable). On Dec 29, 2010, at 2:25 PM, Andromeda Quonset wrote: > Trilo, > > I had the ???'s displaying last night on my friends list for quite awhile, and I have never had a Display Names capable viewer even installed. The version 1.xx viewer I use predates by several months, and I am posting to let anyone know that the problem is not "only appears to be happening on Display Names capable viewers". > > Andro > > At 09:46 AM 12/29/2010, Trilo Byte wrote: >> It's not you, it's been happening to others. A lot. >> >> Before Christmas it happened much less frequently, but since then the phenomenon's been occurring at least once a day. Sometimes they're ??? at login, sometimes they show properly at first and then flip to ??? on their own. Sometimes the ???'s remain throughout the session, and sometimes they flip back to show the correct names. It happens regardless of whether the user has a Display Name set or not. >> >> I've also noticed that if someone with a ??? name types an action in group chat (line starting with /me) it displays their user name. Also, sometimes, if you look up the profile of a person showing ??? it shows the correct name on the profile. As far as I can tell, it's a server-side condition that only appears to be happening on Display Names capable viewers. >> >> https://jira.secondlife.com/browse/DN-202 >> >> On Dec 29, 2010, at 7:36 AM, Ponzu wrote: >> >>> ....Last night I was using the 2.5 beta I had just built from the weekend's changes, and this odd thing happened... >>> >>> I logged in. My friends list showed ???. (Odd, the pictures load OK, but not the names.) I had been logged in about 15 minutes. >>> >>> Then I got an IM from Grumpity Productengine. So far as I know, I don't know Grumpity. I assumed it was someone from this list. The text of the message was something like, "Hi. I was between Highland and La Brea on Franklin, so I thought of you." This message is significant to me, but I don't know how any Productengines would know that. >>> >>> So, I started having a conversation with Grumpity, trying to hide my embarrassment about not really knowing who it was. >>> >>> After two or three minutes, I noticed that Grumpity was now ???. After a bit of conversation, I finally figured out I was talking to a friend named Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite Tagore and all was more or less normal (snafu 8-). >>> >>> No, I do not have a repro. No, I was not stoned beyond oblivion. >>> >>> Just reporting on the off chance that someone will find the information useful for debugging some display name problem or something. >>> >>> regards, >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/28abd1d7/attachment-0001.htm From Lance.Corrimal at eregion.de Wed Dec 29 14:39:18 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 29 Dec 2010 23:39:18 +0100 Subject: [opensource-dev] saved logins In-Reply-To: References: <4D1B9678.3050205@lindenlab.com> Message-ID: <201012292339.18344.Lance.Corrimal@eregion.de> Am Mittwoch, 29. Dezember 2010 schrieb Trilo Byte: > For a short time, the logon screen's user name field had a drop > down that would let you select from the user names/passwords > stored on that computer. Very handy in cases where you might log > in with an alt from time to time. for a short time = stock snowglobe 1.x up to version 1.5.0.3627. bye, LC From aleric.inglewood at gmail.com Wed Dec 29 14:43:30 2010 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 29 Dec 2010 23:43:30 +0100 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: References: <4D1B9A7F.8000809@lindenlab.com> Message-ID: On Wed, Dec 29, 2010 at 10:05 PM, Nicky D. wrote: > But I just *run* snowstorm under gdb by setting LL_WRAPPER. I have not > one breakpoint > set, neither do I interrupt the program at all. > I just use the viewer and it will just lock up the whole X display > sooner or later. > > When I use the viewer without gdb all is fine, no crashes, hang, all good. That is not normal... My X display did lock up too.. until I replaced my videocard ;) If you just let it run, then there is no reason for it to hang X imho :/. But if it only happens when you run gdb and not otherwise... I don't know. Sounds like a software problem then though. From Lance.Corrimal at eregion.de Wed Dec 29 14:46:17 2010 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 29 Dec 2010 23:46:17 +0100 Subject: [opensource-dev] saved logins In-Reply-To: References: <4D1B9678.3050205@lindenlab.com> Message-ID: <201012292346.17127.Lance.Corrimal@eregion.de> Am Mittwoch, 29. Dezember 2010 schrieb Aleric Inglewood: > https://jira.secondlife.com/browse/SNOW-129 > that is one of the main things that are holding me back from going live with dolphin viewer 2.x, the missing saved logins dropdown... bye, LC From jhwelch at gmail.com Wed Dec 29 15:42:18 2010 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 29 Dec 2010 23:42:18 -0000 Subject: [opensource-dev] Review Request: VWR-24347 Reversion in Copy3rdPartyLibs.cmake -- cannot find msvc* files using VS 2005 Express Message-ID: <20101229234218.20369.35141@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/68/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Environment: Windows, VS 2005 Express Back in the days of v2.1 I was able to supply the following option to develop.py, which would allow me to specify the location of msvcr80.dll msvcp80.dll Microsoft.VC80.CRT.manifest -DMSVC_REDIST_PATH:PATH=E:/some/path There was a similar code path for the debug files -DMSVC_DEBUG_REDIST_PATH=E:/some/path This files cannot be found by the Express compiler so without a way of telling the compiler where to find them they have to be dropped into the build tree manually. At some point Copy3rdPartyLibs.cmake was rewritten and this option was dropped. This addresses bug vwr-24347. http://jira.secondlife.com/browse/vwr-24347 Diffs ----- indra/cmake/Copy3rdPartyLibs.cmake 27dae7b01a81 Diff: http://codereview.secondlife.com/r/68/diff Testing ------- I tried using -DMSVC_REDIST_PATH:PATH=E:/some/path with my VS 2005 Express compiler and obtained the desired result. I don't have the debug files to test -DMSVC_DEBUG_REDIST_PATH=E:/some/path Thanks, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/a5baf592/attachment.htm From dave at meadowlakearts.com Wed Dec 29 16:08:00 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Wed, 29 Dec 2010 18:08:00 -0600 Subject: [opensource-dev] saving textures Message-ID: <4D1BCD60.6050906@meadowlakearts.com> Anyone else having issues SAVING textures with the dev viewer? With the 2.4.0 release viewer I can pull up a texture (that I created, so no perms issues) out of my inventory and hit "save as" and pull a fresh copy down to my hdd with no problems.. With the current dev build it hourglasses for a long time and then pops a notification of "unable to download texture" Related to the kdu upgrade perhaps Merov? Dave. From mrfrans at gmail.com Wed Dec 29 17:16:25 2010 From: mrfrans at gmail.com (Frans) Date: Thu, 30 Dec 2010 02:16:25 +0100 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <5F317FDE-697F-499C-B17F-E671ED4F769E@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <4d1bb543.d44de50a.7c11.ffff9abb@mx.google.com> <5F317FDE-697F-499C-B17F-E671ED4F769E@gmail.com> Message-ID: I was in a event a hour ago, and towards the end the viewer forgot my own name, I appeared as ??? (???) in chat and in the balloon above my av. I had all avatar names hiding while this happened, and wonder if that is somehow related. On Wed, Dec 29, 2010 at 11:36 PM, Trilo Byte wrote: > Very interesting - what specific Viewer & version are you running? The > only 1.x Viewers I've heard of that are also experiencing the problem are > recent builds of Phoenix (which are Display Names capable). > > > -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/461696f9/attachment.htm From sl.nicky.ml at googlemail.com Wed Dec 29 17:25:30 2010 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Thu, 30 Dec 2010 02:25:30 +0100 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: References: <4D1B9A7F.8000809@lindenlab.com> Message-ID: > > That is not normal... My X display did lock up too.. until I replaced > my videocard ;) I know :) And I even had those 'nice' GFX card problems once on another PC. But those are a lot nastier :D > If you just let it run, then there is no reason for it to hang X imho :/. > But if it only happens when you run gdb and not otherwise... I don't know. > Sounds like a software problem then though. Yeah. I investigated this further. My suspicion that it has to do with threads seem to be correct. If I forcefully stop gdb from using libthread_db to debug threads all will be good. If gdb hooks threads, it seems to muck in a way with them that seems to cause freezes from time to time. I am not sure if this is a very strange bug in SL, a bug in gdb/libthread_db, or a combination of the two+ati driver. We might never find out, as for obvious reasons I cannot debug it :/ Hopefully this will help someone else having the same problem: Just prevent threads from being debugged. Cheers, Nicky From sl.nicky.ml at googlemail.com Wed Dec 29 17:33:50 2010 From: sl.nicky.ml at googlemail.com (Nicky D.) Date: Thu, 30 Dec 2010 02:33:50 +0100 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> Message-ID: > phenomenon's been occurring at least once a day. ?Sometimes they're ??? at > login, sometimes they show properly at first and then flip to ??? on their > own. ?Sometimes the ???'s remain throughout the session, and sometimes they > flip back to show the correct names. ?It happens regardless of whether the > user has a Display Name set or not. What irks me the most, is that changing from a good name(!) to ??? all of sudden. And whoever thought using ??? was a good idea should really take a few considerations what this means for logs, IMs and so on if suddenly everyone is ??? I can understand that it is a problem if the name cannot be resolved. But why not at least take the safe route and use the old one (if there was already one) and try again instead of overwriting a good cache entry with ???. There should be a few fallback strategies like: a) Try to keep the old cache entry. b) Use the normal user name. c) Maybe even use the UUID. But just showing everyone (in the worst case) as ??? really screws things up IMO. Cheers, Nicky From soft at lindenlab.com Wed Dec 29 17:42:34 2010 From: soft at lindenlab.com (Brian McGroarty) Date: Wed, 29 Dec 2010 17:42:34 -0800 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <5F317FDE-697F-499C-B17F-E671ED4F769E@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <4d1bb543.d44de50a.7c11.ffff9abb@mx.google.com> <5F317FDE-697F-499C-B17F-E671ED4F769E@gmail.com> Message-ID: This was related to a brief load server configuration problem yesterday. This is unrelated to the problem that's taken over this thread. On Wed, Dec 29, 2010 at 2:36 PM, Trilo Byte wrote: > Very interesting - what specific Viewer & version are you running? The > only 1.x Viewers I've heard of that are also experiencing the problem are > recent builds of Phoenix (which are Display Names capable). > > On Dec 29, 2010, at 2:25 PM, Andromeda Quonset wrote: > > Trilo, > > I had the ???'s displaying last night on my friends list for quite awhile, > and I have never had a Display Names capable viewer even installed. The > version 1.xx viewer I use predates by several months, and I am posting to > let anyone know that the problem is not "only appears to be happening on > Display Names capable viewers". > > Andro > > At 09:46 AM 12/29/2010, Trilo Byte wrote: > > It's not you, it's been happening to others. A lot. > > Before Christmas it happened much less frequently, but since then the > phenomenon's been occurring at least once a day. Sometimes they're ??? at > login, sometimes they show properly at first and then flip to ??? on their > own. Sometimes the ???'s remain throughout the session, and sometimes they > flip back to show the correct names. It happens regardless of whether the > user has a Display Name set or not. > > I've also noticed that if someone with a ??? name types an action in group > chat (line starting with /me) it displays their user name. Also, sometimes, > if you look up the profile of a person showing ??? it shows the correct name > on the profile. As far as I can tell, it's a server-side condition that > only appears to be happening on Display Names capable viewers. > > https://jira.secondlife.com/browse/DN-202 > > On Dec 29, 2010, at 7:36 AM, Ponzu wrote: > > ....Last night I was using the 2.5 beta I had just built from the weekend's > changes, and this odd thing happened... > > I logged in. My friends list showed ???. (Odd, the pictures load OK, but > not the names.) I had been logged in about 15 minutes. > > Then I got an IM from Grumpity Productengine. So far as I know, I don't > know Grumpity. I assumed it was someone from this list. The text of the > message was something like, "Hi. I was between Highland and La Brea on > Franklin, so I thought of you." This message is significant to me, but I > don't know how any Productengines would know that. > > So, I started having a conversation with Grumpity, trying to hide my > embarrassment about not really knowing who it was. > > After two or three minutes, I noticed that Grumpity was now ???. After a > bit of conversation, I finally figured out I was talking to a friend named > Aphrodite Tagore. After ten minutes more, the ??? changed to Aphrodite > Tagore and all was more or less normal (snafu 8-). > > No, I do not have a repro. No, I was not stoned beyond oblivion. > > Just reporting on the off chance that someone will find the information > useful for debugging some display name problem or something. > > regards, > 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 > > > > _______________________________________________ > 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 > -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101229/eceab340/attachment-0001.htm From tinselsilvera at frontiernet.net Wed Dec 29 19:54:24 2010 From: tinselsilvera at frontiernet.net (tinselsilvera at frontiernet.net) Date: Thu, 30 Dec 2010 03:54:24 +0000 (UTC) Subject: [opensource-dev] Tab button no longer works Message-ID: <836589695.1446285.1293681264766.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> My tab button has not worked in the last two Dev versions 217861 & 217920. Did I miss a post or Jira regarding this issue? The lack of a tab button makes building and teleporting to exact coordinates more difficult. I tend to tweak my Debug Settings for personal preferences. Did I inadvertently disable the tab button? Any advice on how to correct would be most appreciated. Thanks. -- Tinsel Silvera Spoke n' Cog -- Virtual World Travels - http://www.tinselsilvera.com Spoke n' Cog Marketplace - https://marketplace.secondlife.com/stores/31?id=31 From sllists at boroon.dasgupta.ch Thu Dec 30 03:05:09 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 30 Dec 2010 12:05:09 +0100 Subject: [opensource-dev] Tab button no longer works In-Reply-To: <836589695.1446285.1293681264766.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> References: <836589695.1446285.1293681264766.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> Message-ID: <4D1C6765.5090707@boroon.dasgupta.ch> On 12/30/2010 04:54 AM, tinselsilvera at frontiernet.net wrote: > My tab button has not worked in the last two Dev versions 217861 & 217920. Did I miss a post or Jira regarding this issue? STORM-823 > The lack of a tab button makes building and teleporting to exact coordinates more difficult. Indeed. > I tend to tweak my Debug Settings for personal preferences. Did I inadvertently disable the tab button? Unlikely. I wouldn't know of any setting that would do that. > Any advice on how to correct would be most appreciated. Thanks. I guess there isn't much you can do besides waiting until it's fixed and/or use a version that isn't affected. (Except of course if you're able to fix it yourself, in which case a changeset would be most welcome.) Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/dbfa25a3/attachment.htm From sllists at boroon.dasgupta.ch Thu Dec 30 05:29:11 2010 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 30 Dec 2010 14:29:11 +0100 Subject: [opensource-dev] FMOD or not (was: Debian Squeeze compiling) In-Reply-To: References: Message-ID: <4D1C8927.8000401@boroon.dasgupta.ch> On 12/29/2010 04:21 PM, Duncan Bradders wrote: > Hello, I'm trying to compile the latest viewer development on my > distro, the envoronment it's the same for other viewers and usually I > can compile TPV V1 viewers. > > dbradders at Casa:~/Src/viewer-development/indra$ ./develop.py > --type=Release configure 2>&1 | tee build.log > > then: > > dbradders at Casa:~/Src/viewer-development/indra$ ./develop.py > --type=Release build 2>&1 | tee -a build.log > > It tell me fmod.h is missing but it's not. Where I'm wrong? Maybe that fmod.h is just somewhere else than the build system expects it? STORM-406 probably changed the location where the FMOD files have to be placed. > many thanks in advance for any hint... Since quite some time, you can build the Viewer without FMOD and have sound anyway (OpenAL will be used instead). That's why the instructions for where to place the FMOD files have been removed from the linux build documentation . However, since STORM-406 one has to explicitly disable the FMOD option (e.g. by configuring with -DFMOD=OFF) to be able to build when FMOD cannot be found, which still isn't properly documented, yet. Cheers, Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/4432be19/attachment.htm From wolfpup67 at earthlink.net Thu Dec 30 06:03:09 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 30 Dec 2010 09:03:09 -0500 Subject: [opensource-dev] Convexdecomposition for open source devs Message-ID: <000c01cba82a$4a2e1d20$de8a5760$@net> I have recently had a conversation with someone @ LL that has said they would be willing to help develop and OS version of llconvexdecompisition. I even I even discussed which ones they thought was good but they have not had the time to look at the open source version in a technical way. So what I thought of is start a thread here that would allow the OS community both vote and comment on the OS versions with the one most generally liked being used and converted to be compatible to the LL mesh viewer. Versions that I have found(to place your vote on this put an x next it.): Bullet Physics Library(just the convexdecomp section): Web site : http://code.google.com/p/bullet/ Votes> John Ratcliff's: Web Site : http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now .html Votes> Comments for either system: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/1ce132bf/attachment.htm From oz at lindenlab.com Thu Dec 30 06:28:40 2010 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 30 Dec 2010 09:28:40 -0500 Subject: [opensource-dev] saving textures In-Reply-To: <4D1BCD60.6050906@meadowlakearts.com> References: <4D1BCD60.6050906@meadowlakearts.com> Message-ID: <4D1C9718.8030906@lindenlab.com> On 2010-12-29 19:08, Dave Booth wrote: > Anyone else having issues SAVING textures with the dev viewer? > > With the 2.4.0 release viewer I can pull up a texture (that I created, > so no perms issues) out of my inventory and hit "save as" and pull a > fresh copy down to my hdd with no problems.. > > With the current dev build it hourglasses for a long time and then pops > a notification of "unable to download texture" 'current' is not a version identifier - please be specific. > Related to the kdu upgrade perhaps Merov? Merov is on vacation until Jan 4... From tateru at taterunino.net Thu Dec 30 06:36:49 2010 From: tateru at taterunino.net (Tateru Nino) Date: Fri, 31 Dec 2010 01:36:49 +1100 Subject: [opensource-dev] Convexdecomposition for open source devs In-Reply-To: <000c01cba82a$4a2e1d20$de8a5760$@net> References: <000c01cba82a$4a2e1d20$de8a5760$@net> Message-ID: <4D1C9901.2050402@taterunino.net> Knowing what their licenses are is very important. They'll need to be LGPL compatible, if I remember rightly. On 31/12/2010 1:03 AM, WolfPup Lowenhar wrote: > > I have recently had a conversation with someone @ LL that has said > they would be willing to help develop and OS version of > llconvexdecompisition. I even I even discussed which ones they thought > was good but they have not had the time to look at the open source > version in a technical way. So what I thought of is start a thread > here that would allow the OS community both vote and comment on the OS > versions with the one most generally liked being used and converted to > be compatible to the LL mesh viewer. > > Versions that I have found(to place your vote on this put an x next it.): > > Bullet Physics Library(just the convexdecomp section): > > Web site : http://code.google.com/p/bullet/ > > Votes> > > > John Ratcliff's : > > > Web Site : > http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html > > > Votes> > > > Comments for either system: > > > > _______________________________________________ > 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 -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101231/3060d67b/attachment-0001.htm From wolfpup67 at earthlink.net Thu Dec 30 06:47:27 2010 From: wolfpup67 at earthlink.net (WolfPup Lowenhar) Date: Thu, 30 Dec 2010 09:47:27 -0500 Subject: [opensource-dev] Convexdecomposition for open source devs In-Reply-To: <4D1C9901.2050402@taterunino.net> References: <000c01cba82a$4a2e1d20$de8a5760$@net> <4D1C9901.2050402@taterunino.net> Message-ID: <001d01cba830$7aec6380$70c52a80$@net> That is why I put the link to the sites where the source is hosted so you can check this and the license they are using are full GPL which is compatible with LGPL if I remember correctly. From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Tateru Nino Sent: Thursday, December 30, 2010 9:37 AM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] Convexdecomposition for open source devs Knowing what their licenses are is very important. They'll need to be LGPL compatible, if I remember rightly. On 31/12/2010 1:03 AM, WolfPup Lowenhar wrote: I have recently had a conversation with someone @ LL that has said they would be willing to help develop and OS version of llconvexdecompisition. I even I even discussed which ones they thought was good but they have not had the time to look at the open source version in a technical way. So what I thought of is start a thread here that would allow the OS community both vote and comment on the OS versions with the one most generally liked being used and converted to be compatible to the LL mesh viewer. Versions that I have found(to place your vote on this put an x next it.): Bullet Physics Library(just the convexdecomp section): Web site : http://code.google.com/p/bullet/ Votes> John Ratcliff's: Web Site : http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now .html Votes> Comments for either system: _______________________________________________ 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 -- Tateru Nino http://dwellonit.taterunino.net/ _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3348 - Release Date: 12/30/10 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/bfa17e5d/attachment.htm From dave at meadowlakearts.com Thu Dec 30 08:08:06 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 30 Dec 2010 10:08:06 -0600 Subject: [opensource-dev] saving textures In-Reply-To: <4D1C9718.8030906@lindenlab.com> References: <4D1BCD60.6050906@meadowlakearts.com> <4D1C9718.8030906@lindenlab.com> Message-ID: <4D1CAE66.5010302@meadowlakearts.com> On 12/30/2010 08:28, Oz Linden (Scott Lawrence) wrote: > > 'current' is not a version identifier - please be specific. > Sorry Oz - by "current" I meant an up to date daily build - in that case build 217881, although I've just repro'd it on 217920 too From dave at meadowlakearts.com Thu Dec 30 08:09:57 2010 From: dave at meadowlakearts.com (Dave Booth) Date: Thu, 30 Dec 2010 10:09:57 -0600 Subject: [opensource-dev] Convexdecomposition for open source devs In-Reply-To: <000c01cba82a$4a2e1d20$de8a5760$@net> References: <000c01cba82a$4a2e1d20$de8a5760$@net> Message-ID: <4D1CAED5.90100@meadowlakearts.com> On 12/30/2010 08:03, WolfPup Lowenhar wrote: > > I have recently had a conversation with someone @ LL that has said > they would be willing to help develop and OS version of > llconvexdecompisition. I even I even discussed which ones they thought > was good but they have not had the time to look at the open source > version in a technical way. So what I thought of is start a thread > here that would allow the OS community both vote and comment on the OS > versions with the one most generally liked being used and converted to > be compatible to the LL mesh viewer. > > Versions that I have found(to place your vote on this put an x next it.): > > Bullet Physics Library(just the convexdecomp section): > > Web site : http://code.google.com/p/bullet/ > > Votes> > > > John Ratcliff's : > > > Web Site : > http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html > > > Votes> > > > Comments for either system: > > I cant exactly speak to the quality of either but the fact that Bullet is the physics implementation used by opensim should IMHO give that choice a bit of a leg up. The fact that the library is already in use as the phys engine on the most prevalent opensource server makes its use for decomp in an opensource viewer rational, just as the use of havok decomp in the LL-compiled viewer made sense since that physics library was already present in-house. From slitovchuk at productengine.com Thu Dec 30 08:20:11 2010 From: slitovchuk at productengine.com (Seth ProductEngine) Date: Thu, 30 Dec 2010 16:20:11 -0000 Subject: [opensource-dev] Review Request: (STORM-797) Parcel SLURL rendering Message-ID: <20101230162011.20445.99023@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/69/ ----------------------------------------------------------- Review request for Viewer. Summary ------- Added parcel SLURL rendering with human readable parcel names. - Added parcel info observer to LLUrlEntryParcel. - Added notifying LLUrlEntryParcel by LLRemoteParcelInfoProcessor when parcel data arrives. - Added notifying LLUrlEntryParcel about user login, changing host and viewer connection state to use this data in remote parcel requests. This addresses bug STORM-797. http://jira.secondlife.com/browse/STORM-797 Diffs ----- indra/llui/llurlentry.h 27dae7b01a81 indra/llui/llurlentry.cpp 27dae7b01a81 indra/llui/tests/llurlentry_stub.cpp 27dae7b01a81 indra/newview/llagent.cpp 27dae7b01a81 indra/newview/llappviewer.cpp 27dae7b01a81 indra/newview/llremoteparcelrequest.cpp 27dae7b01a81 indra/newview/llstartup.cpp 27dae7b01a81 indra/newview/tests/llremoteparcelrequest_test.cpp 27dae7b01a81 Diff: http://codereview.secondlife.com/r/69/diff Testing ------- Thanks, Seth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/7a056d36/attachment.htm From monty at lindenlab.com Thu Dec 30 08:39:57 2010 From: monty at lindenlab.com (Monty Brandenberg) Date: Thu, 30 Dec 2010 11:39:57 -0500 Subject: [opensource-dev] Debugging Snowstorm under Linux x64 with GDB locks the whole X session In-Reply-To: References: <4D1B9A7F.8000809@lindenlab.com> Message-ID: <4D1CB5DD.1000306@lindenlab.com> On 12/29/2010 4:05 PM, Nicky D. wrote: > On Wed, Dec 29, 2010 at 9:30 PM, Monty Brandenberg wrote: >> On 12/29/2010 1:19 PM, Aleric Inglewood wrote: >> >>> yes, this is a "known" problem: the viewer sometimes locks the X display, >>> if then you halt it in the debugger you're toast. >> >> I only have creaky old Debians at hand but wondered if those with >> more modern distros with updated GTKs can work around it by >> changing the 'gtk_debug_flags'. There's now a GTK_DEBUG_NOGRABS >> flag (1<< 12, I think). Set that and play a bit. No guarantees, >> you'll need very recent libs and I don't know at what point in >> execution you'll need to set that flag. (The --gtk-debug and >> --gdk-debug cmd options also drive this.) But there it is... >> > > Thank you two for you replies. I will try the gtk debug env later. If anyone does play with the env var on a system with *recent* gtk libs, let us know what happens. (We could probably use a hints-and-tips page with stuff like this.) Won't be any help to those with junk X ddxs or defective OS support libs.... -- Monty Brandenberg 617.401.2384 monty at lindenlab.com From robin.cornelius at gmail.com Thu Dec 30 08:53:17 2010 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 30 Dec 2010 16:53:17 +0000 Subject: [opensource-dev] saving textures In-Reply-To: <4D1CAE66.5010302@meadowlakearts.com> References: <4D1BCD60.6050906@meadowlakearts.com> <4D1C9718.8030906@lindenlab.com> <4D1CAE66.5010302@meadowlakearts.com> Message-ID: On Thu, Dec 30, 2010 at 4:08 PM, Dave Booth wrote: > On 12/30/2010 08:28, Oz Linden (Scott Lawrence) wrote: >> >> 'current' is not a version identifier - please be specific. >> > > Sorry Oz - by "current" I meant an up to date daily build - in that case > build 217881, although I've just repro'd it on 217920 too > I'm not able to repro on my own build from Viewer Development - 14355 (27dae7b01a81), the textures save as expected with a small delay whist ones that are not cached fetch from the server. So if it is consistently reproducing on official binaries then it may be related to the KDU changes (where as my builds would use OpenJpeg). Robin From adyukov at productengine.com Thu Dec 30 08:55:24 2010 From: adyukov at productengine.com (Andrew ProductEngine) Date: Thu, 30 Dec 2010 16:55:24 -0000 Subject: [opensource-dev] Review Request: (STORM-797) Parcel SLURL rendering In-Reply-To: <20101230162011.20445.99023@domU-12-31-38-00-90-68.compute-1.internal> References: <20101230162011.20445.99023@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20101230165524.20621.76461@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/69/#review106 ----------------------------------------------------------- Ship it! Looks plausible. The fix works good, and though some changes may not look pretty, I can't offer a better way to do them. - Andrew On 2010-12-30 08:20:11, Seth ProductEngine wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/69/ > ----------------------------------------------------------- > > (Updated 2010-12-30 08:20:11) > > > Review request for Viewer. > > > Summary > ------- > > Added parcel SLURL rendering with human readable parcel names. > - Added parcel info observer to LLUrlEntryParcel. > - Added notifying LLUrlEntryParcel by LLRemoteParcelInfoProcessor when parcel data arrives. > - Added notifying LLUrlEntryParcel about user login, changing host and viewer connection state to use this data in remote parcel requests. > > > This addresses bug STORM-797. > http://jira.secondlife.com/browse/STORM-797 > > > Diffs > ----- > > indra/llui/llurlentry.h 27dae7b01a81 > indra/llui/llurlentry.cpp 27dae7b01a81 > indra/llui/tests/llurlentry_stub.cpp 27dae7b01a81 > indra/newview/llagent.cpp 27dae7b01a81 > indra/newview/llappviewer.cpp 27dae7b01a81 > indra/newview/llremoteparcelrequest.cpp 27dae7b01a81 > indra/newview/llstartup.cpp 27dae7b01a81 > indra/newview/tests/llremoteparcelrequest_test.cpp 27dae7b01a81 > > Diff: http://codereview.secondlife.com/r/69/diff > > > Testing > ------- > > > Thanks, > > Seth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/77073bdf/attachment.htm From trilobyte550m at gmail.com Thu Dec 30 09:50:06 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Thu, 30 Dec 2010 09:50:06 -0800 Subject: [opensource-dev] saving textures In-Reply-To: <4D1CAE66.5010302@meadowlakearts.com> References: <4D1BCD60.6050906@meadowlakearts.com> <4D1C9718.8030906@lindenlab.com> <4D1CAE66.5010302@meadowlakearts.com> Message-ID: <2ABD9497-4B71-4ECA-B229-7FD02D810C06@gmail.com> I'm experiencing the same failure, build 217920. I wrote up a JIRA: https://jira.secondlife.com/browse/VWR-24353 Please vote, add a comment with your machine/OS info/build info, or any other pertinent info I might have missed. Cheers Trilo On Dec 30, 2010, at 8:08 AM, Dave Booth wrote: > On 12/30/2010 08:28, Oz Linden (Scott Lawrence) wrote: >> >> 'current' is not a version identifier - please be specific. >> > > Sorry Oz - by "current" I meant an up to date daily build - in that case > build 217881, although I've just repro'd it on 217920 too > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/af1c1c2a/attachment.htm From akanevsky at productengine.com Thu Dec 30 10:50:39 2010 From: akanevsky at productengine.com (Anya Kanevsky) Date: Thu, 30 Dec 2010 12:50:39 -0600 Subject: [opensource-dev] Somewhat Regular Scrum(ish) Summary - Thursday, December 30 Message-ID: Thursday, December 30, 2010 General Notes ------------------------------ - With most on vacation in US, only posting PE updates - summaries _for this week to date_. - Happy Impending New Year! Let the resolutions begin! Team Status ------------------------------ Paul ProductEngine ------------------------------ *PAST* - BUG STORM-721 (Information about resident is displayed incorrectly in mini-inspector if there are any resident or group SLURLs) - handed over to Andrew who is more familiar with LLTextBase - BUG STORM-714 (Webprim's control bar doesn't dissapear after switching to mouselook mode) - BUG STORM-512 ("Allow media to auto - play" check-box is enable after Media check-box was unchecked) - BUG STORM-387 (Part of the table is hidden after increasing firsts column width in the floater and then dock it to the SP) - WIP. Investigating. Rude estimate ~ 8 hours - BUG STORM-513 ("Allow media to auto - play" check-box is enable after Media check-box was unchecked) - BUG STORM-493 ('Map' button slightly overlaps scroll bar into My Group info->Land/Assets accordion) *FUTURE* - BUG STORM-370 (Human-readable name of region disappears from Location Bar after pressing ESC) *IMPEDIMENTS* - None Seth Productengine ------------------------------ *PAST* - Code reviews. - TASK (STORM-797) Parcel SLURL rendering - Moved parcel name retrieving to llmessage. Worked on receiving remote parcel names in SLURL objects. Resolved viewer linking problems which appeared after moving parcel name retrieving to llmessage. - Found and fixed crashes when receiving remote parcel names in SLURL objects. - Refactored the parcel name resolving within a SLURL object. Cleaned up and tested the fix. Worked on issues spotted by Vadim's review. Refactored task implementation in order to leave parcel processor class in newview and reduce overhead with observers usage. - Working on fixing unit tests. - BUG (STORM-550) LLDir::getNextFileInDir fails for some complex wildcard combinations - Got feedback from Oz. Working on refactoring the directory iterator class. *FUTURE* - TASK (STORM-797) Parcel SLURL rendering. - Fix unit tests for parcel SLURL - TASK (STORM-28) As a User, I want the ability to send my calling card to others *IMPEDIMENTS* - None Andrew Productengine ------------------------------ *PAST* - Normal task 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). - Found an issue in opened loaded sidetray floaters. Struggling with it. Implementing UI proposed by Esbee. - Major bug STORM-823 (Tab Key not working properly). - Found where in code the bug happens. Searching for root cause and solution. *FUTURE* - STORM-823 (Tab Key not working properly). - Estimate - 3 hours. - Normal task STORM-2 (Customizable viewer layouts). - Estimate for current version of feature - 2 days. *IMPEDIMENTS* - STORM-2. Waiting for Q's reply to letter about organization of layout saving. Vadim Productengine ------------------------------ *PAST* - Bug STORM-682 (Toasts appear in wrong position if switch to mouse look when side tray is expanded) - Bug STORM-242 (Server version dialog message has incorrect release notes link): - Bug STORM-349 (Broken Window: rename shader_heirarchy.txt to shader_hierarchy.txt): - Investigated, not sure how to fix safely. - Bug STORM-394 ('UI size' slider from advanced Preference is shifted to right): - Resolved as not reproducible. - Reported bug STORM-822 (Crash in LLKeyframeDataCache::clear). - Bug STORM-437 (Docked nearby chat overlaps sidebar panel after unmaximizing viewer window). - WIP. Haven't finished yet (ETA 4h). - Code review. *FUTURE* - Short vacatition (will return on 01/04) *IMPEDIMENTS* - Need a decision in STORM-702 (Make it possible to wear partial outfits). - What to do with VWR tickets assigned to ProductEngine Team? https://jira.secondlife.com/secure/IssueNavigator.jspa?mode=hide&requestId=13071 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/54029f21/attachment-0001.htm From monty at lindenlab.com Thu Dec 30 10:58:23 2010 From: monty at lindenlab.com (Monty Brandenberg) Date: Thu, 30 Dec 2010 13:58:23 -0500 Subject: [opensource-dev] saving textures In-Reply-To: <2ABD9497-4B71-4ECA-B229-7FD02D810C06@gmail.com> References: <4D1BCD60.6050906@meadowlakearts.com> <4D1C9718.8030906@lindenlab.com> <4D1CAE66.5010302@meadowlakearts.com> <2ABD9497-4B71-4ECA-B229-7FD02D810C06@gmail.com> Message-ID: <4D1CD64F.8060209@lindenlab.com> On 12/30/2010 12:50 PM, Trilo Byte wrote: > I'm experiencing the same failure, build 217920. I wrote up a JIRA: > https://jira.secondlife.com/browse/VWR-24353 > > Please vote, add a comment with your machine/OS info/build info, or any > other pertinent info I might have missed. There are several interesting things happening in the log file fragment you attached (including a functor lookup problem in UI Toast land). But the interesting one I expect is this: 2010-12-30T18:07:44Z INFO: parse: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap invocation rate exceeded: 'xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' Need more info (logs, additional confirmation) but I suspect we're getting error status back in a bad encoding and so we don't know to retry a save in the viewer. -- Monty Brandenberg monty at lindenlab.com From adyukov at productengine.com Thu Dec 30 11:16:15 2010 From: adyukov at productengine.com (Andrew Dyukov) Date: Thu, 30 Dec 2010 21:16:15 +0200 Subject: [opensource-dev] Tab button no longer works In-Reply-To: <4D1C6765.5090707@boroon.dasgupta.ch> References: <836589695.1446285.1293681264766.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> <4D1C6765.5090707@boroon.dasgupta.ch> Message-ID: The bug is fixed and will be merged into viewer-development after PO review. 2010/12/30 Boroondas Gupte : > On 12/30/2010 04:54 AM, tinselsilvera at frontiernet.net wrote: > > My tab button has not worked in the last two Dev versions 217861 & 217920. > Did I miss a post or Jira regarding this issue? > > STORM-823 > > The lack of a tab button makes building and teleporting to exact coordinates > more difficult. > > Indeed. > > I tend to tweak my Debug Settings for personal preferences. Did I > inadvertently disable the tab button? > > Unlikely. I wouldn't know of any setting that would do that. > > Any advice on how to correct would be most appreciated. Thanks. > > I guess there isn't much you can do besides waiting until it's fixed and/or > use a version that isn't affected. (Except of course if you're able to fix > it yourself, in which case a changeset would be most welcome.) > > 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 > From makosoft at gmail.com Thu Dec 30 12:17:12 2010 From: makosoft at gmail.com (Aidan Thornton) Date: Thu, 30 Dec 2010 20:17:12 +0000 Subject: [opensource-dev] Convexdecomposition for open source devs In-Reply-To: <000c01cba82a$4a2e1d20$de8a5760$@net> References: <000c01cba82a$4a2e1d20$de8a5760$@net> Message-ID: On Thu, Dec 30, 2010 at 2:03 PM, WolfPup Lowenhar wrote: > Bullet Physics Library(just the convexdecomp section): > > Web site : http://code.google.com/p/bullet/ > > John Ratcliff's: > > Web Site : > http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html I seem to recall that the Bullet convex decomposition is actually based on an older version of John Ratcliff's code with their own improvements added. The two use completely different APIs, though, so there's probably no easy way to switch between them. From dahliatrimble at gmail.com Thu Dec 30 13:15:11 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 30 Dec 2010 13:15:11 -0800 Subject: [opensource-dev] Convexdecomposition for open source devs In-Reply-To: <4D1CAED5.90100@meadowlakearts.com> References: <000c01cba82a$4a2e1d20$de8a5760$@net> <4D1CAED5.90100@meadowlakearts.com> Message-ID: There is an implementation of bullet in OpenSimulator but it's not as well tested as ODE, which is the dominant engine in use. Both engines are currently using trimesh colliders for complex prims, sculpties, and meshes and the version of ODE included with OpenSimulator does not support convex hull colliders. On Dec 30, 2010 8:10 AM, "Dave Booth" wrote: > On 12/30/2010 08:03, WolfPup Lowenhar wrote: >> >> I have recently had a conversation with someone @ LL that has said >> they would be willing to help develop and OS version of >> llconvexdecompisition. I even I even discussed which ones they thought >> was good but they have not had the time to look at the open source >> version in a technical way. So what I thought of is start a thread >> here that would allow the OS community both vote and comment on the OS >> versions with the one most generally liked being used and converted to >> be compatible to the LL mesh viewer. >> >> Versions that I have found(to place your vote on this put an x next it.): >> >> Bullet Physics Library(just the convexdecomp section): >> >> Web site : http://code.google.com/p/bullet/ >> >> Votes> >> >> >> John Ratcliff's : >> >> >> Web Site : >> http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html >> >> >> Votes> >> >> >> Comments for either system: >> >> > > I cant exactly speak to the quality of either but the fact that Bullet > is the physics implementation used by opensim should IMHO give that > choice a bit of a leg up. The fact that the library is already in use as > the phys engine on the most prevalent opensource server makes its use > for decomp in an opensource viewer rational, just as the use of havok > decomp in the LL-compiled viewer made sense since that physics library > was already present in-house. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101230/aa33333f/attachment.htm From marinekelley at gmail.com Fri Dec 31 02:42:49 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 31 Dec 2010 11:42:49 +0100 Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? Message-ID: Hello all, I have just filed a JIRA (VWR-23459) about a random crash that would occur in the rendering pipeline, when suddenly it struck me : I remember that years ago the viewer would crash when writing to llerrs, and that it was voluntary (don't ask me why). Is it still the case ? In this JIRA, the fix I provide merely removes the write to llerrs, and returns without going any further into the method. I did not have time to give it more attention, it was more of a dirty hack to be able to keep from crashing every 15 minutes while my friends were waiting for me. Thanks and happy new year to all of you ! Marine From zabb65 at gmail.com Fri Dec 31 04:23:31 2010 From: zabb65 at gmail.com (Zabb65) Date: Fri, 31 Dec 2010 07:23:31 -0500 Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? In-Reply-To: References: Message-ID: Yes, llerrs purposefully dereferences a null pointer to cause a crash, and if that fails it infinitely loops. This is so "errors" get fixed instead of being ignored. On Fri, Dec 31, 2010 at 05:42, Marine Kelley wrote: > Hello all, > > I have just filed a JIRA (VWR-23459) about a random crash that would > occur in the rendering pipeline, when suddenly it struck me : I > remember that years ago the viewer would crash when writing to llerrs, > and that it was voluntary (don't ask me why). > > Is it still the case ? In this JIRA, the fix I provide merely removes > the write to llerrs, and returns without going any further into the > method. I did not have time to give it more attention, it was more of > a dirty hack to be able to keep from crashing every 15 minutes while > my friends were waiting for me. > > Thanks and happy new year to all of you ! > Marine > _______________________________________________ > 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 > From marinekelley at gmail.com Fri Dec 31 04:50:58 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 31 Dec 2010 13:50:58 +0100 Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? In-Reply-To: References: Message-ID: Ah yes that's what I remembered. I didn't think it was still the case in v2. Thanks. On 31/12/2010, Zabb65 wrote: > Yes, llerrs purposefully dereferences a null pointer to cause a crash, > and if that fails it infinitely loops. This is so "errors" get fixed > instead of being ignored. > > On Fri, Dec 31, 2010 at 05:42, Marine Kelley wrote: >> Hello all, >> >> I have just filed a JIRA (VWR-23459) about a random crash that would >> occur in the rendering pipeline, when suddenly it struck me : I >> remember that years ago the viewer would crash when writing to llerrs, >> and that it was voluntary (don't ask me why). >> >> Is it still the case ? In this JIRA, the fix I provide merely removes >> the write to llerrs, and returns without going any further into the >> method. I did not have time to give it more attention, it was more of >> a dirty hack to be able to keep from crashing every 15 minutes while >> my friends were waiting for me. >> >> Thanks and happy new year to all of you ! >> Marine >> _______________________________________________ >> 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 >> > From sheet.spotter at gmail.com Fri Dec 31 07:26:15 2010 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Fri, 31 Dec 2010 09:26:15 -0600 Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? In-Reply-To: References: Message-ID: The random crash reported by Marine was VWR-24359. https://jira.secondlife.com/browse/VWR-24359 (There was a typo in the original post; two digits were transposed.) Sheet Spotter -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Marine Kelley Sent: December 31, 2010 4:43 AM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? [...] I have just filed a JIRA (VWR-23459) about a random crash that would occur in the rendering pipeline [...] From marinekelley at gmail.com Fri Dec 31 07:41:08 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 31 Dec 2010 16:41:08 +0100 Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? In-Reply-To: References: Message-ID: Hehe well there were two ways of writing the name of the JIRA entry : the right way, and the Marine way. Guess which one I chose. Thanks Sheet :) On 31/12/2010, Sheet Spotter wrote: > The random crash reported by Marine was VWR-24359. > https://jira.secondlife.com/browse/VWR-24359 > > (There was a typo in the original post; two digits were transposed.) > > > Sheet Spotter > > -----Original Message----- > From: opensource-dev-bounces at lists.secondlife.com > [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Marine > Kelley > Sent: December 31, 2010 4:43 AM > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? > > [...] > > I have just filed a JIRA (VWR-23459) about a random crash that would > occur in the rendering pipeline [...] > > > From secret.argent at gmail.com Fri Dec 31 09:02:55 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 31 Dec 2010 11:02:55 -0600 Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS (was "Daily Scrum Summary - dec. 23") In-Reply-To: <220D6985B3084D74BBE6D5D523154EAA@Deimos> References: <220D6985B3084D74BBE6D5D523154EAA@Deimos> Message-ID: Why not just paste it into a notecard? On 2010-12-24, at 10:09, Garmin Kawaguichi wrote: > > ----- Original Message ----- > From: "Opensource Obscure" > To: "OpenSource Mailing List" > Sent: Friday, December 24, 2010 12:17 PM > Subject: [opensource-dev] STORM-797 and other ideas about Landmarks&SLURLS > (was "Daily Scrum Summary - dec. 23") > > >> What I was thinking about was a new, different way to achieve >> something we usually achieve through landmarks.. > ... >> I'm thinking about management of Bookmarks in current >> main web browsers,... > > Something like : > secondlife:///app/teleport/furvata/132/126/96 (which can be used to direct > teleport when clicked) > > but > > stored in the inventory as a new asset item different from asset item #3 > (INVENTORY_LANDMARK) and defined as a web link directly usable in the > viewer. This link can be created in the inventory with a right click New > Link and can be edited. > > GCI > > _______________________________________________ > 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 "Welcome back, Anonymous, we're glad to see you again!" From secret.argent at gmail.com Fri Dec 31 09:29:51 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 31 Dec 2010 11:29:51 -0600 Subject: [opensource-dev] STORM-34 Test Binaries In-Reply-To: References: <285058.60774.qm@web23905.mail.ird.yahoo.com> <327279.85976.qm@web23904.mail.ird.yahoo.com> <20101227165911.GA22986@alinoe.com> Message-ID: <4D5C4202-8380-46DA-A678-F1715237C77B@gmail.com> On 2010-12-28, at 14:40, Celierra Darling wrote: > It seems a little unclear to try to communicate "this can have privacy implications" by putting the setting on the privacy tab. It might be better to write the setting label so it's more explicit (i.e. something like "Show my favorites to anyone under 'Start At' before logging in" or "Show my favorites under 'Start At' on login (before authenticating)" or etc.). Add a "login" tab, which would make room for a notation indicating that there are privacy issues (as there are for "remember my password", or enabling message/chat logging). From secret.argent at gmail.com Fri Dec 31 09:45:58 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 31 Dec 2010 11:45:58 -0600 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> Message-ID: <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> > > There should be a few fallback strategies like: > a) Try to keep the old cache entry. > b) Use the normal user name. > c) Maybe even use the UUID. > > But just showing everyone (in the worst case) as ??? really screws > things up IMO. Agreed. The TPV I'm using seems to use the Legacy Name if the Display Name is not available. From secret.argent at gmail.com Fri Dec 31 09:48:01 2010 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 31 Dec 2010 11:48:01 -0600 Subject: [opensource-dev] Convexdecomposition for open source devs In-Reply-To: <001d01cba830$7aec6380$70c52a80$@net> References: <000c01cba82a$4a2e1d20$de8a5760$@net> <4D1C9901.2050402@taterunino.net> <001d01cba830$7aec6380$70c52a80$@net> Message-ID: On 2010-12-30, at 08:47, WolfPup Lowenhar wrote: > That is why I put the link to the sites where the source is hosted so you can check this and the license they are using are full GPL which is compatible with LGPL if I remember correctly. If you use a full GPL component then you have to use full GPL for the whole viewer, rather than the LGPL. It's better to say "the LGPL is compatible with the GPL" rather than the other way around. From lee.ponzu at gmail.com Fri Dec 31 12:50:14 2010 From: lee.ponzu at gmail.com (Ponzu) Date: Fri, 31 Dec 2010 15:50:14 -0500 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> <7E1308B5-D0EE-41D5-8CF2-A419D9A78462@gmail.com> Message-ID: I just thought of looking in the xml files, and indeed "Grumpity Productengine" shows up in a few of them, I assume as some sort of place holder left by a programmer. Maybe such "magic words" should be replace by something like "Unkown Resident" or some such. On Fri, Dec 31, 2010 at 12:45 PM, Argent Stonecutter < secret.argent at gmail.com> wrote: > > > > There should be a few fallback strategies like: > > a) Try to keep the old cache entry. > > b) Use the normal user name. > > c) Maybe even use the UUID. > > > > But just showing everyone (in the worst case) as ??? really screws > > things up IMO. > > Agreed. The TPV I'm using seems to use the Legacy Name if the Display Name > is not available. > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101231/bf8f3c83/attachment.htm From dahliatrimble at gmail.com Fri Dec 31 13:14:21 2010 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri, 31 Dec 2010 13:14:21 -0800 Subject: [opensource-dev] Very Strange occurrence... In-Reply-To: References: <78C5DABF-5934-49D0-9F9D-CB8C35F74178@gmail.com> Message-ID: I've seen evidence that the Improved Instant Message packet still contains a good user name while the group chat window displays ???(???) for the same message. On Wed, Dec 29, 2010 at 5:33 PM, Nicky D. wrote: > > phenomenon's been occurring at least once a day. Sometimes they're ??? > at > > login, sometimes they show properly at first and then flip to ??? on > their > > own. Sometimes the ???'s remain throughout the session, and sometimes > they > > flip back to show the correct names. It happens regardless of whether > the > > user has a Display Name set or not. > > What irks me the most, is that changing from a good name(!) to ??? all > of sudden. > > And whoever thought using ??? was a good idea should really take a few > considerations > what this means for logs, IMs and so on if suddenly everyone is ??? > > I can understand that it is a problem if the name cannot be resolved. > But why not at > least take the safe route and use the old one (if there was already > one) and try again > instead of overwriting a good cache entry with ???. > > There should be a few fallback strategies like: > a) Try to keep the old cache entry. > b) Use the normal user name. > c) Maybe even use the UUID. > > But just showing everyone (in the worst case) as ??? really screws > things up IMO. > > Cheers, > Nicky > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101231/51aa65a0/attachment.htm From marinekelley at gmail.com Fri Dec 31 17:59:55 2010 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 1 Jan 2011 02:59:55 +0100 Subject: [opensource-dev] A weird bug when moving the avatar Message-ID: I have observed this behavior with the rev 14120 of viewer-development : https://jira.secondlife.com/browse/VWR-24361 (name checked this time) In short, when you press a movement key or use the move panel (going forward, backward etc, but not turning left or right), the FPS decrease dramatically (from 90 down to 15 FPS). It can be very annoying during races or fights. Has anybody observed this too ? I don't remember having seen this happen in older viewers, but I recently changed my video card so maybe the change in FPS was not noticeable to me before. And more importantly, has any work been done recently (less than two months ago) on the way the avatar movement is handled, that could trigger this bug ? I don't really know where to look so if anybody has pointers, please feel free to share ! Thanks, Marine From trilobyte550m at gmail.com Fri Dec 31 18:33:57 2010 From: trilobyte550m at gmail.com (Trilo Byte) Date: Fri, 31 Dec 2010 18:33:57 -0800 Subject: [opensource-dev] A weird bug when moving the avatar In-Reply-To: References: Message-ID: <72A6811A-550E-4C41-A8EF-B0F0837A7940@gmail.com> It's possible... I've been semi-crippled by lack of support for my nVidia GPU and the whole framerate stutter thing https://jira.secondlife.com/browse/VWR-23318 When I get a chance, I'll see if I can isolate/reproduce. On Dec 31, 2010, at 5:59 PM, Marine Kelley wrote: > I have observed this behavior with the rev 14120 of viewer-development : > > https://jira.secondlife.com/browse/VWR-24361 (name checked this time) > > In short, when you press a movement key or use the move panel (going > forward, backward etc, but not turning left or right), the FPS > decrease dramatically (from 90 down to 15 FPS). It can be very > annoying during races or fights. > > Has anybody observed this too ? I don't remember having seen this > happen in older viewers, but I recently changed my video card so maybe > the change in FPS was not noticeable to me before. > > And more importantly, has any work been done recently (less than two > months ago) on the way the avatar movement is handled, that could > trigger this bug ? I don't really know where to look so if anybody has > pointers, please feel free to share ! > > Thanks, > Marine > _______________________________________________ > 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