[chromium-dev] Heads up: safely ignored regression on Linux Startup perf test

[John Abd-El-Malek]

Heads up to explain the sudden jump on Linux Startup perf test.

I just submitted r32264 which makes opening and closing processes happen off
the UI thread.  Surprisingly enough, according to UMA stats these would take
an average of 1s on Linux for the first renderer, and 100ms on Windows.
 Subsequent launches were very quick on Linux, but on Windows averaged 50ms.
 When using session restore with many tabs, this would block the UI thread
for quite a bit.  Also, Linux had code which might sleep for up to 2s on the
UI thread waiting for the process to die.

Linux Warm 
Startupperf
test is showing a big regression (200ms->300ms).  With Elliott's
insight, I tracked this down to the fact that the UI thread is very busy at
startup handling GTK messages, so the posted task back to it to tell
BrowserRenderProcessHost that the handle is available is queued up.  This
parallelization is exactly what we want though, and the Linux New Tab
Coldtest
went from ~615ms to ~440ms.  It's hard to see a change on Linux
Warm 
Startup
because
of all the noise.

As for other platforms: Mac
Startup
(both
warm and cold) went from around 307ms to 290ms, while Mac New Tab Cold

went
from 720ms to 620ms.  Windows didn't have much change.

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on XP Tests (dbg)(1), revision 32258

[buildbot]

Automatically closing tree for "unit_tests" on "XP Tests (dbg)(1)"

http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/15667

http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29

--=>  Automatically closing tree for "unit_tests" on "XP Tests (dbg)(1)"  <=--

Revision: 32258
Blame list: y...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Webkit Linux (valgrind), revision 32244

[buildbot]

Automatically closing tree for "compile" on "Webkit Linux (valgrind)"

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Linux%20%28valgrind%29/builds/6483

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Linux%20%28valgrind%29

--=>  Automatically closing tree for "compile" on "Webkit Linux (valgrind)"  
<=--

Revision: 32243, 32244
Blame list: e...@chromium.org,micha...@google.com

Buildbot waterfall: http://build.chromium.org/

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] What is the purpose of the segment_id in the visits table?

[Steve Krulewitz]

Hey all --

I'm trying to get an understanding of the history system and there is
one thing that I can't seem to figure out.  Each visit that gets added
to the visits database table can get assigned a segment_id (a foreign
key to the segments table, stating that the visit is part of a
particular segment), but I don't see anywhere that this is used.  One
thing it could have been used for is to decrement the visit count for
the related segment when the visit is deleted -- but this does not
seem to be implemented.

Any insight would be appreciated!

cheers,
-steve

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] building without svg

[Evan Martin]

On Tue, Nov 17, 2009 at 10:49 AM, Jonathan Dixon  wrote:
> This is tangential to the core of your question, but just to check, are
> asserts disabled on linux release builds?

This is a good thing to check!  But it looks like they are.

> There are numerous calls to ASSERT within the templated functions in
> SVGAnimateedProperty so it seems they could easily blow up the binary size
> if the template is instantiated many times.

Eric the SVG master was not surprised this file shows up; he says it
is all templates and is instantiated once per property in SVG.  On the
other hand, he fairly points out that maybe there are other bits to
worry about first.  I was hoping there was some low hanging fruit.  (I
am still suspicious of logging.h.)

I am investigating further more and will post again once I have some
better results.

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] skia floating point

[Antoine Labour]

On Tue, Nov 17, 2009 at 3:02 PM, Joel Stanley  wrote:

> On Wed, Nov 18, 2009 at 05:23, Antoine Labour  wrote:
> > That's really a question for the Android team, not Chromium...
> > As far as Chrome's use of Skia, if you compile for ARMv7, you'll get NEON
> > acceleration when available.
>
> Except that the tree won't build for ARM, because we don't have a
> buildbot, so it regresses all the time.
>
> I'm in the midst of fixing the latest round of issues (reviews have
> gone out, some have hit the tree).  Who can I poke to get an ARM
> buildbot set up so that once the tree builds again it has a chance of
> staying that way?
>
> Joel
>

It's on my todo list to poke the right people.

Antoine

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] skia floating point

[Joel Stanley]

