[chromium-dev] Re: V8 object-graph-tracing utilities?
Jens, another thing you should be aware of is that DOM nodes are only collected on full garbage collections. In order to see what is actually live at the end of a test, you have to force a number of GCs. If you run in the test shell with the --js-flags=--expose-gc flag, you can force gc's by typing javascript:gc() in the URL bar repeatedly. I can easily imagine that there are cycles between JS and C++ that keep DOM objects alive. I would like to see the reduced test case when you have it. Thanks,-- Mads On Wed, Sep 23, 2009 at 12:28 AM, Mike Belshe mbel...@google.com wrote: Because we have C++ and JS wrappers, and there may be references known to the C++ side not known to the JS side, we have to do an object grouping before we can call GC. This grouping takes all wrappers and groups them by their root; and then they are collected together. This happens in V8GCController::gcPrologue(). So you might fint that an interesting place to look. Mike On Tue, Sep 22, 2009 at 3:21 PM, Jens Alfke s...@google.com wrote: On Sep 22, 2009, at 2:54 PM, Mikhail Naganov wrote: I'm working on showing JS objects retainers. But this only works for objects that live inside V8's heap. That would still be useful — I'd love to be able to look at all the 'Window' objects in the heap and what ref chain is keeping them alive. Please let me know if there's something experimental I can try out. Thanks! —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: debugging the browser started by UI tests
I use --debug-children (usually in conjunction with --single-process). -Darin On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
Sending from proper account, sorry. On Wed, Sep 23, 2009 at 1:05 PM, Anton Muhin ant...@google.com wrote: In your case there should be not that many DOM windows objects and they all should survive in batches, so if I'd face such a problem, I'd just put a break point to see why this object got marked in the first place (that should be doable with simple conditional breakpoint). And just in case, Vitaly is working on leaks, so if you provide more details, chances are this issue is already known and being worked on. yours, anton. On Wed, Sep 23, 2009 at 1:47 AM, Jens Alfke s...@google.com wrote: Are there any utilities that can be used to see which native (DOM) objects are being referenced by JavaScript objects, and to follow references between JS objects to understand what's keeping an object from being GCd? (I'm working on reducing Chrome memory usage. One thing I've discovered is that WebCore::DOMWindow objects (and all their associated object trees) are sometimes being left behind. JavaScript seems to be implicated, as the problem goes away if I disable JS. So something in V8 seems to be holding onto references to DOMWindows, and I'd like to find out what it is.) Thanks! —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: Chromium isn't shutting down cleanly
sounds like this issue http://crbug.com/20451 On Sep 22, 8:39 pm, Daniel Cowx daniel.c...@gmail.com wrote: Can someone please provide a bit of insight into how to solve the following problem: 1. Open Chromium Options Show saved passwords 2. Click the Remove All button Now, *before* you click Yes or No, close the main browser window (e.g. by clicking the X in the upper right corner). When you do this, all windows disappear, but the main browser process remains running. It looks like this is due to a nested invocation of MessageLoop::Run() (via chrome\browser\views\confirm_message_box_dialog.cc) and the fact that Quit is only exiting the most recent invocation. How can we cleanly quit the application in this case? Cheers, Daniel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
On Tue, Sep 22, 2009 at 8:40 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Oh, and, if your change turned the tree red for 3 hours, don't be mad at the sheriff when he pings you repeatedly about the status of the fix. His job is to keep the tree green and running. He does not care about your change. Thoughts? Generally when this happens it's not the webkit gardener's change that has broken everything--it's an upstream change (usually by someone working on chromium, though not always). Since we are committed to taking all upstream webkit changes, and webkit continues to roll along while we clean up the damage, the webkit gardener's only choice is roll now or roll later. If the canary is red, roll later just means that more breakage will pile up behind it. Jeremy and Dmitry have covered most of what I was going to say; I agree that the real solution is to keep pedaling hard to finish the webkit API. Until we do that, all we're doing is to rearranging the pain, not reducing it. --Amanda --~--~-~--~~~---~--~~ 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 merges and tree closures
WebKit gardening occurs more often than sheriff duties. afaik all WebKit gardeners also have sheriff duties. This implies there are people on the team who don't have gardening duties. We need to fix that ASAP. Nobody should get special dispensation. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
On Wed, Sep 23, 2009 at 6:52 AM, Amanda Walker ama...@chromium.org wrote: ... I agree that the real solution is to keep pedaling hard to finish the webkit API. If anyone has cycles to help with the WebKit API, please let me know! :-) -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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
1) writers of patches don't mention that the patch is two-sided and will break Chromium if landed prematurely. I don't have to go far for an example. Commit queue bot landed http://trac.webkit.org/changeset/48659 a few minutes ago and broke the canary. This means that the canary will be red all night and any subsequent regressions will either not be noticed or create more complications. As I found out later that night (as I was fixing the bustage), this particular break wasn't due to the two-sided nature of the patch. It was a couple of missing includes. Apologies for mis-placing it into this category. This one was from the #2 pile :) :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. M-A --~--~-~--~~~---~--~~ 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 merges and tree closures
It is hard to be a WebKit gardener if you do not have WebKit commit access. Sometimes the gardener has to commit a quick bustage fix upstream or roll back a fellow Chromium committers change to WebKit. -Darin Correct, it is hard, but many/most of us who are webkit sheriffs/gardeners are not webkit committers (for example, the entire mac group). I don't understand your point. Are you saying that only webkit committers should be on the webkit sheriff rotation? -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
I find that being a WebKit gardener is always dancing on a minefield regardless of my familiarity with the WebKit code base. Look at yesterday for an example. In addition, we have several gardeners who are not actively working on WebKit (amanda@ has 0 WebKit commits, pinkerton@ has a few all in 2008). Lastly, can we add anyone to the rotation who has ideas how WebKit gardeners should/can do their job better? (This will help them in getting more ideas.) Dave On Wed, Sep 23, 2009 at 7:53 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Wed, Sep 23, 2009 at 7:46 AM, Mike Pinkerton pinker...@chromium.org wrote: It is hard to be a WebKit gardener if you do not have WebKit commit access. Sometimes the gardener has to commit a quick bustage fix upstream or roll back a fellow Chromium committers change to WebKit. -Darin Correct, it is hard, but many/most of us who are webkit sheriffs/gardeners are not webkit committers (for example, the entire mac group). I don't understand your point. Are you saying that only webkit committers should be on the webkit sheriff rotation? In my experience, better familiarity with WebKit code base is a huge advantage for a gardener. I am almost tempted to say that if you're not actively working on WebKit, being a gardener will be a foreign and dancing-on-a-minefield-type task. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
I'll take the action item to remove anyone in the rotation who is not actively working on Webkit / is not a committer. In the past, I've floated the idea in the past of having a Webkit deputy who helps the gardener keep the canary green. I'm not sure if that would help, though. Regards, Glenn On Wed, Sep 23, 2009 at 8:40 AM, David Levin le...@chromium.org wrote: I find that being a WebKit gardener is always dancing on a minefield regardless of my familiarity with the WebKit code base. Look at yesterday for an example. In addition, we have several gardeners who are not actively working on WebKit (amanda@ has 0 WebKit commits, pinkerton@ has a few all in 2008). Lastly, can we add anyone to the rotation who has ideas how WebKit gardeners should/can do their job better? (This will help them in getting more ideas.) Dave On Wed, Sep 23, 2009 at 7:53 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Wed, Sep 23, 2009 at 7:46 AM, Mike Pinkerton pinker...@chromium.org wrote: It is hard to be a WebKit gardener if you do not have WebKit commit access. Sometimes the gardener has to commit a quick bustage fix upstream or roll back a fellow Chromium committers change to WebKit. -Darin Correct, it is hard, but many/most of us who are webkit sheriffs/gardeners are not webkit committers (for example, the entire mac group). I don't understand your point. Are you saying that only webkit committers should be on the webkit sheriff rotation? In my experience, better familiarity with WebKit code base is a huge advantage for a gardener. I am almost tempted to say that if you're not actively working on WebKit, being a gardener will be a foreign and dancing-on-a-minefield-type task. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
I think it would be a good idea to ensure that there is at least someone on call to help new gardeners if they have questions or find themselves in a mess. I know I just asked dglazkov whenever I wasn't sure what to do, but he'd probably appreciate not being the only designated knowledgeable person. :-) On Wed, Sep 23, 2009 at 8:53 AM, Glenn Wilson gwil...@chromium.org wrote: I'll take the action item to remove anyone in the rotation who is not actively working on Webkit / is not a committer. In the past, I've floated the idea in the past of having a Webkit deputy who helps the gardener keep the canary green. I'm not sure if that would help, though. Regards, Glenn On Wed, Sep 23, 2009 at 8:40 AM, David Levin le...@chromium.org wrote: I find that being a WebKit gardener is always dancing on a minefield regardless of my familiarity with the WebKit code base. Look at yesterday for an example. In addition, we have several gardeners who are not actively working on WebKit (amanda@ has 0 WebKit commits, pinkerton@ has a few all in 2008). Lastly, can we add anyone to the rotation who has ideas how WebKit gardeners should/can do their job better? (This will help them in getting more ideas.) Dave On Wed, Sep 23, 2009 at 7:53 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Wed, Sep 23, 2009 at 7:46 AM, Mike Pinkerton pinker...@chromium.org wrote: It is hard to be a WebKit gardener if you do not have WebKit commit access. Sometimes the gardener has to commit a quick bustage fix upstream or roll back a fellow Chromium committers change to WebKit. -Darin Correct, it is hard, but many/most of us who are webkit sheriffs/gardeners are not webkit committers (for example, the entire mac group). I don't understand your point. Are you saying that only webkit committers should be on the webkit sheriff rotation? In my experience, better familiarity with WebKit code base is a huge advantage for a gardener. I am almost tempted to say that if you're not actively working on WebKit, being a gardener will be a foreign and dancing-on-a-minefield-type task. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Webkit merges and tree closures
On Wed, Sep 23, 2009 at 8:53 AM, Glenn Wilson gwil...@chromium.org wrote: I'll take the action item to remove anyone in the rotation who is not actively working on Webkit / is not a committer. Oh no... now it will happen even more often :) Should there also be the reverse adding WebKit committers who are not gardeners to the rotation? In the past, I've floated the idea in the past of having a Webkit deputy who helps the gardener keep the canary green. I'm not sure if that would help, though. fwiw, earlier in the thread I gave 5 things that would definitely help -- For those concerned about this issue, if you tackle these, it would make things go smoother. dave --~--~-~--~~~---~--~~ 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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Wed, Sep 23, 2009 at 8:55 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Tue, Sep 22, 2009 at 18:06, Dimitri Glazkov dglaz...@google.comwrote: Today wasn't a happy day for p...@. He did a seemingly innocuous roll that broke the world: selenium, ui tests, layout tests. I am sure it was stressful and probably added unnecessary gray to his hair. How about running ui and selenium tests on the canary bot? We run selenium already. And UI is covered by try server, but I'll make the change to also run the ui tests on the canary. Nicolas --~--~-~--~~~---~--~~ 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 merges and tree closures
On Tue, Sep 22, 2009 at 10:47 PM, David Levin le...@chromium.org wrote: Actionable items for keeping the tree green (in addition to blaming the WebKit gardener for [insert action here]): - *Get people putting in chromium patches upstream to run their changes through trybots, etc*. imo, patches from @chromium folks cause well over 50% of the grief with WebKit rolls (and usually the worst issues like today). - As Adam suggested, *make changes to the WebKit commit queue to run items through the chromium try bots*. - *WebKit gardeners should be able to submit high priority jobs to the try bots*. These jobs should job to the front of any queues so that they run asap. Why? Time is critical when doing the gardening because if you find a breakage upstream, you need to check in a fix and then roll to that fix. The longer the delay, the more likely another breakage will be checked in. I haven't seen a queue on the try bots in weeks now. If you do see one, and your change is not tested on all platforms as soon as you upload it, please let me know and we'll allocate more resources. Nicolas - *Consider auto-rolling WebKit deps*. Have the something like a parallel buildbot that runs against tip of tree WebKit. If everything passes except layout tests, add any layout test failures to test_expectations.txt (if there are less than 15) and roll DEPS on passing. If things fail, then turn red. - *Make it easier/faster to disable tests and file bugs about them *(using the last person in the blame/annotate for the test as the initial assignee or auto-assign it to the sheriff so (s)he can assign it to the right person) * *because issues will slip from WebKit rolls even though the gardeners try to be thorough. Also, this should help with turning the tree green in other cases as well. The sheriff (and everyone on the chromium team) should care about the WebKit roll as this is critical to the success of this project. Frequent rolls, should isolate issues and hopefully help to keep the tree green. * * To help shed some light on why WebKit gardening is more painful than sheriffing: 1. WebKit gardeners are all alone in trying to deal with things. 2. When things go bad on the canary, no one shuts down the tree for you and any changes to help with merging are not given priority (if the tree is red and you have an innocuous change to fix the webkit merge, you won't get it in.) 3. When tests fail anywhere (on the canary, when committing the roll, etc.), you have to figure out why, typically for a lot of changes that you know nothing about. 4. Two days of gardening -- multiple days of clean up afterward. 5. WebKit gardening occurs more often than sheriff duties. 6. afaik all WebKit gardeners also have sheriff duties. Net: chromium sheriffs please be willing to give a little extra help to the WebKit gardener. Remember that their hair is turning white as they try to run in front of a locomotive. Dave --~--~-~--~~~---~--~~ 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: removing dead code
5) Do a set subtraction of all-syms minus dead-syms. I wrote a small Python script: def load(filename): s = set() for line in open(filename): s.add(line.strip()) return s for sym in sub(load(sys.argv[1]) - load(sys.argv[2]): print sym FWIW, you can do this on the command line with comm. Markus, you've failed me! (Markus is my officemate and the shell script master; I think I asked him about how to do this from the shell.) --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
On Sep 23, 2009, at 12:32 AM, Mads Sig Ager wrote: another thing you should be aware of is that DOM nodes are only collected on full garbage collections. In order to see what is actually live at the end of a test, you have to force a number of GCs. But the GC should happen automatically after the tab's been idle for a little while, shouldn't it? I've left the tab open for several minutes and seen only minor reductions in memory use. The specific issue I'm tracking down seems to be triggered by opening child windows, i.e. a single renderer with multiple tabs. It looks as though closing any of the child tabs doesn't trigger a full GC; does this seem like a good thing to add? Here's the reduced test case I'm using: --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- Title: Open Windows In Same Process This tests opening multiple child windows in the same renderer process. It's similar to the membuster test, at a much smaller scale, and without the automation. To run it, simply click the links below in sequence, waiting for the other tab to finish loading its page between clicks. What I currently see is that memory usage goes up higher than it should, and doesn't come down after closing the second tab. In memory, multiple DOMWindow objects are hanging around, likely because of reference loops between WebCore and V8. In support of this theory, disabling JS entirely makes the problem go away. --Jens Alfke, Sept. 2009 Google Yahoo Apple —Jens
[chromium-dev] Re: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. M-A --~--~-~--~~~---~--~~ 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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
Marc-Antonie knows the try scripts best, so to avoid volunteering him directly, I'll say that I'm sure he can answer any questions from whoever does this. I don't think it'll be much work. On Wed, Sep 23, 2009 at 10:04 AM, Dimitri Glazkov dglaz...@google.comwrote: I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. M-A --~--~-~--~~~---~--~~ 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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
BTW, I trying to be snarky in my request. More like begging :) :DG On Wed, Sep 23, 2009 at 10:08 AM, John Abd-El-Malek j...@chromium.org wrote: Marc-Antonie knows the try scripts best, so to avoid volunteering him directly, I'll say that I'm sure he can answer any questions from whoever does this. I don't think it'll be much work. On Wed, Sep 23, 2009 at 10:04 AM, Dimitri Glazkov dglaz...@google.com wrote: I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. M-A --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
On Wed, Sep 23, 2009 at 7:02 PM, Jens Alfke s...@google.com wrote: On Sep 23, 2009, at 12:32 AM, Mads Sig Ager wrote: another thing you should be aware of is that DOM nodes are only collected on full garbage collections. In order to see what is actually live at the end of a test, you have to force a number of GCs. But the GC should happen automatically after the tab's been idle for a little while, shouldn't it? I've left the tab open for several minutes and seen only minor reductions in memory use. A full GC does indeed occur in idle notifications. Some of the structures that are set up are so complex that it actually takes more than one GC to get rid of them. To know for sure if it is a leak or if it is 'just' late collection it is a good idea to force more GCs explicitly. The specific issue I'm tracking down seems to be triggered by opening child windows, i.e. a single renderer with multiple tabs. It looks as though closing any of the child tabs doesn't trigger a full GC; does this seem like a good thing to add? Adding explicit GC calls are usually never a good idea. I'd like to check whether it really is a leak first. If it is a leak, we cannot get rid of it no matter how many GCs we force. Here's the reduced test case I'm using: Thanks. I'll have a look at it tomorrow. Cheers, -- Mads --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chromium Without SSe2
This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says that For silly reasons our default build depends on SSE, but we don't actually need. Search base/common.gypi and patch out the -msse2 bits before building your package. But I cannot find base.common.gypi in the source tarball of the chromium. How should I fix this problem ? I am wanting to run chromium on XO which has a Geode processor. And I would be helpful if anybody points me to the download page where chromium without SSe2 can be found. Thanks in Advance Ujjwol --~--~-~--~~~---~--~~ 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: Clear Strict-Transport-Security state checkbox added
Apparently an announcement message is also en-route to the W3C WebApps working group. It's in their archives now.. fyi: Strict Transport Security specification http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1148.html Please send feedback on the spec to the public-weba...@w3.org list. thanks, =JeffH PayPal InfoSec Team --~--~-~--~~~---~--~~ 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: V8 object-graph-tracing utilities?
On Wed, Sep 23, 2009 at 2:21 AM, Jens Alfke s...@google.com wrote: On Sep 22, 2009, at 2:54 PM, Mikhail Naganov wrote: I'm working on showing JS objects retainers. But this only works for objects that live inside V8's heap. That would still be useful — I'd love to be able to look at all the 'Window' objects in the heap and what ref chain is keeping them alive. Please let me know if there's something experimental I can try out. Thanks! If something in V8 is holding a DOMWindow then there must be something in C++ heap that in turn holds V8 objects. (Otherwise, V8 objects could be collected and wouldn't longer hold the DOMWindow; cycles that are strictly inside V8 heap are absolutely okay.) So usually such problems are caused by persistent handles to V8 objects. If a persistent handle is placed inside a ref-counted C++ object it's super easy to have a leak. In debug mode V8 bindings keep track of persistent handles by explicitly (un)registering them on creation/deletion. See WebCore/bindings/v8/V8GCController.cpp, functions (un)registerGlobalHandle and enumerateGlobalHandles. You can try to set a breakpoint there and find the handle that causes the trouble. In V8 heap profiles (for Chromium developers) it'd be extremely nice to see what persistent handles are holding V8 objects to find such leaks automatically. I'm currently working on fixing leaks that are caused by persistent handles inside V8EventListener objects (implementations of EventListener interface from WebKit on top of JS functions). Most DOM objects that have listeners can be leaked this way. See e.g. http://crbug.com/17400 and https://bugs.webkit.org/show_bug.cgi?id=29093. -- Vitaly --~--~-~--~~~---~--~~ 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: Store extra HTTP headers in WebHistoryItem
For anyone still interested in this issue, change sets for WebKit and Chromium are available here: http://codereview.chromium.org/220010 (WebKit) http://codereview.chromium.org/225012 (Chromium) Thanks, Marshall On Mon, Jul 6, 2009 at 12:47 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Mon, Jul 6, 2009 at 12:02 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Mon, Jul 6, 2009 at 11:59 AM, Darin Fisher da...@chromium.org wrote: You can probably make the case on bugs.webkit.org for a change like this to HistoryItem by observing that Apple's WebKit API also has a similar LoadRequest method that allows for request headers to be set. It makes for stronger justification for a change to WebCore when you can express your argument in terms of something that would be possible using Apple's WebKit API. http://developer.apple.com/documentation/Cocoa/Reference/WebKit/Classes/WebFrame_Class/Reference/Reference.html#//apple_ref/occ/instm/WebFrame/loadRequest : Thanks Darin. I'll submit it as a WebKit bug and see where it goes. I've added support for this feature as WebKit bug # 26994: https://bugs.webkit.org/show_bug.cgi?id=26994 -Darin On Mon, Jul 6, 2009 at 8:55 AM, Darin Fisher da...@chromium.org wrote: WebHistoryItem is a thin wrapper around WebCore::HistoryItem. So, you would need to change WebCore::HistoryItem. I don't know if this is something that would be accepted upstream or not. Perhaps a WebCore::HistoryItem should just hold a WebCore::ResourceRequest. -Darin On Sun, Jul 5, 2009 at 8:59 AM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi All, We currently have the ability to set extra HTTP header fields in WebURLRequest. However, the extra HTTP header fields are not stored in WebHistoryItem and are therefore lost after navigation. This is a problem for applications that use extra HTTP headers to pass important information to the server. Does anyone object to us storing extra HTTP header fields in WebHistoryItem so that we can re-send them when navigating the history? If not, I'll create a patch to add this functionality. Regards, Marshall --~--~-~--~~~---~--~~ 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 Without SSe2
2009/9/22 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com: But I cannot find base.common.gypi in the source tarball of the chromium. How should I fix this problem ? Opps, there was a typo on that wiki page which I've now fixed. The correct location is build/common.gypi. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chromium Without SSe2
This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says that For silly reasons our default build depends on SSE, but we don't actually need. Search base/common.gypi and patch out the -msse2 bits before building your package. But I cannot find base.common.gypi in the source tarball of the chromium. How should I fix this solution. I am wanting to run chromium on XO which has a Geode processor. And I would be helpful if anybody points me to the download page where chromium without SSe2 can be found. Thanks in Advance Ujjwol --~--~-~--~~~---~--~~ 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 Without SSe2
Does our default build really depend on -msse2 anymore? Doesn't seem to on linux... 2009/9/22 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com: This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says that For silly reasons our default build depends on SSE, but we don't actually need. Search base/common.gypi and patch out the -msse2 bits before building your package. But I cannot find base.common.gypi in the source tarball of the chromium. How should I fix this solution. I am wanting to run chromium on XO which has a Geode processor. And I would be helpful if anybody points me to the download page where chromium without SSe2 can be found. Thanks in Advance Ujjwol --~--~-~--~~~---~--~~ 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 Without SSe2
The code doesn't lie:
'conditions': [
['branding==Chromium', {
'cflags': [
'-march=pentium4',
'-msse2',
'-mfpmath=sse',
],
}],
],
http://code.google.com/p/chromium/issues/detail?id=8475
On Wed, Sep 23, 2009 at 11:00 AM, Dan Kegel d...@kegel.com wrote:
Does our default build really depend on -msse2 anymore? Doesn't
seem to on linux...
2009/9/22 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com:
This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says
that
For silly reasons our default build depends on SSE, but we don't
actually need. Search base/common.gypi and patch out the -msse2 bits
before building your package.
But I cannot find base.common.gypi in the source tarball of the
chromium. How should I fix this solution.
I am wanting to run chromium on XO which has a Geode processor.
And I would be helpful if anybody points me to the download page where
chromium without SSe2 can be found.
Thanks in Advance
Ujjwol
--~--~-~--~~~---~--~~
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 Without SSe2
Oddly, I can still install fine on my pentium III laptop, I think.
On Wed, Sep 23, 2009 at 11:02 AM, Evan Martin e...@chromium.org wrote:
The code doesn't lie:
'conditions': [
['branding==Chromium', {
'cflags': [
'-march=pentium4',
'-msse2',
'-mfpmath=sse',
],
}],
],
http://code.google.com/p/chromium/issues/detail?id=8475
On Wed, Sep 23, 2009 at 11:00 AM, Dan Kegel d...@kegel.com wrote:
Does our default build really depend on -msse2 anymore? Doesn't
seem to on linux...
2009/9/22 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com:
This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says
that
For silly reasons our default build depends on SSE, but we don't
actually need. Search base/common.gypi and patch out the -msse2 bits
before building your package.
But I cannot find base.common.gypi in the source tarball of the
chromium. How should I fix this solution.
I am wanting to run chromium on XO which has a Geode processor.
And I would be helpful if anybody points me to the download page where
chromium without SSe2 can be found.
Thanks in Advance
Ujjwol
--~--~-~--~~~---~--~~
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 Without SSe2
Is there a reason we gate this on branding? The comment doesn't speak
to that at all.
Evan Martin wrote:
The code doesn't lie:
'conditions': [
['branding==Chromium', {
'cflags': [
'-march=pentium4',
'-msse2',
'-mfpmath=sse',
],
}],
],
--~--~-~--~~~---~--~~
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 Without SSe2
Google Chrome builds without SSE2.
On Wed, Sep 23, 2009 at 11:16 AM, Dan Kegel d...@kegel.com wrote:
Oddly, I can still install fine on my pentium III laptop, I think.
On Wed, Sep 23, 2009 at 11:02 AM, Evan Martin e...@chromium.org wrote:
The code doesn't lie:
'conditions': [
['branding==Chromium', {
'cflags': [
'-march=pentium4',
'-msse2',
'-mfpmath=sse',
],
}],
],
http://code.google.com/p/chromium/issues/detail?id=8475
On Wed, Sep 23, 2009 at 11:00 AM, Dan Kegel d...@kegel.com wrote:
Does our default build really depend on -msse2 anymore? Doesn't
seem to on linux...
2009/9/22 Ujjwol (उज्जवल लामिछाने) ujjwollamichh...@gmail.com:
This (http://code.google.com/p/chromium/wiki/LinuxPackaging) page says
that
For silly reasons our default build depends on SSE, but we don't
actually need. Search base/common.gypi and patch out the -msse2 bits
before building your package.
But I cannot find base.common.gypi in the source tarball of the
chromium. How should I fix this solution.
I am wanting to run chromium on XO which has a Geode processor.
And I would be helpful if anybody points me to the download page where
chromium without SSe2 can be found.
Thanks in Advance
Ujjwol
--~--~-~--~~~---~--~~
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 Without SSe2
It's so our tests pass, I think.
On Wed, Sep 23, 2009 at 11:20 AM, Mark Mentovai m...@chromium.org wrote:
Is there a reason we gate this on branding? The comment doesn't speak
to that at all.
Evan Martin wrote:
The code doesn't lie:
'conditions': [
['branding==Chromium', {
'cflags': [
'-march=pentium4',
'-msse2',
'-mfpmath=sse',
],
}],
],
--~--~-~--~~~---~--~~
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 Without SSe2
Dan Kegel wrote: It's so our tests pass, I think. We don't have tests for nothing. If a test exposes a case where something requires 53/64-bit IEEE double precision as opposed to 64/80-bit double extended, and we're changing our configuration to make tests pass but then releasing in another configuration where those same tests wouldn't pass, we're doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. 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: Chromium Without SSe2
On Wed, Sep 23, 2009 at 11:26 AM, Mark Mentovai m...@chromium.org wrote: If a test exposes a case where something requires 53/64-bit IEEE double precision as opposed to 64/80-bit double extended, and we're changing our configuration to make tests pass but then releasing in another configuration where those same tests wouldn't pass, we're doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. I agree; hence the bug. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Search engine settings backup
I had to reinstall recently because of the enable-sync bug that hit a few builds ago. As a result I had to re-establish all of my settings including custom search engines. For future preservation I would like to save a backup of whatever file/reg entry is responsible for these settings. Can anybody tell me where that lives? Also as a suggestion this should be considered as a feature for future syncing similar to the bookmark sync. Cheers, m.f --~--~-~--~~~---~--~~ 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 Without SSe2
On Wed, Sep 23, 2009 at 11:26 AM, Mark Mentovai m...@chromium.org wrote: doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. The reality of the situation: * x87 doubles are 80-bits in registers and 64-bits in memory. This means that changing the optimisation flags of the compiler (and thus the spill profile of the code) changes rounding errors. * So, using x87 means that we would need two sets of image baselines: debug and release. It also means that different versions of GCC might end up needing their own baselines. * However, some people don't have SSE2 processors, so requiring it in Chrome branded builds would exclude them. I believe the current situation, impure as it is, is the best answer. AGL --~--~-~--~~~---~--~~ 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: Search engine settings backup
If you pick help from the wrench menu it takes you to a user help forum. I searched for backup settings there and found the answer in the first page of search results. On Wed, Sep 23, 2009 at 11:31 AM, m.f michael.fa...@gmail.com wrote: I had to reinstall recently because of the enable-sync bug that hit a few builds ago. As a result I had to re-establish all of my settings including custom search engines. For future preservation I would like to save a backup of whatever file/reg entry is responsible for these settings. Can anybody tell me where that lives? Also as a suggestion this should be considered as a feature for future syncing similar to the bookmark sync. Cheers, m.f --~--~-~--~~~---~--~~ 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: Search engine settings backup
On Wed, Sep 23, 2009 at 11:31 AM, m.f michael.fa...@gmail.com wrote: I had to reinstall recently because of the enable-sync bug that hit a few builds ago. As a result I had to re-establish all of my settings including custom search engines. For future preservation I would like to save a backup of whatever file/reg entry is responsible for these settings. Can anybody tell me where that lives? Also as a suggestion this should be considered as a feature for future syncing similar to the bookmark sync. Cheers, m.f there's no feature currently AFAIK (although you could backup your profile manually) you can star http://code.google.com/p/chromium/issues/detail?id=15548 and/or http://code.google.com/p/chromium/issues/detail?id=22596 -- Evan Stade --~--~-~--~~~---~--~~ 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: Search engine settings backup
On Wed, Sep 23, 2009 at 11:34 AM, Evan Stade est...@chromium.org wrote: On Wed, Sep 23, 2009 at 11:31 AM, m.f michael.fa...@gmail.com wrote: I had to reinstall recently because of the enable-sync bug that hit a few builds ago. As a result I had to re-establish all of my settings including custom search engines. For future preservation I would like to save a backup of whatever file/reg entry is responsible for these settings. Can anybody tell me where that lives? Also as a suggestion this should be considered as a feature for future syncing similar to the bookmark sync. Cheers, m.f there's no feature currently AFAIK (although you could backup your profile manually) you can star http://code.google.com/p/chromium/issues/detail?id=15548 and/or http://code.google.com/p/chromium/issues/detail?id=22596 -- Evan Stade first link, not borked: http://code.google.com/p/chromium/issues/detail?id=15548 -- Evan Stade --~--~-~--~~~---~--~~ 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 Without SSe2
Adam Langley wrote: * x87 doubles are 80-bits in registers and 64-bits in memory. Depending on the state of the x87 floating point control word. Can bracket significant test-impacting floating point operations with fldcw or do something else in that code to force spills to memory? I'm aware of the performance implication of mucking with the floating point control register on older CPUs. I'm also aware that some GNU libm functions assume that the x87 is set to 64/80-bit precision. Maybe we care, maybe we don't. Maybe we can just set the register to 53/64-bit precision on renderer threads and leave it that way. If we can't require SSE2 as a baseline on Linux, and I'd agree that we can't, then it seems that we should find a way to do the right things within the confines of the x87 instruction set. Is the issue simply test results are different due to rounding, or are there actually cases where a spec requires that we do floating-point operations in a certain mode? (I know that the JS and XSL or XPath specs fall into the latter bucket.) 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: Chromium Without SSe2
Basically all Intel CPUs since Pentium 4 (since year 2000) support SSE2, as well as AMD K8 CPUs. The main group seemingly left out is Athlons pre-K8 (e.g. the non-64 bit versions available through 2005). Do we have any sense of how big a market is? Is this basically the same thing as Win2K where it's a small user base that is shrinking? 2009/9/23 Adam Langley a...@chromium.org: On Wed, Sep 23, 2009 at 11:26 AM, Mark Mentovai m...@chromium.org wrote: doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. The reality of the situation: * x87 doubles are 80-bits in registers and 64-bits in memory. This means that changing the optimisation flags of the compiler (and thus the spill profile of the code) changes rounding errors. * So, using x87 means that we would need two sets of image baselines: debug and release. It also means that different versions of GCC might end up needing their own baselines. * However, some people don't have SSE2 processors, so requiring it in Chrome branded builds would exclude them. I believe the current situation, impure as it is, is the best answer. AGL --~--~-~--~~~---~--~~ 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: Search engine settings backup
That post suggested the entire User Data folder. I knew about this file long ago. However, the nature of the bug I was trying to overcome had to do with something that was not quite kosher within that folder. So I didn't want to just blindly copy it over. I tried scrounging through the files in there and didn't see anything that pointed at the search engine settings. On Sep 23, 1:34 pm, Evan Martin e...@chromium.org wrote: If you pick help from the wrench menu it takes you to a user help forum. I searched for backup settings there and found the answer in the first page of search results. On Wed, Sep 23, 2009 at 11:31 AM, m.f michael.fa...@gmail.com wrote: I had to reinstall recently because of the enable-sync bug that hit a few builds ago. As a result I had to re-establish all of my settings including custom search engines. For future preservation I would like to save a backup of whatever file/reg entry is responsible for these settings. Can anybody tell me where that lives? Also as a suggestion this should be considered as a feature for future syncing similar to the bookmark sync. Cheers, m.f --~--~-~--~~~---~--~~ 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: Search engine settings backup
On Wed, Sep 23, 2009 at 11:44 AM, m.f michael.fa...@gmail.com wrote: That post suggested the entire User Data folder. I knew about this file long ago. However, the nature of the bug I was trying to overcome had to do with something that was not quite kosher within that folder. So I didn't want to just blindly copy it over. I tried scrounging through the files in there and didn't see anything that pointed at the search engine settings. You need the Web Data file inside Default/. Dunno if maybe you need other things too. 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] Getting pixel tests running on the Mac
I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
No, there's no way to do that but it would be easy enough to add. -- Dirk On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
I'm new to the test runner (and to python in general). Can you give me a pointer where I should start? Avi On Wed, Sep 23, 2009 at 3:22 PM, Dirk Pranke dpra...@google.com wrote: No, there's no way to do that but it would be easy enough to add. -- Dirk On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
BTW, would we want this to be temporary? I was thinking so, but then again, being able to suppress a pixel failure separately from the layout failure might be useful. Avi On Wed, Sep 23, 2009 at 3:24 PM, Avi Drissman a...@google.com wrote: I'm new to the test runner (and to python in general). Can you give me a pointer where I should start? Avi On Wed, Sep 23, 2009 at 3:22 PM, Dirk Pranke dpra...@google.com wrote: No, there's no way to do that but it would be easy enough to add. -- Dirk On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Try server moved
The try server moved. There should be no side-effects except that the logs are lost (yet again). If you want to access the old try job logs, the old try server is still running for a few days, so use the continuous buildbot's address with the try server's port. If you don't have access to corp network, ping me. M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
+pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi --~--~-~--~~~---~--~~ 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 Without SSe2
On Wed, Sep 23, 2009 at 11:30 AM, Evan Martin e...@chromium.org wrote: On Wed, Sep 23, 2009 at 11:26 AM, Mark Mentovai m...@chromium.org wrote: If a test exposes a case where something requires 53/64-bit IEEE double precision as opposed to 64/80-bit double extended, and we're changing our configuration to make tests pass but then releasing in another configuration where those same tests wouldn't pass, we're doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. I agree; hence the bug. To be fair, the bug has been around for 6 months. So it's not like it's a temporary hack. On Wed, Sep 23, 2009 at 11:33 AM, Adam Langley a...@chromium.org wrote: On Wed, Sep 23, 2009 at 11:26 AM, Mark Mentovai m...@chromium.org wrote: doing something wrong. Using SSE2 floating-point operations in a configuration that we test and then using x87 floating-point operations in a configuration that we release is completely bogus. The reality of the situation: * x87 doubles are 80-bits in registers and 64-bits in memory. This means that changing the optimisation flags of the compiler (and thus the spill profile of the code) changes rounding errors. * So, using x87 means that we would need two sets of image baselines: debug and release. It also means that different versions of GCC might end up needing their own baselines. * However, some people don't have SSE2 processors, so requiring it in Chrome branded builds would exclude them. I believe the current situation, impure as it is, is the best answer. I agree that this one case seems fine, but are we positive there are no other differences in how the two apps behave when compiled with this flag? --~--~-~--~~~---~--~~ 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: Try server moved
I just ran git try and the status boxes didn't show up on the codereview page. Related? (http://codereview.chromium.org/219015/show, I do see the jobs on the try-server waterfall..) Matt On Wed, Sep 23, 2009 at 12:32, Marc-Antoine Ruel mar...@chromium.org wrote: The try server moved. There should be no side-effects except that the logs are lost (yet again). If you want to access the old try job logs, the old try server is still running for a few days, so use the continuous buildbot's address with the try server's port. If you don't have access to corp network, ping me. M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
On Wed, Sep 23, 2009 at 12:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think is a great plan. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
so I just tried a few experiments. For some reason, none of the changes in third_party\WebKit do an automatic try when uploading. When I try to do gcl try with --root src\third_party, the change doesn't apply on the server since it tries to patch a diff with src\third_party\WebKit... in the filenames in the src\third_party directory. I tried without --root, and it doesn't work because then the filenames are under WebCore directory (see http://codereview.chromium.org/download/issue223008_1.diff) don't have src\third_party in them. Something seems to be fishy in how the filenames are generates when in the WebKit directory. Marc-Antoine knows this best, so I'm handing it off. On Wed, Sep 23, 2009 at 10:13 AM, Dimitri Glazkov dglaz...@google.comwrote: BTW, I trying to be snarky in my request. More like begging :) :DG On Wed, Sep 23, 2009 at 10:08 AM, John Abd-El-Malek j...@chromium.org wrote: Marc-Antonie knows the try scripts best, so to avoid volunteering him directly, I'll say that I'm sure he can answer any questions from whoever does this. I don't think it'll be much work. On Wed, Sep 23, 2009 at 10:04 AM, Dimitri Glazkov dglaz...@google.com wrote: I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. M-A --~--~-~--~~~---~--~~ 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 Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
FWIW, that command worked for me, but I have a hybrid checkout: http://dev.chromium.org/developers/contributing-to-webkit Adam On Wed, Sep 23, 2009 at 1:10 PM, John Abd-El-Malek j...@chromium.org wrote: so I just tried a few experiments. For some reason, none of the changes in third_party\WebKit do an automatic try when uploading. When I try to do gcl try with --root src\third_party, the change doesn't apply on the server since it tries to patch a diff with src\third_party\WebKit... in the filenames in the src\third_party directory. I tried without --root, and it doesn't work because then the filenames are under WebCore directory (see http://codereview.chromium.org/download/issue223008_1.diff) don't have src\third_party in them. Something seems to be fishy in how the filenames are generates when in the WebKit directory. Marc-Antoine knows this best, so I'm handing it off. On Wed, Sep 23, 2009 at 10:13 AM, Dimitri Glazkov dglaz...@google.com wrote: BTW, I trying to be snarky in my request. More like begging :) :DG On Wed, Sep 23, 2009 at 10:08 AM, John Abd-El-Malek j...@chromium.org wrote: Marc-Antonie knows the try scripts best, so to avoid volunteering him directly, I'll say that I'm sure he can answer any questions from whoever does this. I don't think it'll be much work. On Wed, Sep 23, 2009 at 10:04 AM, Dimitri Glazkov dglaz...@google.com wrote: I think this is a great idea! Do we have a Python/gcl/rietveld expert who can tackle this? :DG On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek j...@chromium.org wrote: I didn't know this was possible. It seems it will get a lot more usage if it just works, i.e. the try script grabs these settings automatically from a codereview.settings file. If we start by putting this file in third_party\WebKit, then people who start with their patch there (also to upload) can use this transparently. What do you think? On Wed, Sep 23, 2009 at 7:42 AM, Marc-Antoine Ruel mar...@chromium.org wrote: On Tue, Sep 22, 2009 at 9:35 PM, Adam Barth aba...@chromium.org wrote: On Tue, Sep 22, 2009 at 6:25 PM, John Abd-El-Malek j...@chromium.org wrote: Is this even possible? i.e. I had uploaded a WebKit patch on codereview but none of the patchsets got run on the try server http://codereview.chromium.org/178030/show It is possible: aba...@zenque:~/svn/kr/src/third_party/WebKit$ gcl try scriptcontext --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try --bot layout_win,layout_mac,layout_linux --root src/third_party I know the format is not very user friendly but it is definitely possible. You probably can skip --use_svn and --svn_repo or at least use the --http stuff instead, see go/chrometryserver. You could want to use both the layout tests and the normal tests so you can send the patch to all the slaves at the same time, e.g. --bot win,linux,mac,layout_win,layout_mac,layout_linux If the layout tests try slaves get overused, I'll add more slaves. M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Problem with gyp every time v8 updates their branch
Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2' At revision 3275. Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966; UUID don't match and there is local changes in a:\chrome2\src\v8. Delete the direct ory and try again. a:\chrome2\src\v8svn st ? tools\gyp\v8.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\js2c.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_nosnapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_snapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_shell.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_base.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\mksnapshot.vcproj.GOOGLE.jabdelmalek.user I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Can the generated files be put elsewhere? Or is there a way that gyp can tell svn to ignore .user files? I realize I could put it in my svn config file, but this doesn't solve it for all the other developers. --~--~-~--~~~---~--~~ 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: Problem with gyp every time v8 updates their branch
On Wed, Sep 23, 2009 at 1:25 PM, John Abd-El-Malek j...@chromium.org wrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. That's weird. I haven't seen this on my machine. 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: Problem with gyp every time v8 updates their branch
On Wed, Sep 23, 2009 at 1:26 PM, Peter Kasting pkast...@google.com wrote: On Wed, Sep 23, 2009 at 1:25 PM, John Abd-El-Malek j...@chromium.orgwrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. That's weird. I haven't seen this on my machine. PK Hmm... I also have been seeing the same problem for a while. I updated my SVN config to ignore .user files and have been happy ever since. But, I agree with John that it sucks for everyone to have to do that. -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: Problem with gyp every time v8 updates their branch
On Wed, Sep 23, 2009 at 1:25 PM, John Abd-El-Malek j...@chromium.org wrote: I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Actually, I have to nuke the v8/ directory every time they update under linux/scons, too. -- Elliot --~--~-~--~~~---~--~~ 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: Problem with gyp every time v8 updates their branch
This happened after a GYP change that Brad made recently (last week, I think). We need to add to v8's svn:ignore. John Abd-El-Malek wrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2' At revision 3275. Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966; UUID don't match and there is local changes in a:\chrome2\src\v8. Delete the direct ory and try again. a:\chrome2\src\v8svn st ? tools\gyp\v8.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\js2c.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_nosnapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_snapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_shell.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_base.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\mksnapshot.vcproj.GOOGLE.jabdelmalek.user I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Can the generated files be put elsewhere? Or is there a way that gyp can tell svn to ignore .user files? I realize I could put it in my svn config file, but this doesn't solve it for all the other developers. --~--~-~--~~~---~--~~ 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: Problem with gyp every time v8 updates their branch
Same here. I see it both on windows and mac. On Wed, Sep 23, 2009 at 1:35 PM, Elliot Glaysher (Chromium) e...@chromium.org wrote: On Wed, Sep 23, 2009 at 1:25 PM, John Abd-El-Malek j...@chromium.org wrote: I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Actually, I have to nuke the v8/ directory every time they update under linux/scons, too. -- Elliot --~--~-~--~~~---~--~~ 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: Problem with gyp every time v8 updates their branch
John Abd-El-Malek wrote: I've seen this before last week as well. OK, then there might be something else going on. When it happened in the past, what did svn status show? I've never seen this, by the way. (Any time I make changes to V8, I don't do it in a Chromium working copy.) Can this really be added to v8's svn:ignore? These VS generated files have the username in them. Yeah, they're patterns. You can svn:ignore *.vcproj.*.user Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
Could we make them TEXTFAIL and IMAGEFAIL, just to be clear? Stephen (And then post them to failblog if they're really embarassing.. J/K ;) On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Problem with gyp every time v8 updates their branch
On Wed, Sep 23, 2009 at 1:43 PM, John Abd-El-Malek j...@chromium.org wrote: I've seen this before last week as well. I have too. Can this really be added to v8's svn:ignore? These VS generated files have the username in them. On Wed, Sep 23, 2009 at 1:39 PM, Mark Mentovai m...@chromium.org wrote: This happened after a GYP change that Brad made recently (last week, I think). We need to add to v8's svn:ignore. John Abd-El-Malek wrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2' At revision 3275. Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966; UUID don't match and there is local changes in a:\chrome2\src\v8. Delete the direct ory and try again. a:\chrome2\src\v8svn st ? tools\gyp\v8.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\js2c.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_nosnapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_snapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_shell.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_base.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\mksnapshot.vcproj.GOOGLE.jabdelmalek.user I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Can the generated files be put elsewhere? Or is there a way that gyp can tell svn to ignore .user files? I realize I could put it in my svn config file, but this doesn't solve it for all the other developers. --~--~-~--~~~---~--~~ 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: Problem with gyp every time v8 updates their branch
I'll look into it. Sorrry, we added support for setting the default run target, but it has to create a per user config file. -BradN On Wed, Sep 23, 2009 at 1:55 PM, Jeremy Orlow jor...@google.com wrote: On Wed, Sep 23, 2009 at 1:43 PM, John Abd-El-Malek j...@chromium.orgwrote: I've seen this before last week as well. I have too. Can this really be added to v8's svn:ignore? These VS generated files have the username in them. On Wed, Sep 23, 2009 at 1:39 PM, Mark Mentovai m...@chromium.org wrote: This happened after a GYP change that Brad made recently (last week, I think). We need to add to v8's svn:ignore. John Abd-El-Malek wrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2' At revision 3275. Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966; UUID don't match and there is local changes in a:\chrome2\src\v8. Delete the direct ory and try again. a:\chrome2\src\v8svn st ? tools\gyp\v8.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\js2c.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_nosnapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_snapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_shell.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_base.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\mksnapshot.vcproj.GOOGLE.jabdelmalek.user I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Can the generated files be put elsewhere? Or is there a way that gyp can tell svn to ignore .user files? I realize I could put it in my svn config file, but this doesn't solve it for all the other developers. --~--~-~--~~~---~--~~ 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: Problem with gyp every time v8 updates their branch
We need builddir != srcdir. sgk was working on it, I helped with a patch, not sure what became of it. On Wed, Sep 23, 2009 at 2:52 PM, Andrew Scherkus scher...@chromium.org wrote: One more data point: happens to me on windows and linux: $ cd src/v8 $ svn st ? tools/gyp/v8_nosnapshot.mk ? tools/gyp/v8_snapshot.mk ? tools/gyp/v8.mk ? tools/gyp/js2c.mk ? tools/gyp/v8_shell.mk ? tools/gyp/mksnapshot.mk ? tools/gyp/v8_base.mk On Wed, Sep 23, 2009 at 2:12 PM, Bradley Nelson bradnel...@google.com wrote: I'll look into it. Sorrry, we added support for setting the default run target, but it has to create a per user config file. -BradN On Wed, Sep 23, 2009 at 1:55 PM, Jeremy Orlow jor...@google.com wrote: On Wed, Sep 23, 2009 at 1:43 PM, John Abd-El-Malek j...@chromium.org wrote: I've seen this before last week as well. I have too. Can this really be added to v8's svn:ignore? These VS generated files have the username in them. On Wed, Sep 23, 2009 at 1:39 PM, Mark Mentovai m...@chromium.org wrote: This happened after a GYP change that Brad made recently (last week, I think). We need to add to v8's svn:ignore. John Abd-El-Malek wrote: Every time v8 team updates which branch is the one that's used in Chrome, gclient sync fails on Windows. The error is below. running 'svn update a:\chrome2\src\tools\tryserver' in 'a:\chrome2' At revision 3275. Error: Can't switch the checkout to http://v8.googlecode.com/svn/tr...@2966; UUID don't match and there is local changes in a:\chrome2\src\v8. Delete the direct ory and try again. a:\chrome2\src\v8svn st ? tools\gyp\v8.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\js2c.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_nosnapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_snapshot.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_shell.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\v8_base.vcproj.GOOGLE.jabdelmalek.user ? tools\gyp\mksnapshot.vcproj.GOOGLE.jabdelmalek.user I have to delete the v8 directory and run gclient sync again (or remove the generated files). This is annoying, since it breaks syncing to all the Windows developers (I don't think this happens on Mac and Linux). Can the generated files be put elsewhere? Or is there a way that gyp can tell svn to ignore .user files? I realize I could put it in my svn config file, but this doesn't solve it for all the other developers. --~--~-~--~~~---~--~~ 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: Replacing BaseTransaction with a straight lock?
[Moving to chromium-dev] Good question. One case where we do any large amount of work with a ReadTransaction is the LoadAssociations step of model association. This happens just once at startup, and I don't expect there's another thread trying to do read-only operations on the syncable::Directory at the same time. Another case is TakeSnapshotForSaveChanges. But I don't see those two interacting commonly. Most of the stuff that happens on the UI thread already needs a WriteTransaction, and there shouldn't typically be contention for many of the operations because of how we dispatch (via ModelChangingSyncerCommand) those operations onto the UI thread. So really, I don't think we'd see an uptick in contention if we went with a simpler lock. - nick On Wed, Sep 23, 2009 at 3:34 PM, Jonathan Huang ch...@google.com wrote: Hi, I talked to jim roskind about putting a read-write lock in chrome to replace our base transaction class and he was of the opinion that performance gains from rwlocks were often not very efficient. With that in mind, I think the way that our transactions work right now, we have a multitude of writers and not all that many readers. I'm thinking of just replacing our transactions with a straight lock. Is there UI that blocks right now on acquiring a read transaction that's likely to bump into another read transaction, or other considerations I haven't thought through? -- As seen on TV --~--~-~--~~~---~--~~ 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: Replacing BaseTransaction with a straight lock?
If most of our uses on the UI thread are WriteTransactions today, then I agree using a Lock alone can't make things any jankier, because if you need to write you need the lock. I guess what I'm wondering is if we'll ever discover we could improve UI responsiveness somehow by using a ReadTransaction in places we haven't yet discovered. But I doubt it, since the UI has it's own cache (BookmarkModel) of the data that should be the only place it reads from. Except the ModelAssociator seems to use ReadTransaction.. I'm not that familiar with when that happens atm. On Wed, Sep 23, 2009 at 4:05 PM, Nick Carter n...@chromium.org wrote: [Moving to chromium-dev] Good question. One case where we do any large amount of work with a ReadTransaction is the LoadAssociations step of model association. This happens just once at startup, and I don't expect there's another thread trying to do read-only operations on the syncable::Directory at the same time. Another case is TakeSnapshotForSaveChanges. But I don't see those two interacting commonly. Most of the stuff that happens on the UI thread already needs a WriteTransaction, and there shouldn't typically be contention for many of the operations because of how we dispatch (via ModelChangingSyncerCommand) those operations onto the UI thread. So really, I don't think we'd see an uptick in contention if we went with a simpler lock. - nick On Wed, Sep 23, 2009 at 3:34 PM, Jonathan Huang ch...@google.com wrote: Hi, I talked to jim roskind about putting a read-write lock in chrome to replace our base transaction class and he was of the opinion that performance gains from rwlocks were often not very efficient. With that in mind, I think the way that our transactions work right now, we have a multitude of writers and not all that many readers. I'm thinking of just replacing our transactions with a straight lock. Is there UI that blocks right now on acquiring a read transaction that's likely to bump into another read transaction, or other considerations I haven't thought through? -- As seen on TV --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
I prefer IMAGE and TEXT since people maintaining these lists need to type these all the time. Also, longer names make for more bloat in the file and in the dashboard. Anyone who works with these lists even a small amount will know that IMAGE and TEXT refer to failures. We should really get rid of FAIL as a valid expectation (forces us to be more strict about what kind of failure it is), so the overlap of FAIL with IMAGE and TEXT is just temporary. Really, the FAIL part is redundant, no? Why not rename TIMEOUT/CRASH to TIMEOUT-FAIL/CRASH-FAIL? Ojan On Wed, Sep 23, 2009 at 6:32 PM, Dirk Pranke dpra...@google.com wrote: I think this plan sounds good, too. I'm mucking with those scripts a bit at the moment for the LTTF reporting, so I can make this change tomorrow, unless someone else would rather do it. I might actually prefer FAIL-TEXT and FAIL-IMAGE, but that's just me. I agree that TEXTFAIL is better than TEXT. Anyone else care to express a preference? -- Dirk On Wed, Sep 23, 2009 at 1:50 PM, Stephen White senorbla...@chromium.org wrote: Could we make them TEXTFAIL and IMAGEFAIL, just to be clear? Stephen (And then post them to failblog if they're really embarassing.. J/K ;) On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Getting pixel tests running on the Mac
Call me a wet blanket, but I don't think there's a strong need for more divergence in the file. Anything not passing is failing and needs looking at; having a way to say oh, it's 'only' the image that's bad will increase maintenance burden and support ignoring problems. Situations where we're willing to ignore one type of failure for an extended time should be rare. I'd vote for keeping FAIL meaning image and/or text, and IMAGEFAIL for temporary use meaning image-only. - Pam On Wed, Sep 23, 2009 at 6:52 PM, Ojan Vafai o...@chromium.org wrote: I prefer IMAGE and TEXT since people maintaining these lists need to type these all the time. Also, longer names make for more bloat in the file and in the dashboard. Anyone who works with these lists even a small amount will know that IMAGE and TEXT refer to failures. We should really get rid of FAIL as a valid expectation (forces us to be more strict about what kind of failure it is), so the overlap of FAIL with IMAGE and TEXT is just temporary. Really, the FAIL part is redundant, no? Why not rename TIMEOUT/CRASH to TIMEOUT-FAIL/CRASH-FAIL? Ojan On Wed, Sep 23, 2009 at 6:32 PM, Dirk Pranke dpra...@google.com wrote: I think this plan sounds good, too. I'm mucking with those scripts a bit at the moment for the LTTF reporting, so I can make this change tomorrow, unless someone else would rather do it. I might actually prefer FAIL-TEXT and FAIL-IMAGE, but that's just me. I agree that TEXTFAIL is better than TEXT. Anyone else care to express a preference? -- Dirk On Wed, Sep 23, 2009 at 1:50 PM, Stephen White senorbla...@chromium.org wrote: Could we make them TEXTFAIL and IMAGEFAIL, just to be clear? Stephen (And then post them to failblog if they're really embarassing.. J/K ;) On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Question about UI and classic views
I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
One day, we may offer further customization of this page. This may include the ability to show more items. I think this is preferable to a classic view option, which sets a bad precedent - that every time we make a UI change we'll carry the burden of supporting the old way too forever. It adds to the testing matrix and raises the opportunity cost of making ambitious UI changes. -Ben On Wed, Sep 23, 2009 at 8:59 PM, Mike Belshe mbel...@google.com wrote: I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
If you want to use the old new tab page, you can add this chrome switch ( --old-new-tab-page ) I personally like the 3x3 grid. I have a 24 screen and the new tab page is so tiny, would of been nice if the user could fully customize it, that is one of the popular features people want on the Chrome forums. - Mohamed Mansour On Wed, Sep 23, 2009 at 11:59 PM, Mike Belshe mbel...@google.com wrote: I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
Note that this mode will probably vanish, it's a figment of the transition. -Ben On Wed, Sep 23, 2009 at 9:08 PM, Mohamed Mansour m...@chromium.org wrote: If you want to use the old new tab page, you can add this chrome switch ( --old-new-tab-page ) I personally like the 3x3 grid. I have a 24 screen and the new tab page is so tiny, would of been nice if the user could fully customize it, that is one of the popular features people want on the Chrome forums. - Mohamed Mansour On Wed, Sep 23, 2009 at 11:59 PM, Mike Belshe mbel...@google.com wrote: I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about UI and classic views
On Wed, Sep 23, 2009 at 9:04 PM, Ben Goodger (Google) b...@chromium.orgwrote: One day, we may offer further customization of this page. This may include the ability to show more items. I think this is preferable to a classic view option, which sets a bad precedent - that every time we make a UI change we'll carry the burden of supporting the old way too forever. It adds to the testing matrix and raises the opportunity cost of making ambitious UI changes. I think you've got the precedent problem backwards. Look at it from the other side. The precedent that we set is that users should not expect any say or control about the UI. And if you, the user, don't like it, well, go back to IE, because we, Chrome, think our support burden is more important than your browser preferences. Is that the precedent we want to set? I'm not really fighting for the old UI, but I am fighting that we are aware of the negative consequences of change and that we better help users through transitions. If other users are saying the same thing, we might want to be a bit more sympathetic. Did we do usability studies of the NTP with existing users? Did they universally like the new layout better? Should we have had better upgrade UI so that users knew this was happening? Mike -Ben On Wed, Sep 23, 2009 at 8:59 PM, Mike Belshe mbel...@google.com wrote: I just got a fairly angry email from my sister about the new tab page UI. She writes: What’s up with the Chrome Tab page change? I thought I screwed up my page at home, but now my page at work has changed too. I don’t like it. Why do I have to have my tabs arranged 4x2 ? I liked 3x3. What happened to the delete tabs? Do we get no say in what our page looks like? Google just gets to make the change without so much as a notice, “Your page has changed for the worse”. Sorry to dump on you but, it sure is nice thinking that I can gripe to someone at a giant company like Google and there actually might be someone listening. This is probably a good point; why didn't we offer a classic view option to users? It is not like the current new-tab-page is all that radically different. I'm sure we were aware that some users would feel this way? But we think we know better than they do what this page should look like? BTW - I liked 3x3 better than 4x2 better too. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
Chrome's UI thread blocks on IO? Please tell me I misunderstand :-) -Darin On Wed, Sep 23, 2009 at 4:06 PM, Tim Steele t...@chromium.org wrote: If most of our uses on the UI thread are WriteTransactions today, then I agree using a Lock alone can't make things any jankier, because if you need to write you need the lock. I guess what I'm wondering is if we'll ever discover we could improve UI responsiveness somehow by using a ReadTransaction in places we haven't yet discovered. But I doubt it, since the UI has it's own cache (BookmarkModel) of the data that should be the only place it reads from. Except the ModelAssociator seems to use ReadTransaction.. I'm not that familiar with when that happens atm. On Wed, Sep 23, 2009 at 4:05 PM, Nick Carter n...@chromium.org wrote: [Moving to chromium-dev] Good question. One case where we do any large amount of work with a ReadTransaction is the LoadAssociations step of model association. This happens just once at startup, and I don't expect there's another thread trying to do read-only operations on the syncable::Directory at the same time. Another case is TakeSnapshotForSaveChanges. But I don't see those two interacting commonly. Most of the stuff that happens on the UI thread already needs a WriteTransaction, and there shouldn't typically be contention for many of the operations because of how we dispatch (via ModelChangingSyncerCommand) those operations onto the UI thread. So really, I don't think we'd see an uptick in contention if we went with a simpler lock. - nick On Wed, Sep 23, 2009 at 3:34 PM, Jonathan Huang ch...@google.com wrote: Hi, I talked to jim roskind about putting a read-write lock in chrome to replace our base transaction class and he was of the opinion that performance gains from rwlocks were often not very efficient. With that in mind, I think the way that our transactions work right now, we have a multitude of writers and not all that many readers. I'm thinking of just replacing our transactions with a straight lock. Is there UI that blocks right now on acquiring a read transaction that's likely to bump into another read transaction, or other considerations I haven't thought through? -- As seen on TV --~--~-~--~~~---~--~~ 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: Replacing BaseTransaction with a straight lock?
Not IO. The only contention it comes up against would be trying to get a lock on data while another thread is applying changes that it already received from a server, but that work is not intensive; it could be done by the UI thread itself if it had to be, but it isn't since in the majority of cases it can just happen peacefully in the background. Except at shutdown, which is http://code.google.com/p/chromium/issues/detail?id=19757. On Wed, Sep 23, 2009 at 10:22 PM, Darin Fisher da...@chromium.org wrote: Chrome's UI thread blocks on IO? Please tell me I misunderstand :-) -Darin On Wed, Sep 23, 2009 at 4:06 PM, Tim Steele t...@chromium.org wrote: If most of our uses on the UI thread are WriteTransactions today, then I agree using a Lock alone can't make things any jankier, because if you need to write you need the lock. I guess what I'm wondering is if we'll ever discover we could improve UI responsiveness somehow by using a ReadTransaction in places we haven't yet discovered. But I doubt it, since the UI has it's own cache (BookmarkModel) of the data that should be the only place it reads from. Except the ModelAssociator seems to use ReadTransaction.. I'm not that familiar with when that happens atm. On Wed, Sep 23, 2009 at 4:05 PM, Nick Carter n...@chromium.org wrote: [Moving to chromium-dev] Good question. One case where we do any large amount of work with a ReadTransaction is the LoadAssociations step of model association. This happens just once at startup, and I don't expect there's another thread trying to do read-only operations on the syncable::Directory at the same time. Another case is TakeSnapshotForSaveChanges. But I don't see those two interacting commonly. Most of the stuff that happens on the UI thread already needs a WriteTransaction, and there shouldn't typically be contention for many of the operations because of how we dispatch (via ModelChangingSyncerCommand) those operations onto the UI thread. So really, I don't think we'd see an uptick in contention if we went with a simpler lock. - nick On Wed, Sep 23, 2009 at 3:34 PM, Jonathan Huang ch...@google.comwrote: Hi, I talked to jim roskind about putting a read-write lock in chrome to replace our base transaction class and he was of the opinion that performance gains from rwlocks were often not very efficient. With that in mind, I think the way that our transactions work right now, we have a multitude of writers and not all that many readers. I'm thinking of just replacing our transactions with a straight lock. Is there UI that blocks right now on acquiring a read transaction that's likely to bump into another read transaction, or other considerations I haven't thought through? -- As seen on TV --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
