Convert LOG(INFO) to VLOG(1) - courgette/.

Convert LOG(INFO) to VLOG(1) - courgette/.

This eliminates the custom logging code as VLOG is per-module configurable.  I did preserve the distinct log level numbers in the VLOG statements.

BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=63407

[Peter Kasting, 2010-10-20 21:41:58]

ping

[sra1, 2010-10-21 00:08:49]

It looks fine, but I'm not sure it is worth doing.

What testing did you do to check that the log file contains essentially the same
data?
When I get the occasional question about Courgette the first thing I do is look
at the log.

My concern is that in applying a patch on a customer's machine the log file
might be bigger and slow down patching.

Since I am currently an occasional builder of this code, could you put a comment
where the ALOGs used to be on how to configure the VLOGs?

http://codereview.chromium.org/3904002/diff/1/6
File courgette/encoded_program.cc (right):

http://codereview.chromium.org/3904002/diff/1/6#newcode237
courgette/encoded_program.cc:237: << "  image base  " << image_base_
You could put it back one per line, or if you don't want to do that, move the \n
from the above line to this one.

[Peter Kasting, 2010-10-21 00:23:09]

On 2010/10/21 00:08:49, sra1 wrote:
> It looks fine, but I'm not sure it is worth doing.

Did you see my message on chromium-dev?  We need to eliminate most uses of
LOG(INFO).

> What testing did you do to check that the log file contains essentially the
same
> data?

I don't understand the question.  We're logging the same things, just using VLOG
instead of macros atop LOG.  What would be different about the data we'd
produce?

> My concern is that in applying a patch on a customer's machine the log file
> might be bigger and slow down patching.

Again, I'm not sure what this means.  Which log file would get bigger and why?

> Since I am currently an occasional builder of this code, could you put a
comment
> where the ALOGs used to be on how to configure the VLOGs?

VLOG is a standard google3ism.  Additionally there are notes about it on
chromium.org.  I would prefer not to put usage instructions in the source files
because I don't think the source code is an appropriate place for that.

[sra1, 2010-10-21 17:43:08]

On Wed, Oct 20, 2010 at 5:23 PM, <pkasting@chromium.org> wrote:

> On 2010/10/21 00:08:49, sra1 wrote:
>
>> It looks fine, but I'm not sure it is worth doing.
>>
>
> Did you see my message on chromium-dev?  We need to eliminate most uses of
> LOG(INFO).


No, but I have read it now.
LGTM


>
>  What testing did you do to check that the log file contains essentially
>> the
>>
> same
>
>> data?
>>
>
> I don't understand the question.  We're logging the same things, just using
> VLOG
> instead of macros atop LOG.  What would be different about the data we'd
> produce?


So long as it is practically impossible for VLOG(2) to log on a user's
machine during update we should be fine.

My worry was that some of that logging is extremely verbose.  I'm just
worried that without doing the verification on the actual logging
configuration in effect on a user's machine when chrome is updating, we will
end up generating a multi-GB log file and add minutes to the update time.
 But all the bad stuff is VLOG(2).


>
>
>  My concern is that in applying a patch on a customer's machine the log
>> file
>> might be bigger and slow down patching.
>>
>
> Again, I'm not sure what this means.  Which log file would get bigger and
> why?
>
>
>  Since I am currently an occasional builder of this code, could you put a
>>
> comment
>
>> where the ALOGs used to be on how to configure the VLOGs?
>>
>
> VLOG is a standard google3ism.  Additionally there are notes about it on
> chromium.org.  I would prefer not to put usage instructions in the source
> files
> because I don't think the source code is an appropriate place for that.
>
>
> http://codereview.chromium.org/3904002/show
>

[Peter Kasting, 2010-10-21 20:35:41]

On 2010/10/21 17:43:08, sra1 wrote:
> So long as it is practically impossible for VLOG(2) to log on a user's
> machine during update we should be fine.
> 
> My worry was that some of that logging is extremely verbose.  I'm just
> worried that without doing the verification on the actual logging
> configuration in effect on a user's machine when chrome is updating, we will
> end up generating a multi-GB log file and add minutes to the update time.
>  But all the bad stuff is VLOG(2).

Ah, I understand.

The default VLOG level is 0, so even VLOG(1) will not log anything during an
update unless someone has managed to make the update process run with "-v=1" or
higher.