Re: [opensource-dev] PO Test build (sprint 10 end game)

[Anya Kanevsky]

Merov, are you sure this build is correct? I tried all issues in the list
with this build (220162)  and each one failed.
a

2011/2/2 Philippe (Merov) Bossut 

> Hi guys,
>
> Here are the binaries for the rest of sprint 10 bugs waiting for PO
> approval (+ 1 sprint 11):
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/220162/index.html
>
> Bug list:
> * STORM-219 : "Folders Always By Name" and "System Folders To Top" options
> are missing from the Inventory menu. Can't sort folders!
> * 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.
> * STORM-397 : Dropping wearables from a notecard to COF should be
> prohibited
> * STORM-507 : User that has sent p2p call invitation to  other user, is not
> added to Recent tab
> * STORM-513 : "Allow media to auto - play" check-box is enable after Media
> check-box was unchecked
> * STORM-610 : Changes to Environment Editor: water color change is not
> saved
> * STORM-655 : mismatched filter extension in snapshot floater (jpeg vs
> jpg).
>
> Please test and report your finding. Folks with PO power (you know who you
> are...), add approval to the JIRAs and mark them for integration (click
> "Merge").
>
> 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
>
___
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

[Oz Linden]

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

Ship it!


- Oz


On Feb. 2, 2011, 3:39 p.m., Twisted Laws wrote:
> 
> ---
> 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.
> 
> 
> 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 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] Need Clarification on interfacing with web-based UI elements

[Arrehn Oberlander]

I'm concerned that I haven't received a response. I've already asked this
question a few times at office hours for Lindens involved in development,
and now here. Even if the answer is "LL will not support a a stable API to
web services" at least it is some kind of answer. "LL will continue to
provide existing non-web APIs for this same data for the indefinite future"
may be an option as well, but I haven't heard this either. "We're working on
this, check back in a month" is also an answer that would be welcomed over
silence.

As a developer I'm looking for a documentation, examples, and best practice
methodology for how to customize the presentation of data LL provides via
web pages, such as web-based profiles. Specifically I'm looking for an
interface to extract at a minimum:

- Profile text
- "Real World" text
- a user's entered web URL
- birthdate info
- payment status
- partner status & partner
- "picks" data
- profile picture at its original resolution
- "real world" profile picture at its original resolution

>From the current web-based profile pages and viewer implementations I've
seen in 2.6, these fields aren't tagged with metadata in a way that would
make them easy and reliable to extract, or provided in a format separate
from the heavyweight presentation layer. Even if this data was tagged in
some way, I'm looking for assurances that it would be a protected, stable
interface, not likely to be broken by casual changes without warning.

Can anyone provide insight on this topic?

Thanks,
-A
___
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

[Vadim ProductEngine]

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

(Updated Feb. 3, 2011, 8:20 a.m.)


Review request for Viewer.


Changes
---

- Reordered strings more logically.
- Removed duplicated "1" string.
- Using a script, found two more duplicates ("Home", "Esc"), removed them.
- Using the same script, found out that the arrow keys names ("Left", "Right", 
"Up", "Down") were duplicated as well.
  Fixed that by renaming HUD direction strings and updated the code utilizing 
them accordingly.

Automated the work as much as possible to avoid further errors (I hope that 
helped :-)).


Summary
---

Made all keys localizable.


This addresses bug STORM-465.
http://jira.secondlife.com/browse/STORM-465


Diffs (updated)
-

  indra/newview/llmaniprotate.cpp b542f8134a2b 
  indra/newview/skins/default/xui/da/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/de/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/en/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/es/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/fr/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/it/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/ja/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/nl/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/pl/strings.xml b542f8134a2b 
  indra/newview/skins/default/xui/pt/strings.xml b542f8134a2b 

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

[Vadim ProductEngine]

> 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 copy&paste 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.
> 
> Torben Trautman wrote:
> 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 :)
> 
> Dil Spitz wrote:
> just a tiny hint, on my german keyboard they call home (Pos 1)
> 
> Dil Spitz wrote:
> indeed the de\strings.xml looks like google translated it.
> Now i remember why i always switch SL to english ;)
> Due the translation is out of the context in the strings.xml a normal 
> translating person, who do not know SL, couldn't get the job right. 
> /me guessing the other non-english languages might look like the german 
> too.
> I suggest to give the residents a role to tune the translation of the 
> language they speak. https://jira.secondlife.com/browse/VWR-24712