On Wed, Nov 18, 2009 at 05:23, Antoine Labour  wrote:
> That's really a question for the Android team, not Chromium...
> As far as Chrome's use of Skia, if you compile for ARMv7, you'll get NEON
> acceleration when available.

Except that the tree won't build for ARM, because we don't have a
buildbot, so it regresses all the time.

I'm in the midst of fixing the latest round of issues (reviews have
gone out, some have hit the tree).  Who can I poke to get an ARM
buildbot set up so that once the tree builds again it has a chance of
staying that way?

Joel

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] I restarted, please try again

[Mr. Try Server]

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Chromium Mac Builder, revision 32204

[buildbot]

Automatically closing tree for "compile" on "Chromium Mac Builder"

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Mac%20Builder/builds/7073

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Mac%20Builder

--=>  Automatically closing tree for "compile" on "Chromium Mac Builder"  <=--

Revision: 32203, 32204
Blame list: j...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linting chrome/ in pre-submit checks

[Paweł Hajdan Jr .]

On Tue, Nov 17, 2009 at 20:43, Peter Kasting  wrote:

> On Tue, Nov 17, 2009 at 11:40 AM, Evan Martin  wrote:
>
>> Since we're talking about style, I'll note that this pattern is no
>> good (and I've seen it explicitly called out somewhere before).
>>
>> The problem is that your assertions are not helpful.  You get
>> "expected 'foo', got 'bar' on line 80" but line 80 is just the body of
>> a for loop.
>
>
> (a) I frequently write EXPECT_EQ(a, b) << "Test case in question is " << c;
> (b) Even when this is not true it costs me almost no time to track down the
> case in question in the debugger (if I need to; often the expected result is
> unique)
>

You can also use SCOPED_TRACE (learned that from eroman).

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linting chrome/ in pre-submit checks

[Peter Kasting]

On Tue, Nov 17, 2009 at 11:40 AM, Evan Martin  wrote:

> Since we're talking about style, I'll note that this pattern is no
> good (and I've seen it explicitly called out somewhere before).
>
> The problem is that your assertions are not helpful.  You get
> "expected 'foo', got 'bar' on line 80" but line 80 is just the body of
> a for loop.


(a) I frequently write EXPECT_EQ(a, b) << "Test case in question is " << c;
(b) Even when this is not true it costs me almost no time to track down the
case in question in the debugger (if I need to; often the expected result is
unique)

Don't assume what is and is not helpful to me.

PK

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linting chrome/ in pre-submit checks

[Elliot Glaysher (Chromium)]

On Tue, Nov 17, 2009 at 11:31 AM, Nico Weber  wrote:
> Is cpplint the thing that generates the "lint errors" column on codereview?
> If so, it doesn't work very well for objective-c++ files (.mm) and .h files
> that contain objc++ declarations.

The PRESUBMIT.py file only runs on cc and h files and explicitly
blacklists any file in the cocoa/ directory or any file that has
"_mac.(cc|h)" or "*_mac_*" in its file name.

-- Elliot

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linting chrome/ in pre-submit checks

[Elliot Glaysher (Chromium)]

On Tue, Nov 17, 2009 at 11:29 AM, Peter Kasting  wrote:
> There are some unittests where we have super-long bits which go over 80
> chars, and there are also some where the linter thinks our indenting is
> strange when we do something like:
> struct Foo { ... };
> Foo foo_cases[] = {
>   {"a",
>"b",
>"c"},
> }

This construct is why I make cpplint run at a different verbosity
level for test code.

-- Elliot

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linting chrome/ in pre-submit checks

[Peter Kasting]

On Tue, Nov 17, 2009 at 11:16 AM, Elliot Glaysher (Chromium) <
e...@chromium.org> wrote:

> Currently, it only runs it at (gcl/git cl)
> upload time and only generates warnings. In the future, it should
> error at commit time, but I want to put this through a trial period so
> please pay attention to the warnings and yell and scream at me if
> there are false positives.


There are some unittests where we have super-long bits which go over 80
chars, and there are also some where the linter thinks our indenting is
strange when we do something like:

struct Foo { ... };
Foo foo_cases[] = {
  {"a",
   "b",
   "c"},
}

(It doesn't like the uneven number of spaces when lining up the struct
member initializers).

I don't know whether those will trigger warnings/errors in your tool.

- ';' shouldn't be used in empty loops. Use "{}" instead.
>

This makes me super sad.  ";" alone, indented, is so much more obvious.

PK

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Linting chrome/ in pre-submit checks

[Marc-Antoine Ruel]

To be clear, it'll be a warning prompt on commit, not an error. You
can say (y)es to continue.

M-A

On Tue, Nov 17, 2009 at 2:16 PM, Elliot Glaysher (Chromium)
 wrote:
> Chromium developers,
>
> I have just submitted a PRESUBMIT.py for chrome/ which will run
> cpplint.py on your change as part of the presubmit process. cpplint is
> currently run at reduced strictness--cpplint run separately may
> generate more errors[1]. Currently, it only runs it at (gcl/git cl)
> upload time and only generates warnings. In the future, it should
> error at commit time, but I want to put this through a trial period so
> please pay attention to the warnings and yell and scream at me if
> there are false positives. If I hear nothing, I'll enable errors at
> commit time sometime next week.
>
> I've also gone through chrome/ code and fixed most style errors.
> Here's a few recurring problems to watch out for:
>
> - There is supposed to be a space between (if|while|for) and the
> opening parenthesis. There ISN'T supposed to be a space between a
> function name and it's arguments.
> - When declaring a class that inherits, the ':' should not just be
> hanging on the previous line.
> - On that note, please remember that "class x : public baseclass" and
> "class x : baseclass" may both compile but have different meanings and
> that you probably want the first.
> - Remember that 'private:', 'public:' and 'protected:' should be
> indented one space.
> - Don't use tabs.
> - Header guards should be of the form "CHROME_DIR_DIR_DIR_FILE_H_".
> Header files require header guards; don't omit them. (Exception: the
> "-message.h" headers which do multiple include trickery.)
> - ';' shouldn't be used in empty loops. Use "{}" instead.
> - If an else has a brace on one side, it should have it on both.
>
> Time permitting, I also hope to have app/ , base/ , and maybe views/
> lint clean with presubmit checks in the future. I also hope to make
> the linter more strict in the future; this is just a starting point.
>
> -- Elliot
>
> [1] For the curious: currently, the presubmit process runs normal
> chrome/ code through "--verbose=4" and unit test code through
> "--verbose=5". In addition, there's a list of tests that we instruct
> cpplint.py to not run due either to common false positives or style
> violations that are really, really common.
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Linting chrome/ in pre-submit checks

[Elliot Glaysher (Chromium)]

Chromium developers,

I have just submitted a PRESUBMIT.py for chrome/ which will run
cpplint.py on your change as part of the presubmit process. cpplint is
currently run at reduced strictness--cpplint run separately may
generate more errors[1]. Currently, it only runs it at (gcl/git cl)
upload time and only generates warnings. In the future, it should
error at commit time, but I want to put this through a trial period so
please pay attention to the warnings and yell and scream at me if
there are false positives. If I hear nothing, I'll enable errors at
commit time sometime next week.

I've also gone through chrome/ code and fixed most style errors.
Here's a few recurring problems to watch out for:

- There is supposed to be a space between (if|while|for) and the
opening parenthesis. There ISN'T supposed to be a space between a
function name and it's arguments.
- When declaring a class that inherits, the ':' should not just be
hanging on the previous line.
- On that note, please remember that "class x : public baseclass" and
"class x : baseclass" may both compile but have different meanings and
that you probably want the first.
- Remember that 'private:', 'public:' and 'protected:' should be
indented one space.
- Don't use tabs.
- Header guards should be of the form "CHROME_DIR_DIR_DIR_FILE_H_".
Header files require header guards; don't omit them. (Exception: the
"-message.h" headers which do multiple include trickery.)
- ';' shouldn't be used in empty loops. Use "{}" instead.
- If an else has a brace on one side, it should have it on both.

