[chromium-dev] Re: When disabling a test, please assign to whoever wrote it
This is still happening. VERY annoying. ANYONE who is disabling tests, marking them flaky, etc needs to take the 30 seconds required to svn blame the file and cc people the relevant people. On Tue, Sep 22, 2009 at 2:33 PM, Aaron Boodman a...@chromium.org wrote: Seriously. In a project as big as Chrome, tests are *critical* and a disabled test can hurt a team within just a few days. This has happened to me a few times and it is terrifying to find out a test that you think was proving you are working had actually been disabled. Disabling bad tests is super important, and I'm not arguing against that. Just make sure that someone knows that it was done who can take action on it. - a On Tue, Sep 22, 2009 at 12:40 PM, John Abd-El-Malek j...@chromium.org wrote: It only takes a few moments to figure out this information, and ensures that the bug lands on the right person's desk. http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the initial test For commits before we moved to the open source repository, look at http://chrome-corpsvn.mtv/viewvc/trunk/?root=chrome (internal only) 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
Hrmm... it looks your script assumes depot_tools is in your PATH -- if it can't find it the script crashes. Trying to figure out a workaround. If all else fails I can always give in and add depot_tools to my PATH :) On Wed, Oct 14, 2009 at 11:08 PM, Aaron Boodman a...@chromium.org wrote: Hooray, this is awesome. On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips ch...@chromium.org wrote: If you don't use git-cl, you can stop reading now. Attention git-cl users: git-cl now has presubmit support! New users that set up their git checkout on or after Wednesday (2009/10/14) are already configured with presubmit support. Feel free to skip the setup instructions since you've already run them but read on to learn more about the recent changes. Presubmit support for Existing Users (if you set up your git checkout before 2009/10/14): Run these commands to install the required git hooks in your repository: cd /work/chromium/src # where /work/chromium/src is the path to your git repository gclient sync # to upgrade your copy of depot_tools and git-cl git cl config http://src.chromium.org/svn/ # to install the git-cl presubmit hooks You must rerun the git cl config command in each of your local git repositories. New and updated git-cl commands: git-cl presubmit Runs upload and commit presubmit checks on the current changelist. git-cl upload Runs presubmit tests on upload, continues even if tests fail. git-cl dcommit Run presubmit tests on commit, halts if tests fail. To bypass the presubmit tests in upload or dcommit, use the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks along with skipping the commit confirm prompt. Questions? Feel free to reply to me off-list with any questions you have. Thanks to Evan Martin, Marc-Antoine Ruel, and Nicolas Sylvain for their help making git-cl presubmit support a reality. Chase --~--~-~--~~~---~--~~ 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 it time to create a SecurityOrigin class in Chromium?
On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow jor...@chromium.org wrote: I think the main points of contention regarding SecurityOrigin::toString() are the name toString and what type it should return. In terms of the names: I think we should provide constructors and getters for each component of each WebKit API type. So, for example, WebSecurityOrigin should have a constructor that takes in a single string and a getter called |origin|. It seems strange for something that is an origin to have a getter named origin. It leads to code like this: origin-origin(), which seems bad to me. toString() is the name used by WebCore, and it seems reasonable to me. It is merely a method that returns a string representation of the SecurityOrigin suitable for pickling. What is your objection to toString? (We can argue about the name later.) base::SecurityOrigin I mentioned before that base is not the right place for SecurityOrigin. See Brett's posts about what should and shouldn't be part of base/. It is a dumping ground today, and we should resist more of that will full force. In this case, only webkit/glue and above needs this type, so it does not need to live in base/. can then have a method to produce WebSecurityOrigins (using that constructor that takes in the base componentswhich is just origin in this classes case) and it can have a constructor that takes in a WebSecurityOrigin (which will construct itself by using the aforementioned getter(s)). This seems fine to me provided we actually need WebSecurityOrigin or SecurityOrigin to expose the component parts. However, I haven't seen any use cases for that yet. Maybe I have missed them? In terms of what it should return: Each component should really be a C++ primitive. This of course leaves the question of how to handle strings. Personally, I think we should do one of 2 things: Either WebString should expose its components (an array of unsigned shorts + a size_t) WebString already has accessors for the array of unsigned shorts and a size_t for the length. or we should just put string16 into the WebKit API. The latter is not as insane as it sounds: it's just a special case of std::string. The former isn't that insane either since it can be fed directly to a std::string(16) constructor. The WebKit API is intended to be usable by consumers who do not have a full STL implementation (e.g., Android). If we add the proper constructors and factories for WebKit types to NullableString16, GURL, SecurityOrigin, and any other types we might want to connect to WebKit types in the future, then we can actually make the dependency 100% one way. It is OK for the WebKit API to know about GURL since WebCore depends on googleurl (specifically the generic, implementation bits). However, since GURL uses STL, there is just an optional (#ifdef controlled) conversion helper on WebURL for it. The same does not apply for NullableString16 or SecurityOrigin. I guess I feel like we should either say that depending on base types is OK (as long as we think they'll be very stable implementation wise) or we should say they're never allowed. This middle ground just feels wrong. Note that the difference between toString and a single getter that returns a string is subtle, but if all WebKit types follow this same convention, then it's much less likely that people will do stupid things with them. I generally prefer all or nothing approaches too, but the implicit conversions to string16 and std::string are extremely nice. I don't want to give them up. At the same time, I object to building further dependencies on base from svn.webkit.org. NullableString16 seemed like a reasonable addition since it is just a slight variant of string16 that we can probably afford to treat as frozen. -Darin J On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow jor...@chromium.orgwrote: You mean string16, right? I see instances of std::string and string16. I would be happiest if we unified on one. string16 is probably the path of least resistance. std::string has the benefit of being more compact, which for something like this which is really just a bag of bytes is probably a good thing. I really don't think it buys us much if it's purely optional that people put the security origin (in string representation) into a wrapper that then blocks them from doing anything silly with it. we could give it a ToString() method. i think the point of SecurityOrigin would be to guide people in the right direction. -darin More to the point, I don't think it's useful enough that I'm going to bother implementing it. If someone else wants to, I'd probably use it. On Wed, Oct 14, 2009 at 4:47 PM, Darin Fisher da...@chromium.orgwrote: To be clear: I only weakly advocate Chrome having a SecurityOrigin. I'm also OKwith just using
[chromium-dev] Who's sheriff?
Today on the waterfall, I see: Sheriffs: munjal From past experience, one sheriff really isn't enough. Munjal should be able to take a lunch break. Also, I think that this will be his first stint as sheriff. It would probably help him out if he had a co-sheriff who had done it at least once before. (Munjal, apologies if you've done it before and I missed it - in that case, maybe we can get you a rookie co-sheriff so you can be the mentor.) Who's sheriff? What do we do in cases where a sheriff declines or goes on vacation without swapping with someone else? 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: Canary bot, now with formatted layout test results
This makes me very happy! 2009/10/15 Glenn Wilson gwil...@chromium.org: Hi Webkit gardeners, The Windows canary bot now generates formatted layout test results on each build that had unexpected failing layout tests, which means you can quickly see layout test failures, diffs, and upstream baselines without running the tool manually. The goal of this output is to help gardeners assess what may have changed, and how to best handle the failure. For example, here are the failures for build 13359: http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html To see the formatted layout test failures for a specific canary build, just click on the layout test results link in the archive webkit test results step, then click on the index-.html file. There's still more work to do, including getting the formatter working properly on the Mac Linux canaries, adding flakiness data, adding a link directly to the waterfall display, and more. Many thanks go to Ojan, Nicolas and all others who endured my many code reviews, and Eric Roman and Dimitri for the original spec and design. Please let me know what you think, and what changes you'd like to see. Glenn -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Running applications in chrome with javascript
hi! i want to know how to run an applicacion with the chrome, as the same as activeX in IE and xpcom interfaces in Mozilla... 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] hi!
- --~--~-~--~~~---~--~~ 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: Who owns crash...@chromium.org and why is there so many updates from it?
Disabled the auto-crash features for Mac. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Oct 12, 2009 at 9:44 AM, Mike Pinkerton pinker...@chromium.orgwrote: I just had crashbot add a totally unrelated stack trace to a bug. I emailed anthony about it, we'll see. Something is clearly wrong. On Mon, Oct 12, 2009 at 12:41 PM, Scott Hess sh...@chromium.org wrote: Does this relate to receiving crashbot emails adding Crash labels on closed-out bugs where the backtrace doesn't apparently have any relevance to the original backtraces involved with the bug? I've gotten a couple of these in the past week. -scott [Unfortunately, I don't remember the earlier one, the latter is http://crbug.com/13113 ] On Tue, Oct 6, 2009 at 9:58 PM, John Abd-El-Malek j...@chromium.org wrote: On Tue, Oct 6, 2009 at 8:57 PM, Anthony LaForge lafo...@chromium.org wrote: The short of it: People manually associated bugs in http:crash My tool creates its own map of signatures and for whatever reason that bug is on all of them It goes through each aggregate signature and updates the status of the bug (which is a flash crasher) It's made much worse because we are dealing w/ crashes that don't have symbols and cannot be aggregated... What went wrong: The limiting function (seeing if crash-VERSION) was applied does not happen for priority updates. This was actually intentional since we start looking at crash data early on. However this should no longer be needed since we wait for enough data that priority should no longer be shifting. What can be done about it? I will put a limiter on setting the priority Thanks. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 8:46 PM, Patrick Johnson patr...@chromium.org wrote: John's question is about why it's generating so many issue updates. Patrick On Tue, Oct 6, 2009 at 8:41 PM, Anthony LaForge lafo...@chromium.org wrote: It's the role account that manages crashes and crash related bugs. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 6, 2009 at 7:26 PM, Patrick Johnson patr...@chromium.org wrote: [+laforge] On Tue, Oct 6, 2009 at 6:51 PM, John Abd-El-Malek j...@chromium.org wrote: I got 21 emails in the last day for http://code.google.com/p/chromium/issues/detail?id=20915 -- 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] How To Compile Chrome OS
Is it possible to Compile Chrome OS version of Chromium? Where I can find more news? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Canary bot, now with formatted layout test results
Hi Webkit gardeners, The Windows canary bot now generates formatted layout test results on each build that had unexpected failing layout tests, which means you can quickly see layout test failures, diffs, and upstream baselines without running the tool manually. The goal of this output is to help gardeners assess what may have changed, and how to best handle the failure. For example, here are the failures for build 13359: http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html To see the formatted layout test failures for a specific canary build, just click on the layout test results link in the archive webkit test results step, then click on the index-.html file. There's still more work to do, including getting the formatter working properly on the Mac Linux canaries, adding flakiness data, adding a link directly to the waterfall display, and more. Many thanks go to Ojan, Nicolas and all others who endured my many code reviews, and Eric Roman and Dimitri for the original spec and design. Please let me know what you think, and what changes you'd like to see. 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: Is it time to create a SecurityOrigin class in Chromium?
I guess you're rightabout pretty much everything. I'll put it in chrome/common then? (Note I actually wasn't planning on putting it in base unless the API depended on it, but it seemed like including that would just make what I was saying more confusing.) On Thu, Oct 15, 2009 at 12:19 AM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 7:17 PM, Jeremy Orlow jor...@chromium.org wrote: I think the main points of contention regarding SecurityOrigin::toString() are the name toString and what type it should return. In terms of the names: I think we should provide constructors and getters for each component of each WebKit API type. So, for example, WebSecurityOrigin should have a constructor that takes in a single string and a getter called |origin|. It seems strange for something that is an origin to have a getter named origin. It leads to code like this: origin-origin(), which seems bad to me. toString() is the name used by WebCore, and it seems reasonable to me. It is merely a method that returns a string representation of the SecurityOrigin suitable for pickling. What is your objection to toString? (We can argue about the name later.) base::SecurityOrigin I mentioned before that base is not the right place for SecurityOrigin. See Brett's posts about what should and shouldn't be part of base/. It is a dumping ground today, and we should resist more of that will full force. In this case, only webkit/glue and above needs this type, so it does not need to live in base/. can then have a method to produce WebSecurityOrigins (using that constructor that takes in the base componentswhich is just origin in this classes case) and it can have a constructor that takes in a WebSecurityOrigin (which will construct itself by using the aforementioned getter(s)). This seems fine to me provided we actually need WebSecurityOrigin or SecurityOrigin to expose the component parts. However, I haven't seen any use cases for that yet. Maybe I have missed them? In terms of what it should return: Each component should really be a C++ primitive. This of course leaves the question of how to handle strings. Personally, I think we should do one of 2 things: Either WebString should expose its components (an array of unsigned shorts + a size_t) WebString already has accessors for the array of unsigned shorts and a size_t for the length. or we should just put string16 into the WebKit API. The latter is not as insane as it sounds: it's just a special case of std::string. The former isn't that insane either since it can be fed directly to a std::string(16) constructor. The WebKit API is intended to be usable by consumers who do not have a full STL implementation (e.g., Android). If we add the proper constructors and factories for WebKit types to NullableString16, GURL, SecurityOrigin, and any other types we might want to connect to WebKit types in the future, then we can actually make the dependency 100% one way. It is OK for the WebKit API to know about GURL since WebCore depends on googleurl (specifically the generic, implementation bits). However, since GURL uses STL, there is just an optional (#ifdef controlled) conversion helper on WebURL for it. The same does not apply for NullableString16 or SecurityOrigin. I guess I feel like we should either say that depending on base types is OK (as long as we think they'll be very stable implementation wise) or we should say they're never allowed. This middle ground just feels wrong. Note that the difference between toString and a single getter that returns a string is subtle, but if all WebKit types follow this same convention, then it's much less likely that people will do stupid things with them. I generally prefer all or nothing approaches too, but the implicit conversions to string16 and std::string are extremely nice. I don't want to give them up. At the same time, I object to building further dependencies on base from svn.webkit.org. NullableString16 seemed like a reasonable addition since it is just a slight variant of string16 that we can probably afford to treat as frozen. -Darin J On Wed, Oct 14, 2009 at 5:15 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 4:51 PM, Jeremy Orlow jor...@chromium.orgwrote: You mean string16, right? I see instances of std::string and string16. I would be happiest if we unified on one. string16 is probably the path of least resistance. std::string has the benefit of being more compact, which for something like this which is really just a bag of bytes is probably a good thing. I really don't think it buys us much if it's purely optional that people put the security origin (in string representation) into a wrapper that then blocks them from doing anything silly with it. we could give it a ToString() method. i think the point of SecurityOrigin would be to guide
[chromium-dev] Re: Canary bot, now with formatted layout test results
Christmas came early for anyone working on WebKit! Thanks Glen. :-) On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry erik.co...@gmail.com wrote: This makes me very happy! 2009/10/15 Glenn Wilson gwil...@chromium.org: Hi Webkit gardeners, The Windows canary bot now generates formatted layout test results on each build that had unexpected failing layout tests, which means you can quickly see layout test failures, diffs, and upstream baselines without running the tool manually. The goal of this output is to help gardeners assess what may have changed, and how to best handle the failure. For example, here are the failures for build 13359: http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html To see the formatted layout test failures for a specific canary build, just click on the layout test results link in the archive webkit test results step, then click on the index-.html file. There's still more work to do, including getting the formatter working properly on the Mac Linux canaries, adding flakiness data, adding a link directly to the waterfall display, and more. Many thanks go to Ojan, Nicolas and all others who endured my many code reviews, and Eric Roman and Dimitri for the original spec and design. Please let me know what you think, and what changes you'd like to see. Glenn -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ 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-extensions] HTML5 spellcheck attribute
This is not really an extensions question. I think you want chromium-...@. - a On Thu, Oct 15, 2009 at 9:10 AM, Mixe twitter...@googlemail.com wrote: Chrome does not support HTML5 spellcheck attribute? Then why spellchecking is enabled by default? How we can disable (using JS) spellchecking into INPUT and TEXTAREA elements? For example, when a user put the path or another specific text into a text box, Chrome spellcheck always put red lines under the text :( A user may think that something is wrong. --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
Glenn, this tool is amazing! It really helped me yesterday on my 1st gardening shift. Re: upstream baselines without running the tool manually How do I do that? On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow jor...@chromium.org wrote: Christmas came early for anyone working on WebKit! Thanks Glen. :-) On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry erik.co...@gmail.com wrote: This makes me very happy! 2009/10/15 Glenn Wilson gwil...@chromium.org: Hi Webkit gardeners, The Windows canary bot now generates formatted layout test results on each build that had unexpected failing layout tests, which means you can quickly see layout test failures, diffs, and upstream baselines without running the tool manually. The goal of this output is to help gardeners assess what may have changed, and how to best handle the failure. For example, here are the failures for build 13359: http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html To see the formatted layout test failures for a specific canary build, just click on the layout test results link in the archive webkit test results step, then click on the index-.html file. There's still more work to do, including getting the formatter working properly on the Mac Linux canaries, adding flakiness data, adding a link directly to the waterfall display, and more. Many thanks go to Ojan, Nicolas and all others who endured my many code reviews, and Eric Roman and Dimitri for the original spec and design. Please let me know what you think, and what changes you'd like to see. Glenn -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ 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-extensions] HTML5 spellcheck attribute
On Thu, Oct 15, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote: This is not really an extensions question. I think you want chromium-...@. - a On Thu, Oct 15, 2009 at 9:10 AM, Mixe twitter...@googlemail.com wrote: Chrome does not support HTML5 spellcheck attribute? Then why spellchecking is enabled by default? How we can disable (using JS) spellchecking into INPUT and TEXTAREA elements? I think there is a bug here, the spellcheck attribute should work. textarea spellcheck=false works, but myTextArea.spellcheck = false seems not to. Can you file a bug for this at crbug.com? For example, when a user put the path or another specific text into a text box, Chrome spellcheck always put red lines under the text :( A user may think that something is wrong. --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
Replying off-list as requested... Firstly, this is awesome! On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips ch...@chromium.org wrote: git-cl upload Runs presubmit tests on upload, continues even if tests fail. This latter part is different than the gcl version. Is that intentional? I don't have an opinion on which is the correct behavior, but it would be nice to keep the scripts consistent. To bypass the presubmit tests in upload or dcommit, use the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks along with skipping the commit confirm prompt. Ditto above. The gcl flag is --no-presubmit. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test dashboard goofup
I put some more thought into this. Given that we only store a month's worth of data, it's not worth doing backups. Keeping around all the data (maybe a year's worth?) would be awesome though. I actually think that would not be too much work and would add value to the dashboard. At that point, doing backups seems more worthwhile. I'm happy to walk someone through how to make this happen. It really would not be a lot of work if you have a workable knowledge of Python and JS. Ojan On Wed, Oct 14, 2009 at 5:15 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Wed, Oct 14, 2009 at 4:53 PM, Ojan Vafai o...@google.com wrote: The data is stored in a single file per bot. For example, the webkit release bot's results are at http://build.chromium.org/buildbot/layout_test_results/webkit-rel/results.json. That file holds all the historical data for that bot and is copied over during the archive step of each run. We intentionally limit the number of results we keep in that file to 750 runs to keep filesize down. In my accidental checking, I changed 750 to 9. :( A little bit unrelated: This data, along with all the data on build.chromium.org, is replicated on at least 4 machines. It would be easy to recover the data if the server dies for example. We are also planning to do daily backups, but the data is huge. For example, we archive 25GB of new layout test results every day. Nicolas A trivial to implement backup would be to also copy the file to the archive location for just that run (same place as where we copy layout_test_results.zip), e.g. also copy it to http://build.chromium.org/buildbot/layout_test_results/webkit-rel/29056/. The downside is that this uses up disk space (e.g. the largest results.json file was 25mb before being clobbered). Another problem with backing up is that you'd also have to find a way to restore from backup that didn't lose data from runs that happened since the problem occurred. Merging the two files results.json should be pretty relatively trivial code, but it's all code that someone would need to write and test. While it sucks, I don't think backing up this data is worth the effort. It's a temporary productivity hit for the team, but we get enough new data to make reasonable decisions relatively quickly. Mistakes like this are very rare. It will become even more rare as coding work on the dashboard winds down. Feel free to have at it if you disagree. Creates the results.json file and it's content: trunk/src/webkit/tools/layout_tests/layout_package/json_results_generator.py Copies the results.json file to the right place: trunk/tools/buildbot/scripts/slave/chromium/archive_layout_test_results.py Ojan On Wed, Oct 14, 2009 at 4:24 PM, Jeremy Orlow jor...@chromium.orgwrote: I haven't actually gotten anything done on LocalStorage this week because I've been doing so many small side projects like this.but if it's a priority, sure. How about a cron job on some machine that ssh's via a cert into whatever machines the data is stored on, pulls it back, and dumps it into some dir? When we start filling up the hard drive, we can look at doing something smarter, deleting old data, or putting it somewhere like GFS. What server can I use and where's the data stored? On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin e...@chromium.org wrote: Sounds like we've got a volunteer! :D :D :D On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote: I assume we're going to start backing this data up from now on? On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting pkast...@google.com wrote: On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai o...@google.com wrote: I accidentally checked in some test code (one number was wrong!) and clobbered all but 10 of the runs of data for each builder. There's no way to recover it. Do you moonlight for the Danger team at Microsoft? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
Hi Andrew, On Wed, Oct 14, 2009 at 11:31 PM, Andrew Scherkus scher...@chromium.orgwrote: Hrmm... it looks your script assumes depot_tools is in your PATH -- if it can't find it the script crashes. Thanks for pointing this out. The hooks should fail gracefully in those cases, so I'll make that happen. Trying to figure out a workaround. If all else fails I can always give in and add depot_tools to my PATH :) I am under the impression depot_tools in each of our PATHs was already a hard requirement. Are tools like git-cl, git-try, trychange.py, etc in some other directory in your PATH, or do you run them with absolute paths, or ...? Giving in might be best. :) Chase On Wed, Oct 14, 2009 at 11:08 PM, Aaron Boodman a...@chromium.org wrote: Hooray, this is awesome. On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips ch...@chromium.org wrote: If you don't use git-cl, you can stop reading now. Attention git-cl users: git-cl now has presubmit support! New users that set up their git checkout on or after Wednesday (2009/10/14) are already configured with presubmit support. Feel free to skip the setup instructions since you've already run them but read on to learn more about the recent changes. Presubmit support for Existing Users (if you set up your git checkout before 2009/10/14): Run these commands to install the required git hooks in your repository: cd /work/chromium/src # where /work/chromium/src is the path to your git repository gclient sync # to upgrade your copy of depot_tools and git-cl git cl config http://src.chromium.org/svn/ # to install the git-cl presubmit hooks You must rerun the git cl config command in each of your local git repositories. New and updated git-cl commands: git-cl presubmit Runs upload and commit presubmit checks on the current changelist. git-cl upload Runs presubmit tests on upload, continues even if tests fail. git-cl dcommit Run presubmit tests on commit, halts if tests fail. To bypass the presubmit tests in upload or dcommit, use the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks along with skipping the commit confirm prompt. Questions? Feel free to reply to me off-list with any questions you have. Thanks to Evan Martin, Marc-Antoine Ruel, and Nicolas Sylvain for their help making git-cl presubmit support a reality. Chase --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Memory] Observations on memory usage in flickr
I spent some time this morning looking at Chrome's memory usage (on OS X 10.5.8) while viewing flickr.com. First I simply started at my photo- stream page and hit Reload over and over. Next I tried going through all of my photos one by one. I used the RPRVT column in 'top', and the 'heap' and 'mmap' tools to examine memory usage. Reloading: • Memory usage keeps going up. The renderer starts at about 13MB resident, and goes up a little over 1MB after each reload. I could easily get it up above 50MB. There is some GC going on during the first few reloads, but not after that. Both the malloc and v8 heaps are growing, primarily malloc. • Forcing full GCs brings usage down somewhat, but you have to do it at least five or six times. • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. Browsing multiple pages: • Similar memory growth, as above. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. Conclusions: • As already known, V8 isn't collecting enough objects that have handles to big native object trees. • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. • There may be an opportunity in WebCore to toss out image backing stores more aggressively. —Jens --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 11:03 AM, Chase Phillips ch...@chromium.org wrote: Hi Andrew, On Wed, Oct 14, 2009 at 11:31 PM, Andrew Scherkus scher...@chromium.orgwrote: Hrmm... it looks your script assumes depot_tools is in your PATH -- if it can't find it the script crashes. Thanks for pointing this out. The hooks should fail gracefully in those cases, so I'll make that happen. Trying to figure out a workaround. If all else fails I can always give in and add depot_tools to my PATH :) I am under the impression depot_tools in each of our PATHs was already a hard requirement. Are tools like git-cl, git-try, trychange.py, etc in some other directory in your PATH, or do you run them with absolute paths, or ...? For git-cl and git-try, they're symlinked from ~/bin to my depot_tools and everything seems to work. The difference here is that the git hook is executed from .git/hooks Giving in might be best. :) Already did :) Chase On Wed, Oct 14, 2009 at 11:08 PM, Aaron Boodman a...@chromium.org wrote: Hooray, this is awesome. On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips ch...@chromium.org wrote: If you don't use git-cl, you can stop reading now. Attention git-cl users: git-cl now has presubmit support! New users that set up their git checkout on or after Wednesday (2009/10/14) are already configured with presubmit support. Feel free to skip the setup instructions since you've already run them but read on to learn more about the recent changes. Presubmit support for Existing Users (if you set up your git checkout before 2009/10/14): Run these commands to install the required git hooks in your repository: cd /work/chromium/src # where /work/chromium/src is the path to your git repository gclient sync # to upgrade your copy of depot_tools and git-cl git cl config http://src.chromium.org/svn/ # to install the git-cl presubmit hooks You must rerun the git cl config command in each of your local git repositories. New and updated git-cl commands: git-cl presubmit Runs upload and commit presubmit checks on the current changelist. git-cl upload Runs presubmit tests on upload, continues even if tests fail. git-cl dcommit Run presubmit tests on commit, halts if tests fail. To bypass the presubmit tests in upload or dcommit, use the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks along with skipping the commit confirm prompt. Questions? Feel free to reply to me off-list with any questions you have. Thanks to Evan Martin, Marc-Antoine Ruel, and Nicolas Sylvain for their help making git-cl presubmit support a reality. Chase --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 10:38 AM, Ojan Vafai o...@chromium.org wrote: Replying off-list as requested... Right! ;) Firstly, this is awesome! Thanks. On Wed, Oct 14, 2009 at 10:35 PM, Chase Phillips ch...@chromium.orgwrote: git-cl upload Runs presubmit tests on upload, continues even if tests fail. This latter part is different than the gcl version. Is that intentional? I don't have an opinion on which is the correct behavior, but it would be nice to keep the scripts consistent. I agree about keeping them as consistent as possible. However, my tests of gcl upload show they already have the same behavior here: gcl uploads the patch to codereview whether or not the presubmit step fails. I just tested this twice again to confirm it. You see gcl fail to upload if the presubmit step fails? To bypass the presubmit tests in upload or dcommit, use the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks along with skipping the commit confirm prompt. Ditto above. The gcl flag is --no-presubmit. I considered both gcl and git's convention. I decided I would first wait to see if anyone cared enough to raise the issue and take it from there. :) git-cl is not Chromium-specific and using gcl's convention appeared to be a Chromium-specific solution. Based on that, I decided to go git's route where not running hooks is done using --bypass-hooks. This also seemed justified because git-cl's hooks could be used for more than just presubmit tests. It might be valid to add --no-presubmit to git-cl, or --bypass-hooks to gcl, or both. Thoughts? Chase --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 11:19 AM, Chase Phillips ch...@chromium.org wrote: To bypass the presubmit tests in upload or dcommit, use the --bypass-hooks flag. git-cl dcommit's -f now implies --bypass-hooks along with skipping the commit confirm prompt. Ditto above. The gcl flag is --no-presubmit. I considered both gcl and git's convention. I decided I would first wait to see if anyone cared enough to raise the issue and take it from there. :) git-cl is not Chromium-specific and using gcl's convention appeared to be a Chromium-specific solution. Based on that, I decided to go git's route where not running hooks is done using --bypass-hooks. This also seemed justified because git-cl's hooks could be used for more than just presubmit tests. It might be valid to add --no-presubmit to git-cl, or --bypass-hooks to gcl, or both. Thoughts? I agree with Chase's reasoning. Also, you shouldn't need to bypass hooks frequently enough for this to matter much, and nobody switches between these two tools (they either use one or the other). --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke s...@google.com wrote: • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. Once I get my MemoryPurger functionality checked in, I'd like you to try it and see if it can successfully purge this memory. It loops calling IdleNotification() until that returns true. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. My tool also dumps backing stores. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. -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: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. We've talked through these repeatedly and I think we've made good cases against them. WebCore canonicalizes security origins. At the moment, we never create security origins in Chrome. You've given some examples of where we _might_ (read: this is vaporware) do this in the future. For all the use cases I've seen so far, I would actually propose adding a canonicalizeSecurityOrigin() method to WebSecurityOrigin that would create a WebCore::SecurityOrigin and then immediately toString() it. What other use cases are there? With each one, please make clear whether it's something we need today or whether it's something you suspect we'll need in the future...because I think most if not all of them are in this second bucket. And I don't want us to code ourselves into a corner, but I also don't want us to write a bunch of dead code that may be used in the future. --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke s...@google.com wrote: I spent some time this morning looking at Chrome's memory usage (on OS X 10.5.8) while viewing flickr.com. First I simply started at my photo- stream page and hit Reload over and over. Next I tried going through all of my photos one by one. I used the RPRVT column in 'top', and the 'heap' and 'mmap' tools to examine memory usage. Reloading: • Memory usage keeps going up. The renderer starts at about 13MB resident, and goes up a little over 1MB after each reload. I could easily get it up above 50MB. There is some GC going on during the first few reloads, but not after that. Both the malloc and v8 heaps are growing, primarily malloc. • Forcing full GCs brings usage down somewhat, but you have to do it at least five or six times. • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. The suspicion is that V8 is holding handles active that are keeping the old DOM alive after refresh, so perhaps we need a way to tell V8 to actively attempt to purge its handles to C++. This would be called after a refresh or a navigation. - James Browsing multiple pages: • Similar memory growth, as above. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. Conclusions: • As already known, V8 isn't collecting enough objects that have handles to big native object trees. • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. • There may be an opportunity in WebCore to toss out image backing stores more aggressively. —Jens --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:11 AM, Jens Alfke s...@google.com wrote: I spent some time this morning looking at Chrome's memory usage (on OS X 10.5.8) while viewing flickr.com. First I simply started at my photo- stream page and hit Reload over and over. Next I tried going through all of my photos one by one. I used the RPRVT column in 'top', and the 'heap' and 'mmap' tools to examine memory usage. Reloading: • Memory usage keeps going up. The renderer starts at about 13MB resident, and goes up a little over 1MB after each reload. I could easily get it up above 50MB. There is some GC going on during the first few reloads, but not after that. Both the malloc and v8 heaps are growing, primarily malloc. • Forcing full GCs brings usage down somewhat, but you have to do it at least five or six times. • Switching to another tab in the same window is the only way to get heap usage down significantly (by calling V8's IdleNotification) and even then it takes over a minute of occasional idle-time GC to have a significant effect. Browsing multiple pages: • Similar memory growth, as above. • Even hiding the tab doesn't bring memory usage down as much. The 'vmmap' tool shows that there's a lot of space allocated to CoreGraphics backing stores, much more than in the single-page case (like 13MB vs 1MB.) I'm not sure if this is for the images on the pages, or snapshots of the pages themselves for the back/forward cache. Safari 4 on Mac has similar behavior. Conclusions: • As already known, V8 isn't collecting enough objects that have handles to big native object trees. I disagree with this conclusion. V8 doesn't know anything about the large object trees. I think we (webkit) need to figure out how to clean up these trees independently. Since you said you're just reloading constantly, it could be that we're not cleaning up on page transitions. Alternatively, we could rework the bindings to allow cleanup of memory, while leaving only a small stub C++ wrapper. Webkit could cleanup it's huge object trees independent of GC this way. The bindings would need to be modified to deal with this case and error out (or re-wrap) appropriately. • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. We should try to avoid this. The V8 team has (rightfully) resisited hooks to allows the application to call gc() directly, because once you do that, invariably, some smart programmer decides to call gc() all the time!! :-) V8IdleNotification is basically a route to get at gc(). Let's not abuse it. If we're having problems getting memory cleaned up we should figure out: - where did the memory go in the first place - how to clean up incrementally We definitely don't want to grow too dependent on gc() to keep memory low. • There may be an opportunity in WebCore to toss out image backing stores more aggressively. —Jens --~--~-~--~~~---~--~~ 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: [announce] git-cl now has presubmit support.. read on to find out how to enable it!
On Thu, Oct 15, 2009 at 11:19 AM, Chase Phillips ch...@chromium.org wrote: On Thu, Oct 15, 2009 at 10:38 AM, Ojan Vafai o...@chromium.org wrote: Replying off-list as requested... Right! ;) Doh. However, my tests of gcl upload show they already have the same behavior here: gcl uploads the patch to codereview whether or not the presubmit step fails. I just tested this twice again to confirm it. You see gcl fail to upload if the presubmit step fails? Huh. I just tested this and see the opposite (it did not upload). I made a change that breaks the test_expectations.txt presubmit check. Maybe that's just a bug? git-cl is not Chromium-specific and using gcl's convention appeared to be a Chromium-specific solution. Based on that, I decided to go git's route where not running hooks is done using --bypass-hooks. This also seemed justified because git-cl's hooks could be used for more than just presubmit tests. It might be valid to add --no-presubmit to git-cl, or --bypass-hooks to gcl, or both. Thoughts? Ah. That makes more sense. Not sure it's worth bothering to put more work into this. As you said, if it becomes a problem we can always fix it later. --~--~-~--~~~---~--~~ 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: [Memory] Observations on memory usage in flickr
On Thu, Oct 15, 2009 at 11:57 AM, Mike Belshe mbel...@google.com wrote: • We should call V8::IdleNotification in situations other than a hidden tab. A long-lived tab might go for quite a while without being hidden in this way: the user might activate another app, hide Chrome itself, or just use multiple windows instead of tabs. We should try to avoid this. The V8 team has (rightfully) resisited hooks to allows the application to call gc() directly, because once you do that, invariably, some smart programmer decides to call gc() all the time!! :-) V8IdleNotification is basically a route to get at gc(). Let's not abuse it. I don't think it's unfair to call IdleNotification() on the foreground tab if e.g. the user has not done anything with it for five or ten minutes. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.org wrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. We've talked through these repeatedly and I think we've made good cases against them. WebCore canonicalizes security origins. At the moment, we never create security origins in Chrome. I wasn't implying that webcore's origin code wasn't doing the work, just mentioning the use case of determining an origin based on a url. Something like this could work. // Returns the security origin associated with the given url. (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL url); You've given some examples of where we _might_ (read: this is vaporware) do this in the future. For all the use cases I've seen so far, I would actually propose adding a canonicalizeSecurityOrigin() method to WebSecurityOrigin that would create a WebCore::SecurityOrigin and then immediately toString() it. What other use cases are there? With each one, please make clear whether it's something we need today or whether it's something you suspect we'll need in the future...because I think most if not all of them are in this second bucket. And I don't want us to code ourselves into a corner, but I also don't want us to write a bunch of dead code that may be used in the future. The use case is tracking usage per-origin in the appcache code. This isn't a hypothetical thing. --~--~-~--~~~---~--~~ 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 it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman micha...@google.comwrote: On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. We've talked through these repeatedly and I think we've made good cases against them. WebCore canonicalizes security origins. At the moment, we never create security origins in Chrome. I wasn't implying that webcore's origin code wasn't doing the work, just mentioning the use case of determining an origin based on a url. Something like this could work. // Returns the security origin associated with the given url. (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL url); You've given some examples of where we _might_ (read: this is vaporware) do this in the future. For all the use cases I've seen so far, I would actually propose adding a canonicalizeSecurityOrigin() method to WebSecurityOrigin that would create a WebCore::SecurityOrigin and then immediately toString() it. What other use cases are there? With each one, please make clear whether it's something we need today or whether it's something you suspect we'll need in the future...because I think most if not all of them are in this second bucket. And I don't want us to code ourselves into a corner, but I also don't want us to write a bunch of dead code that may be used in the future. The use case is tracking usage per-origin in the appcache code. This isn't a hypothetical thing. And also restricting access to resources based on origins, also not a hypothetical thing. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] bugtracker cleanup
Today I reviewed some old bugs which didn't get any attention and tried to correctly mark/assign/close them. Feel free to reassign a bug if I assigned it to you - I was generally looking for people familiar with the area so that they can decide what to do next (please not that the status of such bugs is unconfirmed and not assigned). A lot of bugs got marked with Area-Compat-* so the compatibility metric might be affected. I think I can continue the cleanup at least a little bit. However, if we could have a plan to deal with the bugs so that every bug gets proper attention and an owner, that would be great. --~--~-~--~~~---~--~~ 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 it time to create a SecurityOrigin class in Chromium?
On Thu, Oct 15, 2009 at 12:17 PM, Michael Nordman micha...@google.comwrote: On Thu, Oct 15, 2009 at 12:16 PM, Michael Nordman micha...@google.comwrote: On Thu, Oct 15, 2009 at 11:45 AM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Oct 15, 2009 at 11:33 AM, Michael Nordman micha...@google.comwrote: On Wed, Oct 14, 2009 at 4:42 PM, Darin Fisher da...@chromium.orgwrote: On Wed, Oct 14, 2009 at 3:50 PM, Adam Barth aba...@chromium.orgwrote: On Wed, Oct 14, 2009 at 2:48 PM, Michael Nordman micha...@google.com wrote: As mentioned f2f, this falls apart as soon as Chrome tries to manufacture a security origin. I'm not sure, may already have instances of that in the code base for all I know. I'm not sure Chrome is smart enough to manufacture a SecurityOrigin. There's a lot of tricky work in the canonicalization that we don't want to duplicate. Adam Agreed, and we shouldn't be in that business. I think for all our use cases, the factory for security origins can be WebCore. Chrome just needs to be able to serialize / de-serialize a security origin, compare them, and possibly access some component parts (though I'm not certain of this requirement). I think i have use cases for creating an 'origin' based on a GURL. We've talked through these repeatedly and I think we've made good cases against them. WebCore canonicalizes security origins. At the moment, we never create security origins in Chrome. I wasn't implying that webcore's origin code wasn't doing the work, just mentioning the use case of determining an origin based on a url. Something like this could work. // Returns the security origin associated with the given url. (Web)SecurityOrigin (Web)SecurityOrigin::fromURL((Web)URL url); You've given some examples of where we _might_ (read: this is vaporware) do this in the future. For all the use cases I've seen so far, I would actually propose adding a canonicalizeSecurityOrigin() method to WebSecurityOrigin that would create a WebCore::SecurityOrigin and then immediately toString() it. What other use cases are there? With each one, please make clear whether it's something we need today or whether it's something you suspect we'll need in the future...because I think most if not all of them are in this second bucket. And I don't want us to code ourselves into a corner, but I also don't want us to write a bunch of dead code that may be used in the future. The use case is tracking usage per-origin in the appcache code. This isn't a hypothetical thing. And also restricting access to resources based on origins, also not a hypothetical thing. I don't think I ever used the word hypothetical. Anyway, I think the WebSecurityOrigin::fromURL(blah)-toString() will work fine in this use case. But I might create a static method that's a shortcut for that just to make it super obvious to users. --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
Actually, can you package this so it could be upstreamed to webkit.org?
On Thu, Oct 15, 2009 at 1:09 PM, Glenn Wilson gwil...@chromium.org wrote:
The tool lives in
src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
actually be run against any builder, not just the canaries. Adding better
documentation is on the TODO list :)
(Also, re: adding link to waterfall, I think we can do this -- I'm
investigating now.)
On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman y...@chromium.orgwrote:
Glenn, this tool is amazing! It really helped me yesterday on my 1st
gardening shift.
Re: upstream baselines without running the tool manually
How do I do that?
On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow jor...@chromium.orgwrote:
Christmas came early for anyone working on WebKit! Thanks Glen. :-)
On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry erik.co...@gmail.comwrote:
This makes me very happy!
2009/10/15 Glenn Wilson gwil...@chromium.org:
Hi Webkit gardeners,
The Windows canary bot now generates formatted layout test results on
each
build that had unexpected failing layout tests, which means you can
quickly
see layout test failures, diffs, and upstream baselines without
running the
tool manually. The goal of this output is to help gardeners assess
what may
have changed, and how to best handle the failure.
For example, here are the failures for build 13359:
http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
To see the formatted layout test failures for a specific canary build,
just
click on the layout test results link in the archive webkit test
results
step, then click on the index-.html file.
There's still more work to do, including getting the formatter working
properly on the Mac Linux canaries, adding flakiness data, adding a
link
directly to the waterfall display, and more. Many thanks go to Ojan,
Nicolas and all others who endured my many code reviews, and Eric
Roman and
Dimitri for the original spec and design.
Please let me know what you think, and what changes you'd like to see.
Glenn
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] No co-sheriff today
I am the only scheduled sheriff today and there is no co-sheriff. I was out for 5 minutes to grab lunch and ran to my desk. The tree became red in the meantime. Sorry for not being thoughful to aks someone to cover for me during those 5 minutes. It would be great if someone can help me out today and tomorrow. -Munjal --~--~-~--~~~---~--~~ 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: No co-sheriff today
I'll keep an eye on things tomorrow morning (east coast hours). TVL On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai m...@chromium.org wrote: I've been sheriffing for Munjal for the past hour, when I found the tree in a bad state. I'm happy to keep helping, but it'd be great if some other folks would step up too. Mark Munjal wrote: I am the only scheduled sheriff today and there is no co-sheriff. I was out for 5 minutes to grab lunch and ran to my desk. The tree became red in the meantime. Sorry for not being thoughful to aks someone to cover for me during those 5 minutes. It would be great if someone can help me out today and tomorrow. --~--~-~--~~~---~--~~ 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: No co-sheriff today
On Thu, Oct 15, 2009 at 1:13 PM, Thomas Van Lenten thoma...@chromium.orgwrote: http://dev.chromium.org/developers/tree-sheriffs ...which is the top answer when you search for sheriff on dev.chromium.org. (Plug for automated tools) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: bugtracker cleanup
On Thu, Oct 15, 2009 at 12:41 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Today I reviewed some old bugs which didn't get any attention and tried to correctly mark/assign/close them. Feel free to reassign a bug if I assigned it to you - I was generally looking for people familiar with the area so that they can decide what to do next (please not that the status of such bugs is unconfirmed and not assigned). A lot of bugs got marked with Area-Compat-* so the compatibility metric might be affected. I think I can continue the cleanup at least a little bit. However, if we could have a plan to deal with the bugs so that every bug gets proper attention and an owner, that would be great. Thank you for doing this! I (and I think estade too) periodically skim through [os:linux status:unconfirmed] and try to at least comment on all the bugs that haven't seen any action in a while, so the number of bugs there tend to stay under 100 or so... --~--~-~--~~~---~--~~ 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: No co-sheriff today
oh. Thanks :) On Fri, Oct 16, 2009 at 1:13 AM, Thomas Van Lenten thoma...@chromium.orgwrote: http://dev.chromium.org/developers/tree-sheriffs On Thu, Oct 15, 2009 at 4:12 PM, Abubakar abubak...@gmail.com wrote: whats this sheriff thing can anyone explain :) ?I thought the first email was a spam hehe . On Fri, Oct 16, 2009 at 1:10 AM, Thomas Van Lenten thoma...@chromium.org wrote: I'll keep an eye on things tomorrow morning (east coast hours). TVL On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai m...@chromium.orgwrote: I've been sheriffing for Munjal for the past hour, when I found the tree in a bad state. I'm happy to keep helping, but it'd be great if some other folks would step up too. Mark Munjal wrote: I am the only scheduled sheriff today and there is no co-sheriff. I was out for 5 minutes to grab lunch and ran to my desk. The tree became red in the meantime. Sorry for not being thoughful to aks someone to cover for me during those 5 minutes. It would be great if someone can help me out today and tomorrow. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebKit Layouts bot pulling code from the canary?
The layout try bots are just too slow for the purposes of webkit gardening, which needs to keep up with the fast stream of layout test breakage coming from webkit.org. Gclient and compilation consume most of the time, but the gardener is usually only interested in the layout tests themselves. How hard would it be to ask the bots to use chrome built by the canaries rather than waste time rebuilding it from scratch? --~--~-~--~~~---~--~~ 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] Flaky tests and setTimeout
Another class of layout tests with bad setTimeouts in them -
Tests of the form:
body onload=runTest();
img
...
function runTest() {
// Wait for img to load
setTimeout(step2, 200);
}
These tests are not flaky, but the setTimeouts are completely
unnecessary (body onload always fires AFTER the img loads) and are just
leading to longer cycle times. If you encounter these, feel free to
eliminate the setTimeout and waitUntilDone calls.
Julie
On Tue, Oct 13, 2009 at 11:48 PM, Andrew Scherkus scher...@chromium.orgwrote:
On Tue, Oct 13, 2009 at 3:55 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus
scher...@chromium.orgwrote:
What's happening is loadstart fires and the video reloads which should
cause an abort event. For some reason load will occasionally fire after
loadstart, ending the test.
I know we can patch the test, but I've been digging through the event
dispatching code to verify that the flakiness isn't limited to Chromium.
Even if it is just limited to Chromium, it is still a bug, right? Unless
I'm not understanding, there's no case under which we should be patching the
test in the above case. I don't know anything about video events, so I don't
really know what event order guarantees there should be.
Ojan
Yeah it's has to be a bug somewhere, just tricky to track down due to the
thread interaction between the video subsystem and the renderer thread.
Andrew
--~--~-~--~~~---~--~~
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: WebKit Layouts bot pulling code from the canary?
Would another solution be to have canary bots for both release and debug? On Thu, Oct 15, 2009 at 1:58 PM, Yaar Schnitman y...@chromium.org wrote: The layout try bots are just too slow for the purposes of webkit gardening, which needs to keep up with the fast stream of layout test breakage coming from webkit.org. Gclient and compilation consume most of the time, but the gardener is usually only interested in the layout tests themselves. How hard would it be to ask the bots to use chrome built by the canaries rather than waste time rebuilding it from scratch? --~--~-~--~~~---~--~~ 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: WebKit Layouts bot pulling code from the canary?
That will help too. I've been missing On Thu, Oct 15, 2009 at 2:03 PM, Julie Parent jpar...@chromium.org wrote: Would another solution be to have canary bots for both release and debug? That will certainly help. I've rolled in test failures into our tree because the canaries didn't detect the debug ones. Still, it would be great if a gardener (or anybody) who's just changing some layout tests or expectations could test them against a specified build that already exists on one of the bots (e.g. the canaries), rather than wait 30-60 minutes for that build to complete. On Thu, Oct 15, 2009 at 1:58 PM, Yaar Schnitman y...@chromium.org wrote: The layout try bots are just too slow for the purposes of webkit gardening, which needs to keep up with the fast stream of layout test breakage coming from webkit.org. Gclient and compilation consume most of the time, but the gardener is usually only interested in the layout tests themselves. How hard would it be to ask the bots to use chrome built by the canaries rather than waste time rebuilding it from scratch? --~--~-~--~~~---~--~~ 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] Chromium terminates when running from Terminal
How exactly are you launching it? ie-what are you typing into the terminal. it might be the executable path change last night. TVL On Thu, Oct 15, 2009 at 6:07 PM, Mikhail Naganov mnaga...@chromium.orgwrote: Hi all, Starting from today, I can't run Chromium from Terminal, unless I'm running it under gdb. I'm getting the following bunch of error messages (on a Release build): 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in -[BrowserWindowController initWithWindowNibPath:owner:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not satisfying: windowNibPath 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: windowNibPath' 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( 2417545195, 2485780027, 2417544651, 2463723204, 2433132475, 36896176, 36889665, 36840062, 36542144, 36543780, 36611717, 36618850, 36622599, 36646971, 35731773 ) Trace/BPT trap If I launch Chromium from Finder, XCode, or under gdb in Terminal, it works fine. I've done a clean rebuild of Chromium, and I'm seeing this behavior on two machines. Does anyone have a similar problem, or maybe have a clue what goes wrong? --~--~-~--~~~---~--~~ 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] Chromium terminates when running from Terminal
How are you launching it from the Terminal? Can you tell me the exact invocation? $PATH and working directory too? Can you log the value of path after PathService::Get(base::FILE_EXE, path) in chrome::GetVersionedDirectory(), chrome/common/chrome_paths_mac.mm:72? Mark Mikhail Naganov wrote: Hi all, Starting from today, I can't run Chromium from Terminal, unless I'm running it under gdb. I'm getting the following bunch of error messages (on a Release build): 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in -[BrowserWindowController initWithWindowNibPath:owner:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not satisfying: windowNibPath 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: windowNibPath' 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( 2417545195, 2485780027, 2417544651, 2463723204, 2433132475, 36896176, 36889665, 36840062, 36542144, 36543780, 36611717, 36618850, 36622599, 36646971, 35731773 ) Trace/BPT trap If I launch Chromium from Finder, XCode, or under gdb in Terminal, it works fine. I've done a clean rebuild of Chromium, and I'm seeing this behavior on two machines. Does anyone have a similar problem, or maybe have a clue what goes wrong? --~--~-~--~~~---~--~~ 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] Chromium terminates when running from Terminal
Also answering on Mark's question. $ pwd /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS $ ls -l total 40 -rwxr-xr-x 1 mnaganov eng 16472 Oct 16 01:25 Chromium $ echo $PATH /opt/local/bin:/opt/local/sbin:/Users/mnaganov/depot_tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin/g4bin $ ./Chromium this way, it fails $ gdb ./Chromium (gdb) pwd Working directory /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS. (gdb) show paths Executable and object file path: /opt/local/bin:/opt/local/sbin:/Users/mnaganov/depot_tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin/g4bin:/sbin:/bin:/usr/sbin:/usr/bin (gdb) r Starting program: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/Chromium this way, it runs just fine Here is the value of 'path' when running from Terminal: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/./Chromium When I run it under gdb, the path is printed two times: /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/MacOS/Chromium /Users/mnaganov/chrome/src/xcodebuild/Release/Chromium.app/Contents/Versions/4.0.223.1/Chromium Helper.app/Contents/MacOS/Chromium Helper On Fri, Oct 16, 2009 at 02:10, Thomas Van Lenten thoma...@chromium.org wrote: How exactly are you launching it? ie-what are you typing into the terminal. it might be the executable path change last night. TVL On Thu, Oct 15, 2009 at 6:07 PM, Mikhail Naganov mnaga...@chromium.org wrote: Hi all, Starting from today, I can't run Chromium from Terminal, unless I'm running it under gdb. I'm getting the following bunch of error messages (on a Release build): 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in -[BrowserWindowController initWithWindowNibPath:owner:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not satisfying: windowNibPath 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: windowNibPath' 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( 2417545195, 2485780027, 2417544651, 2463723204, 2433132475, 36896176, 36889665, 36840062, 36542144, 36543780, 36611717, 36618850, 36622599, 36646971, 35731773 ) Trace/BPT trap If I launch Chromium from Finder, XCode, or under gdb in Terminal, it works fine. I've done a clean rebuild of Chromium, and I'm seeing this behavior on two machines. Does anyone have a similar problem, or maybe have a clue what goes wrong? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Change to default build architecture
http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: layout test dashboard goofup
I actually have a copy of the data from Tuesday at 2:30pm. If you need any information out of the results page, just let me know. Julie On Thu, Oct 15, 2009 at 10:58 AM, Ojan Vafai o...@google.com wrote: I put some more thought into this. Given that we only store a month's worth of data, it's not worth doing backups. Keeping around all the data (maybe a year's worth?) would be awesome though. I actually think that would not be too much work and would add value to the dashboard. At that point, doing backups seems more worthwhile. I'm happy to walk someone through how to make this happen. It really would not be a lot of work if you have a workable knowledge of Python and JS. Ojan On Wed, Oct 14, 2009 at 5:15 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Wed, Oct 14, 2009 at 4:53 PM, Ojan Vafai o...@google.com wrote: The data is stored in a single file per bot. For example, the webkit release bot's results are at http://build.chromium.org/buildbot/layout_test_results/webkit-rel/results.json. That file holds all the historical data for that bot and is copied over during the archive step of each run. We intentionally limit the number of results we keep in that file to 750 runs to keep filesize down. In my accidental checking, I changed 750 to 9. :( A little bit unrelated: This data, along with all the data on build.chromium.org, is replicated on at least 4 machines. It would be easy to recover the data if the server dies for example. We are also planning to do daily backups, but the data is huge. For example, we archive 25GB of new layout test results every day. Nicolas A trivial to implement backup would be to also copy the file to the archive location for just that run (same place as where we copy layout_test_results.zip), e.g. also copy it to http://build.chromium.org/buildbot/layout_test_results/webkit-rel/29056/. The downside is that this uses up disk space (e.g. the largest results.json file was 25mb before being clobbered). Another problem with backing up is that you'd also have to find a way to restore from backup that didn't lose data from runs that happened since the problem occurred. Merging the two files results.json should be pretty relatively trivial code, but it's all code that someone would need to write and test. While it sucks, I don't think backing up this data is worth the effort. It's a temporary productivity hit for the team, but we get enough new data to make reasonable decisions relatively quickly. Mistakes like this are very rare. It will become even more rare as coding work on the dashboard winds down. Feel free to have at it if you disagree. Creates the results.json file and it's content: trunk/src/webkit/tools/layout_tests/layout_package/json_results_generator.py Copies the results.json file to the right place: trunk/tools/buildbot/scripts/slave/chromium/archive_layout_test_results.py Ojan On Wed, Oct 14, 2009 at 4:24 PM, Jeremy Orlow jor...@chromium.orgwrote: I haven't actually gotten anything done on LocalStorage this week because I've been doing so many small side projects like this.but if it's a priority, sure. How about a cron job on some machine that ssh's via a cert into whatever machines the data is stored on, pulls it back, and dumps it into some dir? When we start filling up the hard drive, we can look at doing something smarter, deleting old data, or putting it somewhere like GFS. What server can I use and where's the data stored? On Wed, Oct 14, 2009 at 4:17 PM, Evan Martin e...@chromium.org wrote: Sounds like we've got a volunteer! :D :D :D On Wed, Oct 14, 2009 at 4:15 PM, Jeremy Orlow jor...@chromium.org wrote: I assume we're going to start backing this data up from now on? On Wed, Oct 14, 2009 at 4:13 PM, Peter Kasting pkast...@google.com wrote: On Wed, Oct 14, 2009 at 3:58 PM, Ojan Vafai o...@google.com wrote: I accidentally checked in some test code (one number was wrong!) and clobbered all but 10 of the runs of data for each builder. There's no way to recover it. Do you moonlight for the Danger team at Microsoft? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Canary bot, now with formatted layout test results
Yes, possibly. The tool is written explicitly for the Chromium builders'
output, so it would be plausible but non-trivial to generalize it.
It may not be as useful since I don't think they have a concept of an
'upstream' baseline. Those of you who do a lot of work upstream, would it
be worth upstreaming this?
Glenn
On Thu, Oct 15, 2009 at 12:44 PM, Marc-Antoine Ruel mar...@chromium.orgwrote:
Actually, can you package this so it could be upstreamed to webkit.org?
On Thu, Oct 15, 2009 at 1:09 PM, Glenn Wilson gwil...@chromium.orgwrote:
The tool lives in
src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
actually be run against any builder, not just the canaries. Adding better
documentation is on the TODO list :)
(Also, re: adding link to waterfall, I think we can do this -- I'm
investigating now.)
On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman y...@chromium.orgwrote:
Glenn, this tool is amazing! It really helped me yesterday on my 1st
gardening shift.
Re: upstream baselines without running the tool manually
How do I do that?
On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow jor...@chromium.orgwrote:
Christmas came early for anyone working on WebKit! Thanks Glen. :-)
On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry erik.co...@gmail.comwrote:
This makes me very happy!
2009/10/15 Glenn Wilson gwil...@chromium.org:
Hi Webkit gardeners,
The Windows canary bot now generates formatted layout test results on
each
build that had unexpected failing layout tests, which means you can
quickly
see layout test failures, diffs, and upstream baselines without
running the
tool manually. The goal of this output is to help gardeners assess
what may
have changed, and how to best handle the failure.
For example, here are the failures for build 13359:
http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
To see the formatted layout test failures for a specific canary
build, just
click on the layout test results link in the archive webkit test
results
step, then click on the index-.html file.
There's still more work to do, including getting the formatter
working
properly on the Mac Linux canaries, adding flakiness data, adding a
link
directly to the waterfall display, and more. Many thanks go to Ojan,
Nicolas and all others who endured my many code reviews, and Eric
Roman and
Dimitri for the original spec and design.
Please let me know what you think, and what changes you'd like to
see.
Glenn
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] LTTF helping the GTTF make cycle times *minutes* faster
There are a lot of tests that consistently (i.e. not flaky) timeout. They eat up significant percentage (~10%!) of the cycle time for the test bots (e.g., 1 minute on Windows release). If LTTF folk focus some effort on fixing these first, it would help all of us move forward faster as the bot cycle times would be improved as would the times to run the tests locally. To make this easier, I compiled the list of all the tests that consistently timeout. I excluded the flaky timeouts since the LTTF is currently focused on non-flaky failures. Any takers? Ojan ALL PLATFORMS: LayoutTests/fast/dom/Window/window-property-shadowing-name.html LayoutTests/fast/dom/cssTarget-crash.html LayoutTests/fast/events/add-event-without-document.html LayoutTests/http/tests/history/back-to-post.php LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html LayoutTests/http/tests/navigation/onload-navigation-iframe.html LayoutTests/http/tests/security/cross-frame-access-document-direct.html LayoutTests/http/tests/security/xss-DENIED-defineProperty.html LayoutTests/http/tests/xmlhttprequest/methods-async.html LayoutTests/loader/go-back-to-different-window-size.html LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-play-event.html LayoutTests/media/controls-drag-timebar.html LayoutTests/media/event-attributes.html LayoutTests/media/video-no-audio.html LayoutTests/media/video-source-add-src.html LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html LayoutTests/storage/domstorage/localstorage/iframe-events.html LayoutTests/storage/domstorage/sessionstorage/iframe-events.html WIN RELEASE+DEBUG: LayoutTests/http/tests/cache/subresource-expiration.html WIN DEBUG: LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html LINUX RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LINUX DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html MAC RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LayoutTests/http/tests/plugins/get-url.html LayoutTests/http/tests/plugins/interrupted-get-url.html LayoutTests/http/tests/plugins/npapi-response-headers.html LayoutTests/http/tests/plugins/post-url-file.html LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html LayoutTests/plugins/destroy-stream-twice.html LayoutTests/plugins/embed-inside-object.html LayoutTests/plugins/geturl-replace-query.html LayoutTests/plugins/npruntime.html LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html MAC RELEASE: LayoutTests/http/tests/cache/subresource-expiration.html MAC DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html --~--~-~--~~~---~--~~ 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: Canary bot, now with formatted layout test results
One could show baselines of all the other platforms instead of just an
upstream baseline.
I'm not really sure from the output what this tool does. So it's
difficult for me to tell how useful it would be to upstream.
-eric
On Thu, Oct 15, 2009 at 8:38 PM, Glenn Wilson gwil...@chromium.org wrote:
Yes, possibly. The tool is written explicitly for the Chromium builders'
output, so it would be plausible but non-trivial to generalize it.
It may not be as useful since I don't think they have a concept of an
'upstream' baseline. Those of you who do a lot of work upstream, would it
be worth upstreaming this?
Glenn
On Thu, Oct 15, 2009 at 12:44 PM, Marc-Antoine Ruel mar...@chromium.org
wrote:
Actually, can you package this so it could be upstreamed to webkit.org?
On Thu, Oct 15, 2009 at 1:09 PM, Glenn Wilson gwil...@chromium.org
wrote:
The tool lives in
src/webkit/tools/layout_tests/test_output_formatter{.bat,.sh}, and it can
actually be run against any builder, not just the canaries. Adding better
documentation is on the TODO list :)
(Also, re: adding link to waterfall, I think we can do this -- I'm
investigating now.)
On Thu, Oct 15, 2009 at 10:05 AM, Yaar Schnitman y...@chromium.org
wrote:
Glenn, this tool is amazing! It really helped me yesterday on my 1st
gardening shift.
Re: upstream baselines without running the tool manually
How do I do that?
On Thu, Oct 15, 2009 at 10:01 AM, Jeremy Orlow jor...@chromium.org
wrote:
Christmas came early for anyone working on WebKit! Thanks Glen. :-)
On Thu, Oct 15, 2009 at 9:17 AM, Erik Corry erik.co...@gmail.com
wrote:
This makes me very happy!
2009/10/15 Glenn Wilson gwil...@chromium.org:
Hi Webkit gardeners,
The Windows canary bot now generates formatted layout test results
on each
build that had unexpected failing layout tests, which means you can
quickly
see layout test failures, diffs, and upstream baselines without
running the
tool manually. The goal of this output is to help gardeners assess
what may
have changed, and how to best handle the failure.
For example, here are the failures for build 13359:
http://build.chromium.org/buildbot/layout_test_results/webkit-rel-webkit-org/29119/index-13359.html
To see the formatted layout test failures for a specific canary
build, just
click on the layout test results link in the archive webkit test
results
step, then click on the index-.html file.
There's still more work to do, including getting the formatter
working
properly on the Mac Linux canaries, adding flakiness data, adding
a link
directly to the waterfall display, and more. Many thanks go to
Ojan,
Nicolas and all others who endured my many code reviews, and Eric
Roman and
Dimitri for the original spec and design.
Please let me know what you think, and what changes you'd like to
see.
Glenn
--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.
--~--~-~--~~~---~--~~
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 helping the GTTF make cycle times *minutes* faster
I'll take on the media ones. On Thu, Oct 15, 2009 at 6:38 PM, Ojan Vafai o...@google.com wrote: There are a lot of tests that consistently (i.e. not flaky) timeout. They eat up significant percentage (~10%!) of the cycle time for the test bots (e.g., 1 minute on Windows release). If LTTF folk focus some effort on fixing these first, it would help all of us move forward faster as the bot cycle times would be improved as would the times to run the tests locally. To make this easier, I compiled the list of all the tests that consistently timeout. I excluded the flaky timeouts since the LTTF is currently focused on non-flaky failures. Any takers? Ojan ALL PLATFORMS: LayoutTests/fast/dom/Window/window-property-shadowing-name.html LayoutTests/fast/dom/cssTarget-crash.html LayoutTests/fast/events/add-event-without-document.html LayoutTests/http/tests/history/back-to-post.php LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html LayoutTests/http/tests/navigation/onload-navigation-iframe.html LayoutTests/http/tests/security/cross-frame-access-document-direct.html LayoutTests/http/tests/security/xss-DENIED-defineProperty.html LayoutTests/http/tests/xmlhttprequest/methods-async.html LayoutTests/loader/go-back-to-different-window-size.html LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-play-event.html LayoutTests/media/controls-drag-timebar.html LayoutTests/media/event-attributes.html LayoutTests/media/video-no-audio.html LayoutTests/media/video-source-add-src.html LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html LayoutTests/storage/domstorage/localstorage/iframe-events.html LayoutTests/storage/domstorage/sessionstorage/iframe-events.html WIN RELEASE+DEBUG: LayoutTests/http/tests/cache/subresource-expiration.html WIN DEBUG: LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html LINUX RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LINUX DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html MAC RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LayoutTests/http/tests/plugins/get-url.html LayoutTests/http/tests/plugins/interrupted-get-url.html LayoutTests/http/tests/plugins/npapi-response-headers.html LayoutTests/http/tests/plugins/post-url-file.html LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html LayoutTests/plugins/destroy-stream-twice.html LayoutTests/plugins/embed-inside-object.html LayoutTests/plugins/geturl-replace-query.html LayoutTests/plugins/npruntime.html LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html MAC RELEASE: LayoutTests/http/tests/cache/subresource-expiration.html MAC DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: [webkit-dev] Visual Studio 2005 ATL Security Update
In case any of you who hack on WebKit aren't on webkit-dev. (If that's you, you should definitely join webkit-dev now. It's very very low traffic and very high signal to noise ratio.) -eric -- Forwarded message -- From: Brian Weinstein bweinst...@apple.com Date: Thu, Oct 15, 2009 at 11:37 PM Subject: [webkit-dev] Visual Studio 2005 ATL Security Update To: webkit-dev Development webkit-...@lists.webkit.org At least a few people on IRC have noticed errors that look something like the following: 1) If you try to open FindSafari in Windows Explorer you will get the message This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. or 2) In the Control Panel-Administrative Tools-Events Viewer under the System events, you will see a SideBySide error with the message Dependent Assembly Microsoft.VC890.CRT could not be found and Last Error was The referenced assembly is not installed on your system. You need to install the Visual Studio 2005 ATL Security update, which is linked to from http://webkit.org/building/tools.html. The link to download the update is: Visual Studio 2005 Service Pack 1 ATL Security Update. This should fix the problem. Brian Weinstein ___ webkit-dev mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-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: Change to default build architecture
On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES=target_arch=ia32, of course. -- ukai On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss mm...@chromium.org wrote: http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ 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: Change to default build architecture
On Thu, Oct 15, 2009 at 8:59 PM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES=target_arch=ia32, of course. I haven't looked into it yet, but NaCl apparently has it's own notion of target_arch. For now, the best bet is probably explicitly setting GYP_DEFINES as you're doing. Michael On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss mm...@chromium.org wrote: http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ 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 helping the GTTF make cycle times *minutes* faster
I'm currently working on tests under LayoutTests/http/tests/navigation/. Thanks, Yuta 2009/10/16 Ojan Vafai o...@google.com There are a lot of tests that consistently (i.e. not flaky) timeout. They eat up significant percentage (~10%!) of the cycle time for the test bots (e.g., 1 minute on Windows release). If LTTF folk focus some effort on fixing these first, it would help all of us move forward faster as the bot cycle times would be improved as would the times to run the tests locally. To make this easier, I compiled the list of all the tests that consistently timeout. I excluded the flaky timeouts since the LTTF is currently focused on non-flaky failures. Any takers? Ojan ALL PLATFORMS: LayoutTests/fast/dom/Window/window-property-shadowing-name.html LayoutTests/fast/dom/cssTarget-crash.html LayoutTests/fast/events/add-event-without-document.html LayoutTests/http/tests/history/back-to-post.php LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html LayoutTests/http/tests/navigation/onload-navigation-iframe.html LayoutTests/http/tests/security/cross-frame-access-document-direct.html LayoutTests/http/tests/security/xss-DENIED-defineProperty.html LayoutTests/http/tests/xmlhttprequest/methods-async.html LayoutTests/loader/go-back-to-different-window-size.html LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-play-event.html LayoutTests/media/controls-drag-timebar.html LayoutTests/media/event-attributes.html LayoutTests/media/video-no-audio.html LayoutTests/media/video-source-add-src.html LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html LayoutTests/storage/domstorage/localstorage/iframe-events.html LayoutTests/storage/domstorage/sessionstorage/iframe-events.html WIN RELEASE+DEBUG: LayoutTests/http/tests/cache/subresource-expiration.html WIN DEBUG: LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html LINUX RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LINUX DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html MAC RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LayoutTests/http/tests/plugins/get-url.html LayoutTests/http/tests/plugins/interrupted-get-url.html LayoutTests/http/tests/plugins/npapi-response-headers.html LayoutTests/http/tests/plugins/post-url-file.html LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html LayoutTests/plugins/destroy-stream-twice.html LayoutTests/plugins/embed-inside-object.html LayoutTests/plugins/geturl-replace-query.html LayoutTests/plugins/npruntime.html LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html MAC RELEASE: LayoutTests/http/tests/cache/subresource-expiration.html MAC DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html --~--~-~--~~~---~--~~ 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: Change to default build architecture
On Thu, Oct 15, 2009 at 9:04 PM, Michael Moss mm...@chromium.org wrote: On Thu, Oct 15, 2009 at 8:59 PM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES=target_arch=ia32, of course. I haven't looked into it yet, but NaCl apparently has it's own notion of target_arch. For now, the best bet is probably explicitly setting GYP_DEFINES as you're doing. Michael You can also disable NaCl with disable_nacl=1 in GYP_DEFINES. Antoine On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss mm...@chromium.org wrote: http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ 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 helping the GTTF make cycle times *minutes* faster
I'll have a look at LayoutTests/fast/dom/Window/window-property-shadowing-name.html yours, anton. On Fri, Oct 16, 2009 at 8:13 AM, Yuta Kitamura yu...@chromium.org wrote: I'm currently working on tests under LayoutTests/http/tests/navigation/. Thanks, Yuta 2009/10/16 Ojan Vafai o...@google.com There are a lot of tests that consistently (i.e. not flaky) timeout. They eat up significant percentage (~10%!) of the cycle time for the test bots (e.g., 1 minute on Windows release). If LTTF folk focus some effort on fixing these first, it would help all of us move forward faster as the bot cycle times would be improved as would the times to run the tests locally. To make this easier, I compiled the list of all the tests that consistently timeout. I excluded the flaky timeouts since the LTTF is currently focused on non-flaky failures. Any takers? Ojan ALL PLATFORMS: LayoutTests/fast/dom/Window/window-property-shadowing-name.html LayoutTests/fast/dom/cssTarget-crash.html LayoutTests/fast/events/add-event-without-document.html LayoutTests/http/tests/history/back-to-post.php LayoutTests/http/tests/loading/deleted-host-in-resource-load-delegate-callback.html LayoutTests/http/tests/navigation/onload-navigation-iframe-2.html LayoutTests/http/tests/navigation/onload-navigation-iframe-timeout.html LayoutTests/http/tests/navigation/onload-navigation-iframe.html LayoutTests/http/tests/security/cross-frame-access-document-direct.html LayoutTests/http/tests/security/xss-DENIED-defineProperty.html LayoutTests/http/tests/xmlhttprequest/methods-async.html LayoutTests/loader/go-back-to-different-window-size.html LayoutTests/media/audio-constructor-src.html LayoutTests/media/audio-play-event.html LayoutTests/media/controls-drag-timebar.html LayoutTests/media/event-attributes.html LayoutTests/media/video-no-audio.html LayoutTests/media/video-source-add-src.html LayoutTests/platform/gtk/scrollbars/overflow-scrollbar-horizontal-wheel-scroll.html LayoutTests/storage/domstorage/localstorage/iframe-events.html LayoutTests/storage/domstorage/sessionstorage/iframe-events.html WIN RELEASE+DEBUG: LayoutTests/http/tests/cache/subresource-expiration.html WIN DEBUG: LayoutTests/http/tests/xmlhttprequest/redirect-cross-origin-tripmine.html LINUX RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LINUX DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html MAC RELEASE+DEBUG: LayoutTests/fast/loader/local-JavaScript-from-local.html LayoutTests/http/tests/misc/timer-vs-loading.html LayoutTests/http/tests/plugins/get-url.html LayoutTests/http/tests/plugins/interrupted-get-url.html LayoutTests/http/tests/plugins/npapi-response-headers.html LayoutTests/http/tests/plugins/post-url-file.html LayoutTests/http/tests/security/frameNavigation/xss-DENIED-plugin-navigation.html LayoutTests/plugins/destroy-stream-twice.html LayoutTests/plugins/embed-inside-object.html LayoutTests/plugins/geturl-replace-query.html LayoutTests/plugins/npruntime.html LayoutTests/plugins/return-error-from-new-stream-doesnt-invoke-destroy-stream.html MAC RELEASE: LayoutTests/http/tests/cache/subresource-expiration.html MAC DEBUG: LayoutTests/fast/css/large-list-of-rules-crash.html LayoutTests/fast/frames/frame-limit.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
