Re: [opensource-dev] STORM-243 - simulator version notifications
On Tue, Jan 18, 2011 at 11:42 PM, Lance Corrimal lance.corri...@eregion.de wrote: Am Dienstag, 18. Januar 2011 schrieb Kent Quirk (Q Linden): It's not gonna be a debug setting. The information's available to put it on a HUD if you care. We're pulling the feature and simplifying the viewer. then how about getting rid of all the extra and superfluous information that the viewer presents https://jira.secondlife.com/browse/STORM-323 This. If LL's goal is simplification, I will happily help them work towards that goal. I'll have to find another viewer that meets my needs, but at least I'll know to stop making suggestions LL would never be interested in because they don't have the goals I think they have. But right now, I don't know what LL's trying to do with the viewer. Besides bringing it up to modern tech (meshes, materials later, etc), and fixing bugs, what's LL trying to do? Is there a mission statement, a motto, a creed, or a list of goals somewhere? 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
Re: [opensource-dev] STORM-243 - simulator version notifications
On a second though, this solution (paired with the information from
About Second Life) seems good enough to me.
Also, simplifying the viewer as a general approach is indeed necessary
and reasonable.
Opensource Obscure
On Tue, Jan 18, 2011 at 21:30, Twisted Laws twisted_l...@hotmail.com wrote:
Personally I see no reason for it and a user could have a simple script they
are wearing that triggers on changed, CHANGE_REGION, that tells them the
version of the server if they are interested.
default
{
on_rez(integer start_param)
{
llOwnerSay(llGetRegionName + + llGetEnv(sim_channel) + +
llGetEnv(sim_version));
}
changed(integer change)
{
if(change CHANGED_REGION)
{
llOwnerSay(llGetRegionName + + llGetEnv(sim_channel) + +
llGetEnv(sim_version));
}
}
}
___
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
___
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] STORM-243 - simulator version notifications
I don't think that a solution that makes people wear more scripted
attachments is a good one, especially since the viewer already HAS the
information.
make it a popup that is controlled by a debug option which is off by default,
and make the content of the popup more useful for people that actually want to
see it.
bye,
LC
Am Mittwoch, 19. Januar 2011, 10:46:31 schrieb Opensource Obscure:
On a second though, this solution (paired with the information from
About Second Life) seems good enough to me.
Also, simplifying the viewer as a general approach is indeed necessary
and reasonable.
Opensource Obscure
On Tue, Jan 18, 2011 at 21:30, Twisted Laws twisted_l...@hotmail.com
wrote:
Personally I see no reason for it and a user could have a simple script
they are wearing that triggers on changed, CHANGE_REGION, that tells
them the version of the server if they are interested.
default
{
on_rez(integer start_param)
{
llOwnerSay(llGetRegionName + + llGetEnv(sim_channel) +
+ llGetEnv(sim_version));
}
changed(integer change)
{
if(change CHANGED_REGION)
{
llOwnerSay(llGetRegionName + + llGetEnv(sim_channel) +
+ llGetEnv(sim_version));
}
}
}
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Daily Scrum Summary - Tuesday, January 18
Past Updates Tuesday, January 18, 2011 General Notes
--
- MMOTD: Oz
Team Status
--
Merov Linden
--
*PAST*
- MM
- STORM-863 : Using --login on command line silently fails if new TOS
needs accepting : worked on that with Josh, reviewed, built on all
platforms, moved it to review
- STORM-477 : back out that change that was making windows build fail.
Issue with boost package. See here under.
- STORM-865 : boost: logged and linked to STORM-477
- STORM-866 : Default size of web content: integrated in viewer-beta
(2.5)
*FUTURE*
- Merge Monkeying
- OH
- Triaging and code reviews
- STORM-748 : rebuild kdu libs using KDU_X86_INTRINSICS
- STORM-745 : Produce comprehensive perf baseline
*IMPEDIMENTS*
- none
Oz Linden
--
*PAST*
- Third Party Viewer developer meeting
- Did some merges, reviewed several more
- DN-202: improved display name caching
*FUTURE*
- Review many outstanding patches
- Merge Monkey
*IMPEDIMENTS*
- none
= Q Linden
--
*PAST*
- VWR-24420
- VWR-24100
- VWR-24426
- STORM-243
- DN-202
- 2.5 beta 1
*FUTURE*
- VWR-24426
- STORM-725
- DN-202
- STORM-864
- triage
- keyword enhancement
*IMPEDIMENTS*
- None
Esbee Linden
--
*PAST*
- Meetings, Email
- OOO Lunch with Q and Oz
- Play with Viewer 2.5 Beta 1
- Prep Viewer 2.5 Beta 1 blog post
- Jira ticket reviews
*FUTURE*
- Review Snowstorm Team product backlog and bug log
- Tix which require feedback: STORM-28, -812, -226, -174
- Need a developer build for the tix in the PO review queue:
STORM-2, -383, -484, -844, -834, -832, -715
https://jira.secondlife.com/secure/IssueNavigator.jspa?requestId=13662mode=hide
- Hopefully work on STORM-26 w/Q
- Review tickets assigned to me
- Plan tomorrow's Snowstorm Team office hour
*IMPEDIMENTS*
- None
Paul ProductEngine
--
*PAST*
- BUG STORM-634 (Search and World map SLURLs are not translated in
Danish localisation)
- Investigated. Assigned to Eli as it's just caused by missing
translation in xml file.
- BUG STORM-680 (Avaline callers are added to the Recent list)
- WIP. Stuck while subscribing to the AVALINE voice service. Server
doesn't return Access Code, though my balance decreased. Discussed with
Andrey and he has the same problem. Will try tomorrow.
- BUG STORM-484 (The long name is not truncated in Build tools)
- Fixed and sent for review
- BUG STORM-533 (User is unable to save snapshot after pressing More
and Less (without any changes))
- Resolved as cannot reproduce
- BUG STORM-635 (Several strings in My Profile SP are not translated in
Danish localization )
- Resolved as cannot reproduce. Since Web Profiles feature has been
already implemented, this bug is not actual anymore.
*FUTURE*
- BUG STORM-680 (Avaline callers are added to the Recent list)
*IMPEDIMENTS*
- none
Seth Productengine
--
*PAST*
- BUG (STORM-383) Context menu cannot be open for Landmark that are
located in the My inventory-Trash folder
- Updated fix according to review feedback.
- BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
Name/System Folders to Top Do not apply and settings changes do not persist
after relogging.
- Investigating. Looking for the reason for not applying saved
inventory sort order after re-login.
*FUTURE*
- BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
Name/System Folders to Top Do not apply and settings changes do not persist
after relogging.
*IMPEDIMENTS*
- none
Vadim Productengine
--
*PAST*
- Bug STORM-373 ('Rename' is sometimes disabled in inventory item context
menu):
- WIP, 80%.
*FUTURE*
- Bug STORM-373 ('Rename' is sometimes disabled in inventory item context
menu):
- Complete and submit.
*IMPEDIMENTS*
- Unclear what to do with STORM-174 (Checkbox needed to save inventory
scripts as Mono):
- the feature requires simulator work.
- Need Esbee's answer in STORM-243 (Suppress version change message in
the viewer).
- No clear acceptance criteria for STORM-226 (Floating Text aligns
improperly).
Andrey Productengine
--
*PAST*
- picked up v-d- build 219086
- proceeded with regression testing of v-d build
- sidebar testplan review revise
*FUTURE*
- continue with v-d stuff testing
*IMPEDIMENTS*
- none
Wolfpup Lowenhar
--
*PAST*
- Worked @ RL and in world.
- STORM-236 : waiting on email reply from Esbee.
- STORM-243 : gave feedback both in jira and on RB
*FUTURE*
- May check to
Re: [opensource-dev] Review Request: 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.
If everything will remain as it is in current implementation, layouts will be saved as several LLSD files in one folder, not in single LLSD file - it was done to allow adding of image files into layouts in future. So placing a folder into an archive and sending it by email (or other way) would be needed to share a layout. About proposed solutions- they both sound reasonable and probably may be added to the feature in future. 2011/1/18 Opensource Obscure opensourceobsc...@gmail.com: Just to say this new feature looks very promising! A question. The 3rd note says the files associated with saved layouts will be LLSD text files, so you can email or paste layouts into a notecard to share with other users. (the note also explains why this is not the ideal behaviour ever, and also why we have to deal with it for now) This sounds even cooler! ...but - how would that process of sharing LLSD files exactly work? I mean, where will users have to put those LLSD files? here is the scenario I'm thinking about: - a teacher (or mentor, friend, etc) is explaining to a new user how to build in SL - the teacher shares with the new user an LLSD file that contains an ideal layout for building, and says put this in your SL folder - the new user is now confused: many newbies don't know the difference between the software folder and the settings folder, and they don't know where those are; this gets even worst to solve for people trying to help them, because pathnames are different across different operating systems, across different releases of the same o.s. - or because of localization. possible solutions: - add another option in Preferences to choose the folder where we keep layouts - add a menu command to choose a specific layout file - then the viewer would copy that file into the actual settings folder. 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
Re: [opensource-dev] Review Request: 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.
On 2011-01-18 10:28, Opensource Obscure wrote: Just to say this new feature looks very promising! A question. The 3rd note says the files associated with saved layouts will be LLSD text files, so you can email or paste layouts into a notecard to share with other users. (the note also explains why this is not the ideal behaviour ever, and also why we have to deal with it for now) This sounds even cooler! ...but - how would that process of sharing LLSD files exactly work? I mean, where will users have to put those LLSD files? here is the scenario I'm thinking about: - a teacher (or mentor, friend, etc) is explaining to a new user how to build in SL - the teacher shares with the new user an LLSD file that contains an ideal layout for building, and says put this in your SL folder - the new user is now confused: many newbies don't know the difference between the software folder and the settings folder, and they don't know where those are; this gets even worst to solve for people trying to help them, because pathnames are different across different operating systems, across different releases of the same o.s. - or because of localization. possible solutions: - add another option in Preferences to choose the folder where we keep layouts - add a menu command to choose a specific layout file - then the viewer would copy that file into the actual settings folder. There are a variety of possible solutions to sharing between users, but sharing is explicitly not a part of this particular issue. The goal of this one is to make it possible to edit and save your layout choices. If/when we take up sharing those layouts, that will be a new issue. ___ 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] Using the codereview site for consults
On 2011-01-18 22:22, WolfPup Lowenhar wrote: I'll apologize in advanced for length of this email but I need some extra eyes on the code for this Diff to show changes being made(also the reason for the length of email): This post suggests something to me I think it would be easier for everyone if the codereview site was used for posting this kind of query. It displays the code in a more readable way, and with more context. To be clear - it's perfectly ok, in fact encouraged, to post review requests for code that is not complete or ready for submission. Write up what kind of help you're looking for in the Description field, and the query will come to this list just like any other post (incidentally, I'm very happy with how people are responding to these review requests - thank you all for your help and attention). (this is not a criticism of what Wolfpup posted - it's a great query - I'm just clarifying that the codereview site may be used for this 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
[opensource-dev] Review Request: STORM-465 Missing Strings from strings.xml
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/108/ --- 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
[opensource-dev] [JIRA] Indexing by search engines
It seems to me that the Google indexing of jira.secondlife.com is a bit less efficient than in the past, where in the past may approx. mean before the recent JIRA upgrade. I have mixed results - usually no problems - but sometimes it's a bit harder for me to get to the desired jira.secondlife.com/browse/xxx page than in the past. I don't have many evidences about this, but as an example http://www.google.com/search?q=storm-465site:jira.secondlife.com doesn't show https://jira.secondlife.com/browse/STORM-465 in results, nor does www.google.com/search?q=The+missing+strings+are+shown+look+like+the+shortcut+part+of+the+menus Is this expected? Anyone else experiencing this? If this issue exists, can be solved by fine-tuning JIRA website settings? Opensource Obscure -- http://twitter.com/oobscure - http://opensourceobscure.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
Re: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too.
On Jan. 19, 2011, 2:44 p.m., Boroondas Gupte wrote: validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. The different intention is needed. Without the change Aleric suggests, files that have a specific byte of their UUID being 0 will never be validated. On the other hand, sometimes no files will be tested at all (when validate_idx is 256, as no byte can assume that value). The different intention is needed. Err ... I mean The different behavior is intentional (and needed). - Boroondas --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review199 --- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/ --- (Updated Jan. 14, 2011, 1:02 p.m.) Review request for Viewer. Summary --- Trivial patch, just removes stupidity. This addresses bug VWR-24321. http://jira.secondlife.com/browse/VWR-24321 Diffs - doc/contributions.txt b0bd26c5638a indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/90/diff Testing --- Thanks, Aleric ___ 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-24321: Validate textures starting with 00 too.
On Jan. 19, 2011, 2:44 p.m., Boroondas Gupte wrote: indra/newview/lltexturecache.cpp, line 1595 http://codereview.secondlife.com/r/90/diff/1/?file=413#file413line1595 Old code: validate_idx will now be in [1,256]. (one higher than before) New code: validate_idx will stay in [0,256]. (untouched) Old and new code: next_idx will be in [0,256], but different than the new-code validate_idx (one higher modulo 256). ok, tripple checked the ranges, but still typed them wrong ... this should be New code: validate_idx will stay in [0,255]. (untouched) Old and new code: next_idx will be in [0,255], but different than the new-code validate_idx (one higher modulo 256). On Jan. 19, 2011, 2:44 p.m., Boroondas Gupte wrote: indra/newview/lltexturecache.cpp, lines 1596-1598 http://codereview.secondlife.com/r/90/diff/1/?file=413#file413line1596 next_idx (still in the range [0,256]) gets saved to setting. (Thus why the value we get from the setting above must be in that interval.) make this [0,255], too ^_^ - Boroondas --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review199 --- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/ --- (Updated Jan. 14, 2011, 1:02 p.m.) Review request for Viewer. Summary --- Trivial patch, just removes stupidity. This addresses bug VWR-24321. http://jira.secondlife.com/browse/VWR-24321 Diffs - doc/contributions.txt b0bd26c5638a indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/90/diff Testing --- Thanks, Aleric ___ 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-24321: Validate textures starting with 00 too.
On Jan. 18, 2011, 12:09 p.m., Merov Linden wrote: indra/newview/lltexturecache.cpp, line 1595 http://codereview.secondlife.com/r/90/diff/1/?file=413#file413line1595 validate_idx being used in a test later, it's not just for (validate_idx == 0) that the behavior will be different. I need to understand better what that idx is all about or you need to give a bit more explanation before I approve this diff. Aleric Inglewood wrote: The debug setting CacheValidateCounter is set to 'next_id', which makes clear what it's meaning is: namely, the id that we will check next time. next_idx is a very local variable that is simply set to the value of CacheValidateCounter plus 1, and then that value is stored to CacheValidateCounter again for next time. validate_idx is the ID that is actually being tested this time. Hence, it should be the value of CacheValidateCounter before we increase that. Obviously, those ID's should be in the range 0...255, which is garanteed by doing a modulo 256 on next_id before writing it to CacheValidateCounter. The old code also increases validate_idx *before* it is used. That means that it will be in the range 1...256, and 0 is never tested (note that validate_idx is just increased, there is no modulo applied, so it's obvious that it shouldn't be increased). Even the wording (next_id) suggests that validate_idx should just be the value of CacheValidateCounter, which is the value of the previous next_id... So, after this patch, we get to the following code with validate_idx in the range 0...255, as it should be. Cron Stardust wrote: Just double checking, as switching from pre-increment to addition can change behavior: In both cases next_idx will have the same value after this line is executed, however validate_idx will not. Prediff start state: validate_idx == 0; Prediff stop state: validate_idx == 1; next_idx == 1; Postdiff start state: validate_idx == 0; Postdiff stop state: validate_idx == 0; next_idx == 1; And another round over at the other end: Prediff start state: validate_idx == 255; Prediff stop state: validate_idx == 256; next_idx == 0; Postdiff start state: validate_idx == 255; Postdiff stop state: validate_idx == 255; next_idx == 0; So, yes, validate_idx will only have a 255 in it in this last case, however the over-all behavior has changed: validate_idx isn't being incremented at all in this line. WARNING: I have NOT looked at the rest of the diff, only at this one line. Nor do I know if validate_idx should or shouldn't be incremented by this line of code. Twisted Laws wrote: Given the way this seems to work to me without changing the sequence things are checked... I'd change line 1619 to if (uuididx == (validate_idx % 256)) Otherwise it was checking for 1 thru 256 and never 0... this does not change what appears to be incorrect coding where Aleric pointed out and thus won't change the current logic that it starts by checking 1 thru 255 before checking 0. To retain the current sequence that things are checked, you would have to compare uuididx to next_idx along with the change Aleric provided. However it seems to me that all is ok with using Aleric's correction and leaving the remaining code untouched. (I can't see where changing the sequence of checking makes a difference.) Boroondas Gupte wrote: Just double checking, as switching from pre-increment to addition can change behavior: In both cases next_idx will have the same value after this line is executed, however validate_idx will not. That's the intention. Without the change suggested here, validate_idx ends up in the wrong range. See my more detailed review below. @Cron Stardust : That is correct. The bug was that validate_idx was 1 too large. Nor incrementing it is the correct thing. Re the 'WARNING': this line is the only line in the diff :p - Aleric --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review191 --- On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/ --- (Updated Jan. 14, 2011, 1:02 p.m.) Review request for Viewer. Summary --- Trivial patch, just removes stupidity. This addresses bug VWR-24321. http://jira.secondlife.com/browse/VWR-24321 Diffs - doc/contributions.txt b0bd26c5638a indra/newview/lltexturecache.cpp b0bd26c5638a Diff:
Re: [opensource-dev] Review Request: VWR-24321: Validate textures starting with 00 too.
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/#review204 --- Ship it! Thanks for the clarification! Looks good to me. - Cron On Jan. 14, 2011, 1:02 p.m., Aleric Inglewood wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/90/ --- (Updated Jan. 14, 2011, 1:02 p.m.) Review request for Viewer. Summary --- Trivial patch, just removes stupidity. This addresses bug VWR-24321. http://jira.secondlife.com/browse/VWR-24321 Diffs - doc/contributions.txt b0bd26c5638a indra/newview/lltexturecache.cpp b0bd26c5638a Diff: http://codereview.secondlife.com/r/90/diff Testing --- Thanks, Aleric ___ 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] STORM-243 - simulator version notifications
On 2011-01-18, at 15:58, Sarah (Esbee) Kuehnle wrote: This is not a feature belongs in the Viewer. If there's more data you want out of llGetEnv(), I'd suggest filing an SVC feature request. fx voice=eeyoreJust wait, next month we'll have someone needing help figuring out why llGetEnv is broken on the latest BlueSteel/fx :) :) :) :) (No, I'm not arguing, I'm being amused) (in case the smileys didn't get that across) ___ 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