Time permitting, I also hope to have app/ , base/ , and maybe views/
lint clean with presubmit checks in the future. I also hope to make
the linter more strict in the future; this is just a starting point.

-- Elliot

[1] For the curious: currently, the presubmit process runs normal
chrome/ code through "--verbose=4" and unit test code through
"--verbose=5". In addition, there's a list of tests that we instruct
cpplint.py to not run due either to common false positives or style
violations that are really, really common.

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] skia floating point

[Antoine Labour]

On Mon, Nov 16, 2009 at 11:19 PM, Andy Quan  wrote:

> Hi,
> I noticed that SKIA is by default using floating point calculation
> inside android. Does this mean that if the CPU has VFP unit, SKIA will
> run faster?
>
> I asked this due to my interest in JPEG viewer on android which is
> based on SKIA + libjpeg. Will VFP unit boost this application as well?
>

That's really a question for the Android team, not Chromium...
As far as Chrome's use of Skia, if you compile for ARMv7, you'll get NEON
acceleration when available.

Antoine

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] building without svg

[Jonathan Dixon]

2009/11/16 Evan Martin 

> I spent some quality time with nm.  With it I can take a release
> binary (so all the inlining and optimizations like dead code removal
> have been done) and display symbol sizes as well as which file they're
> from.
>
> My Release Linux build stripped is 39.5mb.  (The size bots show ~44mb,
> which I think is a Chrome vs Chromium thing.  It is curious how the
> Windows binary is nearly half the size of the Linux or Mac one.)
>
> My hacky script managed to total up stats for only 23mb of the binary.
>  I'm not sure where the rest is going but it could be the ICU data
> tables or even just references to external functions in shared
> objects.
>
> Below are the top offenders, in bytes, contributing to binary size
> (recall again that this is a release build), as measured by how nm
> attributes symbols to source files.  Note that it didn't attribute a
> bunch of code (for reasons I don't understand) and those are summed in
> the plain "code" entry below.
>
> And like I had guessed, SVG at the top!  I promise I didn't cook these
> to confirm my own hypothesis.  Also note that much of the rest is
> template-heavy code -- I was surprised to see logging.h scores almost
> 100kb.
>
>  2043226 read only data
>  762291 third_party/WebKit/WebCore/svg/SVGAnimatedProperty.h
>


This is tangential to the core of your question, but just to check, are
asserts disabled on linux release builds?
There are numerous calls to ASSERT within the templated functions in
SVGAnimateedProperty so it seems they could easily blow up the binary size
if the template is instantiated many times.
Linux is the one platform I have yet to setup builds for otherwise I'd look
myself (OSX appears to use the same ASSERT definition so might have similar
symptoms)




>  394334 /usr/include/c++/4.4/bits/vector.tcc
>  270298 /usr/include/c++/4.4/bits/stl_tree.h
>  262889 uninitialized data
>  230389 code
>  196369 ./base/task.h
>  187574 third_party/WebKit/JavaScriptCore/wtf/HashTable.h
>  184647 third_party/WebKit/JavaScriptCore/wtf/HashMap.h
>  157126 ./ipc/ipc_message_utils.h
>  140424 v8/src/x64/codegen-x64.cc
>  136807 third_party/libxml/xmlschemas.c
>  117240 third_party/WebKit/WebCore/css/CSSStyleSelector.cpp
>  113895 v8/src/runtime.cc
>  103056 chrome/renderer/render_view.cc
>   97702 ./base/logging.h
>   95653 third_party/glew/src/glew.c
>   95389 third_party/libxml/parser.c
>   89488 /usr/include/c++/4.4/bits/stl_algo.h
>   84431 third_party/WebKit/JavaScriptCore/wtf/Vector.h
>   83865 v8/src/objects.cc
>   82528 third_party/icu/source/common/uchar_props_data.c
>   82042 third_party/WebKit/WebCore/css/CSSParser.cpp
>   81699 third_party/WebKit/WebCore/dom/Document.cpp
>   79284 third_party/libxml/xpath.c
>   73821 third_party/icu/source/i18n/ucol.cpp
>   73796 third_party/WebKit/WebCore/rendering/RenderBlock.cpp
>   68578 third_party/WebKit/WebCore/loader/FrameLoader.cpp
>   59865 third_party/libxml/HTMLparser.c
>   59048 third_party/WebKit/WebCore/svg/SVGAnimatedTemplate.h
>   58057 third_party/libxml/relaxng.c
>   57535 out/Release/obj/gen/protoc_out/chrome/browser/sync/protocol/
> sync.pb.cc
>   56253 v8/src/parser.cc
>   56000 third_party/icu/source/i18n/decimfmt.cpp
>   54954 global ctors
>   51952 v8/src/api.cc
>
>
> On Fri, Nov 13, 2009 at 2:39 PM, Evan Martin  wrote:
> > We track total binary size here:
> >  http://build.chromium.org/buildbot/perf/dashboard/sizes.html
> >
> > I don't know of any place we track per-module sizes.
> >
> > On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel 
> wrote:
> >> Do we have any hard data about where our binary size goes?  It seems
> >> such data would be very useful.
> >>
> >> On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin  wrote:
> >>> I measured that SVG is nearly a sixth of the binary size of a Chrome
> >>> debug build.  That's not only more compile time, it's also more link
> >>> time for each incremental link and more time for the debugger to grind
> >>> it when starting gdb.  For my day-to-day debugging I would like to
> >>> build without SVG (and many other bits, but let's start with SVG).
> >>>
> >>> I put on one obvious patch and one patch I'm not sure about at
> >>>  https://bugs.webkit.org/show_bug.cgi?id=31490
> >>>
> >>> Does anyone have thoughts about the right way to disable SVG in the GYP
> files?
> >>> Here's the hacky second patch mentioned above:
> >>>  https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196
> >>> In particular, I'm not sure of the right way to conditionally build
> >>> the SVGNames bits.
> >>>
> >>> I've seen in some cases files are completely wrapped with "#if
> >>> ENABLE(FOO)"; do you know when that is appropriate?
> >>>
> >>> --
> >>> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >>> View archives, change email options, or unsubscribe:
> >>>http://groups.google.com/group/chromium-dev
> >>>
> >>
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email option

[chromium-dev] skia floating point

[Andy Quan]

Hi,
I noticed that SKIA is by default using floating point calculation
inside android. Does this mean that if the CPU has VFP unit, SKIA will
run faster?

I asked this due to my interest in JPEG viewer on android which is
based on SKIA + libjpeg. Will VFP unit boost this application as well?

Regards,
Andy

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] new matrix-view perf dashboard

[Steven Knight]

>
> 1) I cannot see Dromaeo benchmark;
>