Dil, it's not me who works on the German translation. :-) I think you should 
file bugs about invalid translations you notice.


- Vadim


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


On Feb. 3, 2011, 8:20 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/108/
> ---
> 
> (Updated Feb. 3, 2011, 8:20 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/llmaniprotate.cpp b542f8134a2b 
>   indra/newview/skins/default/xui/da/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/de/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/en/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/es/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/fr/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/it/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/ja/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/nl/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/pl/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/pt/strings.xml b542f8134a2b 
> 
> 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

[Kent Quirk]

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

Ship it!


I'm happy now. :)

- Kent


On Feb. 3, 2011, 8:20 a.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/108/
> ---
> 
> (Updated Feb. 3, 2011, 8:20 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/llmaniprotate.cpp b542f8134a2b 
>   indra/newview/skins/default/xui/da/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/de/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/en/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/es/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/fr/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/it/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/ja/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/nl/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/pl/strings.xml b542f8134a2b 
>   indra/newview/skins/default/xui/pt/strings.xml b542f8134a2b 
> 
> 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] PO Test build (sprint 10 end game)

[Philippe (Merov) Bossut]

On Thu, Feb 3, 2011 at 12:51 AM, Anya Kanevsky
wrote:

> Merov, are you sure this build is correct? I tried all issues in the list
> with this build (220162)  and each one failed.
>
>
Strange. I just noticed that TC fired 2 builds in rapid succession, each
pointing to the same set of changes. Can you try that build then:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/220166/index.html

Let me know if it works or not. If not, I'll clean up that repo and do a new
PO build afresh.

Cheers,
- Merov
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] autobuild and vsexpress

[Nicky Perian]

If anyone wants to help bring autobuild to vsexpress here are two 
starter(1commit each) repositories. 
http://nic...@bitbucket.org/NickyP/viewer-autobuild-express-wip
http://nic...@bitbucket.org/NickyP/autobuild-vcexpress-wip
I was able to make a  warts and all build of LindenDeveloper.exe and logged to 
aditi with 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

Re: [opensource-dev] Need Clarification on interfacing with web-based UI elements

[Oz Linden (Scott Lawrence)]

On 2011-02-03 11:13, Arrehn Oberlander wrote:
> I'm concerned that I haven't received a response. I've already asked 
> this question a few times at office hours for Lindens involved in 
> development, and now here. Even if the answer is "LL will not support 
> a a stable API to web services" at least it is some kind of answer. 
> "LL will continue to provide existing non-web APIs for this same data 
> for the indefinite future" may be an option as well, but I haven't 
> heard this either. "We're working on this, check back in a month" is 
> also an answer that would be welcomed over silence.

Apologies for not at least sending an ACK.

I am pursuing this within LL.   At the very least, "check back in a 
month" is something I can say now.  I expect to be able to say something 
significantly better eventually - maybe even sooner than a month :-)


___
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] autobuild and vsexpress

[Oz Linden (Scott Lawrence)]

On 2011-02-03 11:54, Nicky Perian wrote:
If anyone wants to help bring autobuild to vsexpress here are two 
starter(1commit each) repositories.

http://nic...@bitbucket.org/NickyP/viewer-autobuild-express-wip
http://nic...@bitbucket.org/NickyP/autobuild-vcexpress-wip
I was able to make a  warts and all build of LindenDeveloper.exe and 
logged to aditi with it.



would you mind posting the changesets on codereview.secondlife.com so 
that I can get the autobuild devs to review them?


___
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] PO Test build (sprint 10 end game)

[Anya Kanevsky]

Thank you, Merov!
Yes, this build works, issues that were fixed are actually fixed and all is
well with the world!


2011/2/3 Philippe (Merov) Bossut 

> On Thu, Feb 3, 2011 at 12:51 AM, Anya Kanevsky <
> akanev...@productengine.com> wrote:
>
>> Merov, are you sure this build is correct? I tried all issues in the list
>> with this build (220162)  and each one failed.
>>
>>
> Strange. I just noticed that TC fired 2 builds in rapid succession, each
> pointing to the same set of changes. Can you try that build then:
>
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-import/rev/220166/index.html
>
> Let me know if it works or not. If not, I'll clean up that repo and do a
> new PO build afresh.
>
> 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

