[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?
On Aug 24, 3:58 am, Peter Kasting pkast...@google.com wrote: We already have this since web pages take over things like ctrl-w and ctrl-f (and we wouldn't want to change that since in many cases it's important that they do so). AFAICT, at least Alt+Shift+T and Alt+D seem not to be preventable by a web page. If we were going to do this we should just give up. We already have alt-shit-t and that's good enough if we're going to use hard-to-find non-standard access keys. The entire point of alt, alt-f and alt-e is to pick things users will naively try to use. Well, I wouldn't really call having to hit Alt+Shift+T, Left * 5, Space for accessing the wrench menu good enough. Whether you choose Alt+F or Alt+Shift+whathever, Chrome feels like being less in your way (once you know the shortcut). Then again: Is accessibility one of the goals for Chrome at all? Or is it just not tested for for lack of manpower? As it currently stands, it can get quite frustrating to use without a mouse (double accesskeys in menus, no accesskeys at all in dialogs, certain shortcuts unavailable on non-US keyboards, page actions unreachable). --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] private VM field on the about:memory page
I'm looking at the about:memory page and am wondering how useful is the private VM field? Would it be just as good to have a total VM instead? The reason I ask is because private VM doesn't map easily to Linux where private pages can be shared becuase of copy-on-write. Also, in general, how useful is knowing VM size considering it's not necessarily corollated with actual memory usage? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: fighting the test flakiness
phajdan: Feel free to add a link at the top of the waterfall. Maybe beside perf at the top left corner. You just need to edit http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/master.chromium/public_html/announce.html?view=markup http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/master.chromium/public_html/announce.html?view=markupYou can send me the review. Nicolas On Tue, Aug 18, 2009 at 1:19 PM, Scott Violet s...@chromium.org wrote: This is very useful. How about a link to this some where on the main builder page. -Scott On Tue, Jul 28, 2009 at 9:52 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: So, the flakiness dashboard is now public and updated daily, at http://build.chromium.org/buildbot/flakiness-report/ . It displays top 15 flaky test groups and tests, and relevant parts of the logs (toggle details javascript link). It has dates of the first and last flip of each test or group. It's a feature that was frequently asked for, and if you have any more feedback, I will be glad to hear it. One thing it currently does not track correctly are test crashes/timeouts I think. I'm working on that. It also doesn't track browser_tests yet. There is a label in the bug tracker FlakyTest - please use it when reporting flaky tests. One of my goals is to fix those bugs. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
Hello, On Mon, Aug 24, 2009 at 22:48, Anand Mistryakmis...@gmail.com wrote: Also, in general, how useful is knowing VM size considering it's not necessarily corollated with actual memory usage? I chatted with a few people when doing doing my memory work. Based on this, I think we should look at two criteria for what to display on the Linux port: - what we can measure accurately - information that will be useful to the user I don't think there is any use in showing the user the VM size. If a dev needs it, he can use top(1). Also, by not trying to display the exact same columns as windows does, hopefully there will be fewer uninformed comparisons of the numbers between platforms. Cheers, 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] Re: Chromium / Google Summer of Code
I'll let Paul Wicks chime in on his own experience, but we've been able to successfully integrate the Mac OS X spell checker with the Chromium infrastructure, including introducing platform support for a spelling window. Paul is also in the process of adding OCMock to our build, which we desperately need for many of our unit tests. I'd say it was a smashing success! On Sun, Aug 23, 2009 at 11:05 AM, Joel Stanleyj...@jms.id.au wrote: On Sat, Aug 22, 2009 at 07:31, Lei Zhangthes...@chromium.org wrote: With the Google Summer of Code program winding down, I'm curious how our GSoC participants are doing. Can the students and their mentors share their experiences? (Assuming you're all done with evaluations and all that.) My project was 'Forging a better Cr on Linux', and Dean was my mentor. I had an eye on doing performance/memory usage work motivated by my attempts to run Chromium on the Beagleboard; an ARM system with 128MB of RAM. Chromium works and you can come along to OSDC (http://2009.osdc.com.au) for my talk There's something on my ARM for all the details :) I didn't get as much done as I would have liked as I was attending classes and sitting exams throughout my Summer of Code, a downside of being a student from the southern hemisphere. This means I'm going to stick around the project to continue working on things I'm interested in. (For my record as much as anyone else) here is a summary of the patches I wrote, in chronological order: == Scale backing store cache size == This would scale the number of DIBs stored based on the system RAM. It's since been replaced by a more complex algorithm. == Set process name on Linux == This was to help distinguish the renderer from the browser (and the zygote, which was just appearing at the time). It was reverted as it broke the UI tests which iterate over the process name. I did not resubmit as 'ps f' provides the same information for less lines of code. == Jankfs == An idea Dean had; write a FUSE filesystem to simluate slow and unreliable storage. See http://groups.google.com/group/chromium-dev/browse_thread/thread/59b0440255c87ed3 == ARM build == The tree had built for ARM at some point in the past but had since bitrotted. I went through building a toolchain, and then a root filesystem, and found 3 gcc ICE (internal compiler errors) on the way. I then made a bunch of changes in working towards building and running Chromium on the Beagleboard: * Hide x86 assembly in the seccomp and chroot sandboxes from the ARM build * A Skia build fix * v8 patch for targeting the ARMv7 Cortex-A8 (found on the beagleboard) * Most significantly, re-wrote v8.gyp to make cross-compiling possible For instructions on building see http://code.google.com/p/chromium/wiki/LinuxChromiumArm == Memory usage in task manager on Linux == Calculates the memory usage of each process. This is committed and working, but the API needs to be re-worked to be less Windows-like before about:memory is ready for Linux. See http://codereview.chromium.org/159777 == Fix proxy settings for Gnome =2.26 == Newer versions of Gnome use a different binary name, this made the Change proxy settings button work for both. == Add ctrl+w accelerator to close bookmark manager for linux == == Fix PR_ImplodeTime for Linux x64 == This was one of the last patches to make the chrome tree compile for x64 without patches, building on Dean's work. Beware the 2038 bug. == One liners == * gcc-4.3 / 4.4 build fixes * gitignore updates * window icons According to the logs I wrote 22 patches. Despite having been around open source projects for a number of years, Chroimum's development process taught me many new things. Having code review for all changes made was a new to me, and line by line review is great at ensuring I got detailed feedback. Dean's mentoring was the most valuable part of the experience. He was great at answering questions and explaining the concepts I was not familiar with. Having the ability to communicate via IM made this very easy and I would encourage mentors and students to follow this setup in future years. Thanks to Dean for mentoring me, and everyone else who reviewed and committed my patches. Cheers, Joel -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
On Mon, Aug 24, 2009 at 6:18 AM, Anand Mistryakmis...@gmail.com wrote: I'm looking at the about:memory page and am wondering how useful is the private VM field? Would it be just as good to have a total VM instead? The reason I ask is because private VM doesn't map easily to Linux where private pages can be shared becuase of copy-on-write. Did you see the memory usage backgrounder? http://dev.chromium.org/memory-usage-backgrounder It's written to be Windows specific, but 80% of the things will apply to Linux. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
On Mon, Aug 24, 2009 at 6:18 AM, Anand Mistry akmis...@gmail.com wrote: I'm looking at the about:memory page and am wondering how useful is the private VM field? Would it be just as good to have a total VM instead? The reason I ask is because private VM doesn't map easily to Linux where private pages can be shared becuase of copy-on-write. I don't think it matters much; the VM size is not critical. You could diverge on linux/windows on this field (but you'll have to get the help text mopped up to describe whatever is displayed) Also, in general, how useful is knowing VM size considering it's not necessarily corollated with actual memory usage? Hard to say! But it does seem like an analysis of memory without being able to see some amount of VM information is incomplete. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
On Mon, Aug 24, 2009 at 8:13 AM, Anand Mistry akmis...@gmail.com wrote: On Mon, Aug 24, 2009 at 11:42 PM, Joel Stanley j...@jms.id.au wrote: Hello, On Mon, Aug 24, 2009 at 22:48, Anand Mistryakmis...@gmail.com wrote: Also, in general, how useful is knowing VM size considering it's not necessarily corollated with actual memory usage? I chatted with a few people when doing doing my memory work. Based on this, I think we should look at two criteria for what to display on the Linux port: - what we can measure accurately - information that will be useful to the user I don't think there is any use in showing the user the VM size. If a dev needs it, he can use top(1). Well, out of the 5 stats on that page, 4 of them can be reported with a fair amount of accuracy (WS private, WS shared, WS total, VM mapped). The first three are pretty obvious and apply to just about any platform. VM mapped can be reported very accurately by parsing /proc/pid/smaps and might arguably be useful. Also, by not trying to display the exact same columns as windows does, hopefully there will be fewer uninformed comparisons of the numbers between platforms. Which bring about another question, how consistent should we be across platform? Do we really want to show different stats on different platforms? This page is for geeks and reviewers that like to look at memory. Cater to them. They're going to want to compare windows and linux. So we can either give them the tools and instructions on how to do it, or they'll do it themselves (and who knows what they'll compare with). Mike Cheers, Joel @Brett: I've read it now and the relevant parts only talk about working set, not VM. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
On Mon, Aug 24, 2009 at 11:42 PM, Joel Stanley j...@jms.id.au wrote: Hello, On Mon, Aug 24, 2009 at 22:48, Anand Mistryakmis...@gmail.com wrote: Also, in general, how useful is knowing VM size considering it's not necessarily corollated with actual memory usage? I chatted with a few people when doing doing my memory work. Based on this, I think we should look at two criteria for what to display on the Linux port: - what we can measure accurately - information that will be useful to the user I don't think there is any use in showing the user the VM size. If a dev needs it, he can use top(1). Well, out of the 5 stats on that page, 4 of them can be reported with a fair amount of accuracy (WS private, WS shared, WS total, VM mapped). The first three are pretty obvious and apply to just about any platform. VM mapped can be reported very accurately by parsing /proc/pid/smaps and might arguably be useful. Also, by not trying to display the exact same columns as windows does, hopefully there will be fewer uninformed comparisons of the numbers between platforms. Which bring about another question, how consistent should we be across platform? Do we really want to show different stats on different platforms? Cheers, Joel @Brett: I've read it now and the relevant parts only talk about working set, not VM. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
On Mon, Aug 24, 2009 at 8:13 AM, Anand Mistryakmis...@gmail.com wrote: Also, by not trying to display the exact same columns as windows does, hopefully there will be fewer uninformed comparisons of the numbers between platforms. Which bring about another question, how consistent should we be across platform? Do we really want to show different stats on different platforms? Yes. On X we need to report memory used on the X server as well. This is unscientific, but for my single-tab gmail on Chrome and FF, I get Chrome at 1378k and FF at 618k, and we'll use a lot more with more tabs. See man xrestop. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Linux folks] Splitting First Run into it's own process
On Mon, Aug 24, 2009 at 10:08 AM, Jeremy Moskovichjer...@chromium.org wrote: * Due to some technical limitations with the FF libraries, we need to load them in a separate process. It also doesn't seem like a good idea to run code out of an arbitrary library in the main process. Coincidentally, I was just chatting with an Epiphany (WebKit+Gtk) developer about Firefox import and he too was lamenting how complicated it is to get this data out of Firefox. I had suggested a utility process might be the best way. (Note: not a complaint about Firefox; it's likely it's even harder to import this sort of data out of us...) * The first run dialog needs to be displayed very early on in the launch process since we need to display it before enabling stats and crash reporting so we can ask for the user's consent. The dialog is brought up before we've fully initialized Cocoa which is concerning in terms of it's interaction with the main app runloop, There are also UI artifacts - http://crbug.com/19643 As far as I know there are no such issues on Linux, so we don't have anybody working on doing this split. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Linux folks] Splitting First Run into it's own process
On Fri, Aug 21, 2009 at 7:15 PM, Evan Martin e...@chromium.org wrote: What's the motivation? * Due to some technical limitations with the FF libraries, we need to load them in a separate process. It also doesn't seem like a good idea to run code out of an arbitrary library in the main process. * The first run dialog needs to be displayed very early on in the launch process since we need to display it before enabling stats and crash reporting so we can ask for the user's consent. The dialog is brought up before we've fully initialized Cocoa which is concerning in terms of it's interaction with the main app runloop, There are also UI artifacts - http://crbug.com/19643 Best regards, Jeremy On Fri, Aug 21, 2009 at 5:11 PM, Jeremy Moskovichjer...@chromium.org wrote: I'm looking at splitting the First Run UI import machinery into it's own process on OS X. I just wanted to sync up with people working on the Linux side of things to make sure no-one else is working on the same thing in Linux-land? Best regards, Jeremy --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Handling layout test expectations for failing tests
On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting pkast...@chromium.orgwrote: On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow jor...@chromium.orgwrote: 1) We don't have notes on why tests are failing. = Why not annotate the tests in test_lists? That's what I've always done. Once again, we don't want to add more state to the test_expectations. How may people looked up the tests they were supposed to rebaseline in this file to see if there were notes? I kind of doubt anyone. Um... this makes no sense to me. You can't rebaseline a test without modifying test_expectations. In modifying it, you *have* to look at it. It's pretty difficult to miss comments above tests as you're trying to write REBASELINE or delete the line. If you somehow managed to not see any comments in this file, I think you're an outlier. I was talking about the rebaselining teams, not the act of actually rebaselining. If someone's rebaselining a test, then it means we now believe it's passing. At that point, the notes are not very interesting, right? Are you saying that you looked at all the tests' notes before you looked through the results to determine if they should be rebaselined? We're trying to leave all comments in the bugs now, rather than in the test_expectations file, so there's only one point of contact. We used to leave extensive comments in the file, but they always grew stale. And yes, I looked at the bug for every test that I thought was correct, usually to write tests A, B and C are still bad, but D was actually correct and is being re-baselined. There are different reasons for failing. A layout test could be failing because of a known bug and then start failing in a different way (later) due to a regression. When a bug fails in a new way, it's worth taking a quick look, I think. Why? Unless the earlier failure has been fixed we can't rebaseline the test. (I ran into a number of tests like this when doing my rebaselining pass.) What is the point of looking again? In case the new failure is more serious than the earlier one. True. But I don't think this will happen often, and I'd rather devote the time to fixing the tests. - Pam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
I'm with Matt on this one but if there are serious objections I'll let this die http://codereview.chromium.org/173234/show On Fri, Aug 21, 2009 at 10:27 AM, Matt Perry mpcompl...@chromium.orgwrote: Defining operator is fine. Other types do this: http://www.google.com/codesearch?as_q=operatorbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunk/srcas_filename=\.has_case=http://www.google.com/codesearch?as_q=operator%3C%3CbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunk/srcas_filename=%5C.has_case= string16 is a good example. http://www.google.com/codesearch?as_q=operator%3C%3CbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunkas_filename=%5C.has_case= I say just use iosfwd and add the operator. On Thu, Aug 20, 2009 at 10:10 PM, Jim Roskind j...@chromium.org wrote: Looking at the example you gavehow about: EXPECT_EQ(kExpected.InMilliseconds(), foo.InMilliseconds()); Is that really that painful to write? ...and you could get all the microseconds to compare if you wanted to via ...InMicroseconds(). I suspect you don't really want absolute comparisons at the microsecond level, and more likely you'd want something like; EXPECT_LT((kEpected - foo).InMilliseconds(), 20). ...but if you really wanted the example you cited, the first line seems relatively short. Jim On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkus scher...@chromium.orgwrote: I know microseconds aren't a very user-friendly format, but for unit tests and DCHECKs I'm more interested in whether the assertion is simply true. Perhaps I'm lazy but I'd prefer: EXPECT_EQ(kExpected, foo); error: Value of: foo Actual: 2100 Expected: kExpected Which is: 2200 ...over: EXPECT_TRUE(kExpected == foo) Some message about kExpected.InSecondsF() and foo.InSecondsF(); error: Value of: kExpected == foo Actual: false Expected: true Some message about 21.0 and 22.0 Guaranteed I won't write that message every time and then I end up with a simple true/false dump instead of the erroneous values. On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.orgwrote: Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.orgwrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.org wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?
On Sun, Aug 23, 2009 at 11:14 PM, zeniko zen...@gmail.com wrote: Then again: Is accessibility one of the goals for Chrome at all? Or is it just not tested for for lack of manpower? As it currently stands, it can get quite frustrating to use without a mouse (double accesskeys in menus, no accesskeys at all in dialogs, certain shortcuts unavailable on non-US keyboards, page actions unreachable). Please file bugs on all these. I filed http://code.google.com/p/chromium/issues/detail?id=20125 . PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Overloading operator for TimeDelta
We have that operator defined for a bunch of random types (gfx::Rect comes to mind) so I think if there's a compilation overheard it should be fixed in other places as well. On Mon, Aug 24, 2009 at 10:26 AM, Andrew Scherkusscher...@chromium.org wrote: I'm with Matt on this one but if there are serious objections I'll let this die http://codereview.chromium.org/173234/show On Fri, Aug 21, 2009 at 10:27 AM, Matt Perry mpcompl...@chromium.org wrote: Defining operator is fine. Other types do this: http://www.google.com/codesearch?as_q=operatorbtnG=Search+Codehl=enas_lang=as_license_restrict=ias_license=as_package=src.chromium.org/svn/trunk/srcas_filename=\.has_case= string16 is a good example. I say just use iosfwd and add the operator. On Thu, Aug 20, 2009 at 10:10 PM, Jim Roskind j...@chromium.org wrote: Looking at the example you gavehow about: EXPECT_EQ(kExpected.InMilliseconds(), foo.InMilliseconds()); Is that really that painful to write? ...and you could get all the microseconds to compare if you wanted to via ...InMicroseconds(). I suspect you don't really want absolute comparisons at the microsecond level, and more likely you'd want something like; EXPECT_LT((kEpected - foo).InMilliseconds(), 20). ...but if you really wanted the example you cited, the first line seems relatively short. Jim On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkus scher...@chromium.org wrote: I know microseconds aren't a very user-friendly format, but for unit tests and DCHECKs I'm more interested in whether the assertion is simply true. Perhaps I'm lazy but I'd prefer: EXPECT_EQ(kExpected, foo); error: Value of: foo Actual: 2100 Expected: kExpected Which is: 2200 ...over: EXPECT_TRUE(kExpected == foo) Some message about kExpected.InSecondsF() and foo.InSecondsF(); error: Value of: kExpected == foo Actual: false Expected: true Some message about 21.0 and 22.0 Guaranteed I won't write that message every time and then I end up with a simple true/false dump instead of the erroneous values. On Thu, Aug 20, 2009 at 6:49 PM, Matt Perry mpcompl...@chromium.org wrote: Andrew wants to be able to do: DCHECK_EQ(expected_time_delta, time_delta); This can't be done without operator support. On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind j...@chromium.org wrote: +1 for Peter's suggestion. TimeDelta has an internal accuracy of microseconds. What resolution/scaling do you want to print in a check? Sometimes it is minutes, sometimes seconds, sometimes milliseconds, I doubt that we want microseconds :-/. Explicit conversion as suggested doesn't seem that painful IMO. Jim On Thu, Aug 20, 2009 at 4:02 PM, Peter Kasting pkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus scher...@chromium.org wrote: Any opposition to globally declaring an operator ostream overload for TimeDelta in base/time.h? This will pull the stream headers into all files that use time.h. Is that going to bloat any code or cost compile time? Is there another easy solution like doing DCHECK() TimeDelta was: myTimeDelta.asInt64OrWhatever()? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Question about resource_dispatcher_host.h
From http://dev.chromium.org/developers/design-documents/multi-process-architecture, Resoruce dispatcher Host should have the list of all the channel opened with each Renderer Process. But when I look at the resource_dispatcher_host.h, I dont' find any attribute of ResourceDispatcherHost which maintains that list. Can you please tell me how/where does ResourceDispatcherHost keep track of that list of Channel? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Handling layout test expectations for failing tests
On Mon, Aug 24, 2009 at 10:37 AM, Pam Greene p...@chromium.org wrote: On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting pkast...@chromium.orgwrote: On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow jor...@chromium.orgwrote: There are different reasons for failing. A layout test could be failing because of a known bug and then start failing in a different way (later) due to a regression. When a bug fails in a new way, it's worth taking a quick look, I think. Why? Unless the earlier failure has been fixed we can't rebaseline the test. (I ran into a number of tests like this when doing my rebaselining pass.) What is the point of looking again? In case the new failure is more serious than the earlier one. True. But I don't think this will happen often, and I'd rather devote the time to fixing the tests. The end goal is to be in a state where we have near zero failing tests that are not for unimplemented features. And new failures from the merge get addressed within a week. Once we're at that point, would this new infrastructure be useful? I completely support infrastructure that sustainably supports us being at near zero failing tests (e.g. the rebaseline tool). All infrastructure/process has a maintenance cost though. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
There's one host per renderer, so there's no need for any list. On Mon, Aug 24, 2009 at 11:22 AM, hap 497 hap...@gmail.com wrote: From http://dev.chromium.org/developers/design-documents/multi-process-architecture, Resoruce dispatcher Host should have the list of all the channel opened with each Renderer Process. But when I look at the resource_dispatcher_host.h, I dont' find any attribute of ResourceDispatcherHost which maintains that list. Can you please tell me how/where does ResourceDispatcherHost keep track of that list of Channel? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
Thanks. But the picture in the document shows there is only 1 ResourceDispatcherHost and there are 2 Renderer Processes: http://dev.chromium.org/developers/design-documents/multi-process-architecture And the ResourceDispatcherHost has access to both Channels for each Renderer Process. On Mon, Aug 24, 2009 at 12:37 PM, Jeremy Orlow jor...@google.com wrote: There's one host per renderer, so there's no need for any list. On Mon, Aug 24, 2009 at 11:22 AM, hap 497 hap...@gmail.com wrote: From http://dev.chromium.org/developers/design-documents/multi-process-architecture, Resoruce dispatcher Host should have the list of all the channel opened with each Renderer Process. But when I look at the resource_dispatcher_host.h, I dont' find any attribute of ResourceDispatcherHost which maintains that list. Can you please tell me how/where does ResourceDispatcherHost keep track of that list of Channel? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
There's one ResourceDispatcherHost for all renderers (but there is one ResourceMessageFilter per renderer process). That graph shows a connection between the filter (ResourceMessageFilter) and the ResourceDispatcherHost, but it's the former that has a pointer to the latter. RDH doesn't have a list of active RMF objects. On Mon, Aug 24, 2009 at 12:49 PM, hap 497 hap...@gmail.com wrote: Thanks. But the picture in the document shows there is only 1 ResourceDispatcherHost and there are 2 Renderer Processes: http://dev.chromium.org/developers/design-documents/multi-process-architecture And the ResourceDispatcherHost has access to both Channels for each Renderer Process. On Mon, Aug 24, 2009 at 12:37 PM, Jeremy Orlow jor...@google.com wrote: There's one host per renderer, so there's no need for any list. On Mon, Aug 24, 2009 at 11:22 AM, hap 497 hap...@gmail.com wrote: From http://dev.chromium.org/developers/design-documents/multi-process-architecture, Resoruce dispatcher Host should have the list of all the channel opened with each Renderer Process. But when I look at the resource_dispatcher_host.h, I dont' find any attribute of ResourceDispatcherHost which maintains that list. Can you please tell me how/where does ResourceDispatcherHost keep track of that list of Channel? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
Indeed. The diagram could certainly be improved. If you are artistically inclined, I hope you'll consider improving the diagram after you gain a solid understanding of how the components fit together. Adam On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote: Thanks. But the picture in the document shows there is only 1 ResourceDispatcherHost and there are 2 Renderer Processes: http://dev.chromium.org/developers/design-documents/multi-process-architecture And the ResourceDispatcherHost has access to both Channels for each Renderer Process. On Mon, Aug 24, 2009 at 12:37 PM, Jeremy Orlow jor...@google.com wrote: There's one host per renderer, so there's no need for any list. On Mon, Aug 24, 2009 at 11:22 AM, hap 497 hap...@gmail.com wrote: From http://dev.chromium.org/developers/design-documents/multi-process-architecture, Resoruce dispatcher Host should have the list of all the channel opened with each Renderer Process. But when I look at the resource_dispatcher_host.h, I dont' find any attribute of ResourceDispatcherHost which maintains that list. Can you please tell me how/where does ResourceDispatcherHost keep track of that list of Channel? Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote: Thanks. But the picture in the document shows there is only 1 ResourceDispatcherHost and there are 2 Renderer Processes: http://dev.chromium.org/developers/design-documents/multi-process-architecture And the ResourceDispatcherHost has access to both Channels for each Renderer Process. Information about each request including the originating renderer is tacked onto each URLRequest in the form of ExtraRequestInfo. See one of the functions in there such as ResourceDispatcherHost::OnResponseCompleted for how this is retrieved. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.org wrote: On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote: Thanks. But the picture in the document shows there is only 1 ResourceDispatcherHost and there are 2 Renderer Processes: http://dev.chromium.org/developers/design-documents/multi-process-architecture And the ResourceDispatcherHost has access to both Channels for each Renderer Process. Information about each request including the originating renderer is tacked onto each URLRequest in the form of ExtraRequestInfo. See one of the functions in there such as ResourceDispatcherHost::OnResponseCompleted for how this is retrieved. Right, information such as renderer process id is available, but there are no pointers to the ResourceMessageFilter in there. Using the process id, you could get to the RenderProcessHost (but only on the UI thread) and from there to the RMF. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Handling layout test expectations for failing tests
On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafaio...@chromium.org wrote: The end goal is to be in a state where we have near zero failing tests that are not for unimplemented features. And new failures from the merge get addressed within a week. Once we're at that point, would this new infrastructure be useful? I completely support infrastructure that sustainably supports us being at near zero failing tests (e.g. the rebaseline tool). All infrastructure/process has a maintenance cost though. True enough. There are at least two counterexamples that are worth considering. The first is that probably won't be at zero failing tests any time soon (where any time soon == next 3-6 months), and so there may be intermediary value. The second is that we have a policy of running every test, even tests for unimplemented features, and so we may catch regressions for the foreseeable future. That said, I don't know if the value will offset the cost. Hence the desire to run a couple of cheap experiments :) -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Would it be possible/reasonable to use distcc plus a farm of cross-compiler machines to let you do faster self-hosted builds? It's not the right solution, but in the past I've found it to sometimes be an easier path to take in the short term while you're working on fixing all the little problems. -scott On Fri, Aug 21, 2009 at 12:54 PM, Antoine Labourpi...@chromium.org wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Handling layout test expectations for failing tests
On Mon, Aug 24, 2009 at 1:52 PM, David Levinle...@google.com wrote: On Mon, Aug 24, 2009 at 1:37 PM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafaio...@chromium.org wrote: The end goal is to be in a state where we have near zero failing tests that are not for unimplemented features. And new failures from the merge get addressed within a week. Once we're at that point, would this new infrastructure be useful? I completely support infrastructure that sustainably supports us being at near zero failing tests (e.g. the rebaseline tool). All infrastructure/process has a maintenance cost though. True enough. There are at least two counterexamples that are worth considering. The first is that probably won't be at zero failing tests any time soon (where any time soon == next 3-6 months), and so there may be intermediary value. The second is that we have a policy of running every test, even tests for unimplemented features, and so we may catch regressions for the foreseeable future. That said, I don't know if the value will offset the cost. Hence the desire to run a couple of cheap experiments :) What do the cheap experiments entail? Key concern: If the cheapness is to put more work on the webkit gardeners, it isn't cheap at all imo. Cheap experiments == me snapshotting the results of tests I run periodically and comparing them. No work for anyone else. -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Handling layout test expectations for failing tests
On Mon, Aug 24, 2009 at 1:37 PM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafaio...@chromium.org wrote: The end goal is to be in a state where we have near zero failing tests that are not for unimplemented features. And new failures from the merge get addressed within a week. Once we're at that point, would this new infrastructure be useful? I completely support infrastructure that sustainably supports us being at near zero failing tests (e.g. the rebaseline tool). All infrastructure/process has a maintenance cost though. True enough. There are at least two counterexamples that are worth considering. The first is that probably won't be at zero failing tests any time soon (where any time soon == next 3-6 months), and so there may be intermediary value. The second is that we have a policy of running every test, even tests for unimplemented features, and so we may catch regressions for the foreseeable future. That said, I don't know if the value will offset the cost. Hence the desire to run a couple of cheap experiments :) What do the cheap experiments entail? Key concern: If the cheapness is to put more work on the webkit gardeners, it isn't cheap at all imo. -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
That still requires you to link locally, and I don't think we have any ARM machines with enough memory to do that. On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess sh...@chromium.org wrote: Would it be possible/reasonable to use distcc plus a farm of cross-compiler machines to let you do faster self-hosted builds? It's not the right solution, but in the past I've found it to sometimes be an easier path to take in the short term while you're working on fixing all the little problems. -scott On Fri, Aug 21, 2009 at 12:54 PM, Antoine Labourpi...@chromium.org wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Even with gold? On Mon, Aug 24, 2009 at 5:14 PM, Dean McNamee de...@chromium.org wrote: That still requires you to link locally, and I don't think we have any ARM machines with enough memory to do that. On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess sh...@chromium.org wrote: Would it be possible/reasonable to use distcc plus a farm of cross-compiler machines to let you do faster self-hosted builds? It's not the right solution, but in the past I've found it to sometimes be an easier path to take in the short term while you're working on fixing all the little problems. -scott On Fri, Aug 21, 2009 at 12:54 PM, Antoine Labourpi...@chromium.org wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
Oops...sorry for the misinformation...should have double checked before I said anything. :-) On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.org wrote: On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.org wrote: On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote: Thanks. But the picture in the document shows there is only 1 ResourceDispatcherHost and there are 2 Renderer Processes: http://dev.chromium.org/developers/design-documents/multi-process-architecture And the ResourceDispatcherHost has access to both Channels for each Renderer Process. Information about each request including the originating renderer is tacked onto each URLRequest in the form of ExtraRequestInfo. See one of the functions in there such as ResourceDispatcherHost::OnResponseCompleted for how this is retrieved. Right, information such as renderer process id is available, but there are no pointers to the ResourceMessageFilter in there. Using the process id, you could get to the RenderProcessHost (but only on the UI thread) and from there to the RMF. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Splitting First Run into it's own process
On Aug 24, 10:14 am, Evan Martin e...@chromium.org wrote: On Mon, Aug 24, 2009 at 10:08 AM, Jeremy Moskovichjer...@chromium.org wrote: * Due to some technical limitations with the FF libraries, we need to load them in a separate process. It also doesn't seem like a good idea to run code out of an arbitrary library in the main process. First run import on windows is run in a separate process. I wrote that before there was a need for a full blown utility process so the what I do is the browser process just spawns another browser-like process. That other process does the import + UI. The original process waits for confirmation of job done or for a crash. Coincidentally, I was just chatting with an Epiphany (WebKit+Gtk) developer about Firefox import and he too was lamenting how complicated it is to get this data out of Firefox. I had suggested a utility process might be the best way. (Note: not a complaint about Firefox; it's likely it's even harder to import this sort of data out of us...) * The first run dialog needs to be displayed very early on in the launch process since we need to display it before enabling stats and crash reporting so we can ask for the user's consent. The dialog is brought up before we've fully initialized Cocoa which is concerning in terms of it's interaction with the main app runloop, There are also UI artifacts - http://crbug.com/19643 As far as I know there are no such issues on Linux, so we don't have anybody working on doing this split. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?
On Aug 24, 7:42 pm, Peter Kasting pkast...@google.com wrote: Please file bugs on all these. Filed http://code.google.com/p/chromium/issues/detail?id=20086 , http://code.google.com/p/chromium/issues/detail?id=20160 , http://code.google.com/p/chromium/issues/detail?id=20164 , http://code.google.com/p/chromium/issues/detail?id=20165 and had already filed http://code.google.com/p/chromium/issues/detail?id=14745 and http://code.google.com/p/chromium/issues/detail?id=14739 . --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Access keys for Chrome menus, what do you prefer?
On Sat, Aug 22, 2009 at 6:18 PM, Evan Martine...@chromium.org wrote: On Fri, Aug 21, 2009 at 11:05 PM, zenikozen...@gmail.com wrote: If you e.g. use Alt+F for Chrome, you break quick access to Wikipedia's in-page search box. It's already the case that if a page grabs a key it overrides the Chrome shortcut, so this would actually work properly with no additional effort. this is normally true, but not true of alt+ combos. Alt is a special case (in ie as well as chrome, but not firefox). Don't ask me why. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
On Mon, Aug 24, 2009 at 1:53 PM, Scott Hesssh...@chromium.org wrote: Would it be possible/reasonable to use distcc plus a farm of cross-compiler machines to let you do faster self-hosted builds? It's not the right solution, but in the past I've found it to sometimes be an easier path to take in the short term while you're working on fixing all the little problems. -scott Interesting take, it might work. Like Dean mentions, we're talking about 512 MB boards (or even 256 MB), which in practice only means about 400 MB accessible to the OS. I don't know how gold performs on ARM. Antoine On Fri, Aug 21, 2009 at 12:54 PM, Antoine Labourpi...@chromium.org wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] error C2065: 'LOG_CHANNEL_PREFIXFATAL' : undeclared identifier
hi, all
While compiling chrome, I get an error :error C2065:
'LOG_CHANNEL_PREFIXFATAL' : undeclared identifier.
I locate this error at some codes just like:
static CommandLine* ForCurrentProcessMutable() {
---DCHECK(current_process_commandline_);
return current_process_commandline_;
}
I also find a lot of usages of DCHECK, so, what's wrong with it?
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] layout test dashboard
A first version of the layout test flakiness dashboard is up. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html Some of the key features: - updates roughly as quickly as the bots have run the tests (no post-processing, stdio parsing or crons) - sortable by any column include flakiness - builder + sort order permalinks (i.e. you can copy-paste URLs for a given builder + sort order) - highlights tests with missing expectations (i.e. the test passed, but is marked only as failing) - prints out test run times for tests that took 1 second - shows the expectations for a test on all platforms Taking a look at the dashboard, you can immediately see a couple things: 1. A bunch of cases where we currently have the missing expectations for a test. For example, LayoutTests/accessibility/plugin.html fails on Windows, but is only listed as failing on the Mac. 2. We have a few dozen very slow tests that considerably slow down how long the tests take to run. How do you get this awesomeness for UI tests, unittests, etc? It's actually *really* easy. Someone just needs to add something to the test runners for those test types that spits out JSON files in the right format and copies them to the appropriate place. Let me know if you're interested in adding support for a new test type. Known issues: 1. The JS that generates the page could stand to be faster. 2. The windows builders have a bunch of junk entries with windows style paths. Ignore them for now, they'll gradually fall off the end of the tests tracked by the dashboard. Only the tests with unix style paths should be looked at. If you have bugs or feature requests. Please file them at crbug.com and CC me. One feature request that I have is to also highlight cases where we list an expectation for a test that never happens (e.g. the test is listed as PASS CRASH FAIL, but has never crashed. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test dashboard
On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafai o...@chromium.org wrote: A first version of the layout test flakiness dashboard is up. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html AWESOME O RAMA Seriously, this has been critically needed, thanks tons. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test dashboard
Great work, dude. Seriously good stuff. I'll be digging through this tomorrow. Now, how do I change the theme on this thing? ;P :DG On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafaio...@chromium.org wrote: A first version of the layout test flakiness dashboard is up. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html Some of the key features: updates roughly as quickly as the bots have run the tests (no post-processing, stdio parsing or crons) sortable by any column include flakiness builder + sort order permalinks (i.e. you can copy-paste URLs for a given builder + sort order) highlights tests with missing expectations (i.e. the test passed, but is marked only as failing) prints out test run times for tests that took 1 second shows the expectations for a test on all platforms Taking a look at the dashboard, you can immediately see a couple things: A bunch of cases where we currently have the missing expectations for a test. For example, LayoutTests/accessibility/plugin.html fails on Windows, but is only listed as failing on the Mac. We have a few dozen very slow tests that considerably slow down how long the tests take to run. How do you get this awesomeness for UI tests, unittests, etc? It's actually *really* easy. Someone just needs to add something to the test runners for those test types that spits out JSON files in the right format and copies them to the appropriate place. Let me know if you're interested in adding support for a new test type. Known issues: The JS that generates the page could stand to be faster. The windows builders have a bunch of junk entries with windows style paths. Ignore them for now, they'll gradually fall off the end of the tests tracked by the dashboard. Only the tests with unix style paths should be looked at. If you have bugs or feature requests. Please file them at crbug.com and CC me. One feature request that I have is to also highlight cases where we list an expectation for a test that never happens (e.g. the test is listed as PASS CRASH FAIL, but has never crashed. Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