Added.


> 2) is it possible to make column titles sticky?  I mean that when you
> scroll down and don't see nor footer, nor header, it's hard to tell
> the flavour of each graph in the raw.
>

I'm sure there's a way, but that's beyond my JS skills.  As a stopgap until
something more sophisticated comes along, I added a quick hack to replicate
the column title row every four graphs, so you should probably have the
build slave title in view (or very close) on most displays.

Thanks,

  --SK


> And just an observation.  At least for me newer page loads notably
> faster than the previous one.
>
> yours,
> anton.
>
> On Tue, Nov 17, 2009 at 3:05 AM, Steven Knight  wrote:
> > The current perf dashboard is getting long and unwieldy.  I've put up a
> new
> > page which packs the same thumbnail graphs into a matrix:
> >
> > http://build.chromium.org/buildbot/perf/dashboard/perf.html
> > Rows are the various perf tests we run, columns are the different build
> > slaves.  It compresses the graphs horizontally to fit your window size at
> > page load time.  (No dynamic resizing.)
> > Row (test) and column (slave) headings are links that take you to
> separate
> > pages that show just one test's graphs from all slaves (row), or just all
> > the test graphs for a single slave (column).  In addition to making it
> more
> > convenient to focus on a specific test's/slave's results, these
> individual
> > pages also have the advantage of (re)loading a lot more quickly than the
> > full dashboard, since you're only pulling down and displaying data for
> about
> > ten graphs, instead of the ~100 thumbnail graphs in the full dashboard.
> > The pages for the new matrix Perf view and the old classic Perf view now
> > have clickable links at the top for switching between the two.  (Neither
> is
> > very fast, though, given that you load ~100 graphs each time you switch).
> > Let me know if you notice any problems or have any suggestions for making
> > this more useful.
> > --SK
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] buildbot failure in Chromium on Mac10.5 Tests, revision 32176

