Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
10381057:
Add logging of Google Update configuration/statistics to UMA report. (Closed)
|
Created:
8 years, 7 months ago by Ryan Myers (chromium) Modified:
8 years, 7 months ago CC:
chromium-reviews, grt+watch_chromium.org, MAD, jar (doing other things) Base URL:
svn://svn.chromium.org/chrome/trunk/src/ Visibility:
Public. |
DescriptionAdd logging of Google Update configuration/statistics to UMA report.
BUG=127279
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=137017
Patch Set 1 #Patch Set 2 : #Patch Set 3 : #
Total comments: 9
Patch Set 4 : #
Total comments: 19
Patch Set 5 : #
Total comments: 8
Patch Set 6 : #Patch Set 7 : #Patch Set 8 : #Patch Set 9 : #
Total comments: 30
Patch Set 10 : #Patch Set 11 : #Patch Set 12 : #
Total comments: 24
Patch Set 13 : #
Total comments: 13
Patch Set 14 : #Patch Set 15 : #Patch Set 16 : #
Total comments: 1
Patch Set 17 : #Patch Set 18 : #Patch Set 19 : #
Total comments: 11
Patch Set 20 : #Patch Set 21 : #
Total comments: 2
Patch Set 22 : #
Total comments: 16
Patch Set 23 : #
Total comments: 2
Patch Set 24 : #Messages
Total messages: 38 (0 generated)
GRT for the additions to installer\util\google_update_*, Jeff/Ilya for metrics_log. Thanks! :)
http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1001: } nit: No need for curly braces for a one-line if-stmt. (Ditto below.) http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1017: } nit: This code block is essentially repeated below. Would be better to decompose a function that does this work, and then call into it twice. http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1032: #endif nit: Please add " // defined(GOOGLE_CHROME_BUILD) && defined(OS_WIN)" to document what this #endif is balancing. http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.h (right): http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.h:160: void WriteGoogleUpdateData(bool write_as_xml); Did we conclude that writing the XML version is ok without updating the backend to understand the new XML? Last I remember, I think Jim had expressed concerns about this...
Thanks! http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1001: } On 2012/05/08 21:25:43, Ilya Sherman wrote: > nit: No need for curly braces for a one-line if-stmt. (Ditto below.) Done. http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1017: } On 2012/05/08 21:25:43, Ilya Sherman wrote: > nit: This code block is essentially repeated below. Would be better to > decompose a function that does this work, and then call into it twice. Done. (See ProductDataToProto() added to anonymous namespace at top of file.) http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.h (right): http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.h:160: void WriteGoogleUpdateData(bool write_as_xml); On 2012/05/08 21:25:43, Ilya Sherman wrote: > Did we conclude that writing the XML version is ok without updating the backend > to understand the new XML? Last I remember, I think Jim had expressed concerns > about this... During development, I tested it against XML and Protobuf servers running on my own machine, and saw no issues. We can omit the XML version if it's a concern, of course; the XML version just assists in debugging.
http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.h (right): http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.h:160: void WriteGoogleUpdateData(bool write_as_xml); On 2012/05/08 21:56:36, ryanmyers wrote: > On 2012/05/08 21:25:43, Ilya Sherman wrote: > > Did we conclude that writing the XML version is ok without updating the > backend > > to understand the new XML? Last I remember, I think Jim had expressed > concerns > > about this... > > During development, I tested it against XML and Protobuf servers running on my > own machine, and saw no issues. We can omit the XML version if it's a concern, > of course; the XML version just assists in debugging. Jim's comment from the email thread was: "I do think we have to be careful to land the server side changes first, especially in the XML. I *think* that if surprising XML arrives, the log servers might discard the data. Maybe it is only if it is malformed XML.... but I'd rather be sure we are set to receive the field before sending." So, unless you hear otherwise from Jim, I'd rather that we just not upload this as XML data if the plan is to not update the XML parser. http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:265: SystemProfileProto::GoogleUpdate::ProductInfo* pi) { nit: Please avoid abbreviations when naming variables. http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:266: DCHECK(pi); nit: No need, since this is used immediately below. http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:272: product_data.last_result)); Please add an IsValid() check: https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#enum http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1020: google_update->mutable_google_update_status()); nit: If-stmts should still use curly braces if they span multiple lines (even if only due to line-wrapping).
Thanks! http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.h (right): http://codereview.chromium.org/10381057/diff/13001/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.h:160: void WriteGoogleUpdateData(bool write_as_xml); On 2012/05/08 22:33:48, Ilya Sherman wrote: > On 2012/05/08 21:56:36, ryanmyers wrote: > > On 2012/05/08 21:25:43, Ilya Sherman wrote: > > > Did we conclude that writing the XML version is ok without updating the > > backend > > > to understand the new XML? Last I remember, I think Jim had expressed > > concerns > > > about this... > > > > During development, I tested it against XML and Protobuf servers running on my > > own machine, and saw no issues. We can omit the XML version if it's a > concern, > > of course; the XML version just assists in debugging. > > Jim's comment from the email thread was: > > "I do think we have to be careful to land the server side changes first, > especially in the XML. I *think* that if surprising XML arrives, the log > servers might discard the data. Maybe it is only if it is malformed XML.... but > I'd rather be sure we are set to receive the field before sending." > > So, unless you hear otherwise from Jim, I'd rather that we just not upload this > as XML data if the plan is to not update the XML parser. No problem. Removed XML path. http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:265: SystemProfileProto::GoogleUpdate::ProductInfo* pi) { On 2012/05/08 22:33:49, Ilya Sherman wrote: > nit: Please avoid abbreviations when naming variables. Done. http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:266: DCHECK(pi); On 2012/05/08 22:33:49, Ilya Sherman wrote: > nit: No need, since this is used immediately below. Done. http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:272: product_data.last_result)); On 2012/05/08 22:33:49, Ilya Sherman wrote: > Please add an IsValid() check: > https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#enum Done. (Unfortunately, the extra scope makes it impossible to keep to 80 chars wide.) http://codereview.chromium.org/10381057/diff/11005/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1020: google_update->mutable_google_update_status()); On 2012/05/08 22:33:49, Ilya Sherman wrote: > nit: If-stmts should still use curly braces if they span multiple lines (even if > only due to line-wrapping). Done.
http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:264: void ProductDataToProto(const GoogleUpdateSettings::ProductData& product_data, nit: Please move this parameter to the next line -- all params should be aligned. http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:275: product_data.last_result)); nit: You can wrap this as: static_cast<SystemProfileProto::GoogleUpdate::ProductInfo:: InstallResult>(product_data.last_result); Or, better yet, add a using declaration at the top of the file so that this line isn't quite so long :) http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1002: #endif // defined(GOOGLE_CHROME_BUILD) && defined(OS_WIN) The closing curly brace should be outside of the #endif http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1003: nit: Please remove this empty line.
Thanks! http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:264: void ProductDataToProto(const GoogleUpdateSettings::ProductData& product_data, On 2012/05/08 23:33:40, Ilya Sherman wrote: > nit: Please move this parameter to the next line -- all params should be > aligned. Done. http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:275: product_data.last_result)); On 2012/05/08 23:33:40, Ilya Sherman wrote: > nit: You can wrap this as: > > static_cast<SystemProfileProto::GoogleUpdate::ProductInfo:: > InstallResult>(product_data.last_result); > > Or, better yet, add a using declaration at the top of the file so that this line > isn't quite so long :) Done. (You can't use "using" with a nested type, unfortunately; you can typedef it, though.) http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1003: On 2012/05/08 23:33:40, Ilya Sherman wrote: > nit: Please remove this empty line. Linter complains if there's no \n at EOF. Still want it removed?
LGTM http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... File chrome/browser/metrics/metrics_log.cc (right): http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... chrome/browser/metrics/metrics_log.cc:1003: On 2012/05/08 23:54:53, Ryan Myers (chromium) wrote: > On 2012/05/08 23:33:40, Ilya Sherman wrote: > > nit: Please remove this empty line. > > Linter complains if there's no \n at EOF. Still want it removed? Does your text editor show one newline or two? The linter is often wrong, for some reason.
On 2012/05/08 23:57:33, Ilya Sherman wrote: > LGTM > > http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... > File chrome/browser/metrics/metrics_log.cc (right): > > http://codereview.chromium.org/10381057/diff/14002/chrome/browser/metrics/met... > chrome/browser/metrics/metrics_log.cc:1003: > On 2012/05/08 23:54:53, Ryan Myers (chromium) wrote: > > On 2012/05/08 23:33:40, Ilya Sherman wrote: > > > nit: Please remove this empty line. > > > > Linter complains if there's no \n at EOF. Still want it removed? > > Does your text editor show one newline or two? The linter is often wrong, for > some reason. Shows one now.
Hy Ryan. Looks good overall. Just a bunch of small comments/questions. https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:552: int64 GoogleUpdateSettings::GetGoogleUpdateLastStartedAU(bool system_install) { why int64 for a DWORD value? isn't uint32 sufficient? https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:569: int64 GoogleUpdateSettings::GetGoogleUpdateLastChecked(bool system_install) { same q https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; remove ' = L""' https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; consider string16 here, too https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... File chrome/installer/util/google_update_constants.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_constants.cc:10: const wchar_t kGoogleUpdateUpgradeCode[] chromium style: move the '=' up to this line https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_constants.cc:34: const wchar_t kRegLastStartedAUField[] = L"LastStartedAU"; i can't seem to find this in google update's code. am i looking in the wrong place, or has it not yet landed there. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_constants.cc:37: const wchar_t kRegLastInstallResultField[] = L"LastInstallerResult"; could you make the names match the values here (Install -> Installer)? https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:552: int64 GoogleUpdateSettings::GetGoogleUpdateLastStartedAU(bool system_install) { why int64 for a DWORD value? is uint32 insufficient for some reason? (or base::Time as per my comment in the header) https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:569: int64 GoogleUpdateSettings::GetGoogleUpdateLastChecked(bool system_install) { uint32 or base::Time here, too? https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:587: const std::wstring& app_guid, consider changing this to const wchar_t* to avoid the creation of a temporary std::wstring by half of the callers. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:598: string16 clientstate_reg_path = google_update::kRegPathClientState; style: string16 clientstate_reg_path(...) is preferred over string16 clientstate_reg_path = .... for compound types; see gotw #1. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; please remove this initializer. also, pv -> version https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:606: DWORD dw_value = 0; dw_value -> dword_value https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:611: product_found = true; i suggest clearing out all other members of |data| in here so that the caller doesn't need to do it. consider: *data = ProductData(); before assigning values, or zero-out the individual fields down below, or something along those lines. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:617: // Google Update convention is that if an installer writes an result an -> a https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:645: BrowserDistribution* dist = BrowserDistribution::GetDistribution(); This will return the distribution for Chrome Frame when called from within a GCF process (npchrome_frame.dll or chrome.exe spawned from npchrome_frame). If this is intended (my guess is that it is), please rename the function to simply GetUpdateDetail and update the documentation comment in the header to indicate that it gets the detail for whatever the current product is (Chrome, SxS Chrome/Canary, or Chrome Frame). (consider changing GetGoogleUpdateDetail to GetUpdateDetailForAppGuid or something if the names are too similar.) Otherwise, if it's only for use for Chrome and SxS/canary (and not for Chrome Frame), use GetSpecificDistribution(BrowserDistribution::CHROME_BROWSER) here. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:649: it looks like there's an extra newline here. please remove it if so (the file should end with }\n rather than }\n\n). ignore what the lint check on rietveld says; it lies, cheats, and steals. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... File chrome/installer/util/google_update_settings.h (right): https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:203: // Returns the time, in seconds since the epoch, that Google Update last which epoch? :-) does it make sense to use base::Time everywhere in this new code so there's no ambiguity? https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:214: struct ProductData { chromium style: type definitions in a class precede methods. please move this up after the UpdatePolicy enum. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:236: const std::wstring& app_guid, there's a move to eradicate std::wstring, even in Windows code. consider using string16 (in base/string16.h) here. for Windows-specific code, it's okay to assume that you can directly pass the result of string16::c_str() to system functions (like the registry api) or things that still use std::wstring/wchar_t (since string16 is just a typedef on Windows).
Thanks! https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:552: int64 GoogleUpdateSettings::GetGoogleUpdateLastStartedAU(bool system_install) { On 2012/05/09 14:41:09, grt wrote: > why int64 for a DWORD value? isn't uint32 sufficient? The other functions that return timestamps in this file return int64, so I figured I'd follow suit. (That, and it's ultimately being stored in a PB, convention for PBs is to store those as int64.) I don't mind changing it and casting to int64 in the PB-filling function, if you think it's worthwhile. https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; On 2012/05/09 14:41:09, grt wrote: > remove ' = L""' Done. https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; On 2012/05/09 14:41:09, grt wrote: > consider string16 here, too RegKey.ReadValue works exclusively with wstring. Is there a conversion to string16 that can be used?
https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:552: int64 GoogleUpdateSettings::GetGoogleUpdateLastStartedAU(bool system_install) { On 2012/05/09 17:08:48, Ryan Myers (chromium) wrote: > On 2012/05/09 14:41:09, grt wrote: > > why int64 for a DWORD value? isn't uint32 sufficient? > > The other functions that return timestamps in this file return int64, so I > figured I'd follow suit. Which functions? > (That, and it's ultimately being stored in a PB, > convention for PBs is to store those as int64.) I don't mind changing it and > casting to int64 in the PB-filling function, if you think it's worthwhile. Ah, okay, I didn't know that int64 is a PB-specific thing. It looks like google update's time.cc uses int32. Since we know an int is at least 32 bits, do you think it's safe to go the easy way and return an "int" from these functions? Maybe I'm weird, but int64 makes me think it must have greater than 1-second precision. It also sets off my bug-alarm when I see that the origin is a 32bit value (e.g., is someone on the other side trying to write an int64 into a DWORD?). https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; On 2012/05/09 17:08:48, Ryan Myers (chromium) wrote: > On 2012/05/09 14:41:09, grt wrote: > > consider string16 here, too > > RegKey.ReadValue works exclusively with wstring. Is there a conversion to > string16 that can be used? string16 is std::wstring on Windows. If the compiler is satisfied with the use of string16, it's safe. I don't remember if you'll get a compile error for passing a string16* where a std::wstring* is expected.
Thanks! https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:552: int64 GoogleUpdateSettings::GetGoogleUpdateLastStartedAU(bool system_install) { On 2012/05/09 17:27:16, grt wrote: > On 2012/05/09 17:08:48, Ryan Myers (chromium) wrote: > > On 2012/05/09 14:41:09, grt wrote: > > > why int64 for a DWORD value? isn't uint32 sufficient? > > > > The other functions that return timestamps in this file return int64, so I > > figured I'd follow suit. > > Which functions? > > > (That, and it's ultimately being stored in a PB, > > convention for PBs is to store those as int64.) I don't mind changing it and > > casting to int64 in the PB-filling function, if you think it's worthwhile. > > Ah, okay, I didn't know that int64 is a PB-specific thing. It looks like google > update's time.cc uses int32. Since we know an int is at least 32 bits, do you > think it's safe to go the easy way and return an "int" from these functions? > > Maybe I'm weird, but int64 makes me think it must have greater than 1-second > precision. It also sets off my bug-alarm when I see that the origin is a 32bit > value (e.g., is someone on the other side trying to write an int64 into a > DWORD?). Was looking at other timestamp functions being called from metrics_log. This makes sense, though -- I'd rather have this return a uint32 and cast at metrics_log. Fixed. https://chromiumcodereview.appspot.com/10381057/diff/11005/chrome/installer/u... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; On 2012/05/09 17:27:16, grt wrote: > On 2012/05/09 17:08:48, Ryan Myers (chromium) wrote: > > On 2012/05/09 14:41:09, grt wrote: > > > consider string16 here, too > > > > RegKey.ReadValue works exclusively with wstring. Is there a conversion to > > string16 that can be used? > > string16 is std::wstring on Windows. If the compiler is satisfied with the use > of string16, it's safe. I don't remember if you'll get a compile error for > passing a string16* where a std::wstring* is expected. Done.
On 2012/05/09 17:49:29, Ryan Myers (chromium) wrote: > Thanks! Those changes look good to me, thanks. Would you take a look through my other comments on patch set 9?
Ooops, missed those! Thanks. (BTW, I'm still non-committer, so I'll need one of you to commit on my behalf once review is finished. TIA.) https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... File chrome/installer/util/google_update_constants.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_constants.cc:10: const wchar_t kGoogleUpdateUpgradeCode[] On 2012/05/09 14:41:10, grt wrote: > chromium style: move the '=' up to this line Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_constants.cc:34: const wchar_t kRegLastStartedAUField[] = L"LastStartedAU"; On 2012/05/09 14:41:10, grt wrote: > i can't seem to find this in google update's code. am i looking in the wrong > place, or has it not yet landed there. Hasn't landed yet. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_constants.cc:37: const wchar_t kRegLastInstallResultField[] = L"LastInstallerResult"; On 2012/05/09 14:41:10, grt wrote: > could you make the names match the values here (Install -> Installer)? Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:552: int64 GoogleUpdateSettings::GetGoogleUpdateLastStartedAU(bool system_install) { On 2012/05/09 14:41:10, grt wrote: > why int64 for a DWORD value? is uint32 insufficient for some reason? (or > base::Time as per my comment in the header) Done. (Switched to base::Time.) https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:587: const std::wstring& app_guid, On 2012/05/09 14:41:10, grt wrote: > consider changing this to const wchar_t* to avoid the creation of a temporary > std::wstring by half of the callers. Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:605: std::wstring pv = L""; On 2012/05/09 14:41:10, grt wrote: > please remove this initializer. > also, pv -> version Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:606: DWORD dw_value = 0; On 2012/05/09 14:41:10, grt wrote: > dw_value -> dword_value Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:611: product_found = true; On 2012/05/09 14:41:10, grt wrote: > i suggest clearing out all other members of |data| in here so that the caller > doesn't need to do it. consider: > *data = ProductData(); > before assigning values, or zero-out the individual fields down below, or > something along those lines. Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:645: BrowserDistribution* dist = BrowserDistribution::GetDistribution(); On 2012/05/09 14:41:10, grt wrote: > This will return the distribution for Chrome Frame when called from within a GCF > process (npchrome_frame.dll or chrome.exe spawned from npchrome_frame). If this > is intended (my guess is that it is), please rename the function to simply > GetUpdateDetail and update the documentation comment in the header to indicate > that it gets the detail for whatever the current product is (Chrome, SxS > Chrome/Canary, or Chrome Frame). (consider changing GetGoogleUpdateDetail to > GetUpdateDetailForAppGuid or something if the names are too similar.) > Otherwise, if it's only for use for Chrome and SxS/canary (and not for Chrome > Frame), use GetSpecificDistribution(BrowserDistribution::CHROME_BROWSER) here. Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:649: On 2012/05/09 14:41:10, grt wrote: > it looks like there's an extra newline here. please remove it if so (the file > should end with }\n rather than }\n\n). ignore what the lint check on rietveld > says; it lies, cheats, and steals. Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... File chrome/installer/util/google_update_settings.h (right): https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:203: // Returns the time, in seconds since the epoch, that Google Update last On 2012/05/09 14:41:10, grt wrote: > which epoch? :-) does it make sense to use base::Time everywhere in this new > code so there's no ambiguity? Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:214: struct ProductData { On 2012/05/09 14:41:10, grt wrote: > chromium style: type definitions in a class precede methods. > please move this up after the UpdatePolicy enum. Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:236: const std::wstring& app_guid, On 2012/05/09 14:41:10, grt wrote: > there's a move to eradicate std::wstring, even in Windows code. consider using > string16 (in base/string16.h) here. for Windows-specific code, it's okay to > assume that you can directly pass the result of string16::c_str() to system > functions (like the registry api) or things that still use std::wstring/wchar_t > (since string16 is just a typedef on Windows). Done. https://chromiumcodereview.appspot.com/10381057/diff/2015/chrome/installer/ut... chrome/installer/util/google_update_settings.h:236: const std::wstring& app_guid, On 2012/05/09 14:41:10, grt wrote: > there's a move to eradicate std::wstring, even in Windows code. consider using > string16 (in base/string16.h) here. for Windows-specific code, it's okay to > assume that you can directly pass the result of string16::c_str() to system > functions (like the registry api) or things that still use std::wstring/wchar_t > (since string16 is just a typedef on Windows). Done.
Next round. As for committing, I think you'll be able to hit the checkbox for the commit queue once you have the magic acronym from the committer-reviewers. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/browser/met... File chrome/browser/metrics/metrics_log.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/browser/met... chrome/browser/metrics/metrics_log.cc:976: const bool is_system_level = GoogleUpdateSettings::IsSystemInstall(); This is going to interact with the filesystem. Is that okay from whatever thread this is running on? I assume this is only done in the browser process. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:24: using base::Time; i think this file's use of "using" in this way is counter to the style guide. please use base::Time explicitly down below and remove this. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:554: // The registry functions below will end up going to disk. Do this on another I don't think new code should include this hack, especially low-level utility code like this. If you must do registry access from a banned thread, can you move the ScopedAllowIO up to the one specific caller? https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:566: return Time::FromTimeT(last_start); chromium style: put braces around this since the "if" conditional spans multiple line https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:585: return Time::FromTimeT(last_check); braces around this, too https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:617: *data = ProductData(); ugh, what was i thinking? since ProductData doesn't specify a ctor that zero-initializes its members, this won't actually zero them out. sorry for the bad advice. i think it's better to either explicitly zero them out here (e.g., data->last_result = 0;, etc..) or in else clauses down below. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... File chrome/installer/util/google_update_settings.h (right): https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:223: // Returns the time, in seconds since the epoch, that Google Update last Since this returns a Time instance, the comment can be simplified to "Returns the time at which Google Update last..., or the NULL time if this information isn't available." https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:228: // Returns the time, in seconds since the epoch, that Google Update last This comment can be simplified, too. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:236: static bool GetUpdateDetailForAppGuid(bool system_install, Hmm, now I think just "ForApp" is better. Apologies for the ping-pong. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:241: // GetUpdateDetailForAppGuid with the app guid for Google Update itself). ). -> .) https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:242: static bool GetUpdateDetailForGU(bool system_install, ProductData* data); Although it makes the method name long, it's more stylish to not abbreviate "GoogleUpdate". https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:245: // GetUpdateDetailForAppGuid with the app guid stored in BrowserDistribution). ). -> .)
Thanks! I've redesigned the code slightly so that the registry accesses are done from a FILE thread in metrics_service.cc rather than at the time of log creation, which eliminates the need for the AllowIO stuff. Ilya, PTAL for metrics_service.cc changes. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/browser/met... File chrome/browser/metrics/metrics_log.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/browser/met... chrome/browser/metrics/metrics_log.cc:976: const bool is_system_level = GoogleUpdateSettings::IsSystemInstall(); On 2012/05/09 21:30:06, grt wrote: > This is going to interact with the filesystem. Is that okay from whatever > thread this is running on? I assume this is only done in the browser process. It is done from the browser process only. It's now been refactored so that it is called on the FILE thread. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:24: using base::Time; On 2012/05/09 21:30:06, grt wrote: > i think this file's use of "using" in this way is counter to the style guide. > please use base::Time explicitly down below and remove this. Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:554: // The registry functions below will end up going to disk. Do this on another On 2012/05/09 21:30:06, grt wrote: > I don't think new code should include this hack, especially low-level utility > code like this. If you must do registry access from a banned thread, can you > move the ScopedAllowIO up to the one specific caller? Refactored so that we grab it on a FILE thread. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:566: return Time::FromTimeT(last_start); On 2012/05/09 21:30:06, grt wrote: > chromium style: put braces around this since the "if" conditional spans multiple > line Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:585: return Time::FromTimeT(last_check); On 2012/05/09 21:30:06, grt wrote: > braces around this, too Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.cc:617: *data = ProductData(); On 2012/05/09 21:30:06, grt wrote: > ugh, what was i thinking? since ProductData doesn't specify a ctor that > zero-initializes its members, this won't actually zero them out. sorry for the > bad advice. i think it's better to either explicitly zero them out here (e.g., > data->last_result = 0;, etc..) or in else clauses down below. Good catch! Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... File chrome/installer/util/google_update_settings.h (right): https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:223: // Returns the time, in seconds since the epoch, that Google Update last On 2012/05/09 21:30:06, grt wrote: > Since this returns a Time instance, the comment can be simplified to "Returns > the time at which Google Update last..., or the NULL time if this information > isn't available." Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:228: // Returns the time, in seconds since the epoch, that Google Update last On 2012/05/09 21:30:06, grt wrote: > This comment can be simplified, too. Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:236: static bool GetUpdateDetailForAppGuid(bool system_install, On 2012/05/09 21:30:06, grt wrote: > Hmm, now I think just "ForApp" is better. Apologies for the ping-pong. Done. No problem. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:241: // GetUpdateDetailForAppGuid with the app guid for Google Update itself). On 2012/05/09 21:30:06, grt wrote: > ). -> .) Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:242: static bool GetUpdateDetailForGU(bool system_install, ProductData* data); On 2012/05/09 21:30:06, grt wrote: > Although it makes the method name long, it's more stylish to not abbreviate > "GoogleUpdate". Done. https://chromiumcodereview.appspot.com/10381057/diff/15001/chrome/installer/u... chrome/installer/util/google_update_settings.h:245: // GetUpdateDetailForAppGuid with the app guid stored in BrowserDistribution). On 2012/05/09 21:30:06, grt wrote: > ). -> .) Done.
https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... File chrome/browser/metrics/metrics_service.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.cc:185: #include "chrome/installer/util/google_update_settings.h" nit: No need to #include this here if it's already #included in the header file. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.cc:295: // Will run the provided task after finished. What is this comment describing? https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.cc:779: #endif // defined(OS_WIN) && defined(GOOGLE_CHROME_BUILD) You should create a separate method for this, rather than inserting it into the InitTaskGetHardwareClass() method. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.h:365: // Google Update statistics, which were retrieved on the file thread. Are you sure you want to use the file thread, rather than a worker thread? If you're not sure, you probably want to use a worker pool, as the file thread is prone to massive bottlenecks. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... chrome/installer/util/google_update_settings.cc:654: GoogleUpdateStatus* details) { nit: Should you DCHECK that this method -- or perhaps one of its subsidiaries -- is called on a valid thread? https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... chrome/installer/util/google_update_settings.cc:658: // requiring the IO thread. No idea why. What is this comment describing?
https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... File chrome/browser/metrics/metrics_service.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.cc:185: #include "chrome/installer/util/google_update_settings.h" On 2012/05/10 21:27:41, Ilya Sherman wrote: > nit: No need to #include this here if it's already #included in the header file. Done. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.cc:295: // Will run the provided task after finished. On 2012/05/10 21:27:41, Ilya Sherman wrote: > What is this comment describing? Ooops - comment from an earlier refactor attempt. Removed. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.cc:779: #endif // defined(OS_WIN) && defined(GOOGLE_CHROME_BUILD) On 2012/05/10 21:27:41, Ilya Sherman wrote: > You should create a separate method for this, rather than inserting it into the > InitTaskGetHardwareClass() method. Done. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/browser/met... chrome/browser/metrics/metrics_service.h:365: // Google Update statistics, which were retrieved on the file thread. On 2012/05/10 21:27:41, Ilya Sherman wrote: > Are you sure you want to use the file thread, rather than a worker thread? If > you're not sure, you probably want to use a worker pool, as the file thread is > prone to massive bottlenecks. Done. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... chrome/installer/util/google_update_settings.cc:654: GoogleUpdateStatus* details) { On 2012/05/10 21:27:41, Ilya Sherman wrote: > nit: Should you DCHECK that this method -- or perhaps one of its subsidiaries -- > is called on a valid thread? RegKey::Open does a DCHECK for IsAllowedIO, so it'd be redundant, I think. (Also, there's no equivalent of BrowserThread::CurrentlyOn() for blocking pool.) https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... chrome/installer/util/google_update_settings.cc:658: // requiring the IO thread. No idea why. On 2012/05/10 21:27:41, Ilya Sherman wrote: > What is this comment describing? Deleted. https://chromiumcodereview.appspot.com/10381057/diff/13007/chrome/installer/u... chrome/installer/util/google_update_settings.cc:658: // requiring the IO thread. No idea why. On 2012/05/10 21:27:41, Ilya Sherman wrote: > What is this comment describing? Removed.
Pushed up one more set for cleanup and fixing a few style issues that mac-clang complained about. TIA!
metrics/ change lgtm https://chromiumcodereview.appspot.com/10381057/diff/8020/chrome/browser/metr... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/8020/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:373: // Google Update statistics, which were retrieved on the file thread. nit: No longer on the file thread.
Thanks. Had to make one more change to fix a linker break on mac/linux. Sorry about the churn! (GoogleUpdateSettings has enough non-POD types in it to require a constructor now, according to clang. Renamed to GoogleUpdateMetrics and moved it to be defined in metrics_log.h; metrics_service now holds it in a scoped_ptr.)
https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.cc:802: void MetricsService::InitTaskGetGoogleUpdateData( nit: Please annotate this method as static, by adding "// static" above line 802 https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.cc:805: GoogleUpdateMetrics google_update_metrics; Why not just use self->google_update_metrics_? https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:375: scoped_ptr<GoogleUpdateMetrics> google_update_metrics_; I don't think this needs to be a scoped_ptr -- see the comments in the implementation file.
https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.cc:802: void MetricsService::InitTaskGetGoogleUpdateData( On 2012/05/11 23:15:34, Ilya Sherman wrote: > nit: Please annotate this method as static, by adding "// static" above line 802 Done. https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.cc:805: GoogleUpdateMetrics google_update_metrics; On 2012/05/11 23:15:34, Ilya Sherman wrote: > Why not just use self->google_update_metrics_? You're not supposed to use a WeakPtr on the thread that didn't create it (or otherwise has hard knowledge of its lifespan). In this case, it would be fine, since the MetricsService is around for the life of the browser, but I'd rather be safe. https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:375: scoped_ptr<GoogleUpdateMetrics> google_update_metrics_; On 2012/05/11 23:15:34, Ilya Sherman wrote: > I don't think this needs to be a scoped_ptr -- see the comments in the > implementation file. Unfortunately, it does need to be a pointer. This header doesn't include metrics_log.h, so it doesn't know GoogleUpdateMetrics's definition, only its declaration.
https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.cc:805: GoogleUpdateMetrics google_update_metrics; On 2012/05/11 23:52:24, Ryan Myers (chromium) wrote: > On 2012/05/11 23:15:34, Ilya Sherman wrote: > > Why not just use self->google_update_metrics_? > > You're not supposed to use a WeakPtr on the thread that didn't create it (or > otherwise has hard knowledge of its lifespan). In this case, it would be fine, > since the MetricsService is around for the life of the browser, but I'd rather > be safe. Ah, that's a good point, thanks for reminding me about that. https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:39: struct GoogleUpdateMetrics; nit: Please move this between BookmarkNode and MetricsLog https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:375: scoped_ptr<GoogleUpdateMetrics> google_update_metrics_; On 2012/05/11 23:52:24, Ryan Myers (chromium) wrote: > On 2012/05/11 23:15:34, Ilya Sherman wrote: > > I don't think this needs to be a scoped_ptr -- see the comments in the > > implementation file. > > Unfortunately, it does need to be a pointer. This header doesn't include > metrics_log.h, so it doesn't know GoogleUpdateMetrics's definition, only its > declaration. Presumably you could #include metrics_log.h in this header...
https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:39: struct GoogleUpdateMetrics; On 2012/05/12 00:41:30, Ilya Sherman wrote: > nit: Please move this between BookmarkNode and MetricsLog Eliminated by switching to including metrics_log. https://chromiumcodereview.appspot.com/10381057/diff/1023/chrome/browser/metr... chrome/browser/metrics/metrics_service.h:375: scoped_ptr<GoogleUpdateMetrics> google_update_metrics_; On 2012/05/12 00:41:30, Ilya Sherman wrote: > On 2012/05/11 23:52:24, Ryan Myers (chromium) wrote: > > On 2012/05/11 23:15:34, Ilya Sherman wrote: > > > I don't think this needs to be a scoped_ptr -- see the comments in the > > > implementation file. > > > > Unfortunately, it does need to be a pointer. This header doesn't include > > metrics_log.h, so it doesn't know GoogleUpdateMetrics's definition, only its > > declaration. > > Presumably you could #include metrics_log.h in this header... Good point. Done.
Metrics changes LGTM, thanks https://chromiumcodereview.appspot.com/10381057/diff/41/chrome/browser/metric... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/41/chrome/browser/metric... chrome/browser/metrics/metrics_service.h:22: #include "chrome/browser/metrics/metrics_log.h" nit: Please move this one line up
https://chromiumcodereview.appspot.com/10381057/diff/41/chrome/browser/metric... File chrome/browser/metrics/metrics_service.h (right): https://chromiumcodereview.appspot.com/10381057/diff/41/chrome/browser/metric... chrome/browser/metrics/metrics_service.h:22: #include "chrome/browser/metrics/metrics_log.h" On 2012/05/12 00:59:21, Ilya Sherman wrote: > nit: Please move this one line up Done. (Also eliminated the forward declaration for MetricsLog since we now have it from the header.)
https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... File chrome/browser/metrics/metrics_log.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... chrome/browser/metrics/metrics_log.cc:280: GoogleUpdateMetrics::GoogleUpdateMetrics() {} please initialize members that aren't otherwise initialized: : is_system_install(false) {} https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... File chrome/browser/metrics/metrics_log.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... chrome/browser/metrics/metrics_log.h:85: // profile_metrics, if non-null, gives a dictionary of all profile metrics Please update this comment so it includes |google_update_status|, too. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... chrome/browser/metrics/metrics_log.h:95: // the UI thread. This is exposed as a separate method from the here, too https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/common/metri... File chrome/common/metrics/proto/system_profile.proto (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/common/metri... chrome/common/metrics/proto/system_profile.proto:135: // update check, in seconds since epoch. Please either say "Unix epoch" in all cases throughout this CL, or explicitly state "since 1/1/1970" or something; "epoch" by itself is too generic (e.g., the Windows epoch is 1/1/1601). https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:608: product_found = true; this function still potentially leaves last_result, last_error_code, and last_extra_code uninitialized, no? https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... File chrome/installer/util/google_update_settings.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.h:36: struct ProductData { please give this a ctor that zero-initializes the ints. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.h:236: const wchar_t* app_guid, nit: indentation https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.h:242: ProductData* data); nit: indentation
Thanks! https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... File chrome/browser/metrics/metrics_log.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... chrome/browser/metrics/metrics_log.cc:280: GoogleUpdateMetrics::GoogleUpdateMetrics() {} On 2012/05/14 13:58:47, grt wrote: > please initialize members that aren't otherwise initialized: > : is_system_install(false) {} Done. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... File chrome/browser/metrics/metrics_log.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... chrome/browser/metrics/metrics_log.h:85: // profile_metrics, if non-null, gives a dictionary of all profile metrics On 2012/05/14 13:58:47, grt wrote: > Please update this comment so it includes |google_update_status|, too. Done. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/browser/metr... chrome/browser/metrics/metrics_log.h:95: // the UI thread. This is exposed as a separate method from the On 2012/05/14 13:58:47, grt wrote: > here, too Done. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/common/metri... File chrome/common/metrics/proto/system_profile.proto (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/common/metri... chrome/common/metrics/proto/system_profile.proto:135: // update check, in seconds since epoch. On 2012/05/14 13:58:47, grt wrote: > Please either say "Unix epoch" in all cases throughout this CL, or explicitly > state "since 1/1/1970" or something; "epoch" by itself is too generic (e.g., the > Windows epoch is 1/1/1601). Done. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... File chrome/installer/util/google_update_settings.cc (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.cc:608: product_found = true; On 2012/05/14 13:58:47, grt wrote: > this function still potentially leaves last_result, last_error_code, and > last_extra_code uninitialized, no? Ooops! Forgot to restore this code when I was moving constructors around. Done. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... File chrome/installer/util/google_update_settings.h (right): https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.h:36: struct ProductData { On 2012/05/14 13:58:47, grt wrote: > please give this a ctor that zero-initializes the ints. That's problematic -- google_update_settings.cc isn't compiled on mac/linux, so if I declare a ctor here, I have to put the body somewhere that's visible to those platforms. I'd rather leave it with the compiler-generated ctor and clear it properly inside GetUpdateDetailForApp() -- that has the added upside of having proper behavior if someone reuses ProductData for more than one query. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.h:236: const wchar_t* app_guid, On 2012/05/14 13:58:47, grt wrote: > nit: indentation Done. https://chromiumcodereview.appspot.com/10381057/diff/1026/chrome/installer/ut... chrome/installer/util/google_update_settings.h:242: ProductData* data); On 2012/05/14 13:58:47, grt wrote: > nit: indentation Done.
lgtm w/ one question (looks like a stale forward decl that can be removed?). https://chromiumcodereview.appspot.com/10381057/diff/4036/chrome/browser/metr... File chrome/browser/metrics/metrics_log.h (right): https://chromiumcodereview.appspot.com/10381057/diff/4036/chrome/browser/metr... chrome/browser/metrics/metrics_log.h:22: struct GoogleUpdateMetrics; remove this?
Thank you! https://chromiumcodereview.appspot.com/10381057/diff/4036/chrome/browser/metr... File chrome/browser/metrics/metrics_log.h (right): https://chromiumcodereview.appspot.com/10381057/diff/4036/chrome/browser/metr... chrome/browser/metrics/metrics_log.h:22: struct GoogleUpdateMetrics; On 2012/05/14 19:52:42, grt wrote: > remove this? Done.
As I thought, I don't have committer access yet. One of you two will have to dcommit for me :\ Sorry!
On 2012/05/14 20:55:59, Ryan Myers (chromium) wrote: > As I thought, I don't have committer access yet. One of you two will have to > dcommit for me :\ Sorry! Since the CL has been LGTM'ed by committers, you can tick the "Commit" checkbox right under the trybot results.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/10381057/4038
Change committed as 137017 |
