[opensource-dev] Daily Scrum Summary - Tuesday, February 1
Tuesday, February 1 General Notes -- - Sprint planning today - no standup - MMOTD: Oz Team Status -- Merov Linden -- *PAST* - Triage JIRA for sprint planning meeting - Code reviews *FUTURE* - Sprint planning - STORM-746 : KDU Improvements: Compress j2c with precincts *IMPEDIMENTS* - none Grumpity ProductEngine -- *PAST* - Sprint 11 Theme - Customization - Sprint review - jira wrangling to prep for sprint planning - find victim for inventory issues (STORM-526) - Maestro commented on STORM-379 (Buy copy of floater) *FUTURE* - Sprint planning - continue to prod others to resolve impediments - Product triage *IMPEDIMENTS* - moving Paul ProductEngine -- *PAST* - BUG STORM-655 (mismatched filter extension in snapshot floater (jpeg vs jpg).) - Fixed and sent for review. - BUG STORM-680 (Avaline callers are added to the Recent list) - WIP. Estimate ~ 6-8 hours. *FUTURE* - BUG STORM-680 (Avaline callers are added to the Recent list) *IMPEDIMENTS* - none Seth Productengine -- *PAST* - BUG (STORM-219) Folders Always By Name and System Folders To Top options are missing from the Inventory menu. Can't sort folders! - Fixed with patch for STORM-316. - BUG (STORM-433) Friendship offer shifted up and placed over Second Life text - Investigating how friendship offers notifications are placed inside IM chat history. *FUTURE* - BUG (STORM-433) Friendship offer shifted up and placed over Second Life text *IMPEDIMENTS* - STORM-316 Vadim Productengine -- *PAST* - STORM-2 (Customizable viewer layouts): - Implementing saving sidetray state. ETA: 2d. *FUTURE* - Continue with STORM-2. *IMPEDIMENTS* - Bug STORM-465 (Missing Strings from strings.xml): - Waiting for Q to provide code-related feedback. Andrey ProductEngine -- *PAST* - picked up 2.5.0 Beta3 r220094 build - smoke tests have been passed on Linux, OSX, and Windows, refer to the spreadsheet - integrity test has been failed by VWR-24681, but I think this is some kind of a server-side issue - 2.5.0 bug-fixes verification almost has been completed, refer to spreadsheet - 87 tickets marked as Deferred because TPE has no clue how to verify those - reported 4 tickets - picked up v-d 220024 build - verified 3 issues - proceeded with regression testing of v-d branch *FUTURE* - proceed with regression testing of v-d build *IMPEDIMENTS* - none Wolfpup Lowenhar -- *PAST* - Worked @ RL . - STORM-236 : waiting for Oz's suggestions. - Attended Sprint Planning Metting. - Attended Merov’s OH. *FUTURE* - Work @ RL - STORM-941 : Dig into code and then email Oz and Leyla concerning possible fix as this is related to the DN code and there is some place that was missed in llimview that the logs still gets generated using legacy as a fallback instead of converting legacy to user name. *IMPEDIMENTS* - STORM-236 : waiting for Oz's suggestions. - Not enough time to actually work on code. Cummere Mayo -- *PAST* - jira work - another blog post *FUTURE* - more jira work - more blogs *IMPEDIMENTS* - many ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Need Clarification on interfacing with web-based UI elements
Seems to me that as more of that goes Web-side it needs more comprehensive standardization, documentation and versioning. On 2/02/2011 2:36 PM, Arrehn Oberlander wrote: This is an open question I've tried to ask at a few different linden office hours, but haven't yet received a response one way or the other. There's a couple different viewer UI elements now in the pipeline that are effectively full web pages- the search window, and now the profile window. It seems like there is more to come. As a community developer interested in customizing that user interface for particular audiences, can LL clarify a best practice for working with these elements? From a glance it appears that the presentation info and data model are commingled, complicating client-side customization of the presentation. It may be possible to scrape out data, but unmanaged minor server-side adjustments to the presentation page may break scraping activity suddenly without warning. For an example of this, one can look at the number of times LSL scripts which display profile pictures by scraping UUID's from web lookups have been broken over the last few years. I'm hoping that LL can clarify which interface a community developer can use to request and retreive this web-based data, particularly for avatar profile page information, that will not be prone to casual breakage after a third party viewer has been released. Thanks, and my apologies if the answer for this is someplace obvious I've overlooked. ___ 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/ ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] autobuild project VCExpress Command Line Build Need Testers
I tested this on my machine and in viewer-autobuild after autobuild configure -c OpenSourceRelWithDebInfo but, my machine has both Express and Pro present. From /viewer-autobuild vcbuild.exe /logfile:Secondlife.log build-vc80\Secondlife.sln /platform=win32 RelWithDebInfo|Win32 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-17050 No nearby people when over approxiamately 1000 meters
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/132/#review309 --- indra/newview/llworld.cpp http://codereview.secondlife.com/r/132/#comment235 I would strongly prefer to see this rearranged as properly nested if/then/else rather than using continue. Similarly, I'd like to have the break replaced by just adding another exit condition to the 'for' loop. - Oz On Jan. 31, 2011, 3:34 p.m., Twisted Laws wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/132/ --- (Updated Jan. 31, 2011, 3:34 p.m.) Review request for Viewer. Summary --- This modifies the getAvatars function in llworld to also include any avatars that are found within the range from the LLCharactes list as well (the list of avatars that is in the viewer object list). This should make sure that anyone that you visually see within range shows up in the list. Note that changing it in this function also affects LLFloaterAvatarPicker::populateNearMe, LLLocalSpeakerMgr::updateSpeakerList, as well as the LLPanelPeople::updateNearbyList that was originally mentioned in the Jira. The region avatars lists only contain valid position data when the avatars are below 1024m. The comment that mentions about retrieving uuids is based on the function, not the current uses. No current calls in the code are done with the avatar_ids argument NULL. Duplicates in the returned list need to be suppressed. This addresses bug VWR-17050. http://jira.secondlife.com/browse/VWR-17050 Diffs - indra/newview/llworld.cpp 691e3941d950 Diff: http://codereview.secondlife.com/r/132/diff Testing --- Simple testing in sandboxes of this patch at 20m and 2000m heights with and without avatars nearby. Tested with varying the NearMeRange to insure it does not show avatars beyond the range. Testers need to understand that RenderFarClip has an impact on the avatars that are actually in the viewer object list, so setting NearMeRange to a great distance at high altitude won't necessarily add avatars to the list. Basically if you can see the avatar and its within NearMeRange, the avatar should be in the nearby avatar list in the people panel. Thanks, Twisted ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Help prevent DOS line endings...
On 2011-02-01 15:33, Discrete Dreamscape wrote: Possible cover-all solution: use Mercurial's eol extension. It's worked pretty well for me so far, and handily autofixed all the DOS endings in a particular fork I looked at in one go. It works much like the autoprops configuration does in Subversion; hopefully with less pain. Enable it (should be included by default in all recent versions, dunno about Tortoise) by adding the following section and options to your system-wide or repo-local .hgrc file: [extensions] eol = Then add a .hgeol file to the root of the repository (it can be versioned and thus easily distributed!), and fill it with whatever standard Mercurial pattern entries are needed, like so: [patterns] **.py = native **.txt = native **.h = native **.cpp = native **Makefile = LF As soon as this file exists and the extension is active for you, further hg commands will immediately treat any non-conforming line-endings as modifications to your current working copy. Hope this is helpful; if so, it could be added to that page as well. I considered adding that, but didn't know whether some of the windows-specific files might be broken by it (if so, they too could be configured). Does anyone know? Could always put this into a test repo and run a TeamCity build ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-465 Missing Strings from strings.xml
On Feb. 2, 2011, 8:56 a.m., Kent Quirk wrote: So I have a couple of issues with this patch: * I'm worried about the translation impact, how these strings are used and where. Should they be localized? Should they not be localized? I find it hard to believe that we ONLY need to translate Home and End. * The 1 key is duplicated. Are there others? * I think the single-letter keys should be placed in a more useful order so that we can easily find missing items. Keyboard order (especially since keyboards differ) is not good enough. * I'm worried about the naming convention; single-letter names (ahem, yes, I know who's talking here) can be rather ambiguous. It's probably the easiest fix -- anything else may require much more extensive changes -- but I'm worried about this. Is this fix robust under localization? I haven't had time to investigate these issues yet; does someone else have the knowledge to discuss? Vadim ProductEngine wrote: 1) AFAIU, only those keys need translation that are currrently used in menu shortcuts (see menu_*.xml). We don't know in advance what keys we're gonna use in future shortcuts, so it makes sense to make them all localizable. 2) Thanks, the 1 is indeed duplicated. Looks like a copypaste issue. 3) Ok, the order doesn't matter to me. I can change it if you want. 4) I borrowed the naming style from existing code (see llkeyboard.cpp). Moreover, we tried adding Key_ prefix to key names for the same reasons as you say, but had to roll that change back because it had broken translation of older shortcuts (see comments in STORM-362). I would like to see a revised changeset please, reflecting 2 and 3. I'm happy with your responses to 1 and 4. - Kent --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/#review307 --- On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/ --- (Updated Jan. 19, 2011, 8:30 a.m.) Review request for Viewer. Summary --- Made all keys localizable. This addresses bug STORM-465. http://jira.secondlife.com/browse/STORM-465 Diffs - indra/newview/skins/default/xui/en/strings.xml 38465c40c060 Diff: http://codereview.secondlife.com/r/108/diff Testing --- Tested on Linux. No keys produce the warning for me. Thanks, Vadim ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-465 Missing Strings from strings.xml
On Feb. 2, 2011, 8:56 a.m., Kent Quirk wrote: So I have a couple of issues with this patch: * I'm worried about the translation impact, how these strings are used and where. Should they be localized? Should they not be localized? I find it hard to believe that we ONLY need to translate Home and End. * The 1 key is duplicated. Are there others? * I think the single-letter keys should be placed in a more useful order so that we can easily find missing items. Keyboard order (especially since keyboards differ) is not good enough. * I'm worried about the naming convention; single-letter names (ahem, yes, I know who's talking here) can be rather ambiguous. It's probably the easiest fix -- anything else may require much more extensive changes -- but I'm worried about this. Is this fix robust under localization? I haven't had time to investigate these issues yet; does someone else have the knowledge to discuss? Vadim ProductEngine wrote: 1) AFAIU, only those keys need translation that are currrently used in menu shortcuts (see menu_*.xml). We don't know in advance what keys we're gonna use in future shortcuts, so it makes sense to make them all localizable. 2) Thanks, the 1 is indeed duplicated. Looks like a copypaste issue. 3) Ok, the order doesn't matter to me. I can change it if you want. 4) I borrowed the naming style from existing code (see llkeyboard.cpp). Moreover, we tried adding Key_ prefix to key names for the same reasons as you say, but had to roll that change back because it had broken translation of older shortcuts (see comments in STORM-362). Kent Quirk wrote: I would like to see a revised changeset please, reflecting 2 and 3. I'm happy with your responses to 1 and 4. There is a few more keys that have been localized or need to be localized. In german we also translated Shift (Umschalt) and Home (Zuhause)[which is a wrong translation by the way]. We still need to localize ` (snapshot to disk and region debug console shortcuts don´t work in german) and \ (Look at last speaker shortcut doesn´t work). I´m pretty sure this is also true at least for french. Hope this helps :) - Torben --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/#review307 --- On Jan. 19, 2011, 8:30 a.m., Vadim ProductEngine wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/ --- (Updated Jan. 19, 2011, 8:30 a.m.) Review request for Viewer. Summary --- Made all keys localizable. This addresses bug STORM-465. http://jira.secondlife.com/browse/STORM-465 Diffs - indra/newview/skins/default/xui/en/strings.xml 38465c40c060 Diff: http://codereview.secondlife.com/r/108/diff Testing --- Tested on Linux. No keys produce the warning for me. Thanks, Vadim ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Help prevent DOS line endings...
This is from the help page on the extension: The optional [repository] section specifies the line endings to use for files stored in the repository. It has a single setting, native, which determines the storage line endings for files declared as native in the [patterns] section. It can be set to LF or CRLF. The default is LF. For example, this means that on Windows, files configured as native (CRLF by default) will be converted to LF when stored in the repository. Files declared as LF, CRLF, or BIN in the [patterns] section are always stored as-is in the repository. Example versioned .hgeol file: [patterns] **.py = native **.vcproj = CRLF **.txt = native Makefile = LF **.jpg = BIN [repository] native = LF So if a file pattern is specifically declared to have Windows line-endings, it should remain that way for everyone and in the repository.. probably worth some quick testing. Discrete On Wed, Feb 2, 2011 at 3:06 PM, Oz Linden (Scott Lawrence) o...@lindenlab.com wrote: On 2011-02-01 15:33, Discrete Dreamscape wrote: Possible cover-all solution: use Mercurial's eol extension. It's worked pretty well for me so far, and handily autofixed all the DOS endings in a particular fork I looked at in one go. It works much like the autoprops configuration does in Subversion; hopefully with less pain. Enable it (should be included by default in all recent versions, dunno about Tortoise) by adding the following section and options to your system-wide or repo-local .hgrc file: [extensions] eol = Then add a .hgeol file to the root of the repository (it can be versioned and thus easily distributed!), and fill it with whatever standard Mercurial pattern entries are needed, like so: [patterns] **.py = native **.txt = native **.h = native **.cpp = native **Makefile = LF As soon as this file exists and the extension is active for you, further hg commands will immediately treat any non-conforming line-endings as modifications to your current working copy. Hope this is helpful; if so, it could be added to that page as well. I considered adding that, but didn't know whether some of the windows-specific files might be broken by it (if so, they too could be configured). Does anyone know? Could always put this into a test repo and run a TeamCity build ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: VWR-17050 No nearby people when over approxiamately 1000 meters
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/132/ --- (Updated Feb. 2, 2011, 3:39 p.m.) Review request for Viewer. Changes --- I redid the patch, hopefully making the comments more acceptable and took out the use of continue. I moved retrieval of the character positions before the world positions as I found cases where the information would be incorrect right near 1024 testing with a couple people below 1024, and a couple people above. Note this is a replacement patch. Summary --- This modifies the getAvatars function in llworld to also include any avatars that are found within the range from the LLCharactes list as well (the list of avatars that is in the viewer object list). This should make sure that anyone that you visually see within range shows up in the list. Note that changing it in this function also affects LLFloaterAvatarPicker::populateNearMe, LLLocalSpeakerMgr::updateSpeakerList, as well as the LLPanelPeople::updateNearbyList that was originally mentioned in the Jira. The region avatars lists only contain valid position data when the avatars are below 1024m. The comment that mentions about retrieving uuids is based on the function, not the current uses. No current calls in the code are done with the avatar_ids argument NULL. Duplicates in the returned list need to be suppressed. This addresses bug VWR-17050. http://jira.secondlife.com/browse/VWR-17050 Diffs (updated) - indra/newview/llworld.cpp ebd53632620a Diff: http://codereview.secondlife.com/r/132/diff Testing --- Simple testing in sandboxes of this patch at 20m and 2000m heights with and without avatars nearby. Tested with varying the NearMeRange to insure it does not show avatars beyond the range. Testers need to understand that RenderFarClip has an impact on the avatars that are actually in the viewer object list, so setting NearMeRange to a great distance at high altitude won't necessarily add avatars to the list. Basically if you can see the avatar and its within NearMeRange, the avatar should be in the nearby avatar list in the people panel. Thanks, Twisted ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Review Request: STORM-864: As as developer, I would like an object oriented wrapper to make safe use of memory pools easier
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/99/#review315 --- indra/llcommon/llaprpool.h http://codereview.secondlife.com/r/99/#comment237 I think it's be more clear to use an explicit name like getAPRPool() rather than the function operator here. It produces hard to read code in a couple of places and it's just plain unclear what myPool() really does. indra/llmessage/llpumpio.cpp http://codereview.secondlife.com/r/99/#comment236 An example where the use of operator() is particularly unsightly... - Merov On Jan. 29, 2011, 9:10 a.m., Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/99/ --- (Updated Jan. 29, 2011, 9:10 a.m.) Review request for Viewer. Summary --- Please see http://jira.secondlife.com/browse/STORM-864 I made a mercurial repository available for testing here: hg clone https://bitbucket.org/aleric/viewer-development-storm-864 From the commit message: Introduces a LLThreadLocalData class that can be accessed through the static LLThread::tldata(). Currently this object contains two (public) thread-local objects: a LLAPRRootPool and a LLVolatileAPRPool. The first is the general memory pool used by this thread (and this thread alone), while the second is intended for short lived memory allocations (needed for APR). The advantages of not mixing those two is that the latter is used most frequently, and as a result of it's nature can be destroyed and reconstructed on a regular basis. This patch adds LLAPRPool (completely replacing the old one), which is a wrapper around apr_pool_t* and has complete thread-safity checking. Whenever an apr call requires memory for some resource, a memory pool in the form of an LLAPRPool object can be created with the same life-time as this resource; assuring clean up of the memory no sooner, but also not much later than the life-time of the resource that needs the memory. Many, many function calls and constructors had the pool parameter simply removed (it is no longer the concern of the developer, if you don't write code that actually does an libapr call then you are no longer bothered with memory pools at all). However, I kept the notion of short-lived and long-lived allocations alive (see my remark in the jira here: https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356 which requires that the LLAPRFile API needs to allow the user to specify how long they think a file will stay open. By choosing 'short_lived' as default for the constructor that immediately opens a file, the number of instances where this needs to be specified is drastically reduced however (obviously, any automatic LLAPRFile is short lived). This addresses bug STORM-864. http://jira.secondlife.com/browse/STORM-864 Diffs - doc/contributions.txt fe7fe04ccc9a indra/llaudio/llaudioengine_fmod.cpp fe7fe04ccc9a indra/llaudio/llvorbisencode.cpp fe7fe04ccc9a indra/llcharacter/llbvhloader.cpp fe7fe04ccc9a indra/llcharacter/llkeyframemotionparam.cpp fe7fe04ccc9a indra/llcharacter/llstatemachine.cpp fe7fe04ccc9a indra/llcommon/CMakeLists.txt fe7fe04ccc9a indra/llcommon/llapp.cpp fe7fe04ccc9a indra/llcommon/llapr.h fe7fe04ccc9a indra/llcommon/llapr.cpp fe7fe04ccc9a indra/llcommon/llaprpool.h PRE-CREATION indra/llcommon/llaprpool.cpp PRE-CREATION indra/llcommon/llcommon.h fe7fe04ccc9a indra/llcommon/llcommon.cpp fe7fe04ccc9a indra/llcommon/llerror.h fe7fe04ccc9a indra/llcommon/llerror.cpp fe7fe04ccc9a indra/llcommon/llfixedbuffer.cpp fe7fe04ccc9a indra/llcommon/llscopedvolatileaprpool.h PRE-CREATION indra/llcommon/llthread.h fe7fe04ccc9a indra/llcommon/llthread.cpp fe7fe04ccc9a indra/llcommon/llthreadsafequeue.h fe7fe04ccc9a indra/llcommon/llthreadsafequeue.cpp fe7fe04ccc9a indra/llcommon/llworkerthread.h fe7fe04ccc9a indra/llcommon/llworkerthread.cpp fe7fe04ccc9a indra/llcrashlogger/llcrashlogger.cpp fe7fe04ccc9a indra/llimage/llimage.cpp fe7fe04ccc9a indra/llimage/llimagedimensionsinfo.cpp fe7fe04ccc9a indra/llimage/llimagej2c.cpp fe7fe04ccc9a indra/llimage/llimageworker.h fe7fe04ccc9a indra/llimage/llimageworker.cpp fe7fe04ccc9a indra/llmath/llvolumemgr.cpp fe7fe04ccc9a indra/llmessage/llares.cpp fe7fe04ccc9a indra/llmessage/llcurl.cpp fe7fe04ccc9a indra/llmessage/lliohttpserver.h fe7fe04ccc9a indra/llmessage/lliohttpserver.cpp fe7fe04ccc9a indra/llmessage/lliosocket.h fe7fe04ccc9a