Re: [opensource-dev] autobuild and vsexpress

[Nicky Perian]

sure, 
Be later today or first thing in the morning at -6GMT.




From: Oz Linden (Scott Lawrence) 
To: Nicky Perian 
Cc: opensource-dev@lists.secondlife.com; robin.cornel...@gmail.com
Sent: Thu, February 3, 2011 11:05:12 AM
Subject: Re: autobuild and vsexpress

On 2011-02-03 11:54, Nicky Perian wrote: 
If anyone wants to help bring autobuild to vsexpress here are two 
starter(1commit each) repositories. 
>http://nic...@bitbucket.org/NickyP/viewer-autobuild-express-wip
>http://nic...@bitbucket.org/NickyP/autobuild-vcexpress-wip
>I was able to make a  warts and all build of LindenDeveloper.exe 
>and 
>logged to aditi with it.
>
>
>
would you mind posting the changesets on codereview.secondlife.com so that I 
can 
get the autobuild devs to review them?


  ___
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

[Kadah]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It would have been nice if web profiles had been done in something like
XSLT instead :P
Raw profile data can easily be converted or stored into XML and
presintation would be taken care of by Webkit's libxslt.

On 2/3/2011 9:01 AM, Oz Linden (Scott Lawrence) wrote:
> On 2011-02-03 11:13, Arrehn Oberlander wrote:
>> I'm concerned that I haven't received a response. I've already asked 
>> this question a few times at office hours for Lindens involved in 
>> development, and now here. Even if the answer is "LL will not support 
>> a a stable API to web services" at least it is some kind of answer. 
>> "LL will continue to provide existing non-web APIs for this same data 
>> for the indefinite future" may be an option as well, but I haven't 
>> heard this either. "We're working on this, check back in a month" is 
>> also an answer that would be welcomed over silence.
> 
> Apologies for not at least sending an ACK.
> 
> I am pursuing this within LL.   At the very least, "check back in a 
> month" is something I can say now.  I expect to be able to say something 
> significantly better eventually - maybe even sooner than a month :-)
> 
> 
> ___
> 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNSwAxAAoJEIdLfPRu7qE2EPkIAL8nCxbPJqBOYM4pjM7h3APJ
GTzoMgm0CgQybOr2QuJMkK6Y00oy+iMvVoYwRyOOPHUX4bzN3AbFMxIxnuJMg+zv
Ko7qSPVarfPkaWuuh3Pkxau3tpeuaDAOYg42IPiQm0Dt/kL28UX+Np5YiQ9WlDoz
BAWmxEHrwUDGXC9CYuP7snrOeLjVtVTGsB0H3FeEXEFi+Tl49/3iTPDuNf4Ec+yf
Lwxn3fng2jybNiruRKSO4OxWhu2Dgy0B0TZMCk7bLrz/wQLR6Op3e/x9t2zihMES
nti9WdGkIpm7OU6/iDyK6aqtbqv/c+cphGMimM6RNj8pvWdL80yE9/FPsXSYESI=
=nr1M
-END PGP SIGNATURE-
___
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-971 'Stop Tracking' menu item is still enabled in Mini-map floater after you stopped tracking in Nearby mini-map

[Twisted Laws]

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

Review request for Viewer.


Summary
---

Sets "Stop Tracking" enabled based on tracking if true or false instead of only 
when true.  Also made it check for menu pointer validity to remove a remote 
crash possiblity.


This addresses bug STORM-971.
http://jira.secondlife.com/browse/STORM-971


Diffs
-

  indra/newview/llnetmap.cpp ec4a9fd30688 

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


Testing
---

My testing was to open the side panel nearby, and verify that the state of the 
menu was correct when tracking by the different methods and disabled.   Then 
leaving that open, openned a mini-map instance and repeated testing its state 
tracking and not.  Also tried the reverse. Verified that every possibility I 
could think of, the state of both menus was always correct.  

Correct state is Stop Tracking is enabled anytime tracking is on for avatars or 
landmarks and is not enabled when Tracking has been stopped no matter where you 
stopped tracking (i.e, clicking on red arrow in view window, and using the 
various menues).


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