[Marc-Antoine Ruel]

Glad to see you back, gatekeeper!

chase++

On Tue, Nov 17, 2009 at 12:29 PM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "unit_tests" on "Mac10.5 Tests"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests/builds/8528
>
> Revision: 32176
> Blame list: miran...@chromium.org
>
>  Mac10.5 Tests
> Build 
> 8528
>   update
> scripts
> stdio
> update
> stdio
>   extract
> build
> stdio
> ipc_tests
> stdio
> unit_tests
> did not complete
> crashed or hung
> stdio
>
> Changed by: *miran...@chromium.org*
> Changed at: *Tue 17 Nov 2009 09:19:54*
> Branch: *src*
> Revision: 
> *32176*
> Changed files:
>
>- *chrome/browser/browser.cc*
>- *chrome/browser/dom_ui/dom_ui_theme_source.cc*
>- *chrome/browser/dom_ui/new_tab_ui.cc*
>- *chrome/browser/resources/new_new_tab.css*
>- *chrome/browser/resources/new_new_tab.js*
>- *chrome/common/pref_names.cc*
>- *chrome/common/pref_names.h*
>
> Comments:
>
> Tweaks and fixes for NTP extension promo.
>
> Don't show promo for extensions on Mac, as they're not available yet. 
> Decrement promo counter even when NTP is not home page, and do not remove 
> puzzle piece when promo line is closed. When message bar is closed, make it 
> zip off bottom of screen instead of just disappearing.
>
> BUG= 27814, 25258, 27815
> TEST= see various bugs.
> Review URL: http://codereview.chromium.org/385135
>
> Properties:
>
>
>   --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Mac10.5 Tests, revision 32176

