[chromium-dev] Re: Try the magic_browzR
On Fri, Sep 12, 2008 at 1:13 PM, Ben Goodger (Google) [EMAIL PROTECTED]wrote: Over the past few weeks, I have been working to improve our browser window frames. This includes fixing a number of bugs that we've had for a while, consolidating code, and putting us in a better position to do certain things like respond to theme changes, etc. I've been doing this work under a command line flag, --magic_browzR (yes that's an underscore). If you're running dailies as your primary browser, please consider adjusting your shortcut to pass in this flag, Just to clarify, we don't yet produce nightlies (or dailies). There are continuous-build snapshots, and you can run your own builds, but there's nothing that's guaranteed even to launch, much less pass the automated tests. It's almost guaranteed that some of them will have horrible problems. You can live on the edge, but please be aware that that's what you're doing. :) - Pam and test and report issues that don't appear when you don't pass the flag. When you file an issue, please add the MagicBrowzr label. The frames will work on both XP and Vista. -Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: code style verification/formatting tool
I'll ask around and see if I can find one we can open-source. - Pam On Thu, Sep 18, 2008 at 7:06 AM, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi All, Does a tool currently exist for verifying and/or formatting source code based on the Google style guide? If not, has any thought been given to developing such a tool? Something like lint, but perhaps more modular, would be a great help to people who don't live and breathe Google style every day. We could then augment gcl to check code changes for style violations and warn/assist users in correcting any problems before the patches are uploaded for code review. Regards, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: code style verification/formatting tool
On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi Mark/Pam, On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai [EMAIL PROTECTED] wrote: Great question. We've been talking about open-sourcing something for this, but so far, we don't have anything yet. We do have something we use internally, but someone needs to go through it and clean up a few things before releasing it so that it runs well in the wild. When it does materialize, it'll show up on the style guide project (http://google-styleguide.googlecode.com/). Do you guys have a timeline in mind of when such a tool might become available? If there are potential code licensing/IP issues, perhaps it could be made available as a web-based service? For instance, something like the w3c validator but returning the corrections in either human-readable format or a format conducive to automation. Everybody's generally in support of open-sourcing the tool, and I don't anticipate any licensing conflicts; it's just a matter of finding the time to go through it. For what it's worth, setting it up as a web-based service wouldn't be any faster. More than days, less than months, would be my guess. - Pam Thanks, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: Review mail best practices
On Wed, Oct 8, 2008 at 7:31 PM, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi Peter, On Wed, Oct 8, 2008 at 8:06 PM, Peter Kasting [EMAIL PROTECTED] wrote: Two recommendations for folks participating in code reviews using Rietveld (codereview.chromium.org): (2) When reviewing a patch or responding to review comments, use the same Publish+Mail Comments link to converse. Tempting as it is, try to avoid using your mail client to respond to the comment emails directly, because that doesn't put your comments online on the issue where others can see and respond to them later. This helps avoid strange half-broken threads when someone else tries to look over and comment on an issue after it's been in review for a while. Feel free to share other best practices you've encountered. One small thing that makes responding in Publish+Mail Comments a bit awkward is the width of the message text field. Could we perhaps increase this to something closer to the gmail message field width? Also, the values in the reviewers field default to just the user name(s). When I submit the message I get an error saying that the reviewer(s) don't exist, or something to that effect. I need to add @chromium.org to each one before it will let me send. Right now all the reviewers have chromium.org accounts, but that may not always be the case. - Pam PK Regards, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Stuck on build 152.1
I'm on the dev channel, but still running 152.1. This is the one that had broken manual update check, you'll recall -- but apparently I haven't been auto-updated either. What can I provide to help find the problem? - Pam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Partial buildbot downtime Saturday midday
The buildbot will be partly unavailable midday (PDT, GMT-7) tomorrow (Saturday, October 18). The whole thing will be restarted at least once (more only if something goes wrong), after which most of the performance graphs will be missing their historical data for a while. I'll be working to restore the data until they're all back, which should be by Saturday evening at the latest. There won't be any long-term loss of historical information. Since this is only a partial downtime, I'll only close the tree for the restart, and I won't schedule the maintenance more precisely. (It depends on how my Saturday goes.) Please try not to land things that are likely to have performance impact until everything's up again. - Pam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: get_chromium - Automatic installation, synchronization and building of Google Chrome from source
Just to be clear, this is configuring, downloading, and building Chromium, not Google Chrome. The difference is mainly the icons, strings, and trademark. - Pam On Thu, Oct 30, 2008 at 8:20 AM, SkyLined [EMAIL PROTECTED] wrote: Hi all, Because I needed ToT builds of Chrome on multiple machines and because I like automation, I created a script that can automatically get you set up to build Chrome. The aim of this project is to require only one manual download to get set up. It is pretty much feature complete and I need some people to test this and comment on it. Here's what it does: - check if your machine meets the requirements for building Chrome from source (VS2005 and Windows SDK installed) - download and unpack depot tools - download and unpack source tarball - sync Chromium source - build Debug/Release Google Chrome - clean the build environment and fix a number of issues. - detect known build errors and provide useful tips to solve them. (Basically everything on http://dev.chromium.org/developers/how-tos/getting-started, with a few added features.) I am looking for people that are willing to give it a try and give feedback. WARNING: This script is in development and may not function properly which could potentially cause damage to your system, which will be your problem (but I sure hope it does not). It's not officially supported in any way, so if you have a problem, I cannot guarantee you will receive help in fixing it. WARNING: The script downloads scripts and executables over HTTP connections and executes them. As with any such download, there is always a risk of an attacker modifying the executables in transit and taking over your system when they are executed. (Though I highly doubt it) Now that we have that out of the way, here's how to get started: 1) Download http://skypher.com/SkyLined/download/get_chromium/get_chromium.cmd 2) Run it. It will ask you a few questions about where you want your source installed and such and then automatically download and unpack everything. This includes downloading md5sum.exe and 7za.exe for checking downloads and unpacking them. If automatic downloading and/or unpacking fails, it should fall back to asking you to do it manually before it continues with the installation. Once everything is installed, it will sync source and build Debug Google Chrome. PS. It has a crude automatic update system that checks if there is a new version every time you run it. That way, you can benefit from bug fixes and updates. This is specifically helpful for the known build errors problem solving feature; when there is a known issue, I can update this and everybody that encounters it will be alerted to the potential fix. Cheers, SkyLined --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Consolidating our platform-specific layout test results
On Thu, Nov 13, 2008 at 4:57 PM, Pam Greene [EMAIL PROTECTED] wrote: Today I got our custom (platform-specific) layout test results mostly straightened out. (Apologies for the large-ish sync that will cause.) If you re-baseline tests, please keep reading. We no longer keep kjs or common results. The layout_test_results directory will be gone within the hour. All platform baselines, whether they're text, images, or checksums, are now in webkit/layout_tests/platform/chromium-win/. (We can create chromium-mac/ and others as needed.) Eventually I, or someone else, will adjust run_webkit_tests.py so its --new-baseline option puts files into the platform-specific directory by default, but for now, please remember to specify the new path. Eventually happened today. The --new-baseline option to run_webkit_tests.py (or .sh, by extension -- no pun intended) now places the newly generated results in the platform-specific directory, with no directory needed on the command line. If you're running pixel tests -- which is now the default, unless you specify --no-pixel-tests -- it puts both text and image results there. - Pam - Pam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: tree status in gmail
More details: At the top right of your gmail window, click the green flask icon. If you have no flask icon, click Settings, then the Labs tab.. Scroll down near the bottom and enable the Add any gadget by URL experiment. Click the Save Changes button at the bottom. Gmail will reload. Click Settings again, then the new Gadgets tab. Paste Ojan's nifty URL in and click Add. Hey Ojan, how about letting me pick one of the three sets of builders and showing their green/red boxes below the status header? - Pam On Thu, Nov 20, 2008 at 11:08 AM, Ojan Vafai [EMAIL PROTECTED] wrote: Sigh. Yet another email I sent to the wrong address. Shows the state of your tree in gmail. -- Forwarded message -- From: Ojan Vafai [EMAIL PROTECTED] Date: Fri, Oct 31, 2008 at 10:02 AM Subject: tree status in gmail To: chromium-dev@googlegroups.com Inspired by the V8 team, I've made a gadget that shows our tree's status. Now that you can embed gadgets in gmail, you can add this one by URL. http://hosting.gmodules.com/ig/gadgets/file/111904373629053571529/chromium-status.xml Lemme know if it's useful. I can definitely make it way more awesomer. Ojan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: [Chrome-team] Running unit test on a virgin install
It's almost certainly in need of some maintenance, but there's a smoketests.py script in http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/test/smoketests.py?view=log When it's properly up to date, it runs any or all of the tests, using the same command lines as the buildbot, skipping any whose data is not available. But the reason that script isn't maintained is that as far as I know, nobody uses it. In practice, I rather suspect that developers run at most any unit tests that look directly applicable, and let the buildbots run the rest for them. The tryserver can help here too. Given that a full run of every test takes well over an hour, that's understandable, if not theoretically ideal. - Pam On Sat, Nov 22, 2008 at 9:52 AM, Marc-André Decoste [EMAIL PROTECTED] wrote: Thanks for the info. But I sitll wonder: How does an external developer identify the tests that CAN (and should) be run before submitting a patch? BYE MAD 2008/11/22 Pam Greene [EMAIL PROTECTED] The long-term goal is to create new page-cycler data, through a combination of research (what pages are representative?), mangling (replacing data that we don't have permission to redistribute with generic images and lorem ipsum text), and evangelism (asking page owners for permission). In the meantime, there are a few tests that can't be run externally, page-cyclers among them. (As an aside, the page-cycler is pretty far from a unit test in the conventional sense of the phrase. The unit tests are mostly runnable; the large-scale tests not as universally so.) - Pam On Sat, Nov 22, 2008 at 9:07 AM, Marc-André Decoste [EMAIL PROTECTED] wrote: So what are we expecting the external partner to do to run as many unit test as possible and know which ones? Thanks! BYE MAD 2008/11/22 Marc-Antoine Ruel [EMAIL PROTECTED] [+chromium-dev] Please look at http://build.chromium.org/buildbot/waterfall/builders/Vista%20Perf/builds/1064/steps/page_cycler_moz/logs/stdio for an example use. On Sat, Nov 22, 2008 at 1:42 AM, Marc-Andre Decoste [EMAIL PROTECTED] wrote: Salut, sorry if I missed something in the setup documentation, but while I followed it the best I can, I'm not able to run some unit tests because the data folder isn't in my svn repository. For example, when I run the src\chrome\Debug\page_cycler_tests.exe test, it looks for file:///C:/src/chromium/src/data/page_cycler/moz/start.html?iterations=2auto=1 and can't find it, there is to data folder under c:/src/chromium/src. Did I miss anything? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: [Chrome-team] Running unit test on a virgin install
Sure, that sounds like a great option to add to the smoketests script. You can come very close now with --nowebkit --nopage-cycler. - Pam On Sat, Nov 22, 2008 at 10:03 AM, Marc-André Decoste [EMAIL PROTECTED] wrote: OK, cool, thanks... This does answer my question now :-) The problem is that newbies are not realy sure what tests are actually applicable, though they are probably willing to wait an hour for the whole set of tests to run since they must get validation anyway, and it may take as long to get it as it takes to get the tests ran, especially when doing it from other time zones... I think it would be worth it to have a script that allows us to at least run all the small tests. I'll see if I can do something there once I get more familiar with all this... BYE MAD 2008/11/22 Pam Greene [EMAIL PROTECTED] It's almost certainly in need of some maintenance, but there's a smoketests.py script in http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/test/smoketests.py?view=log When it's properly up to date, it runs any or all of the tests, using the same command lines as the buildbot, skipping any whose data is not available. But the reason that script isn't maintained is that as far as I know, nobody uses it. In practice, I rather suspect that developers run at most any unit tests that look directly applicable, and let the buildbots run the rest for them. The tryserver can help here too. Given that a full run of every test takes well over an hour, that's understandable, if not theoretically ideal. - Pam On Sat, Nov 22, 2008 at 9:52 AM, Marc-André Decoste [EMAIL PROTECTED] wrote: Thanks for the info. But I sitll wonder: How does an external developer identify the tests that CAN (and should) be run before submitting a patch? BYE MAD 2008/11/22 Pam Greene [EMAIL PROTECTED] The long-term goal is to create new page-cycler data, through a combination of research (what pages are representative?), mangling (replacing data that we don't have permission to redistribute with generic images and lorem ipsum text), and evangelism (asking page owners for permission). In the meantime, there are a few tests that can't be run externally, page-cyclers among them. (As an aside, the page-cycler is pretty far from a unit test in the conventional sense of the phrase. The unit tests are mostly runnable; the large-scale tests not as universally so.) - Pam On Sat, Nov 22, 2008 at 9:07 AM, Marc-André Decoste [EMAIL PROTECTED] wrote: So what are we expecting the external partner to do to run as many unit test as possible and know which ones? Thanks! BYE MAD 2008/11/22 Marc-Antoine Ruel [EMAIL PROTECTED] [+chromium-dev] Please look at http://build.chromium.org/buildbot/waterfall/builders/Vista%20Perf/builds/1064/steps/page_cycler_moz/logs/stdio for an example use. On Sat, Nov 22, 2008 at 1:42 AM, Marc-Andre Decoste [EMAIL PROTECTED] wrote: Salut, sorry if I missed something in the setup documentation, but while I followed it the best I can, I'm not able to run some unit tests because the data folder isn't in my svn repository. For example, when I run the src\chrome\Debug\page_cycler_tests.exe test, it looks for file:///C:/src/chromium/src/data/page_cycler/moz/start.html?iterations=2auto=1 and can't find it, there is to data folder under c:/src/chromium/src. Did I miss anything? Thanks! BYE MAD --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Sending accumulated new layout tests to WebKit
Part of our effort to move to WebKit tip-of-tree and participate fully in the WebKit community is to contribute the nearly 80 new layout tests we wrote before Google Chrome and Chromium were public. You can see our progress here: http://tinyurl.com/cr-tests or http://spreadsheets.google.com/ccc?key=piGkUUMLW-PNUzuhTCzm4NQ Many of the tests were written some time ago, when we weren't very knowledgeable about layout-test tools and style yet, so they will need some fixup before they're ready for submission. That's complicated by the fact that the bugs they test have all been fixed, so we have to be careful not to spoil the tests. Have a Mac? Want to help? Please feel free to sign up for a test or two. You'll need a Mac running Leopard and the free developer tools (Xcode), basic knowledge of HTML and JavaScript (possibly a little more advanced for some tests), a WebKit Bugzilla account, and willingness to respond to the WebKit review process. You don't need a Chromium checkout or even a Windows machine. The second page of that spreadsheet (click How To at the bottom) has more details and links. You can also ask me any questions, here or on #chromium. - Pam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bookmark menu
On Mon, Dec 15, 2008 at 5:02 PM, Bizzeh killallthehum...@gmail.com wrote: no, nothing i can give as a spreadsheet, hard fact, just what i have heard from people. to keep me from the effort of starting an argument that i wont win, because whoever's mind it is that decides this has already been made up, and this has less chance of getting in than the logo has of being changed to a photograph of hitler... *blink* I'd like to think the group is more open-minded than that. We just like to see something to back up claims about what is and isn't common. For example, I use the bookmark toolbar many times a day, and I never click Other bookmarks. But I recognize that I might just be an outlier, so I'd like to see broader data. - Pam On 16 Dec, 00:55, Peter Kasting pkast...@google.com wrote: On Mon, Dec 15, 2008 at 4:50 PM, Darren Horrocks killallthehum...@gmail.com wrote: and as most people will only use the bookmark bar to access the other bookmarks button, Do you have data to back up this claim? PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: bugtracker cleanup
Thanks, Paweł. I haven't looked at all those bugs, but I'm sure your changes were appropriate, and this kind of cleanup is very helpful! - Pam 2008/12/29 Paweł Hajdan Jr. phajdan...@chromium.org: Before Christmas I asked on #chromium about doing a small cleanup. Today I reviewed unconfirmed bugs, and removed duplicates, changed Area- label to be more specific etc. I generally followed the rule to only make quite obvious changes. In case you'd like to review my changes, I attach a list of changed bugs at the end of this message. Paweł http://code.google.com/p/chromium/issues/detail?id=1651 http://code.google.com/p/chromium/issues/detail?id=5888 http://code.google.com/p/chromium/issues/detail?id=333 http://code.google.com/p/chromium/issues/detail?id=355 http://code.google.com/p/chromium/issues/detail?id=426 http://code.google.com/p/chromium/issues/detail?id=471 http://code.google.com/p/chromium/issues/detail?id=3873 http://code.google.com/p/chromium/issues/detail?id=1915 http://code.google.com/p/chromium/issues/detail?id=3354 http://code.google.com/p/chromium/issues/detail?id=5229 http://code.google.com/p/chromium/issues/detail?id=4622 http://code.google.com/p/chromium/issues/detail?id=4480 http://code.google.com/p/chromium/issues/detail?id=496 http://code.google.com/p/chromium/issues/detail?id=2644 http://code.google.com/p/chromium/issues/detail?id=566 http://code.google.com/p/chromium/issues/detail?id=684 http://code.google.com/p/chromium/issues/detail?id=1378 http://code.google.com/p/chromium/issues/detail?id=769 http://code.google.com/p/chromium/issues/detail?id=848 http://code.google.com/p/chromium/issues/detail?id=943 http://code.google.com/p/chromium/issues/detail?id=2075 http://code.google.com/p/chromium/issues/detail?id=2119 http://code.google.com/p/chromium/issues/detail?id=3566 http://code.google.com/p/chromium/issues/detail?id=3635 http://code.google.com/p/chromium/issues/detail?id=4756 http://code.google.com/p/chromium/issues/detail?id=4770 http://code.google.com/p/chromium/issues/detail?id=4781 http://code.google.com/p/chromium/issues/detail?id=4924 http://code.google.com/p/chromium/issues/detail?id=4926 http://code.google.com/p/chromium/issues/detail?id=4996 http://code.google.com/p/chromium/issues/detail?id=5484 http://code.google.com/p/chromium/issues/detail?id=5513 http://code.google.com/p/chromium/issues/detail?id=5902 http://code.google.com/p/chromium/issues/detail?id=5717 http://code.google.com/p/chromium/issues/detail?id=5781 http://code.google.com/p/chromium/issues/detail?id=5803 http://code.google.com/p/chromium/issues/detail?id=5854 http://code.google.com/p/chromium/issues/detail?id=5864 http://code.google.com/p/chromium/issues/detail?id=5870 http://code.google.com/p/chromium/issues/detail?id=5879 http://code.google.com/p/chromium/issues/detail?id=5889 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Proposal: enforcing unit testing in gcl
We don't have very good unit test coverage (in the broad sense, including
ui_tests, test_shell_tests, etc.) for our code. We've always had a policy
that any new code had to have an associated test, but historically we've
been really bad about enforcing it.
As a way to help contributors and reviewers remember to add tests, here's a
proposal to have gcl report when they are (or might be) missing. It's a
very rough guess now, and will probably need some refinement as we see what
it misses and where its false positives are too annoying.
What changes might need tests?
- Any new source file (.cc, .cpp, .m, or .mm), or
- Any new method added to a source or header (.h file
- A new method is identified by a flush-left non-comment line that has
( somewhere before the next flush-left line and either ends with
{ or has {
at the start of the next flush-left line.
What counts as a test?
- Any change to any code file whose name ends in test.* or tests.*
- This is very rough, but at least it shows that the contributor
thought about testing when making the patch
What do we do if we don't find a test?
- On 'gcl change', report a warning to the user
- On 'gcl upload', add a warning to the change description so the
reviewer sees it too
- Add an option to override this
Future possibilities
- Is it worth restricting the check to only public or protected methods?
- Since any real change ought to either fix a bug or add a feature that
should be tested, warn whenever there are no changes to any tests (including
layout tests) or a test_lists file, even when no source files or methods
were added. Alas, this is probably not feasible since we don't keep layout
tests in the same repository
- Rather than adding a warning to the change description, it'd be nice to
have a separate warning in the review app, so it showed up no matter what
and the path author didn't have to override anything. But since we want the
warning in client-side 'gcl change' anyway, for now we'll keep it simple and
trust people.
Comments and volunteers welcome.
- 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: Proposal: enforcing unit testing in gcl
Yes, there's an override option in the proposal below. It'll still give a
warning on 'gcl change', but that's harmless.
- Pam
On Mon, Jan 5, 2009 at 4:08 PM, Ben Goodger (Google) b...@chromium.orgwrote:
I think you also need a way to override this in some instances, since
there are methods (especially in views/ and the UI) for which there is
no simple way to verify correctness of an implementation in code -
e.g. a function that paints a series of bitmaps at specific locations.
(Nor would we really want to invest in one, since visual designs
evolve continuously over time).
-Ben
On Mon, Jan 5, 2009 at 3:25 PM, Pam Greene p...@chromium.org wrote:
We don't have very good unit test coverage (in the broad sense, including
ui_tests, test_shell_tests, etc.) for our code. We've always had a
policy
that any new code had to have an associated test, but historically we've
been really bad about enforcing it.
As a way to help contributors and reviewers remember to add tests, here's
a
proposal to have gcl report when they are (or might be) missing. It's a
very rough guess now, and will probably need some refinement as we see
what
it misses and where its false positives are too annoying.
What changes might need tests?
Any new source file (.cc, .cpp, .m, or .mm), or
Any new method added to a source or header (.h file
A new method is identified by a flush-left non-comment line that has (
somewhere before the next flush-left line and either ends with { or has {
at
the start of the next flush-left line.
What counts as a test?
Any change to any code file whose name ends in test.* or tests.*
This is very rough, but at least it shows that the contributor thought
about
testing when making the patch
What do we do if we don't find a test?
On 'gcl change', report a warning to the user
On 'gcl upload', add a warning to the change description so the reviewer
sees it too
Add an option to override this
Future possibilities
Is it worth restricting the check to only public or protected methods?
Since any real change ought to either fix a bug or add a feature that
should be tested, warn whenever there are no changes to any tests
(including
layout tests) or a test_lists file, even when no source files or methods
were added. Alas, this is probably not feasible since we don't keep
layout
tests in the same repository
Rather than adding a warning to the change description, it'd be nice to
have
a separate warning in the review app, so it showed up no matter what and
the
path author didn't have to override anything. But since we want the
warning
in client-side 'gcl change' anyway, for now we'll keep it simple and
trust
people.
Comments and volunteers welcome.
- 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: V8Bindings_prebuild slowness
On Fri, Jan 9, 2009 at 3:37 PM, Darin Fisher da...@chromium.org wrote: On Sun, Jan 4, 2009 at 5:44 PM, t...@chromium.org wrote: On Sun, 4 Jan 2009, Brett Wilson wrote: On Sun, Jan 4, 2009 at 1:23 PM, Darin Fisher da...@chromium.org wrote: This problem could also be solved by ignoring DerivedSources.make, and instead just add the source files to the vcproj. Then write a custom .rules file for each file type that runs the appropriate batch command to create the generated file. Then, dependency tracking would work just as it does for .cpp files. Well, but you'd still have the slowness of spawing perl hundreds of times. I'm not sure that would speed up the build at all (though it would improve the dependency management). But you would only pay it once. Using native vcproj files may get the dependencies right and maybe you wouldn't need to do a full rebuild after each sync then. Or maybe I put too much faith in MSVC's dependency management. Right. This is what I was thinking too. I do clobber builds primarily (only?) because of issues related to DerivedSources. Our DerivedSources.make is already so tremendously out of sync with the one upstream that there doesn't seem to be much point in using it. I agree. It's not used in the scons build which properly tracks dependencies so the files are only generated once. Would Incredibuild be able to parallelize the perl scripts or does it only know how to parallelize c++ compiles? That's a great question :) I suspect it only runs those locally. Without an additional extension license, only locally. But if it only had to do it once, that'd still be a big help. Alternatively, if we find we still need to speed clobber builds and are willing to move away from DerivedSources.make, I'd expect that only launching perl once rather than 200+ times -- just move the do this for every file in this long list from make into perl -- would provide a dramatic speedup. - Pam -Darin --~--~-~--~~~---~--~~ 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: Problems compiling with xcode 3.1
That broke archives/, which is a link to tarball/ but also contains the depot_tools. I renamed tarball.old/ back to tarball/ and renamed chromium.tgz to chromium.old.tgz instead. Also I'll upload a new tarball today. - Pam On Tue, Jan 13, 2009 at 6:21 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: I renamed tarball/ to tarball.old/ until someones creates new tarballs. On Tue, Jan 13, 2009 at 9:06 AM, Mike Pinkerton pinker...@chromium.org wrote: Hrm, I'm not sure anyone has tried the tarball in a while. I think the last person who did said it didn't work. What about if you pull from scratch from svn? Does it still happen? On Mon, Jan 12, 2009 at 7:40 PM, kc kec...@gmail.com wrote: I actually did use gclient sync after untarring. but i will give your suggestion a try also. On Jan 12, 7:21 pm, Jon j...@chromium.org wrote: You probably used svn directly instead of gclient. http://dev.chromium.org/developers/how-tos/get-the-code I think you can recover by going into your repository directory (not into src) and using: gclient confighttp://src.chromium.org/svn/trunk/src Then use: gclient sync Then always use gclient sync instead of svn sync. Jon On Mon, Jan 12, 2009 at 9:19 AM, kc kec...@gmail.com wrote: Hi, I am kind of new to this. Could someone pls kindly help provide me with some guidance? I ran into tons and tons of compilation errors with xcode 3.1. (I downloaded the tarball base and did a sync while tree is opened). The first error I ran into said it couldnt find the header file carbon/carbon.h in an include of one of the cc files. What I noticed is that Carbon/Carbon.h (Upper Case) will rid of that particular error. Lot of errors look like it doesnt know how to handle header files. I speculate one can fix this in the Build Settings (under Project Edit Project Settings). I went there and under the Build tab, I am wondering why it only contained user defined settings, and missing all the others (eg. Compiler Version, Search Paths). Thanks. -- 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: Problems compiling with xcode 3.1
Windows doesn't come with svn installed. Windows users want to download the depot_tools so they have svn. - Pam On Tue, Jan 13, 2009 at 12:14 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Yes but I fixed the wiki link to directly pull from svn. I don't see any reason to keep at copy of depot_tools at that place ? On Tue, Jan 13, 2009 at 2:31 PM, Pam Greene p...@chromium.org wrote: That broke archives/, which is a link to tarball/ but also contains the depot_tools. I renamed tarball.old/ back to tarball/ and renamed chromium.tgz to chromium.old.tgz instead. Also I'll upload a new tarball today. - Pam On Tue, Jan 13, 2009 at 6:21 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I renamed tarball/ to tarball.old/ until someones creates new tarballs. On Tue, Jan 13, 2009 at 9:06 AM, Mike Pinkerton pinker...@chromium.org wrote: Hrm, I'm not sure anyone has tried the tarball in a while. I think the last person who did said it didn't work. What about if you pull from scratch from svn? Does it still happen? On Mon, Jan 12, 2009 at 7:40 PM, kc kec...@gmail.com wrote: I actually did use gclient sync after untarring. but i will give your suggestion a try also. On Jan 12, 7:21 pm, Jon j...@chromium.org wrote: You probably used svn directly instead of gclient.http://dev.chromium.org/developers/how-tos/get-the-code I think you can recover by going into your repository directory (not into src) and using: gclient confighttp://src.chromium.org/svn/trunk/src Then use: gclient sync Then always use gclient sync instead of svn sync. Jon On Mon, Jan 12, 2009 at 9:19 AM, kc kec...@gmail.com wrote: Hi, I am kind of new to this. Could someone pls kindly help provide me with some guidance? I ran into tons and tons of compilation errors with xcode 3.1. (I downloaded the tarball base and did a sync while tree is opened). The first error I ran into said it couldnt find the header file carbon/carbon.h in an include of one of the cc files. What I noticed is that Carbon/Carbon.h (Upper Case) will rid of that particular error. Lot of errors look like it doesnt know how to handle header files. I speculate one can fix this in the Build Settings (under Project Edit Project Settings). I went there and under the Build tab, I am wondering why it only contained user defined settings, and missing all the others (eg. Compiler Version, Search Paths). Thanks. -- 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: Problems compiling with xcode 3.1
The tarball is made with svn 1.4, so it should be OK. - Pam On Tue, Jan 13, 2009 at 1:09 PM, Mike Pinkerton pinker...@chromium.orgwrote: Also, the default svn on Mac is 1.4. If someone on windows/linux pulls a tree with 1.5, will that affect the ability of the tarball to update? On Tue, Jan 13, 2009 at 3:14 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Yes but I fixed the wiki link to directly pull from svn. I don't see any reason to keep at copy of depot_tools at that place ? On Tue, Jan 13, 2009 at 2:31 PM, Pam Greene p...@chromium.org wrote: That broke archives/, which is a link to tarball/ but also contains the depot_tools. I renamed tarball.old/ back to tarball/ and renamed chromium.tgz to chromium.old.tgz instead. Also I'll upload a new tarball today. - Pam On Tue, Jan 13, 2009 at 6:21 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I renamed tarball/ to tarball.old/ until someones creates new tarballs. On Tue, Jan 13, 2009 at 9:06 AM, Mike Pinkerton pinker...@chromium.org wrote: Hrm, I'm not sure anyone has tried the tarball in a while. I think the last person who did said it didn't work. What about if you pull from scratch from svn? Does it still happen? On Mon, Jan 12, 2009 at 7:40 PM, kc kec...@gmail.com wrote: I actually did use gclient sync after untarring. but i will give your suggestion a try also. On Jan 12, 7:21 pm, Jon j...@chromium.org wrote: You probably used svn directly instead of gclient.http://dev.chromium.org/developers/how-tos/get-the-code I think you can recover by going into your repository directory (not into src) and using: gclient confighttp://src.chromium.org/svn/trunk/src Then use: gclient sync Then always use gclient sync instead of svn sync. Jon On Mon, Jan 12, 2009 at 9:19 AM, kc kec...@gmail.com wrote: Hi, I am kind of new to this. Could someone pls kindly help provide me with some guidance? I ran into tons and tons of compilation errors with xcode 3.1. (I downloaded the tarball base and did a sync while tree is opened). The first error I ran into said it couldnt find the header file carbon/carbon.h in an include of one of the cc files. What I noticed is that Carbon/Carbon.h (Upper Case) will rid of that particular error. Lot of errors look like it doesnt know how to handle header files. I speculate one can fix this in the Build Settings (under Project Edit Project Settings). I went there and under the Build tab, I am wondering why it only contained user defined settings, and missing all the others (eg. Compiler Version, Search Paths). Thanks. -- Mike Pinkerton Mac Weenie pinker...@google.com -- 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: Problems compiling with xcode 3.1
OK, I see what you mean: the link now points to the base copy of depot_tools.zip. So no, I don't think we need these copies of depot_tools in archives/ anymore. But it's still better to rename the tgz file than the directory if you want to mark it as outdated; otherwise people's links break for less-obvious reasons. Hopefully none of this will matter soon, as the tarball will be updated more often. - Pam On Tue, Jan 13, 2009 at 1:21 PM, Pam Greene p...@chromium.org wrote: Windows doesn't come with svn installed. Windows users want to download the depot_tools so they have svn. - Pam On Tue, Jan 13, 2009 at 12:14 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Yes but I fixed the wiki link to directly pull from svn. I don't see any reason to keep at copy of depot_tools at that place ? On Tue, Jan 13, 2009 at 2:31 PM, Pam Greene p...@chromium.org wrote: That broke archives/, which is a link to tarball/ but also contains the depot_tools. I renamed tarball.old/ back to tarball/ and renamed chromium.tgz to chromium.old.tgz instead. Also I'll upload a new tarball today. - Pam On Tue, Jan 13, 2009 at 6:21 AM, Marc-Antoine Ruel mar...@chromium.org wrote: I renamed tarball/ to tarball.old/ until someones creates new tarballs. On Tue, Jan 13, 2009 at 9:06 AM, Mike Pinkerton pinker...@chromium.org wrote: Hrm, I'm not sure anyone has tried the tarball in a while. I think the last person who did said it didn't work. What about if you pull from scratch from svn? Does it still happen? On Mon, Jan 12, 2009 at 7:40 PM, kc kec...@gmail.com wrote: I actually did use gclient sync after untarring. but i will give your suggestion a try also. On Jan 12, 7:21 pm, Jon j...@chromium.org wrote: You probably used svn directly instead of gclient.http://dev.chromium.org/developers/how-tos/get-the-code I think you can recover by going into your repository directory (not into src) and using: gclient confighttp://src.chromium.org/svn/trunk/src Then use: gclient sync Then always use gclient sync instead of svn sync. Jon On Mon, Jan 12, 2009 at 9:19 AM, kc kec...@gmail.com wrote: Hi, I am kind of new to this. Could someone pls kindly help provide me with some guidance? I ran into tons and tons of compilation errors with xcode 3.1. (I downloaded the tarball base and did a sync while tree is opened). The first error I ran into said it couldnt find the header file carbon/carbon.h in an include of one of the cc files. What I noticed is that Carbon/Carbon.h (Upper Case) will rid of that particular error. Lot of errors look like it doesnt know how to handle header files. I speculate one can fix this in the Build Settings (under Project Edit Project Settings). I went there and under the Build tab, I am wondering why it only contained user defined settings, and missing all the others (eg. Compiler Version, Search Paths). Thanks. -- 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: 2-day merges and the cleanup schedule
When fixing layout tests only means re-baselining, that's easy. But sometimes they break (or new ones fail) for deeper reasons, and the person doing the merge may not be the right one to make the fix (or may not be able to fix them in one day). So perhaps clean up in this context means re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. - Pam On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote: I'm currently doing a 2-day merge rotation.As part of this, various layout tests are regressing or getting added that I'm inserting into the tests_fixable list. But, like every other layout test fixer, after my merges are done, I'll finally go back to my old work and not think about it any more. This is how we get a monotonically increasing list of broken tests at the end of the tests fixable. I'm pretty certain this happens faster than the tests are getting fixed because nobody wants to fix them. I'm sort of tempted to just fix the ones my merge broke now, but that will put me behind for my next merge, so I don't do that. I propose a different rotation schedule for WebKit merges. You would do one day of merges, and the next day you would have to clean up all the regressed and new layout tests your merge introduced. The layout tests usually aren't that hard, so it normally wouldn't take the whole day. This way we can be in a good steady state of WebKit merges. It should also have a big advantage for fixing the broken tests since the things that changed, the build numbers involved, etc. are still fresh in the merger's head, and it won't be like approaching a random layout test from the list with no context. The disadvantage of doing this is that we have to find people to do the merges faster (we should probably formalize the schedule), and you'll lose some advantage the second day of having all the instructions and gotchas of the merge fresh in your mind. I was thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but that seems too heavyweight for the people volunteering to do this. Anybody have any comments? 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: 2-day merges and the cleanup schedule
On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote: On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org wrote: When fixing layout tests only means re-baselining, that's easy. But sometimes they break (or new ones fail) for deeper reasons, and the person doing the merge may not be the right one to make the fix (or may not be able to fix them in one day). So perhaps clean up in this context means re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. I think our tendency to file bugs and forget about it is part of the problem. I am at least as guilty as anybody else. I think the merger should have the responsibility to get their regressions fixed. They will have to talk with some other people to get input. If they aren't the right person to fix a problem, it should be their responsibility as part of the cleanup to make sure that the right person has been assigned to it and is actually working on it. Taking responsibility, check. Making sure someone is assigned, check. Fixing tricky regressions yourself may not be the most efficient use of time, and would be a strong deterrent to volunteer for a merge. Merging isn't much fun; fixing layout tests isn't much fun. Let's spread the pain where suitable, rather than piling it all on the person who volunteers for one part. In fact, I'd ask the merger to fix the easy problems (tests changed, new tests need baselines) before committing the merge. When people are assigned merge bugs, they should be treated as important regressions and prioritized over other work. We currently had a whole lot of layout tests bugs filed that are getting no love. The only way to not keep getting behind is to be much more proactive. Absolutely. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. I'm proposing overlapping so we merge every day. I think there is an advantage in having the same person who did the merge do the fixing. This hopefully also makes the merge less tedious since you have different tasks your two days. Sounds fine. People can always trade if they want. - Pam 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: Chromium source tarball now being produced nightly
Yes... build.chromium.org in general is having some problems. The buildbot waterfall is back, but other pieces are still being worked on. It should be better soon. - Pam On Wed, Jan 21, 2009 at 3:46 PM, Tommi to...@chromium.org wrote: fyi - both tarball pages are returning a 502 server error right now. 2009/1/20 Pam Greene p...@chromium.org A new tarball (.tgz file) of the Chromium source is now being created and uploaded each night. Depending on how long the process takes, it should be available around 2:30 AM Pacific time (currently UTC-8). The tarballs are now versioned to avoid the risk of breaking downloads that start in the middle of a new upload, but a redirecting download page will always point to the latest version. To download the file directly, visit http://build.chromium.org/buildbot/archives/chromium_tarball.html To see the available versions, visit http://build.chromium.org/buildbot/archives/ Note that as always, the tarball is produced without considering whether the tree is stable and building properly, so it's wise to run a gclient sync to get to the latest green revision before trying to build. See http://dev.chromium.org/developers/how-tos/get-the-code - 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: Building with VS2008 the smart way.
On Thu, Jan 22, 2009 at 8:09 AM, noemata ma...@noemata.org wrote: After ignoring most of the provided build instructions and thus having great success with a failed build, I switched to following the build docs rigidly and wound up with this: == Rebuild All: 152 succeeded, 0 failed, 1 skipped == Chromium built with VS2008 is alive and kicking on my system. Very impressive for such a complex build process. I was also impressed with the quick responses I got to my rather dumb flailing build attempt. Nice! And thanks for one of the best examples of structuring and building a complex software solution!! My only small query to the process is curiousity about the fact that the tar archive has to be synced in order to build correctly. It shouldn't be too much trouble to hoist online a fully working build setup as a tar archive and gather a history of such archives?? True enough. Please file that as a feature request at http://crbug.com/ . For historical reference, until this week the tar archive dated from October, so even having a daily copy shows progress. :) The next step, as you note, is to pull a green checkout rather than whatever happens to be in the tree at 2 AM. We do have a record of the last working revision number for each day; the latest is noted in http://build.chromium.org/buildbot/continuous/LATEST/REVISION . Cheers, - Pam (Built on Vista with latest SDK and a non SP1 version of VS2008, also had previously installed WTL8) --~--~-~--~~~---~--~~ 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: gcl warnings about missing build system updates
The new gcl warning for missing unit tests currently only appears on 'gcl change', but the plan is to set up a generic alert system so gcl can tell Rietveld to show whatever warnings it wants. This would fit well with both of those (a warning on change, a message in Rietveld). - Pam On Thu, Jan 22, 2009 at 12:56 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: It'd be better to have them in rietveld instead? 2009/1/22 Paweł Hajdan Jr. phajdan...@chromium.org: What would you think about few new ideas for gcl warnings? - warn when files are added, deleted or moved and no build file is modified (including vcproj, scons and pbxproj) - warn when one build file is modified, but not the other (like changed vcproj but no scons and vice versa) There's one problem, that some not-so-small part of these warnings would be bogus. Anyway, that's just an idea. (I'm not volunteering to actually make these changes, at least not at this moment) Paweł --~--~-~--~~~---~--~~ 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: gcl warnings about missing build system updates
Sounds good. Can they call Python modules? Most of the relevant pieces should be callable externally. - Pam 2009/1/22 Evan Martin e...@chromium.org It would be nice if these lint-y sorts of tools could be ran independently of gcl, so that our git tools could make use of them. 2009/1/22 Pam Greene p...@chromium.org: The new gcl warning for missing unit tests currently only appears on 'gcl change', but the plan is to set up a generic alert system so gcl can tell Rietveld to show whatever warnings it wants. This would fit well with both of those (a warning on change, a message in Rietveld). - Pam On Thu, Jan 22, 2009 at 12:56 PM, Marc-Antoine Ruel mar...@chromium.org wrote: It'd be better to have them in rietveld instead? 2009/1/22 Paweł Hajdan Jr. phajdan...@chromium.org: What would you think about few new ideas for gcl warnings? - warn when files are added, deleted or moved and no build file is modified (including vcproj, scons and pbxproj) - warn when one build file is modified, but not the other (like changed vcproj but no scons and vice versa) There's one problem, that some not-so-small part of these warnings would be bogus. Anyway, that's just an idea. (I'm not volunteering to actually make these changes, at least not at this moment) Paweł --~--~-~--~~~---~--~~ 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: build problem (chromium.r9040.tar.gz)
We could make fully self-sufficient tarballs, but then we'd need three separate ones, since the three platforms have different dependencies. (Or we'd need to stick Mac and Linux developers with downloading a bigger tarball than they need.) I think it's fair to require a sync after downloading the tarball, since you'll need to have the tools working at some point. If you don't ever want to update your source code, you can use the continuous builds. (For the moment, since the tarballs are generated arbitrarily at 2 AM, syncing to a working build is a good idea anyway. But I plan to change it to package up a known-green revision.) - Pam On Tue, Feb 3, 2009 at 9:57 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Tue, Feb 3, 2009 at 9:55 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Feb 3, 2009 at 9:05 PM, t...@chromium.org wrote: What evan means is that after downloading the tar ball, you need to run gclient sync to get all the platform specific dependencies. We recently started generating the source tar ball on a regular basis and it doesn't include all the Windows and Mac dependencies from the src/third_party directory. Running gclient sync will download these platform specific dependencies for you. In that case, the build instructions are out of date. I updated the getting-the-code page to reflect that this is now required. If this is now required, we screwed up somewhere. The goal of the tarball is mainly to give an easy way for people to download and build chromium. If they need to call gclient sync, it defeats the purpose. Are you sure we really need that? Nicolas 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: Layout test expectations and fallbacks
The end result here sounds good to me. Just a few side comments: * If we ever set up a directory for baselines common to all Chromium platforms, it should be called 'chromium'. This matches the WebKit side, where they have mac-tiger, mac-leopard, and mac. In fact, the layout-test script is already set up to look in 'chromium' (after chromium-this-platform and before chromium-win or mac, IIRC). * We initially decided to avoid such a directory because it makes it harder to figure out what to do when you make a change. For example, when one platform diverges it's not clear that you have to move a file from chromium into each other platform's directory. The kjs/v8/common split got terribly jumbled after a while. Deliberate duplication is inconvenient, but at least it's straightforward. * If you run_webkit_tests with the --sources option, it will tell you the full path to the expected result file it's using for each comparison (text and image). - Pam On Thu, Jan 29, 2009 at 10:52 PM, Mads Sig Ager a...@chromium.org wrote: Thanks Tony, that would make it easier to work with. I still think that it is pretty confusing that chromium-linux does a fallback to chromium-win when chromium-mac doesn't. But maybe there is no way to avoid confusion here. -- Mads On Thu, Jan 29, 2009 at 6:17 PM, t...@chromium.org wrote: In practice, people tend to only test on one platform and create baselines for one platform. Normally, it's sufficient to add a comment to the tests_fixable file that the test is fixed on platform X and probably needs to be rebaselined on platform Y and Z. Anyway, I think the fix is to change run_webkit_tests.py --new-baseline to check to see if it's a pixel test or not and if it's not a pixel test, it should automatically copy the results into chromium-win and chromium-mac. I'll look into doing this today. tony On Thu, 29 Jan 2009, Dean McNamee wrote: I guess Mads's point here was that he works on V8, and when he wants to fix something for V8 (rebaseline), it's not clear to him where it should go. Should he copy it into all 3 places? The idea was maybe there should be a chromium-common (which is not chromium-win), where we can stick fallbacks where we know all platforms should match. It gets difficult to manage expectations across 3 platforms, especially when you think they should be the same. We've had that a lot now, someone stumbles over a broken test on Linux, and finds out that it was rebaselined on Windows already, etc. It's just confusing / a lot of work for someone like Mads's on the V8 team to know how to handle all 3 platforms differently... On Thu, Jan 29, 2009 at 4:50 PM, Thomas Van Lenten thoma...@chromium.org wrote: On Thu, Jan 29, 2009 at 10:44 AM, Dean McNamee de...@chromium.org wrote: On Thu, Jan 29, 2009 at 4:43 PM, Mark Mentovai m...@chromium.org wrote: On the Mac, I think we want to match Apple WebKit baselines. I don't know if there are any baselines currently in chromium-win that we should share. All of the V8 differences, for example. We copy those into chromium-mac as needed. But the majority of the expected files come down to fonts and the windows files wouldn't be of any use there. In the pixel dumps, again, font and controls pretty much make using the windows ones pointless. TVL Mark Dean wrote: I talked to Mads a bit, basically: 1) I think the Mac expected result fallback is currently wrong, it doesn't seem to look in chromium-win correctly. This is probably causing a lot of failures. 2) We should move chromium-win to chromium (or chromium-common), and then chromium-win should not be a fallback. This might be more confusing to manage, but it's also less confusing to understand that everything should / can fallback to the Windows expectations. On Thu, Jan 29, 2009 at 2:49 PM, Mads Sig Ager a...@chromium.org wrote: It seems that when running layout tests on linux, if there are no special expected results for linux in chromium-linux, we fallback to the special expected results for windows in chromium-win. This is not the case on mac if there are no results in chromium-mac, we take the expectations that are next to the test even if there are other expectations in chromium-win. Is that on purpose? A related question: what is the intention with our custom expected resulsts? If we need to change the expectation for all three platforms, should we only add the new expectations in chromium-win? That sounds confusing to me. Maybe we should have a chromium-common? Cheers,-- Mads --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe:
[chromium-dev] Re: Writing tips to our build instructions?
And I've updated http://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code to make the make sure the path has no spaces note apply to all platforms rather than only Windows. (Is it true for Linux too?) - Pam On Tue, Feb 17, 2009 at 9:16 AM, Sam Kerner sker...@gmail.com wrote: Hironori, Good catch. I updated http://code.google.com/p/chromium/wiki/MacBuildInstructions with the following text: The path to the build directory should not contains spaces (e.g. ~/Mac OS X/chromium), as this will cause the build to fail. Sam On Mon, Feb 16, 2009 at 11:57 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Hey there, This wiki is open to anyone to edit, http://code.google.com/p/chromium/wiki/MacBuildInstructions It is linked directly from: http://dev.chromium.org/developers I have seen the IRC log :) Many people are having this issue, would be great to update it so future coders wont run into the same problems. On Mon, Feb 16, 2009 at 11:54 PM, Hironori Bono (坊野 博典) hb...@chromium.org wrote: Hi Chromium developers, Today, I noticed a person who could not build Chromium (on Mac OS X) because he/she downloaded the source code of Chromium to a directory which contains space characters (e.g. ~/Mac OS X/chromium). Even though I'm not sure this is a known issue, I would like to note this to somewhere in our build instructions if not. Is it possible to give me good places to write such build tips? Regards, Hironori Bono E-mail: hb...@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] Re: staying on top of layout tests
Perhaps this should exclude tests that we've ever passed, since those are also regressions, albeit more recent ones. - Pam On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. 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: staying on top of layout tests
Do we plan to live on the edge of the wave once we're entirely unforked, and never do merges again? - Pam On Fri, Feb 20, 2009 at 11:01 AM, Darin Fisher da...@chromium.org wrote: This sounds good to me as a temporary measure while we are still doing merges. We are supposed to be unforked by the end of the quarter, right? ;-) -Darin On Thu, Feb 19, 2009 at 2:49 PM, Ojan Vafai o...@chromium.org wrote: In the spirit of trying to fix all the layout tests that represent real regressions since our initial launch, I've just committed a changelist that defers the tests that are failing that are new to webkit since the revision of our launch or whose expectations changed upstream (the latter was only a couple tests, the former was almost 80 tests). If people think this is an awful idea, I can rollback. I don't think it makes sense to block releases to the stable channel on new tests that we've never passed. My biggest concern with each release is breaking sites that previously used to work in Chrome. New tests, for the most part, don't represent regressions like that. Does it make sense to make a policy of deferring new, failing tests from a webkit merge by default. The person doing the merge should put a good faith effort into getting it fixed, but it shouldn't block cutting a release. Eventually we'll get to a point where we only have deferred tests left and we can start tackling that long list of tests without having it hinder our ability to push releases to the stable channel. 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: 2-day merges and the cleanup schedule
I'm not sure how closely that's followed. Me, I did merges Monday and Tuesday, and layout-test cleanup (baselines and bugs) today. - Pam On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher da...@chromium.org wrote: Right. I just mean that the merger should take care to ensure that all of the easy fixes are done and that the rest are accounted for somehow, probably via regression bugs. If that's the current process, then great. It just sounded like it wasn't. -Darin On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene p...@chromium.org wrote: Define resolved. Is filing and assigning a bug sufficient? It's not efficient to have whoever volunteers to do a merge personally pester people to fix the resulting test errors forever after. Whatever we do, we're going to have broken layout tests after a merge. Easy fixes -- re-baselining the ones that are actually all right, and filing specific bugs for the rest -- are definitely part of the merge task. But we don't want to put too much blame on the messenger: if a bunch of tests really break, or new tests don't pass, it's hardly the fault of the person who happened to bring the changes in. - Pam On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher da...@chromium.org wrote: I think the merger should be responsible for ensuring that any layout test fallout from the merge gets resolved. This doesn't mean necessary fixing everything, but rather it can be mean reaching out to others for help. I think the merger has to have incentive not to create a big mess with the merge and to also make sure the job gets done completely :-) -Darin On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet s...@chromium.org wrote: If we are ever to keep up to date with layout tests we need to come to a consensus on this. Here's the current set of proposals: 1. The merge becomes a two day activity. First day is merge, second day is fixing any failing layout tests. 2. We tag team people: first person does merge, next day another person fixes any failing layout tests. 3. One person for merge (like we do now), and failures are handled by owners of the layout tests. This assumes we can identify owners for buckets of layout tests so that folks know they are on the spot for a failing test. At this point we only care about regressions since 1.0, but that'll change soon. Can we make a decision on this at next weeks WebKit meeting? -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote: I'm currently doing a 2-day merge rotation.As part of this, various layout tests are regressing or getting added that I'm inserting into the tests_fixable list. But, like every other layout test fixer, after my merges are done, I'll finally go back to my old work and not think about it any more. This is how we get a monotonically increasing list of broken tests at the end of the tests fixable. I'm pretty certain this happens faster than the tests are getting fixed because nobody wants to fix them. I'm sort of tempted to just fix the ones my merge broke now, but that will put me behind for my next merge, so I don't do that. I propose a different rotation schedule for WebKit merges. You would do one day of merges, and the next day you would have to clean up all the regressed and new layout tests your merge introduced. The layout tests usually aren't that hard, so it normally wouldn't take the whole day. This way we can be in a good steady state of WebKit merges. It should also have a big advantage for fixing the broken tests since the things that changed, the build numbers involved, etc. are still fresh in the merger's head, and it won't be like approaching a random layout test from the list with no context. The disadvantage of doing this is that we have to find people to do the merges faster (we should probably formalize the schedule), and you'll lose some advantage the second day of having all the instructions and gotchas of the merge fresh in your mind. I was thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but that seems too heavyweight for the people volunteering to do this. Anybody have any comments? 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: 2-day merges and the cleanup schedule
Added layout-test cleanup steps to the instructions. - Pam On Wed, Mar 4, 2009 at 6:08 PM, David Levin le...@chromium.org wrote: I know that I haven't filed chromium bugs for layout test failures in the past because it isn't in the instructions (I thought adding the the tests_fixable was sufficient.) http://dev.chromium.org/developers/how-tos/webkit-merge-1 Though I do usually have at least a partial 3rd day of items for clean up: upstreaming, some times filing bugs for new reliability crashes, etc. Dave On Wed, Mar 4, 2009 at 5:30 PM, Pam Greene p...@chromium.org wrote: I'm not sure how closely that's followed. Me, I did merges Monday and Tuesday, and layout-test cleanup (baselines and bugs) today. - Pam On Wed, Mar 4, 2009 at 5:10 PM, Darin Fisher da...@chromium.org wrote: Right. I just mean that the merger should take care to ensure that all of the easy fixes are done and that the rest are accounted for somehow, probably via regression bugs. If that's the current process, then great. It just sounded like it wasn't. -Darin On Wed, Mar 4, 2009 at 4:51 PM, Pam Greene p...@chromium.org wrote: Define resolved. Is filing and assigning a bug sufficient? It's not efficient to have whoever volunteers to do a merge personally pester people to fix the resulting test errors forever after. Whatever we do, we're going to have broken layout tests after a merge. Easy fixes -- re-baselining the ones that are actually all right, and filing specific bugs for the rest -- are definitely part of the merge task. But we don't want to put too much blame on the messenger: if a bunch of tests really break, or new tests don't pass, it's hardly the fault of the person who happened to bring the changes in. - Pam On Wed, Mar 4, 2009 at 3:18 PM, Darin Fisher da...@chromium.orgwrote: I think the merger should be responsible for ensuring that any layout test fallout from the merge gets resolved. This doesn't mean necessary fixing everything, but rather it can be mean reaching out to others for help. I think the merger has to have incentive not to create a big mess with the merge and to also make sure the job gets done completely :-) -Darin On Wed, Mar 4, 2009 at 10:06 AM, Scott Violet s...@chromium.orgwrote: If we are ever to keep up to date with layout tests we need to come to a consensus on this. Here's the current set of proposals: 1. The merge becomes a two day activity. First day is merge, second day is fixing any failing layout tests. 2. We tag team people: first person does merge, next day another person fixes any failing layout tests. 3. One person for merge (like we do now), and failures are handled by owners of the layout tests. This assumes we can identify owners for buckets of layout tests so that folks know they are on the spot for a failing test. At this point we only care about regressions since 1.0, but that'll change soon. Can we make a decision on this at next weeks WebKit meeting? -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote: I'm currently doing a 2-day merge rotation.As part of this, various layout tests are regressing or getting added that I'm inserting into the tests_fixable list. But, like every other layout test fixer, after my merges are done, I'll finally go back to my old work and not think about it any more. This is how we get a monotonically increasing list of broken tests at the end of the tests fixable. I'm pretty certain this happens faster than the tests are getting fixed because nobody wants to fix them. I'm sort of tempted to just fix the ones my merge broke now, but that will put me behind for my next merge, so I don't do that. I propose a different rotation schedule for WebKit merges. You would do one day of merges, and the next day you would have to clean up all the regressed and new layout tests your merge introduced. The layout tests usually aren't that hard, so it normally wouldn't take the whole day. This way we can be in a good steady state of WebKit merges. It should also have a big advantage for fixing the broken tests since the things that changed, the build numbers involved, etc. are still fresh in the merger's head, and it won't be like approaching a random layout test from the list with no context. The disadvantage of doing this is that we have to find people to do the merges faster (we should probably formalize the schedule), and you'll lose some advantage the second day of having all the instructions and gotchas of the merge fresh in your mind. I was thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but that seems too heavyweight for the people volunteering to do this. Anybody have any comments? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options
[chromium-dev] Re: Changes to the waterfall.
On Mon, Mar 9, 2009 at 8:56 AM, Erik Kay erik...@chromium.org wrote: (repost) On Mon, Mar 9, 2009 at 9:45 AM, Nicolas Sylvain nsylv...@chromium.org wrote: I think purify ui tests is just waiting for a new version of purify maybe? After that it should be easy enough to turn it green. Nope. The purify UI tests are looking for some love and attention (AFAIK, nobody's working on it right now). While some of the hangs are likely Purify bugs, without someone actually tracking them down, no progress will be made. Slightly off-topic, but... I was looking at this, then stopped to do a merge. Paul picked it up, but I don't know how far he got. I'll circle back to it this week. It's http://crbug.com/7810 . - Pam I could also move valgrind to the FYI waterfall if we don't plan to make progress and add it to the top bar anytime soon. From what I remember Dan Kegel owns this and was going to get on it a few weeks ago. Dan? Erik --~--~-~--~~~---~--~~ 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: Setting Default Search Engine
Yes, Chromium supports the OpenSearch specification. As you browse pages, if they offer a search engine (a link rel=search tag), we'll pick it up and automatically add it to the list of engines available in the browser. For instance, visit http://www.slashdot.org/ and their engine will be detected and automatically added. For that matter, if you visited Mycroft as Adam mentioned, you now have Mycroft's own search available. We also support the JavaScript window.external.AddSearchProvider() call that Mycroft and other sites use, to let you add an engine by clicking on a link or button. The part we don't (yet) do is let you set the engine as your default at the same time as you add it. To see all the engines Chromium has encountered and choose one for your default, either right-click on the Omnibox and pick Edit search engines... or pick Options from the wrench menu, go to Basics, and then either pick one of the suggested defaults or click Manage for the full list. (Engines that come with Chrome, and any you add by clicking, are part of the suggested defaults list. Engines that were added by automatically detecting them are only on the full list, until you promote them.) I should write a blog post about this sometime. - Pam On Fri, Mar 20, 2009 at 2:41 PM, Adam Barth aba...@chromium.org wrote: Yeah, this great works in Chrome. Head over to http://mycroft.mozdev.org/search-engines.html and try adding any of the OpenSearch search engines (with the A9 logos). Adam On Fri, Mar 20, 2009 at 2:19 PM, Meok meok...@gmail.com wrote: I'm not talking about tricking someone into setting a search engine. i'm talking about how Firefox has a page that you can click on a list of search engines to install them into the browser. IE8 does the same thing. The user has to confirm that they really want the search engine installed or set as default. I guess this would fall under the extensions framework but you can do it manually in Chrome (which is great) but I just wondered if there was an automated way to do it as well, like Firefox. I hope that's clear. On Mar 20, 4:23 pm, Adam Langley a...@chromium.org wrote: On Fri, Mar 20, 2009 at 7:57 AM, Meok meok...@gmail.com wrote: My question is, whether or not there is code which will trigger Chromium to change the default search engine? In other words, can I make an html link that when clicked on, will set the default search engine in Chromium to that of my website? If you find such a security bug, please tell us so that we can fix it. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging
Just to make sure I understand correctly, the model here is that each test has a BUG12345 note, possibly shared with other tests. But it doesn't have a name or priority, not even the (ambiguous) priority implied by DEFER, directly in the list. Instead, we use the bug tracker to track all that, that being what it as designed for, after all. Sounds good to me. I can think of several advantages to this plan not listed in your original email, and no additional disadvantages. (And as for the overhead of filing and closing bugs for a rebaseline, if it's clear a priori that that's all that's needed, you can always choose to do the rebaseline instead.) The merger, or whoever is adding a test to the list, should still be responsible for a preliminary investigation. Bug reports should be more than test a/b/c.html is failing. At a minimum, started failing in r34567; better, a sentence or two such as started failing in r34567, which looks like David's change to the zorkmid system, or new test in r34567, will fail until we implement FrobozzClient. (So any script that does this should ask for a description, not just file a bare bug.) - Pam On Wed, Mar 25, 2009 at 4:00 PM, Ojan Vafai o...@google.com wrote: Just want to make sure everyone sees this. Please voice yourself now if you care about layout test fixing process and about managing test list process. I'll give another day. Unless I hear objections, I'll make run_webkit_tests do option 3. I'm not quite sure how we transition from the current world with no bug ids to a future world with a bug id for each test, but I'll figure that out. Ojan On Wed, Mar 25, 2009 at 3:51 PM, David Levin le...@google.com wrote: We could go with option 3 until someone is annoyed enough by the overhead to write a script. :) On Tue, Mar 24, 2009 at 4:19 PM, Ojan Vafai o...@google.com wrote: OK. So, what I'm hearing is that every test should have a bug assigned to it, no matter the priority. In that case, there's a couple other options. *Option 3* Get rid of DEFER and don't add priorities to the test list. Instead require that every test have an associated bug (multiple tests can share a bug) and rely on the bug priority/owner to figure out when the test needs fixing and who is responsible for fixing it. Pros: -Works with our current bug triage process (kind of) -Makes for one easy place that people need to look for their todo list (the google code issue tracker) Cons: -Overhead of filing and closing bugs when the common case is just a rebaseline anyways -Hard to triage layout tests without understanding what's wrong with them *Option 4* Same as option 3, except we have a script that monitors the test list and automatically files a bug whenever a new test appears. The subject of the test is just the path listed in the test list, so the test can be found by searching the issue tracker. Similarly, when a test is removed from the test list, the bug is automatically closed. This has the same pros and cons as option 3 except that it totally removes the overhead associated with having a bug for each test path. Also, this would require someone to write the script to do this. Ojan On Tue, Mar 24, 2009 at 12:31 PM, David Levin le...@google.com wrote: I like this proposal. I would also like a bugs for P3 which could explain why it is a P3. If is it an unimplemented feature, then all tests for that unimplemented feature could have the same bug. (Since I do merges and took a while to layout test file bugs from that) I like option 2. BUT I'm concerned that adding someone's email address to test_fixable will not get any attention. Right now, when you file a bug, people get email and the bugs seem to be followed up. BUGS/PRIORITY TRIAGING Option 1 Addition Pro Email sent about new bug alerts people to the new issue -- I suppose one could email people separately when adding their email address to test_fixable (but this step could easily be missed). Dave On Tue, Mar 24, 2009 at 12:14 PM, Marc-Andre Decoste m...@chromium.org wrote: I personally prefer having a bug assigned for the layout tests that we want to be fixed soon... It makes for a more consistent way of following up on our progress... Even if the end result is just a re-baseline, we also gain the link to the bug from the committed change list (and vice versa). And if we want some sort of dashboard for this, we could add a page on the chromium-status appEngine that would read from the latest version of the test list file, and maybe some details (e.g., owner) from the issue tracker... Maybe... ;-) BYE MAD On Tue, Mar 24, 2009 at 2:57 PM, Ojan Vafai o...@google.com wrote: I'm going about adding support to the webkit test list for BUGx metadata and replacing DEFER with P0/P1/P2/P3. I've come to the conclusion that we need to better understand our desired workflow for dealing with failing layout
Re: IMPORTANT: Re: [chromium-dev] Re: layout tests and bug triaging
I take it back: there's one additional disadvantage. With no DEFER, we won't be able to use the layout-test report directly to say what percentage of tests that we want to pass for the next release we pass. Instead, we'll have to take one number from that report and one number (searching on priority/milestone) from the code tracker. If the people who do that regularly (Jon?) are happy with that, then I have no problem with it. - Pam On Thu, Mar 26, 2009 at 3:45 PM, Ojan Vafai o...@google.com wrote: This matches my understanding. As a transition plan, I'm thinking to replace DEFER with UNTRIAGED. That way there is a way we can keep from adding 400 this test has no bug id warnings until we add bugs for all the currently deferred tests. Ojan On Thu, Mar 26, 2009 at 3:28 PM, Pam Greene p...@chromium.org wrote: Just to make sure I understand correctly, the model here is that each test has a BUG12345 note, possibly shared with other tests. But it doesn't have a name or priority, not even the (ambiguous) priority implied by DEFER, directly in the list. Instead, we use the bug tracker to track all that, that being what it as designed for, after all. Sounds good to me. I can think of several advantages to this plan not listed in your original email, and no additional disadvantages. (And as for the overhead of filing and closing bugs for a rebaseline, if it's clear a priori that that's all that's needed, you can always choose to do the rebaseline instead.) The merger, or whoever is adding a test to the list, should still be responsible for a preliminary investigation. Bug reports should be more than test a/b/c.html is failing. At a minimum, started failing in r34567; better, a sentence or two such as started failing in r34567, which looks like David's change to the zorkmid system, or new test in r34567, will fail until we implement FrobozzClient. (So any script that does this should ask for a description, not just file a bare bug.) - Pam On Wed, Mar 25, 2009 at 4:00 PM, Ojan Vafai o...@google.com wrote: Just want to make sure everyone sees this. Please voice yourself now if you care about layout test fixing process and about managing test list process. I'll give another day. Unless I hear objections, I'll make run_webkit_tests do option 3. I'm not quite sure how we transition from the current world with no bug ids to a future world with a bug id for each test, but I'll figure that out. Ojan On Wed, Mar 25, 2009 at 3:51 PM, David Levin le...@google.com wrote: We could go with option 3 until someone is annoyed enough by the overhead to write a script. :) On Tue, Mar 24, 2009 at 4:19 PM, Ojan Vafai o...@google.com wrote: OK. So, what I'm hearing is that every test should have a bug assigned to it, no matter the priority. In that case, there's a couple other options. *Option 3* Get rid of DEFER and don't add priorities to the test list. Instead require that every test have an associated bug (multiple tests can share a bug) and rely on the bug priority/owner to figure out when the test needs fixing and who is responsible for fixing it. Pros: -Works with our current bug triage process (kind of) -Makes for one easy place that people need to look for their todo list (the google code issue tracker) Cons: -Overhead of filing and closing bugs when the common case is just a rebaseline anyways -Hard to triage layout tests without understanding what's wrong with them *Option 4* Same as option 3, except we have a script that monitors the test list and automatically files a bug whenever a new test appears. The subject of the test is just the path listed in the test list, so the test can be found by searching the issue tracker. Similarly, when a test is removed from the test list, the bug is automatically closed. This has the same pros and cons as option 3 except that it totally removes the overhead associated with having a bug for each test path. Also, this would require someone to write the script to do this. Ojan On Tue, Mar 24, 2009 at 12:31 PM, David Levin le...@google.com wrote: I like this proposal. I would also like a bugs for P3 which could explain why it is a P3. If is it an unimplemented feature, then all tests for that unimplemented feature could have the same bug. (Since I do merges and took a while to layout test file bugs from that) I like option 2. BUT I'm concerned that adding someone's email address to test_fixable will not get any attention. Right now, when you file a bug, people get email and the bugs seem to be followed up. BUGS/PRIORITY TRIAGING Option 1 Addition Pro Email sent about new bug alerts people to the new issue -- I suppose one could email people separately when adding their email address to test_fixable (but this step could easily be missed). Dave On Tue, Mar 24, 2009 at 12:14 PM, Marc-Andre Decoste m...@chromium.org wrote: I personally
[chromium-dev] Re: Layout test valgrind initial impressions
For comparison, running the layout tests in a release Purify build took about 20 hours last time we did that. We now split it into 1-hour chunks for convenience and to divide the eggs into multiple baskets.[1] A debug Purify build is too slow to be worth running. - Pam [1] http://idioms.thefreedictionary.com/put+all+eggs+in+one+basket On Sat, Mar 28, 2009 at 3:21 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: The change that adds support for valgrinding layout tests is http://codereview.chromium.org/55034 I'm about about 10% of the way through valgrinding the layout tests on a debug build, and about 20% of the way through on a release build. With valgrind set to ignore reachable and possible leaks, and using the valgrind/suppressions.txt files in the tree to suppress previously known problems, and not paying much attention to whether tests are actually passing, the vast majority of new valgrind warnings I see are the two memory leaks: http://code.google.com/p/chromium/issues/detail?id=9475 http://code.google.com/p/chromium/issues/detail?id=9458 I've also seen two invalid read errors: http://code.google.com/p/chromium/issues/detail?id=9486 http://code.google.com/p/chromium/issues/detail?id=9488 All in all, it looks pretty promising, except for how darn long it takes to do a complete purify or valgrind run. It would take about ten machine-days to do a complete run with a debug build, and about half that with a release buld. To get to a one-hour cycle time with a release build would take about 120 bots. - Dan --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. 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: Creating bugs from test_expectations.txt
On Thu, Apr 9, 2009 at 6:49 PM, Ojan Vafai o...@google.com wrote: At a quick glance, this looks great. I didn't look over every bug, but the ones I did look at look good. Yep. You'll want some sort of default description for the ones that have none. 200+ bugs is certainly too many, but that's no reason not to file them. (Sorry, couldn't resist. Seriously, yes, definitely file them. Better in the issue tracker than getting lost.) It would be great to check in a version of this script that we could run when a number of tests fail (e.g. when doing a bad webkit merge). That way, we can add them all to the local test_expectations.txt file and have it spit out the new results. Fixing the file we have and moving forward are slightly different use cases, but yes. In the long run, we shouldn't need any script to fix an existing bug-less expectations file, only the part that adds bugs for newly added tests. I'm not sure whether that part should be controlled by adding the tests to the file and having the script file bugs, or making it a fully interactive app: give it a list of files and a description, and it both changes the file and creates a bug. Really, it would be great if the script filed bugs and then just modified test_expectations.txt directly (without committing it). Also, the script should remove any comments it moves into bug descriptions. We should get to a point where all the comments about layout tests are in the bug descriptions themselves instead of in this file. I disagree with this last part. I'd prefer a brief description to remain in the file, with any details in the bug. Certainly that's needed for WONTFIX bugs, where we may not have a bug since there's no work to be tracked, but it's helpful for others too. I've found it frustrating and time-consuming to track down when I see big blocks of failures with no explanations at all. Think of it like the svn checkin comment: enough to have an idea what's going on right there where you need it, with more detail in the bug for when you're really digging. - Pam I think it would be good to get the script checked in first and then run it on the existing test_expectations.txt file. Ojan On Thu, Apr 9, 2009 at 6:42 PM, Glenn Wilson gwil...@google.com wrote: Hi Pam Ojan, I wrote a script that would extract all of the layout tests from test_expectations.txt that we haven't marked as WONTFIX and don't have a bug number. I also tried a simple heuristic to get the context of the layout test via nearby commentsit's not perfect, and I'll have to change some of them by hand, but many of the merge comments are getting picked up. I've also hooked up our library for creating demetrius bugs, so getting bugs made for these should be a matter of running the script with different arguments (I hope). What are your thoughts? Is these as descriptive/accurate as we need? Is 200+ bugs too many? Thanks! Glenn --~--~-~--~~~---~--~~ 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: Creating bugs from test_expectations.txt
On Mon, Apr 13, 2009 at 9:09 AM, Glenn Wilson gwil...@chromium.org wrote: Yes, the intention is to have something maintainable that gets run as part of the regular testing/merging/etc. process -- which means eventually rewriting in python. I wrote this in Java because we had a java lib for automatically creating bugs in the issue tracker, and I wanted to get it up and running quickly. We should have a python API for doing the same thing. I can easily change the script so it marks DEFERs as P3s. However, currently, the script doesn't alter any entries in the file that already have bugs -- meaning something like BUG1234 DEFER : ... or WONTFIX DEFER : ... won't change. Is this the correct behavior? The end goal is to take DEFER out and let the bug priorities run the show. But if we're not entirely confident that this will work (both the script and the human tracking process afterward), it's easy enough to strip the DEFER modifiers later. - Pam I'm planning on running the script later today with the most recent version of test_expectations.txt -- there will be 200+ new bugs. Let me know if I should hold off on doing so. Ojan, I'll send you the review for test_expecations.txt. Regards, Glenn On Fri, Apr 10, 2009 at 4:36 PM, Ojan Vafai o...@google.com wrote: I hate to ask this, but any chance we could rewrite it in python? It would be a lot less code in python (one script file) and would match the rest of our codebase (which currently does all scripting in python). I'm mainly worried about usability and maintainability here. That all said, I think you should go ahead and run this script as a one off so we can get the test lists having bug IDs ASAP as that's kind of urgent to us being able to track the current state of layout tests. Then we can worry about checking in a python version later if we decide it's necessary. Pam, Darin, Jon, Mark: You might want to confirm that my request below makes sense with respect to future handling/triaging of layout tests bugs. Also for the initial one-off version, can you make any tests that are currently marked as DEFER be P3s? Then when you spit out the results to the test_expectations file, I don't think there's any need to include the DEFER anymore as we'll rely entirely on bug priorities to decide which tests need fixing for the next release (i.e. all P1 tests and maybe some P2 tests). That way there will be less initial triaging to do in order to make sure we keep the tree shippable. Eventually we'll have to go through all the P3s in the Untriaged state and up some of them to P2s, but there is no pressing need to do so right away. Ojan On Fri, Apr 10, 2009 at 3:42 PM, Glenn Wilson gwil...@chromium.orgwrote: (Ack...resending) Ok, I have the CL ready, if anyone with Java readability would be willing to do a review, please let me know. more inline... On Fri, Apr 10, 2009 at 2:07 PM, Pam Greene p...@chromium.org wrote: On Thu, Apr 9, 2009 at 6:49 PM, Ojan Vafai o...@google.com wrote: At a quick glance, this looks great. I didn't look over every bug, but the ones I did look at look good. Yep. You'll want some sort of default description for the ones that have none. I ran the script on a small test file...an example bug is here: http://code.google.com/p/chromium/issues/detail?id=9991 There's at least a small bit of indication of where it came from. I also added the line numbers from test_expectations.txt that generated the bug. Additionally, I also wrote the script to then add the created bug numbers to the file. This ends up re-arranging some of the flags (DEBUG DEFER ... etc. -- DEFER DEBUG ...), but all data is retained. 200+ bugs is certainly too many, but that's no reason not to file them. (Sorry, couldn't resist. Seriously, yes, definitely file them. Better in the issue tracker than getting lost.) There are probably some improvements to be had to better group some of the bugs, but it's probably not an order of magnitude improvement. I just didn't want to create tons of bugs that were not useful. It would be great to check in a version of this script that we could run when a number of tests fail (e.g. when doing a bad webkit merge). That way, we can add them all to the local test_expectations.txt file and have it spit out the new results. Fixing the file we have and moving forward are slightly different use cases, but yes. In the long run, we shouldn't need any script to fix an existing bug-less expectations file, only the part that adds bugs for newly added tests. I'm not sure whether that part should be controlled by adding the tests to the file and having the script file bugs, or making it a fully interactive app: give it a list of files and a description, and it both changes the file and creates a bug. There may be a short-term solution and a long-term solution. The short term solution seems to be for someone (assumedly the merger) to add
[chromium-dev] Re: Creating bugs from test_expectations.txt
On Mon, Apr 13, 2009 at 6:57 PM, Glenn Wilson gwil...@chromium.org wrote: Ok, I ran the script and created 211 bugs (in the ~10270 - 10500 range). As far as I can tell, all the bugs were created successfullythe script now picks up 0 tests without bugs. Ojan, I sent you the review of test_expectations: http://codereview.chromium.org/73026/show Two things I noticed: 1. The script didn't recognize layout tests in chrome/ and not in LayoutTests/ -- it's only a handful, so updating those by hand shouldn't take very long. 2. The script re-arranged some of the flags, as expected. If it is important that we keep the prior ordering of the flags, let me know. No, order is not important. Also, I'd love to get this script reviewed and checked in, if anyone would be willing to do a Java review. If I knew Java, much less had Java readability, I'd be glad to... - Pam Regards, Glenn On Mon, Apr 13, 2009 at 10:19 AM, Ojan Vafai o...@google.com wrote: On Mon, Apr 13, 2009 at 9:35 AM, Pam Greene p...@chromium.org wrote: On Mon, Apr 13, 2009 at 9:09 AM, Glenn Wilson gwil...@chromium.orgwrote: Yes, the intention is to have something maintainable that gets run as part of the regular testing/merging/etc. process -- which means eventually rewriting in python. I wrote this in Java because we had a java lib for automatically creating bugs in the issue tracker, and I wanted to get it up and running quickly. We should have a python API for doing the same thing. I can easily change the script so it marks DEFERs as P3s. However, currently, the script doesn't alter any entries in the file that already have bugs -- meaning something like BUG1234 DEFER : ... or WONTFIX DEFER : ... won't change. Is this the correct behavior? The end goal is to take DEFER out and let the bug priorities run the show. But if we're not entirely confident that this will work (both the script and the human tracking process afterward), it's easy enough to strip the DEFER modifiers later. Makes sense to me. Lets leave in the defer modifiers, but mark any *new* bugs for deferred tests as P3s. The current behavior of leaving existing bugs unaltered seems correct to me. BTW, doing it in Java for expediency sake is totally reasonable. Ojan - Pam I'm planning on running the script later today with the most recent version of test_expectations.txt -- there will be 200+ new bugs. Let me know if I should hold off on doing so. Ojan, I'll send you the review for test_expecations.txt. Regards, Glenn On Fri, Apr 10, 2009 at 4:36 PM, Ojan Vafai o...@google.com wrote: I hate to ask this, but any chance we could rewrite it in python? It would be a lot less code in python (one script file) and would match the rest of our codebase (which currently does all scripting in python). I'm mainly worried about usability and maintainability here. That all said, I think you should go ahead and run this script as a one off so we can get the test lists having bug IDs ASAP as that's kind of urgent to us being able to track the current state of layout tests. Then we can worry about checking in a python version later if we decide it's necessary. Pam, Darin, Jon, Mark: You might want to confirm that my request below makes sense with respect to future handling/triaging of layout tests bugs. Also for the initial one-off version, can you make any tests that are currently marked as DEFER be P3s? Then when you spit out the results to the test_expectations file, I don't think there's any need to include the DEFER anymore as we'll rely entirely on bug priorities to decide which tests need fixing for the next release (i.e. all P1 tests and maybe some P2 tests). That way there will be less initial triaging to do in order to make sure we keep the tree shippable. Eventually we'll have to go through all the P3s in the Untriaged state and up some of them to P2s, but there is no pressing need to do so right away. Ojan On Fri, Apr 10, 2009 at 3:42 PM, Glenn Wilson gwil...@chromium.orgwrote: (Ack...resending) Ok, I have the CL ready, if anyone with Java readability would be willing to do a review, please let me know. more inline... On Fri, Apr 10, 2009 at 2:07 PM, Pam Greene p...@chromium.org wrote: On Thu, Apr 9, 2009 at 6:49 PM, Ojan Vafai o...@google.com wrote: At a quick glance, this looks great. I didn't look over every bug, but the ones I did look at look good. Yep. You'll want some sort of default description for the ones that have none. I ran the script on a small test file...an example bug is here: http://code.google.com/p/chromium/issues/detail?id=9991 There's at least a small bit of indication of where it came from. I also added the line numbers from test_expectations.txt that generated the bug. Additionally, I also wrote the script to then add the created bug numbers to the file. This ends up re-arranging some of the flags (DEBUG DEFER
[chromium-dev] Re: RE : chrome's testing
If you've been through all those links, you've already seen these: http://dev.chromium.org/developers/testing http://dev.chromium.org/developers/testing/chromium-build-infrastructure/tour-of-the-chromium-buildbot Can you be more specific about what additional information you are looking for? - Pam 2009/6/3 sitan2...@sina.com BTW: I have reviewed all For developer docs on dev.chromium.org. But I don't think I started to know about chrome's test. --~--~-~--~~~---~--~~ 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: Is there a way to change the order in which individual unit tests are run?
Reordering is awkward (basically, edit the source file to reorder or disable some), but you can run only the CommandLine tests by appending this to your (hah) command line: --gtest_filter=CommandLine.* In VS, go to the project properties for base_unittests, pick Debugging, and put that in as the debugging command line. For full details about the --gtest_filter switch to include or exclude tests, see http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide - Pam On Fri, Jun 5, 2009 at 12:38 PM, Book'em Dano daniel.c...@gmail.com wrote: As an example, let's say I'm making some changes to CommandLine. As part of these changes, I'm wanting to run base_unittests. However, it's super annoying that I have to wait a few minutes while the other unit tests within this suite are run before the CommandLine unit test is hit. Is there a way to change this order _temporarily_ without excluding them from the project via Visual Studio? -Daniel --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
That's what we do now. It sounds like someone checked in new checksums without their corresponding new images, though, so the tests pass even though the nominally expected PNGs are wrong. - Pam On Mon, Jun 22, 2009 at 11:40 AM, Greg Spencer gspen...@google.com wrote: How about just running the pixel comparison only when the checksums don't match? Still not ideal, of course. -Greg. On Mon, Jun 22, 2009 at 11:30 AM, Ojan Vafai o...@chromium.org wrote: This isn't the best, but it would be easy to add a flag to run-webkit-tests that told it to always do the pixel comparison even if the checksums matched. Ojan On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote: Just so I'm not all negative, my suggestions after consulting with Tony: 1) Make Linux behavior match Windows, ignoring the recommendation in the comments below. 2) Rebaseline everything on Linux. :( 3) Now converting from a PNG file to expected output is easy on all three platforms: convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum (Not certain if Mac uses BGRA images, though.) On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksumO T T pngO T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: Pixel layout tests and checksums
Sounds right. If that doesn't catch them all, then I don't know offhand what's up. - Pam On Tue, Jun 23, 2009 at 8:59 PM, Evan Stade est...@chromium.org wrote: (replying to all this time) if that's the case, can't we run a script to find all the cases where svn log --limit 1 is different for the PNG and checksum, then just rebaseline em? -- Evan Stade On Mon, Jun 22, 2009 at 11:51 AM, Pam Greenep...@chromium.org wrote: That's what we do now. It sounds like someone checked in new checksums without their corresponding new images, though, so the tests pass even though the nominally expected PNGs are wrong. - Pam On Mon, Jun 22, 2009 at 11:40 AM, Greg Spencer gspen...@google.com wrote: How about just running the pixel comparison only when the checksums don't match? Still not ideal, of course. -Greg. On Mon, Jun 22, 2009 at 11:30 AM, Ojan Vafai o...@chromium.org wrote: This isn't the best, but it would be easy to add a flag to run-webkit-tests that told it to always do the pixel comparison even if the checksums matched. Ojan On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote: Just so I'm not all negative, my suggestions after consulting with Tony: 1) Make Linux behavior match Windows, ignoring the recommendation in the comments below. 2) Rebaseline everything on Linux. :( 3) Now converting from a PNG file to expected output is easy on all three platforms: convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum (Not certain if Mac uses BGRA images, though.) On Mon, Jun 22, 2009 at 10:24 AM, Evan Martine...@chromium.org wrote: Since I'm waiting for a build I sat down to implement this. But our image checksums are not checksums of the image files :(, but rather checksums of the pixels stored in the image. And Tony points out that our image checksumming is completely insane: = // Fix the alpha. The expected PNGs on Mac have an alpha channel, so we want // to keep it. On Windows, the alpha channel is wrong since text/form control // drawing may have erased it in a few places. So on Windows we force it to // opaque and also don't write the alpha channel for the reference. Linux // doesn't have the wrong alpha like Windows, but we ignore it anyway. #if defined(OS_WIN) bool discard_transparency = true; device-makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); #elif defined(OS_LINUX) bool discard_transparency = true; #elif defined(OS_MACOSX) bool discard_transparency = false; #endif // Compute MD5 sum. We should have done this before calling // device-makeOpaque on Windows. Because we do it after the call, there are // some images that are the pixel identical on windows and other platforms // but have different MD5 sums. At this point, rebaselining all the windows // tests is too much of a pain, so we just check in different baselines. To be more clear, here's a table of the platforms and their behaviors. O=opaque, T=transparent. (Sorry for my ghetto proportionally-spaced table here.) Win Mac Lin cksumO T T pngO T O I conclude that on Linux, you cannot go from the PNG file back to the checksum in the presence of alpha. Just for fun I played around a bit with commands like: convert path/to/pngfile rgba:- | md5sum and wasn't able to repro the checksums I'm seeing. It looks ok from convert path/to/pngfile rgba:- | xxd -g4 (the RGBA-BGRA problem doesn't apply for this black and while png file...). In summary: tears. On Mon, Jun 22, 2009 at 3:20 AM, Dean McNameede...@chromium.org wrote: Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: PSA: irc awareness [Was: Trick question: Who is responsible for repairing a red tree?]
For Colloquy, enter your nick in Preferences Alerts Highlight words. You can also enter other things you might be interested in, such as red or sheriff or caja. - Pam On Wed, Aug 5, 2009 at 7:25 PM, Dirk Pranke dpra...@google.com wrote: I would love to enable that feature ... anyone know how to do that for Adium on the Mac (IRC support is new in the 1.4 beta)? Failing that, Colloquy? -- Dirk On Wed, Aug 5, 2009 at 5:48 PM, Marc-Antoine Ruelmar...@chromium.org wrote: Most irc clients have an option to beep, flash or shutdown your computer when your nick is mentioned on a channel. It may not be enabled by default so please enable this. Ask around if you can't find how to enable this. Thanks, M-A On Wed, Aug 5, 2009 at 5:48 PM, Dan Kegel d...@kegel.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steelet...@chromium.org wrote: you have to keep asking, unless you're always on IRC and can cleverly search the window contents. A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) You need to be on IRC and scroll back: [13:55] dkegelmac valgrind unit - rohitrao? [13:57] motownavi dkegel: very likely [13:58] dkegelemailed rohit [14:02] rohitrao dkegel, jar: looking [14:30] rohitrao jar, dkegel: reverted 22517 I doubt anything more durable than IRC is going to help... IRC and the tree status are the place to go, I'm afraid. --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
I've been using a local copy with this change (add all files to a new change, but not to an existing one) forever, but last I checked around, some people prefer the always copy-paste model. I'd be glad to check in my change if the consensus agrees. - Pam On Thu, Aug 6, 2009 at 12:51 AM, Adam Barth aba...@chromium.org wrote: Perhaps a better default is to use this behavior when first creating a changelist and to use the old behavior when modifying a changelist. Adam On Thu, Aug 6, 2009 at 12:37 AM, Dirk Prankedpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Git usage in chromium
On Thu, Aug 6, 2009 at 9:55 AM, n179911 n179...@gmail.com wrote: Hi, I read this about git usage in chromium: http://code.google.com/p/chromium/wiki/UsingGit It looks like it is using a combination of git and svn for version control. Can you please tell me what are using git and what are using svn? My guess is third-party/webkit will be using svn and everything else is git? Is that correct? Both Chromium and WebKit use svn, but you can wrap git on top of that if you want by following those instructions. - Pam 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: gcl change that you should be aware of
On Thu, Aug 6, 2009 at 11:22 AM, Peter Kasting pkast...@google.com wrote: On Thu, Aug 6, 2009 at 8:59 AM, Pam Greene p...@chromium.org wrote: I've been using a local copy with this change (add all files to a new change, but not to an existing one) forever, but last I checked around, some people prefer the always copy-paste model. I'd be glad to check in my change if the consensus agrees. Yes, please do this. laforge's behavior is awesome as long as the bug of subsequent modifications doesn't affect it. PK Done. Edited files (but not those with only changed properties) will be included in the Paths in this changelist section of a new change. All unchanged files, and those with only property changes, are still below. The file list of an existing change won't be modified when you run 'gcl change' on it again. - 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: Mac History Menu
You want undo-close-tab for that use case, not history. The where-to-open behavior of undo-close-tab is completely different. Agreed that there's some overlap in usage, though. - Pam On Wed, Aug 12, 2009 at 12:59 PM, Mike Pinkerton pinker...@chromium.orgwrote: The few times I've needed to use the history menu (gak, i just closed something by accident, let me get it back), re-using the current tab is exactly what i don't want, as it clobbers something totally unrelated that I had open. That's what prompted this discussion. I agree that it should behave like bookmarks in theory, since it's effectively the same presentation, but it seems to get in the way of my workflow when I try to actually use it. On Wed, Aug 12, 2009 at 3:33 PM, Scott Violets...@chromium.org wrote: I would suggest you create something like browser/views/event_utils on the Mac (and Linux) side. Any place you're opening a URL from a user gesture you map the event to a WindowOpenDisposition. This way the UI is consistent with regards to what user gestures do. As to this particular case, I believe the default should be current tab. -Scott On Wed, Aug 12, 2009 at 12:23 PM, Brett Wilsonbre...@chromium.org wrote: On Wed, Aug 12, 2009 at 12:18 PM, Avi Drissmana...@chromium.org wrote: Brett— Are we talking about the history page, or history items? The history page gets its own tab, sure. But when someone picks an item from the history menu, where does it go? I think current foreground tab is right, with command for background tabs. Yes, I was confused. I think clobbering is OK in that case. My new improved opinion is it should act like the drop-down on the back/forward menus. Brett -- 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: Mac History Menu
They always felt pretty different to me. In one case, I'm undoing something I did, and I expect the state to be restored to how it was. In the other, I'm initiating a new action, and I expect the behavior to be the same as for bookmarks. - Pam On Thu, Aug 13, 2009 at 6:50 AM, Mike Pinkerton pinker...@chromium.orgwrote: As a Chrome developer, I understand the difference, but undo closed tab is just the most recent tab, where we have the 5 most recently closed tabs in the history menu. From a user perspective, why should one be different than the other? Why do I only get a new tab when I'm undoing the last tab, and not 2 or 3 tabs ago? Just because in code they're different, and that seems wrong. On Wed, Aug 12, 2009 at 5:53 PM, Pam Greenep...@chromium.org wrote: You want undo-close-tab for that use case, not history. The where-to-open behavior of undo-close-tab is completely different. Agreed that there's some overlap in usage, though. - Pam On Wed, Aug 12, 2009 at 12:59 PM, Mike Pinkerton pinker...@chromium.org wrote: The few times I've needed to use the history menu (gak, i just closed something by accident, let me get it back), re-using the current tab is exactly what i don't want, as it clobbers something totally unrelated that I had open. That's what prompted this discussion. I agree that it should behave like bookmarks in theory, since it's effectively the same presentation, but it seems to get in the way of my workflow when I try to actually use it. On Wed, Aug 12, 2009 at 3:33 PM, Scott Violets...@chromium.org wrote: I would suggest you create something like browser/views/event_utils on the Mac (and Linux) side. Any place you're opening a URL from a user gesture you map the event to a WindowOpenDisposition. This way the UI is consistent with regards to what user gestures do. As to this particular case, I believe the default should be current tab. -Scott On Wed, Aug 12, 2009 at 12:23 PM, Brett Wilsonbre...@chromium.org wrote: On Wed, Aug 12, 2009 at 12:18 PM, Avi Drissmana...@chromium.org wrote: Brett— Are we talking about the history page, or history items? The history page gets its own tab, sure. But when someone picks an item from the history menu, where does it go? I think current foreground tab is right, with command for background tabs. Yes, I was confused. I think clobbering is OK in that case. My new improved opinion is it should act like the drop-down on the back/forward menus. Brett -- Mike Pinkerton Mac Weenie pinker...@google.com -- 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: Running UI test in parallel (experimental)
On Wed, Aug 19, 2009 at 9:54 PM, Huan Ren hu...@google.com wrote:
On Thu, Aug 6, 2009 at 1:06 PM, John Abd-El-Malek j...@chromium.orgwrote:
This is very cool, but I ran into a few problems when I tried to run it:
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
You must have your local path of trunk/src/tools/python added to your
PYTHONPATH.
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 32, in
module
import google.httpd_utils
ImportError: No module named google.httpd_utils
hmmm, never needed PYTHONPATH set before. Can't this script set it
itself? Setting it manually will fail when I move depot locations etc..
But anyways, I set it and then
a:\chrome2\src\chromeset PYTHONPATH=a:\chrome\src\tools\python
a:\chrome2\src\chrometools\test\smoketests.py --tests=ui
Traceback (most recent call last):
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 274, in
module
result = main(options, args)
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 155, in main
sys.path.insert(0, _BuildbotScriptPath('slave'))
File A:\chrome2\src\chrome\tools\test\smoketests.py, line 84, in
_BuildbotScriptPath
'scripts', sub_dir)
File a:\chrome\src\tools\python\google\path_utils.py, line 72, in
FindUpward
parent = FindUpwardParent(start_dir, *desired_list)
File a:\chrome\src\tools\python\google\path_utils.py, line 55, in
FindUpwardParent
(desired_path, start_dir))
google.path_utils.PathNotFound: Unable to find
tools\buildbot\scripts\slave above A:\chrome2\src\chrome\tools\test
tools\buildbot isn't in the public tree I think, since I don't find it
here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/tools/. So
external contributors can't use this? Also, why should this script depend
on the buildbot scripts? I don't have them so I can't try this out.
It is externally available.
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/
Can't we just have a minimal python script that runs ui_tests in parallel?
Pam wrote the original smoketests.py. Pam, is it easy to drop those
dependencies? Otherwise, I will write a minimal python script.
I'll take a look. At a quick glance, it looks like the buildbot slave
scripts are only needed if you're running layout tests, so I'll try to
extract that.
- Pam
Huan
On Wed, Jul 29, 2009 at 3:28 PM, Huan Ren hu...@google.com wrote:
I just checked in a change to run ui_tests in parallel based on
sharding mechanism provided by GTest. Each ui_tests instance has its
own user data dir, and the number of ui_tests instances is
NUMBER_OF_PROCESSORS. I have updated
src/chrome/tools/test/smoketests.py so you can run it through command
line:
python.exe smoketests.py --tests=ui [--verbose]
Running ui_tests.exe directly is still the old behavior of
sequentially running. On my 4 core machine, the running time has been
reduced by half, from 832 secs to 443 secs. But I need to make sure
all tests can run reliably in this parallel fashion. So if you try it
out, I will be interested to know how fast the performance is improved
and what additional tests are failing.
Huan
P.S. this change is for Windows platform as I think Linux/Mac is
already using GTest sharding.
--~--~-~--~~~---~--~~
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
At least in the batch of tests I examined, the ones that needed re-baselining weren't tests we'd originally failed and suddenly started passing. They were new tests that nobody had ever taken a good look at. If that matches everyone else's experience, then all we need is an UNTRIAGED annotation in the test_expectations file to mark ones the next Great Re-Baselining needs to examine. I'm not convinced that passing tests we used to fail, or failing tests differently, happens often enough to warrant the extra work of producing, storing, and using expected-bad results. Of course, I may be completely wrong. What did other people see in their batches of tests? - Pam On Fri, Aug 21, 2009 at 1:16 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Aug 21, 2009 at 1:00 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, As Glenn noted, we made great progress last week in rebaselining the tests. Unfortunately, we don't have a mechanism to preserve the knowledge we gained last week as to whether or not tests need to be rebaselined or not, and why not. As a result, it's easy to imagine that we'd need to repeat this process every few months. I've written up a proposal for preventing this from happening again, and I think it will also help us notice more regressions in the future. Check out: http://dev.chromium.org/developers/design-documents/handlinglayouttestexpectations Here's the executive summary from that document: We have a lot of layout test failures. For each test failure, we have no good way of tracking whether or not someone has looked at the test output lately, and whether or not the test output is still broken or should be rebaselined. We just went through a week of rebaselining, and stand a good chance of needing to do that again in a few months and losing all of the knowledge that was captured last week. So, I propose a way to capture the current broken output from failing tests, and to version control them so that we can tell when a test's output changes from one expected failing result to another. Such a change may reflect that there has been a regression, or that the bug has been fixed and the test should be rebaselined. Changes We modify the layout test scripts to check for 'foo-bad' as well as 'foo-expected'. If the output of test foo does not match 'foo-expected', then we check to see if it matches 'foo-bad'. If it does, then we treat it as we treat test failures today, except that there is no need to save the failed test result (since a version of the output is already checked in). Note that although -bad is similar to a different platform, we cannot actually use a different platform, since we actually need up to N different -bad versions, one for each supported platform that a test fails on. We check in a set of '*-bad' baselines based on current output from the regressions. In theory, they should all be legitimate. We modify the test to also report regressions from the *-bad baselines. In the cases where we know the failing test is also flaky or nondeterministic, we can indicate that as NDFAIL in test expectations to distinguish from a regular deterministic FAIL. We modify the rebaselining tools to handle *-bad output as well as *-expected. Just like we require each test failure to be associated with a bug, we require each *-bad output to be associated with a bug - normally (always?) the same bug. The bug should contain comments about what the difference is between the broken output and the expected output, and why it's different, e.g., something like Note that the text is in two lines in the -bad output, and it should be all on the same line without wrapping. The same approach can be used here to justify platform-specific variances in output, if we decide to become even more picky about this, but I suggest we learn to walk before we try to run. Eventually (?) we modify the layout test scripts themselves to fail if the *-bad baselines aren't matched. Let me know what you think. If it's a thumbs' up, I'll probably implement this next week. Thanks! I really like this plan. It seems easy to implement and quite useful. +1 from me! --~--~-~--~~~---~--~~ 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: newbie : gclient config http://chromium-status.appspot.com/lkgr
The first URL gives the location of the source repository. It should be http://src.chromium.org/svn/trunk/src . The second URL is optional. It gives the location of a file holding the number of the Last Known Good Revision (lkgr); that is, the last revision that compiled and passed automated tests. If you use it, it should be http://chromium-status.appspot.com/lkg . So either of these will work: gclient config http://src.chromium.org/svn/trunk/src gclient config http://src.chromium.org/svn/trunk/src http://chromium-status.appspot.com/lkg The first version will pull the tip of the tree, which may be broken at any given moment. The second version will pull the LKGR. - Pam On Sat, Aug 29, 2009 at 5:18 AM, TsanChungtsanchung.w...@gmail.com wrote: I am a newbie chromium developer on ubuntu 8.04.. Should I use gclient config http://chromium-status.appspot.com/lkgr instead of gclient config http://src.chromium.org/svn/trunk/src or gclient config http://src.chromium.org/svn/trunk/src http://chromium-status.appspot.com/lkgr? --~--~-~--~~~---~--~~ 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: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovaim...@chromium.org wrote: I spent a chunk of last week looking at the new tab page performance on startup on the Mac. I found that the renderer was waiting on data from the browser process for what seemed like far too long. The key to this problem is that resource requests for the new tab page are funneled through the browser process' main (UI) thread. At least on the Mac, when a new tab is being created or while the application is starting up, there's a lot of contention for the UI thread: the window is being drawn and there might be animations or other effects, not to mention that infernal throbber. The good news is that turning off the tab strip's Core Animation layer improves this, as well as many other things. A patch to do this just landed again at r24881 (on the third try). In my experiments, this reduced the time from when the renderer requests the new tab page to the time that all of the resources are present in the renderer from between 1-3 seconds to just a hair over 300ms. This is a huge improvement. I still think that 300ms is too long, though, especially when you consider that this is not the time from launch, but the time from the renderer's request, which itself can come as much as 300ms after launch. I'm experimenting with a change that lets the new tab HTML and CSS be served directly from the browser's IO thread instead of the UI thread. Since these tasks require profile and theme access, the approach is to build up the HTML and CSS early, on the UI thread where such access is permitted, and cache them. When a request for the HTML or CSS comes in, the browser can then service them entirely on the IO thread. This gets the data into the renderer almost immediately after it's requested, so that the renderer is able to fully lay out the new tab page without having to wait for the browser to do things like draw the new tab. Additional resource requests, such as thumbnails and favicons, are still being served from the UI thread. Based on my experiments, this shouldn't be a problem: the renderer isn't ready to receive these until it's done with layout based on the HTML and CSS, and once it reaches that point, the browser should be done with heavy UI tasks and there shouldn't be much contention for its main loop. It might ultimately be better to be able to serve all new tab requests from a non-UI thread in the browser, but that could mean additional caching. This change improves new tab page performance by about 65ms on my laptop in release mode. Now we're down to 240. Great. What else can we do? Well, that annoying throbber is still chewing up time, causing some amount of UI loop contention while the images, thumbnails, and icons are fetched. Windows and Linux don't have a throbber for the new tab page. We shouldn't either. Excellent, now we're down to 200ms. It's still high, but it's reasonable. It's a perceptible improvement from the 300ms we started with. What else can we do? One thing that's begging for improvement based on my timings is the renderer startup delay. We don't bother starting up a renderer until about 200ms after launch, and it takes the renderer 70ms from that point to reach its main loop. I bet that if we did renderer startup much earlier, we'd have one warm and ready to go by the time we needed it. This doesn't have to be startup-specific, we could always maintain a spare renderer in the pool (within reason) so that we're not caught twiddling our thumbs waiting for the one we just launched. Go Mark go! This is definitely one of my annoyances on Mac. - Pam Mark --~--~-~--~~~---~--~~ 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: Getting pixel tests running on the Mac
Call me a wet blanket, but I don't think there's a strong need for more divergence in the file. Anything not passing is failing and needs looking at; having a way to say oh, it's 'only' the image that's bad will increase maintenance burden and support ignoring problems. Situations where we're willing to ignore one type of failure for an extended time should be rare. I'd vote for keeping FAIL meaning image and/or text, and IMAGEFAIL for temporary use meaning image-only. - Pam On Wed, Sep 23, 2009 at 6:52 PM, Ojan Vafai o...@chromium.org wrote: I prefer IMAGE and TEXT since people maintaining these lists need to type these all the time. Also, longer names make for more bloat in the file and in the dashboard. Anyone who works with these lists even a small amount will know that IMAGE and TEXT refer to failures. We should really get rid of FAIL as a valid expectation (forces us to be more strict about what kind of failure it is), so the overlap of FAIL with IMAGE and TEXT is just temporary. Really, the FAIL part is redundant, no? Why not rename TIMEOUT/CRASH to TIMEOUT-FAIL/CRASH-FAIL? Ojan On Wed, Sep 23, 2009 at 6:32 PM, Dirk Pranke dpra...@google.com wrote: I think this plan sounds good, too. I'm mucking with those scripts a bit at the moment for the LTTF reporting, so I can make this change tomorrow, unless someone else would rather do it. I might actually prefer FAIL-TEXT and FAIL-IMAGE, but that's just me. I agree that TEXTFAIL is better than TEXT. Anyone else care to express a preference? -- Dirk On Wed, Sep 23, 2009 at 1:50 PM, Stephen White senorbla...@chromium.org wrote: Could we make them TEXTFAIL and IMAGEFAIL, just to be clear? Stephen (And then post them to failblog if they're really embarassing.. J/K ;) On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ 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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
I don't think it's realistic to expect the gardener, or any one person, to be able to fix an arbitrary broken layout test in a reasonable period of time. That's certainly true for new tests, but even for regressions I often can't even tell for sure whether our results are correct, much less what to do if they're not. It's far more efficient to have the right person fix a test. (Of course, people should also strive to broaden their knowledge, but there's a limit to how much of that one can do in a week.) Never having broken layout tests is an excellent goal, but quite frankly I don't think it's one we should prioritize so high that we hobble other efforts and burn out developers. - Pam On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: I think we need to change something. I am not sure what -- I have ideas, but -- I would appreciate some collective thinking on this. PROBLEM: We accumulate more test failures via WebKit rolls than we fix with our LTTF effort. This ain't right. ANALYSIS: Ok, WebKit gardening is hard. So is fixing layout tests. You can't call it a successful WebKit roll if it breaks layout tests. But we don't revert WebKit rolls. It's a forward-only thing. And we want to roll quickly, so that we can react to next big breaker faster. So we're stuck with roll-now/clean-up-after deal. This sucks, because the clean-up-after is rarely fully completed. Which brings failing layout tests, which brings the suffering and spells asymptotic doom to the LTTF effort. POSSIBLE SOLUTIONS: * Extend WebKit gardener's duties to 4 days. First two days you roll. Next two days you fix layout tests. Not file bugs -- actually fix them. The net result of 4 days should be 0 (or less!) new layout test failures. This solution kind of expects the gardener to be part of LTTF, which is not always the case. So it may not seem totally fair. * Assign LTTF folks specifically for test clean-up every day. The idea here is to slant LTTF effort aggressively toward fixing newer failures. This seems nice for the gardeners, but appears to separate the action/responsibility dependency: no matter what you roll, the LTTF elves will fix it. * [ your idea goes here ] TIMELINE: I would like for us to agree on a solution and make the necessary changes to the process today. Tomorrow is a new day, full of surprising changes upstream. :DG --~--~-~--~~~---~--~~ 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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
a bit about this - I agree with Dmitri that the current Sisyphean approach is unsustainable. I don't think the right path is to ask the sheriffs to do the cleanup themselves - for example, a webkit roll that breaks workers in some obscure way is almost certainly beyond the ability of any random gardener to fix in two days, especially when there may be multiple bugs. A better solution would be to have the sheriff (or someone from LTTF) assign the bugs to specific people, with a general rule that such bugs must be fixed within two days (make these bugs the top priority over other tasks). This allows for load balancing of bugs, and also makes sure that we have the right people working on any specific bug. -atw On Tue, Oct 13, 2009 at 10:40 AM, Pam Greene p...@chromium.org wrote: I don't think it's realistic to expect the gardener, or any one person, to be able to fix an arbitrary broken layout test in a reasonable period of time. That's certainly true for new tests, but even for regressions I often can't even tell for sure whether our results are correct, much less what to do if they're not. It's far more efficient to have the right person fix a test. (Of course, people should also strive to broaden their knowledge, but there's a limit to how much of that one can do in a week.) Never having broken layout tests is an excellent goal, but quite frankly I don't think it's one we should prioritize so high that we hobble other efforts and burn out developers. - Pam On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.org wrote: I think we need to change something. I am not sure what -- I have ideas, but -- I would appreciate some collective thinking on this. PROBLEM: We accumulate more test failures via WebKit rolls than we fix with our LTTF effort. This ain't right. ANALYSIS: Ok, WebKit gardening is hard. So is fixing layout tests. You can't call it a successful WebKit roll if it breaks layout tests. But we don't revert WebKit rolls. It's a forward-only thing. And we want to roll quickly, so that we can react to next big breaker faster. So we're stuck with roll-now/clean-up-after deal. This sucks, because the clean-up-after is rarely fully completed. Which brings failing layout tests, which brings the suffering and spells asymptotic doom to the LTTF effort. POSSIBLE SOLUTIONS: * Extend WebKit gardener's duties to 4 days. First two days you roll. Next two days you fix layout tests. Not file bugs -- actually fix them. The net result of 4 days should be 0 (or less!) new layout test failures. This solution kind of expects the gardener to be part of LTTF, which is not always the case. So it may not seem totally fair. * Assign LTTF folks specifically for test clean-up every day. The idea here is to slant LTTF effort aggressively toward fixing newer failures. This seems nice for the gardeners, but appears to separate the action/responsibility dependency: no matter what you roll, the LTTF elves will fix it. * [ your idea goes here ] TIMELINE: I would like for us to agree on a solution and make the necessary changes to the process today. Tomorrow is a new day, full of surprising changes upstream. :DG -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ 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: Need your help
Also http://dev.chromium.org/developers/testing/chromium-build-infrastructure/tour-of-the-chromium-buildbot http://dev.chromium.org/developers/testing/chromium-build-infrastructure/performance-test-plots http://dev.chromium.org/developers/testing/chromium-build-infrastructure/performance-test-plots- Pam On Wed, Oct 14, 2009 at 9:22 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: You can read these: http://dev.chromium.org/developers/testing http://code.google.com/p/chromium/wiki/RunningChromeUITests http://dev.chromium.org/developers/how-tos/reliability-tests I also suggest reading code in src/chrome/test. On Tue, Oct 13, 2009 at 09:21, Landon Xue xueyunl...@gmail.com wrote: HI, I want to explore Chromium's auto-testing mechanism, include: auto- test, auto collect performance data. Can you provide me some document about it? thanks! --~--~-~--~~~---~--~~ 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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
Excellent, thanks Stephen. I'm sure not all the slots will be filled. I'd say the best way to complete the list is lazily, in the software sense -- that is, when a test fails, if it has no owner, find the best person (or a random volunteer, if nobody has any knowledge about the topic) and then add them to the list. - Pam On Wed, Oct 14, 2009 at 12:24 PM, Stephen White senorbla...@chromium.orgwrote: Ok, I have lousy docs-sharing-fu, but I gave it a shot. This should be writeable by anyone @chromium.org: http://spreadsheets.google.com/a/chromium.org/ccc?key=0AmBv0BNymMh5dHlHZnJDSjR1X0ZzNnRYOFZTVWtvb0Ehl=en (To edit, you'll probably have to log into http://docs.google.com/a/chromium.org first, then click the link above.). I basically split up the big directories, and the ones which obviously contained more than one type of test. Feel free to split/merge at will. It's probably a good idea that each directory has more than one expert/owner, so don't be shy. Stephen On Wed, Oct 14, 2009 at 2:43 PM, Dirk Pranke dpra...@chromium.org wrote: +1 On Tue, Oct 13, 2009 at 10:20 PM, Pam Greene p...@chromium.org wrote: If there are areas that nobody knows anything about, that's a lack that's hobbling us. Suppose we take the entire list of directories, slap it into a doc, and assign at least one owner to everything. For the areas that don't yet have anyone knowledgeable, we take volunteers to become knowledgeable if needed. It will be a valuable investment. Tests often fail due to problems outside their nominal tested areas, but the area owner would still be better than an arbitrary gardener at recognizing that and reassigning the bug. - Pam On Tue, Oct 13, 2009 at 10:09 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Ownership is a great concept. I started out planning LTTF as ownership-based. Unfortunately, the types of failures are scattered far and wide across the directories, some clustered, some not. After a few initial passes, I walked away thinking that it's not as simple as drawing the lines and basically gave up. That's how Finders/Fixers idea was born. :DG On Tue, Oct 13, 2009 at 4:24 PM, Yaar Schnitman y...@chromium.org wrote: I think ownership might actually help with flakiness. Today, in order to distinguish flakiness from real bugs, the gardener needs to have intimate knowledge of the relevant part of the code base and its history. That is beyond the capabilities of the average webkit gardener. Now, imagine a world were every layout test has an owner who can decide intelligently that the bug is flakey and advise the gardener what to do with it. Wouldn't it make gardening much easier? [Flakiness dashboard is very helpful in making the decision, but specialized knowledge topples generic statistics, especially if a test just started flaking] On Tue, Oct 13, 2009 at 1:21 PM, Julie Parent jpar...@chromium.org wrote: I like the idea of ownership of groups of layout tests. Maybe these directory owners could be more like the finders? An owner shouldn't have to necessarily fix everything in a group/directory, but they should be responsible for triaging and getting meaningful bugs filled for them, to keep things moving along. (I volunteer for editing/) Another complicating factor - The state of the main Chrome tree has a lot of effect on the gardener. If the tree is already filled with flakiness, then the webkit roll is likely to show failures, which may or may not have been there before the roll. This was largely the case in the situation pkasting was referring to, when he took over as sheriff, he inherited a tree with a lot of flakiness not reflected in test_expectations/disabled ui tests. I think very few (if any) of the tests he added to test_expectations had anything to do with the roll. Any policy we make needs to keep in mind that main tree sheriffs deal with flakiness differently; some cross their fingers and hope it goes away, and some do clean up. Maybe we need to get better at enforcing (or automating) adding flaky tests to expectations, so we at least have a clean slate for gardeners to start with. On Tue, Oct 13, 2009 at 11:53 AM, Stephen White senorbla...@chromium.org wrote: I agree with Dimitri that we're fighting a losing battle here. In my last stint as gardener, I did informally what I proposed formally last time: I spent basically 1 full day just triaging failures from my 2 days gardening. Not fixing, but just running tests locally, analyzing, grouping, creating bugs, assigning to appropriate people (when I knew who they were, cc'ing poor dglazkov when I didn't). So at least I didn't leave a monster bug with layout tests broken by merge #foo but at least grouped by area. That was manageable, but I don't
[chromium-dev] Re: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 1:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. That should move all the way upstream to WebKit... Real Soon Now, I'm sure! :) - Pam I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 1:50 PM, Ben Goodger (Google) b...@chromium.orgwrote: +1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). chrome/tools/test/smoketests.py Runs all the available unit tests, layout tests, page-cycler tests, etc. for a build of Chrome, imitating a buildbot. - Pam I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Tech talk topics
I'd be happy to give a talk about layout tests. It would help me if people could suggest subtopics, or more simply, ask questions they'd like answered. I've been working with the things for so long, it's hard for me to know what's confusing or unclear anymore. - Pam On Thu, Nov 5, 2009 at 4:10 PM, Jeremy Orlow jor...@chromium.org wrote: That's an excellent idea! Do you think you'd be able to give it? If not, do you have any suggestions on who would be good? Maybe Pam? On Thu, Nov 5, 2009 at 3:08 PM, Jeremy Moskovich jer...@chromium.orgwrote: IMHO it would be immensely valuable to give a talk explaining what Layout tests are and how they work in a *simple* enough manner to allow web developers to create tests for bugs that affect them. I haven't found any easily discoverable introductory material on this topic. Best regards, Jeremy On Fri, Nov 6, 2009 at 12:30 AM, Scott Violet s...@chromium.org wrote: A general big picture talk would be a great starter. How the DOM is modeled, how the render tree works, the interesting objects ... -Scott On Thu, Nov 5, 2009 at 2:22 PM, Jeremy Orlow jor...@chromium.org wrote: Sure...we definitely have some in-house expertise on this. I could even see if any of the Apple guys would be interested in this...but I wouldn't hold my breath. :-) What types of WebKit topics? On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) J --~--~-~--~~~---~--~~ 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] [GTTF] running tests that fail most often early in the queue
Sounds good, and very easy. Just edit the order of test steps in _AddTests() in trunk/tools/buildbot/scripts/master/factory/chromium_factory.py . - Pam On Thu, Nov 12, 2009 at 10:58 AM, Dirk Pranke dpra...@chromium.org wrote: +1. Great idea! -- Dirk On Thu, Nov 12, 2009 at 1:52 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I was just looking at the buildbot cycle stats at http://build.chromium.org/buildbot/waterfall/stats and realized that on many bots the most frequently failing tests are browser_tests and ui_tests. Then I checked how early they are run by each bot (the earlier we know about the failure, the earlier we can react). So, for example Chromium XP runs a lot of slow page cycler tests before browser_tests, and then another bunch of page cycler tests. page_cycler tests don't fail so frequently, and when they fail, it's frequently some evil flakiness. When browser_tests do fail however, it may indicate something more serious. A similar thing is with XP Tests: we're running mini_installer_tests (which take about 2 minutes), and then some other things which rarely fail, then UI tests (which fail frequently), and browser_tests at the end! I know that some of these cases are just flaky failures. But by knowing earlier about a failure, we'd have more time to decide what to do 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 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] Information about revisions
Can you be more specific? I gather you mean the revision information at the
bottom of the performance graphs, when you select a data point on the graph.
I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems to be
working correctly. What exactly causes this error?
Thanks,
- Pam
On Tue, Dec 1, 2009 at 6:29 AM, Anton Muhin ant...@chromium.org wrote:
Dear chromiumers,
Relatively recently I stopped seeing information about revisions for
build bot graphs. If I open our debugger it reports something like:
Uncaught TypeError: Cannot call method 'slice' of undefined.
Line number it gives is incorrect. Most probably it should be actually
line 50:
function received_data(data) {
var tbody = document.getElementById(tbody);
data.replace('\r', '');
var col_sums = [];
var rows = data.split('\n');
for (var i = 0; i rows.length; ++i) {
var tr = document.createElement(TR);
var cols = rows[i].split(' ');
// cols[0] = page name
// cols[1] = (mean+/-standard deviation):
// cols[2...] = individual runs
// Require at least the page name and statistics.
if (cols.length 2)
continue;
var page = cols[0];
var values = cols[1].split('+/-');
append_column(tr, page, col_sums, -1);
append_column(tr, values[0].slice(1), col_sums, 0); // HERE WE'RE
FAILING
append_column(tr, values[1].slice(0,-2), col_sums, 1);
for (var j = 2; j cols.length; ++j)
append_column(tr, cols[j], col_sums, j);
tbody.appendChild(tr);
}
It looks like data are returned in a wrong format. Chances are it is
a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
for other build bots either (e.g. Page Cycler Moz), there is no
exception however.
Any ideas what goes on?
yours,
anton.
--
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] Information about revisions
Hi, Anton,
Thanks for the additional information. I tried several points on that graph.
They didn't show any revision information at first, but a few seconds later
the frame loaded. Now I can look at other data points without any delay.
Since it works sometimes, I suspect that the problem is in the network (a
timeout, partial result sent, proxy error, or something of that sort),
rather than an actual bug in the data file or parsing.
What happens if you click the Show Changelog button, either with or
without changing the revision range? It should (re)load the svn log for the
range shown.
- Pam
On Tue, Dec 1, 2009 at 12:19 PM, Anton Muhin ant...@chromium.org wrote:
Good day, Pam.
On Tue, Dec 1, 2009 at 11:13 PM, Pam Greene p...@chromium.org wrote:
Can you be more specific? I gather you mean the revision information at
the
bottom of the performance graphs, when you select a data point on the
graph.
Precisely, one with SVN path, revision range, etc.
I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems to
be
working correctly. What exactly causes this error?
I tried
http://build.chromium.org/buildbot/perf/xp-release-dual-core/intl1/report.html?history=150
and for several random points (in Chrome, Safari and FF) it shows no
info for revisions (inside the big test field), it shows revision
range and pages info (if I click pages on the right). For this URL I
see no errors in the log.
yours,
anton.
On Tue, Dec 1, 2009 at 6:29 AM, Anton Muhin ant...@chromium.org
wrote:
Dear chromiumers,
Relatively recently I stopped seeing information about revisions for
build bot graphs. If I open our debugger it reports something like:
Uncaught TypeError: Cannot call method 'slice' of undefined.
Line number it gives is incorrect. Most probably it should be actually
line 50:
function received_data(data) {
var tbody = document.getElementById(tbody);
data.replace('\r', '');
var col_sums = [];
var rows = data.split('\n');
for (var i = 0; i rows.length; ++i) {
var tr = document.createElement(TR);
var cols = rows[i].split(' ');
// cols[0] = page name
// cols[1] = (mean+/-standard deviation):
// cols[2...] = individual runs
// Require at least the page name and statistics.
if (cols.length 2)
continue;
var page = cols[0];
var values = cols[1].split('+/-');
append_column(tr, page, col_sums, -1);
append_column(tr, values[0].slice(1), col_sums, 0); // HERE WE'RE
FAILING
append_column(tr, values[1].slice(0,-2), col_sums, 1);
for (var j = 2; j cols.length; ++j)
append_column(tr, cols[j], col_sums, j);
tbody.appendChild(tr);
}
It looks like data are returned in a wrong format. Chances are it is
a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
for other build bots either (e.g. Page Cycler Moz), there is no
exception however.
Any ideas what goes on?
yours,
anton.
--
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] Re: Chromium Tech Talks
I've just published my talk. Since the bulk of it was verbal, the slides are much more useful with the speaker's notes visible. (This also means it's not so great as an embedded presentation. Oh well.) http://docs.google.com/present/view?id=dcs84g92_1cjns9f73 http://docs.google.com/present/view?id=dcs84g92_1cjns9f73- Pam On Wed, Dec 9, 2009 at 11:02 AM, Jeremy Orlow jor...@chromium.org wrote: Personally, I really like the tech talk format as an introduction to a topic, but you're right that some would prefer something in written form and that a Wiki has many benefits that a video does not have. If you're willing to transcribe the information, I'm sure it would help others. On Wed, Dec 9, 2009 at 6:37 AM, Jacques jacques.ag...@googlemail.comwrote: On Dec 8, 10:49 pm, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some ideas for the next round of talks: Would these interesting points not be better suited to be covered in a wiki? What Jeremy presented there as videos seems more like an appetizer. With a growing wiki the experienced user aswell as potential contributors could actually use, transform and expand that information. For example, a few people could grab some parts off from the wiki, put it in a wave, chew on it long enough and then feed any results back to the wiki. Or is that on the list of you just but with a different priority? Friendly Greetings, Jac -- 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-dev] Re: all chrome/ LayoutTests have been upstreamed or removed
Yes, all but a couple of pending/ were upstreamed long ago, and Dirk has now handled the stragglers too. - Pam On Fri, Dec 18, 2009 at 7:01 PM, Ojan Vafai o...@chromium.org wrote: Does this include the pending/ directory as well? On Fri, Dec 18, 2009 at 6:59 PM, Dirk Pranke dpra...@chromium.org wrote: I have either deleted or submitted patches to upstream all of the remaining tests under chrome/ . There are a few that appear to be platform-specific, but most weren't. Assuming they clear the review process over the weekend, I intended to remove the chrome/ dir on Monday and submit patches to run_webkit_tests to only handle tests under LayoutTests/. If you happen to be gardening in the meantime, just mark the tests as SKIP and I will update the expectations and baselines as necessary. -- Dirk -- 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] Two Students Looking to work on Chromium for a Semester-Long Class Project (and beyond)
Not to put words into Alex's mouth, but my impression from his first email is that he and Mark are mostly looking for the weekly guidance from a 'client' piece -- i.e., a Chromium mentor for the semester. I'd gladly volunteer, but I won't be around the whole time. - Pam On Fri, Jan 15, 2010 at 11:42 AM, Jens Alfke s...@google.com wrote: On Jan 15, 2010, at 10:37 AM, Peter Kasting wrote: One thing to note is that Chromium uses neither a distributed VC system nor Bugzilla, so your development process will look a little different than with Mozilla patches. Actually you can work on Chrome using githttp://code.google.com/p/chromium/wiki/UsingGit; it just takes a bit more work to get it set up, and you have to use special commands to push or pull. But IMHO it's worth the up-front cost. You should probably decide beforehand whether to use git or SVN, since the two checkouts aren't compatible, so switching from one to the other requires a lengthy download. —Jens -- 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