[opensource-dev] Asstiance needed for STORM-236

[WolfPup Lowenhar]

After today's scrum meeting I started working on adding an new panel to the
code to contain the resize handle for NearByChat and I'm having trouble
figuring out how to add the panel to the code, it has been added to the xml,
as there is no clear definition in the code for how the panels are read from
the xml file so that the panels size information can be processed. I need
help figuring out the following things:

1. How the panels are defined in the code.

2. How the code is actually reading the size of said panel.

3. How does the code handle panels being drawn.

 

None of the above is documented in the code at all!

 

 

___
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] UI Hints - getting them again

[Jonathan Welch]

There is a menu control for UI Hints, but as there are only 10 of
them, and you only get each one once, you might want to know how to
reset them from their "has already been seen" state if you are
debugging or doing development work.

These settings are kept in ignorable_dialogs.xml in the same directory
where you will find your local copy of settings.xml, etc.

-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

[opensource-dev] Review Request: Make autobuild-viewer work under Visual Studio 2005 Express Edition

[Nicky Perian]

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

Review request for Viewer.


Summary
---

Make viewer-autobuild work under Visual Studio 2005 Express Edition.

This modification is a test case and applies to  -OpenSourceRelWithDebInfo only.


This addresses bugs autobuild, vcexpress and with.
http://jira.secondlife.com/browse/autobuild
http://jira.secondlife.com/browse/vcexpress
http://jira.secondlife.com/browse/with


Diffs
-

  autobuild.xml 00453191c1b9 

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


Testing
---

Configuration batch file content:
@echo
call c:\VC80\VC\bin\vcvars32.bat
C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug configure -c 
OpenSourceRelWithDebInfo

Build batch file content:
C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug build -c 
OpenSourceRelWithDebInfo

There is one post build re-configuration error related to devenv versus vcbuild 
parameter sequence.
However,C:\lindenhg\viewer-autobuild-express-wip\build-vc80\newview\RelWithDebInfo\LindenDeveloper.exe
 was built and
log on to aditi successful.


Thanks,

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

Re: [opensource-dev] Review Request: Make autobuild-viewer work under Visual Studio 2005 Express Edition

[Nicky Perian]

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


will redo looks like line ending problems.

- Nicky


On Feb. 3, 2011, 1:51 p.m., Nicky Perian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/134/
> ---
> 
> (Updated Feb. 3, 2011, 1:51 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Make viewer-autobuild work under Visual Studio 2005 Express Edition.
> 
> This modification is a test case and applies to  -OpenSourceRelWithDebInfo 
> only.
> 
> 
> This addresses bugs autobuild, vcexpress and with.
> http://jira.secondlife.com/browse/autobuild
> http://jira.secondlife.com/browse/vcexpress
> http://jira.secondlife.com/browse/with
> 
> 
> Diffs
> -
> 
>   autobuild.xml 00453191c1b9 
> 
> Diff: http://codereview.secondlife.com/r/134/diff
> 
> 
> Testing
> ---
> 
> Configuration batch file content:
> @echo
> call c:\VC80\VC\bin\vcvars32.bat
> C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug configure -c 
> OpenSourceRelWithDebInfo
> 
> Build batch file content:
> C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug build -c 
> OpenSourceRelWithDebInfo
> 
> There is one post build re-configuration error related to devenv versus 
> vcbuild parameter sequence.
> However,C:\lindenhg\viewer-autobuild-express-wip\build-vc80\newview\RelWithDebInfo\LindenDeveloper.exe
>  was built and
> log on to aditi successful.
> 
> 
> Thanks,
> 
> 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

Re: [opensource-dev] Review Request: Make autobuild-viewer work under Visual Studio 2005 Express Edition

[Nicky Perian]

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

(Updated Feb. 3, 2011, 2:35 p.m.)


Review request for Viewer.


Summary
---

Make viewer-autobuild work under Visual Studio 2005 Express Edition.

This modification is a test case and applies to  -OpenSourceRelWithDebInfo only.


This addresses bugs autobuild, vcexpress and with.
http://jira.secondlife.com/browse/autobuild
http://jira.secondlife.com/browse/vcexpress
http://jira.secondlife.com/browse/with


Diffs
-

  autobuild.xml 00453191c1b9 

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


Testing
---

Configuration batch file content:
@echo
call c:\VC80\VC\bin\vcvars32.bat
C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug configure -c 
OpenSourceRelWithDebInfo

Build batch file content:
C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug build -c 
OpenSourceRelWithDebInfo

There is one post build re-configuration error related to devenv versus vcbuild 
parameter sequence.
However,C:\lindenhg\viewer-autobuild-express-wip\build-vc80\newview\RelWithDebInfo\LindenDeveloper.exe
 was built and
log on to aditi successful.


Thanks,

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

Re: [opensource-dev] Review Request: Make autobuild-viewer work under Visual Studio 2005 Express Edition

[Nicky Perian]

> On Feb. 3, 2011, 1:59 p.m., Nicky Perian wrote:
> > will redo looks like line ending problems.

Reponed for comment. Don't know if it is line endings or normal operations that 
cause view diff to display the entire file. 


- Nicky


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


On Feb. 3, 2011, 2:35 p.m., Nicky Perian wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/134/
> ---
> 
> (Updated Feb. 3, 2011, 2:35 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Make viewer-autobuild work under Visual Studio 2005 Express Edition.
> 
> This modification is a test case and applies to  -OpenSourceRelWithDebInfo 
> only.
> 
> 
> This addresses bugs autobuild, vcexpress and with.
> http://jira.secondlife.com/browse/autobuild
> http://jira.secondlife.com/browse/vcexpress
> http://jira.secondlife.com/browse/with
> 
> 
> Diffs
> -
> 
>   autobuild.xml 00453191c1b9 
> 
> Diff: http://codereview.secondlife.com/r/134/diff
> 
> 
> Testing
> ---
> 
> Configuration batch file content:
> @echo
> call c:\VC80\VC\bin\vcvars32.bat
> C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug configure -c 
> OpenSourceRelWithDebInfo
> 
> Build batch file content:
> C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug build -c 
> OpenSourceRelWithDebInfo
> 
> There is one post build re-configuration error related to devenv versus 
> vcbuild parameter sequence.
> However,C:\lindenhg\viewer-autobuild-express-wip\build-vc80\newview\RelWithDebInfo\LindenDeveloper.exe
>  was built and
> log on to aditi successful.
> 
> 
> Thanks,
> 
> 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

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

[Aleric Inglewood]

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


- Aleric


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

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

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

[Aleric Inglewood]

> On Feb. 3, 2011, 6:35 p.m., Aleric Inglewood wrote:
> >

Can this patch please be added to viewer-development? It's getting really 
annoying that I have to apply patches to the soruce tree before it even can 
compile cleanly :(.


- Aleric


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


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

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: VWR-24366: CMAKE_EXE_LINKER_FLAGS not honored when linking the viewer binary if -DLL_TESTS:BOOL=ON

[Aleric Inglewood]

> On Jan. 14, 2011, 5:27 p.m., Merov Linden wrote:
> > Makes sense.

*bump*

Can this patch please be added to viewer-development soon? It's annoying that I 
can't even compile the viewer without having to apply local patches :/ (I just 
lost an hour because I didn't realize that this patch still wasn't in v-d and 
waited and waited and waited and waited an waited for the viewer to link, until 
I finally just hit control-C.)


- Aleric


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


On Jan. 14, 2011, 1:15 p.m., Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/95/
> ---
> 
> (Updated Jan. 14, 2011, 1:15 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Setting CMAKE_EXE_LINKER_FLAGS to "" because the tests "need" that is pretty
> hard measure. Not only is it not necessary to do so, it also changes how
> the viewer is linked depending on a whether or not the tests are compiled
> and that is not good.
> 
> The reason that this was needed is that libgmock is underlinked
> (see http://wiki.mandriva.com/en/Underlinking), which is not compatible
> with -Wl,--as-needed that is being used on linux. libgmock.so.0 needs
> a symbol that is defined in libgtest.so.o, but -lgtest was not passed
> to the linker when creating libgmock.so.0:
> 
> Underlinked (no libgtest.so.o):
> $ objdump -p /usr/lib/libgmock.so.0 | grep NEEDED
> NEEDED libstdc++.so.6
> NEEDED libm.so.6
> NEEDED libc.so.6
> NEEDED libgcc_s.so.1
> 
> The solution is to wrap between -Wl,--no-as-needed -lgtest -Wl,--as-needed
> causing it to be added again. This is only needed on linux, since that
> the only platform that we use -Wl,--as-needed on. Moreover, we can just
> set GOOGLEMOCK_LIBRARIES to "gmock -Wl,--no-as-needed gtest -Wl,--as-needed"
> since that is only passed to TARGET_LINK_LIBRARIES which only adds -l
> in front of 'things' that don't start with '-', to allow you do pass
> special flags like this.
> 
> 
> This addresses bug VWR-24366.
> http://jira.secondlife.com/browse/VWR-24366
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 422f636c3343 
>   indra/cmake/GoogleMock.cmake 422f636c3343 
>   indra/cmake/LLAddBuildTest.cmake 422f636c3343 
> 
> Diff: http://codereview.secondlife.com/r/95/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-24312: Massively duplicated objects (part 2)

[Aleric Inglewood]

> On Jan. 31, 2011, 6:44 p.m., Merov Linden wrote:
> > @Aleric: OK, you convinced me on all accounts *except* for the ease of 
> > merge which I want to test myself before giving my blessing to this patch. 
> > You wouldn't be the first one be to claim that "it merges" and create some 
> > issues unwittingly. If you could post the URL of an hg repo with your 
> > patch, I'll be happy to give it a spin building on all platforms.
> > 
> > BTW, thanks for the super detailed comment: very interesting stuff.

Thanks. I made a repository available here:
https://bitbucket.org/aleric/viewer-development-storm-955

Due to technical reasons I had to base it on a recent viewer-development commit,
but during the merge I had no collisions except in contributions.txt ;) (while
I made the original patch a few hunderd commits ago).

[PS I added this TWO DAYS ago... but forgot to click on 'Publish'... this kinda 
sucks a bit]


- Aleric


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


On Jan. 16, 2011, 5:53 a.m., Aleric Inglewood wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/81/
> ---
> 
> (Updated Jan. 16, 2011, 5:53 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Turns out that most of my SNOW-800 patch was included in Viewer 2 (albeit 
> without crediting me).
> However, not everything was used and some more cleaning up was possible.
> 
> After this patch, and when compiling with optimization, there are no 
> duplicates left
> anymore that shouldn't be there in the first place: apart from the debug 
> stream
> iostream guard variable, there are several static variables with the same 
> name (r, r1,
> r2, etc) but that indeed actually different symbol objects. Then there are a 
> few
> constant POD arrays that are duplicated a hand full of times because they are
> accessed with a variable index (so optimizing them away is not possible). I 
> left them
> like that (although defining those as extern as well would have been more 
> consistent
> and not slower; in fact it would be faster theoretically because those arrays 
> could
> share the same cache page then). 
> 
> 
> This addresses bug VWR-24312.
> http://jira.secondlife.com/browse/VWR-24312
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt 422f636c3343 
>   indra/llcharacter/llanimationstates.cpp 422f636c3343 
>   indra/llcommon/llavatarconstants.h 422f636c3343 
>   indra/llcommon/lllslconstants.h 422f636c3343 
>   indra/llcommon/llmetricperformancetester.h 422f636c3343 
>   indra/llmath/llcamera.h 422f636c3343 
>   indra/llmath/llcamera.cpp 422f636c3343 
>   indra/newview/llviewerobject.cpp 422f636c3343 
>   indra/newview/llvoavatar.cpp 422f636c3343 
>   indra/newview/llvosky.h 422f636c3343 
>   indra/newview/llvosky.cpp 422f636c3343 
> 
> Diff: http://codereview.secondlife.com/r/81/diff
> 
> 
> Testing
> ---
> 
> Compiled with optimization and then running readelf on the executable to find 
> duplicated symbols.
> 
> 
> 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: STORM-864: As as developer, I would like an object oriented wrapper to make safe use of memory pools easier

[Aleric Inglewood]

> On Feb. 2, 2011, 6:30 p.m., Merov Linden wrote:
> > indra/llcommon/llaprpool.h, lines 107-116
> > 
> >
> > 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.

That is actually on purpose. Developers should never actually "get" the pool.
Like the comment says, it's painful that we have to provide access at all:
we want to hide apt_pool_t completely from the user. The user should use
LLAPRPool instead. And then, when that has to be passed to the actual
libapr function, it's passed like this:  apr_whatever_create(foo, mPool());
because that is just a little bit more safe than have it auto convert
and allow writing apr_whatever_create(foo, mPool); or so I thought.
It's deliberately a bit weird, to make people think twice before they
"get" the underlaying apr_pool_t.  Also... see comment below...


- Aleric


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


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=235356&page=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 fe7fe04c

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

[Aleric Inglewood]

> On Jan. 31, 2011, 7:56 p.m., Merov Linden wrote:
> > indra/llcommon/llaprpool.cpp, lines 206-207
> > 
> >
> > K,it's just a paranoid assert. Still, I'm curious how you came up with 
> > the (*4) value. Also, not much point using bitshift here (I know: old 
> > habits... :)

I have no idea :p. This assert wasn't created by me, it comes from the old code.


- Aleric


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


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=235356&page=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/lliohtt

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

[Aleric Inglewood]

> On Feb. 2, 2011, 6:30 p.m., Merov Linden wrote:
> > indra/llmessage/llpumpio.cpp, line 359
> > 
> >
> > An example where the use of operator() is particularly unsightly...

And rightfully so! It should be "extremely unpleasant" for the user to get to 
the underlaying apr_pool_t*.
That this code hacks access is exactly that: a hack. One has to be very careful 
when doing this.
The reason I did it here is because 1) I know what I'm doing, so it's ok in 
this case, 2) for this
first introduction of LLAPRPool I tried to make minimal changes to the actual 
functionality of
existing code using apr pools (with the exception of LLAPRFile, the rewrite of 
its API actually
coming from SNOW-103 which already proved itself in snowglobe, imprudence and 
other TPV's).
The fact that this access here is needed actually signifies that this code is 
not handling
pools in a very safe way, but I consider(ed) it better to keep the code "as-is" 
and hack around the
*safity* of LLAPRPool (and as a result not changing anything!) than to rewrite 
the interface at this
point for this particular part of the code; changing things is more risk, in 
this case, than not
using the API of LLAPRPool as intended. It would be harder to find if that 
rewrite would introduce
some kind of bug we made lots of changes at the same time. I propose to leave 
this as it is now
and look at changing it later once everyone feels secure about the stability of 
the current patch.

Okay, that sounded nice -- but the truth is that I have no idea (at this point) 
if it is even
possible to do what that code does without accessing the underlaying 
apr_pool_t* like that (meaning,
not passing it directly to an APR function, but storing it in a structure). I 
just know that it
should feel dangerous to do so, so it seems OK that code that does it doesn't 
look very nice.


- Aleric


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


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=235356&page=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 
>

[opensource-dev] Review Request: Make viewer-autobuild work under Visual Studio 2005 Express Edition.

[Nicky Perian]

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

Review request for Viewer.


Summary
---

This modification is a test case and applies to  -OpenSourceRelWithDebInfo only.

Configuration batch file content:
@echo
call c:\VC80\VC\bin\vcvars32.bat
C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug configure -c 
OpenSourceRelWithDebInfo

Build batch file content:
C:\lindenhg\autobuild-vcexpress-wip\bin\autobuild --debug build -c 
OpenSourceRelWithDebInfo

This is a clean up of a discarded RB


This addresses bug viewer-autobuild.
http://jira.secondlife.com/browse/viewer-autobuild


Diffs
-

  autobuild.xml 00453191c1b9 

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


Testing
---

There is one post build re-configuration error related to devenv versus vcbuild 
parameter sequence.
However,C:\lindenhg\viewer-autobuild-express-wip\build-vc80\newview\RelWithDebInfo\LindenDeveloper.exe
 was built and
log on to aditi successful.


Thanks,

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

[opensource-dev] Review Request: Debugging autobuild post build re-configuration error.

[Nicky Perian]

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

Review request for Viewer.


Summary
---

Print out failed build_config from autobuild_tool_build.py


This addresses bug autobuild.


Diffs
-

  autobuild/autobuild_tool_build.py ffcfcf7cde2c 

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


Testing
---

Just started, trying to determine if the error can be corrected with 
autobuild.xml entries or by post-build string adjustments.


Thanks,

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