[buildbot]

Automatically closing tree for "unit_tests" on "Mac10.5 Tests"

http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Tests/builds/8528

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Mac10.5%20Tests

--=>  Automatically closing tree for "unit_tests" on "Mac10.5 Tests"  <=--

Revision: 32176
Blame list: miran...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Getting 'This is a read-only checkout' error from gcl

[Jens Alfke]

On Nov 13, 2009, at 1:05 PM, Chase Phillips wrote:

> Thanks for the feedback.  gcl no longer requires --force to create  CL in a 
> read-only checkout.

It wasn't actually a read-only checkout. WebKit doesn't use a separate URL for 
the writeable repo; after you get commit privileges, your repo is still at an 
http: URL. So the simple test of the URL scheme that gcl is doing is not an 
accurate way to test for writeability.

—Jens

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] How to compile Google Chrome with Visual C++ 2008 Express Edition

[PhistucK]

OK, so I am trying with Visual C++ 2005 Express. After working around most
of the errors, I got one (hopefully...) left -
fatal error LNK1104: cannot open file ‘atl.lib’ chrome_dll

The last error that I resolved before that, was almost the same, but “atlz”
instead of “atl” in the file name.
So I went to the chrome_dll properties and chose to dynamically link ATL and
it worked. But then I got the above error and I am at a loss.

Any ideas?

☆PhistucK


On Tue, Nov 17, 2009 at 04:03, Marc-Antoine Ruel  wrote:

> Dominic, you should turn /WX off globally in src/build/common.gypi.
> That would simplify the patch.
>
> I guess the incremental link failure is due to the exe size on a 32
> bit OS, I'll mark it as a large binary so you can remove that step
> too.
>
> M-A
>
> On Mon, Nov 16, 2009 at 8:58 PM, Bradley Nelson 
> wrote:
> > That's good to hear!
> > I see you are mainly just turning off warnings as errors in a few spots.
> > Is this something that we can either gate in the build based on some
> flag,
> > or are the warnings something that we could fix properly in the source?
> I'd
> > love to peel off more steps from the process.
> > -BradN
> > On Mon, Nov 16, 2009 at 5:44 PM, Dominic Jodoin <
> dominic.jod...@gmail.com>
> > wrote:
> >>
> >> Hey Brad!
> >>
> >> I just wanted to let you know that this is working great for me on
> >> VC++ 2008 Express Edition. Thanks a lot!
> >>
> >> I have updated my page to reflect your change. I also added a patch
> >> that modifies some GYP files in such a way that you won’t have to
> >> manually “play” with the project settings in order to compile without
> >> errors (with this compiler that is).
> >>
> >>
> >>
> http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/
> >>
> >> -- Dominic.
> >>
> >> On Thu, Nov 12, 2009 at 7:51 PM, Bradley Nelson 
> >> wrote:
> >> > Ok that fix is in.
> >> > You'd need to set GYP_MSVS_VERSION=2008e
> >> > Let me know how that goes for you.
> >> > -BradN
> >> >
> >> > On Wed, Nov 11, 2009 at 12:50 PM, Marc-Antoine Ruel
> >> > 
> >> > wrote:
> >> >>
> >> >> Updated
> >> >>
> >> >>
> http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows
> >> >> to reference your blog entry.
> >> >>
> >> >> I don't want to copy these instructions since it's too lengthy,
> >> >> inefficient and unsupported.
> >> >>
> >> >> I didn't realize one could download WDK 7 without needing a MSDN
> >> >> account. That's cool.
> >> >>
> >> >> M-A
> >> >>
> >> >> On Tue, Nov 10, 2009 at 10:39 PM, Dominic Jodoin
> >> >>  wrote:
> >> >> > On Tue, Nov 10, 2009 at 10:25 PM, Peter Kasting <
> pkast...@google.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> What do you mean?  Or to be more precise, what would considering
> >> >> >> your
> >> >> >> steps
> >> >> >> "a valid setup to contribute" concretely result in?
> >> >> >> PK
> >> >> >
> >> >> > I'm wondering if using a hacked ATL version 7.1 could lead to bugs
> >> >> > given the product is built, I suppose, with ATL coming with Visual
> >> >> > Studio 2005 or 2008 which is a different version.
> >> >> >
> >> >> > But what I meant was that if the steps were to be approved, I
> thought
> >> >> > they could be included on http://dev.chromium.org.
> >> >> >
> >> >> > -- Dominic.
> >> >> >
> >> >> > --
> >> >> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> >> > View archives, change email options, or unsubscribe:
> >> >> >http://groups.google.com/group/chromium-dev
> >> >> >
> >> >>
> >> >> --
> >> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
> >> >> View archives, change email options, or unsubscribe:
> >> >>http://groups.google.com/group/chromium-dev
> >> >
> >> >
> >
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] new matrix-view perf dashboard

[Anton Muhin]

Very cool, Steven, thanks a lot.

Two notes:

1) I cannot see Dromaeo benchmark;
2) is it possible to make column titles sticky?  I mean that when you
scroll down and don't see nor footer, nor header, it's hard to tell
the flavour of each graph in the raw.

And just an observation.  At least for me newer page loads notably
faster than the previous one.

yours,
anton.

On Tue, Nov 17, 2009 at 3:05 AM, Steven Knight  wrote:
> The current perf dashboard is getting long and unwieldy.  I've put up a new
> page which packs the same thumbnail graphs into a matrix:
>
> http://build.chromium.org/buildbot/perf/dashboard/perf.html
> Rows are the various perf tests we run, columns are the different build
> slaves.  It compresses the graphs horizontally to fit your window size at
> page load time.  (No dynamic resizing.)
> Row (test) and column (slave) headings are links that take you to separate
> pages that show just one test's graphs from all slaves (row), or just all
> the test graphs for a single slave (column).  In addition to making it more
> convenient to focus on a specific test's/slave's results, these individual
> pages also have the advantage of (re)loading a lot more quickly than the
> full dashboard, since you're only pulling down and displaying data for about
> ten graphs, instead of the ~100 thumbnail graphs in the full dashboard.
> The pages for the new matrix Perf view and the old classic Perf view now
> have clickable links at the top for switching between the two.  (Neither is
> very fast, though, given that you load ~100 graphs each time you switch).
> Let me know if you notice any problems or have any suggestions for making
> this more useful.
>         --SK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Warning about missing newline

[PhistucK]

This is a work in progress, according to some recent (few days) change
lists. Someone currently goes over most of the sources and lint cleans them
in preparation for adding the lint check to the presubmit check, or
something like that.

☆PhistucK


On Tue, Nov 17, 2009 at 07:48, Peter Kasting  wrote:

> On Mon, Nov 16, 2009 at 9:07 PM, Ian Fette  wrote:
>
>> Lint will warn you about this -- and I know that everyone runs gcl lint
>> changelist_name before uploading...
>
>
> Why do I have to remember to run a separate command?  Why does this not run
> during presubmit?
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev