[chromium-dev] Re: Replacing BaseTransaction with a straight lock?
I see. Yeah, we've had to deal with the quit asap issues in other cases too. For example, the host resolver uses detached threads so that it can simply leak a thread that is stuck on a getaddrinfo call. (FF does the same thing.) -Darin On Wed, Sep 23, 2009 at 10:30 PM, Tim Steele t...@chromium.org wrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Problem with gyp every time v8 updates their branch
Yes, please!! The srcdir should not be littered with output from the build
system. (At least it should be an option.)-Darin
On Wed, Sep 23, 2009 at 2:56 PM, Evan Martin e...@chromium.org wrote:
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: Question about UI and classic views
Do websites provide users with previous versions after overhauling their UX? Some do (gmail seems to), but most do not. You just get to surf the latest. Hopefully, the website changes for the better. That's our burden to bear. -Darin 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: Problem with gyp every time v8 updates their branch
I think the tools should support your use of tags, but thanks for switching back to tr...@version. -Darin On Thu, Sep 24, 2009 at 12:12 AM, Mads Sig Ager a...@chromium.org wrote: I think something else is going on here as well. The changes you are talking about making sounds great though, so please do! The increased number of issues with V8 updates was caused by the V8 team and I should have sent an email about it. We changed the DEPS file to pull V8 from svn/tags/version instead of from svn/tr...@revision. This has the effect that if you have modifications in the V8 source dir you have to delete it. This was not our intention, so I switched back to the svn/tr...@version scheme. There should be less issues with the next updates. Sorry for the inconvenience. -- Mads On Thu, Sep 24, 2009 at 8:56 AM, Darin Fisher da...@chromium.org wrote: Yes, please!! The srcdir should not be littered with output from the build system. (At least it should be an option.) -Darin On Wed, Sep 23, 2009 at 2:56 PM, Evan Martin e...@chromium.org wrote: 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: Problem with gyp every time v8 updates their branch
I think something else is going on here as well. The changes you are
talking about making sounds great though, so please do!
The increased number of issues with V8 updates was caused by the V8
team and I should have sent an email about it. We changed the DEPS
file to pull V8 from svn/tags/version instead of from
svn/tr...@revision. This has the effect that if you have
modifications in the V8 source dir you have to delete it. This was
not our intention, so I switched back to the svn/tr...@version scheme.
There should be less issues with the next updates.
Sorry for the inconvenience.
-- Mads
On Thu, Sep 24, 2009 at 8:56 AM, Darin Fisher da...@chromium.org wrote:
Yes, please!! The srcdir should not be littered with output from the build
system. (At least it should be an option.)
-Darin
On Wed, Sep 23, 2009 at 2:56 PM, Evan Martin e...@chromium.org wrote:
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] Pasteboards and the mac valgrind builder
Hi, Chromium Mac (valgrind) and I just had a good time. The bot is green now, but some tests still finish as FAILED (they just don't leak). Most of them were in that state before my CL made me look into this. Most of the failing tests seem to be related to NSPasteboard. 1. Does the valgrind builder only become red on memory leaks but not on any test failures? 2. It looks like there was some trouble with NSPasteboards in the past. Do we know why these tests work fine locally and on the test bots, but fail on the valgrind bot? Thanks, Nico --~--~-~--~~~---~--~~ 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 Thu, Sep 24, 2009 at 12:11 AM, Darin Fisher da...@chromium.org wrote: Do websites provide users with previous versions after overhauling their UX? Some do (gmail seems to), but most do not. You just get to surf the latest. Hopefully, the website changes for the better. That's our burden to bear. I suspect it has to do with apps that contain your personal information (web history, contacts, email, etc). Users come to expect their information is found in certain places, and when you change that around, you can alienate some users. I suspect that is why GMail has backward compatible UIs but sites like CNN do not. It sounds like Alice and others will figure out if there is something that needs to change. Mike -Darin 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: Getting pixel tests running on the Mac
If you're already in there, go ahead. Thanks, Avi On Wed, Sep 23, 2009 at 9: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
I had assumed that test_shell was also going to be modified, in order to produce IMAGEFAIL or TEXTFAIL automatically in regressions.txt. So it wouldn't require any intervention other than a first pass through test_expectations.txt to mark the partial failures. I'm sure how often IMAGEFAIL - FAIL regressions would happen (which I think is what Avi was trying to catch originally), but it might be useful for other things. For example, when triaging a bunch of new webkit merge failures without having to run the tests locally. IMAGEFAIL probably points to a Skia or CG issue, whereas the other might be a DOM issue (not 100% guaranteed, but a hint for grouping, anyway). Stephen On Wed, Sep 23, 2009 at 11:34 PM, Pam Greene p...@chromium.org wrote: 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 -- All truth passes through three stages. First, it is ridiculed. Second, it is violently
[chromium-dev] Re: Pasteboards and the mac valgrind builder
We've got a bug that covers some strange issues with pasteboards on the valgrind bot, but the exact bug escapes me. Were you seeing outright test failures or new leaks? I think Mark was poking into it at one point, but I don't think we got anywhere closer to resolving the underlying issue. On Thu, Sep 24, 2009 at 3:21 AM, Nico Weber tha...@chromium.org wrote: Hi, Chromium Mac (valgrind) and I just had a good time. The bot is green now, but some tests still finish as FAILED (they just don't leak). Most of them were in that state before my CL made me look into this. Most of the failing tests seem to be related to NSPasteboard. 1. Does the valgrind builder only become red on memory leaks but not on any test failures? 2. It looks like there was some trouble with NSPasteboards in the past. Do we know why these tests work fine locally and on the test bots, but fail on the valgrind bot? Thanks, Nico -- 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: Pasteboards and the mac valgrind builder
Test failures. This is from an old run: [--] Global test environment tear-down [==] 981 tests from 219 test cases ran. (908043 ms total) [ PASSED ] 978 tests. [ FAILED ] 3 tests, listed below: [ FAILED ] AutocompleteTextFieldEditorTest.CutCopyTest [ FAILED ] BookmarkEditorControllerTest.UserEditsStuff [ FAILED ] DownloadUtilTest.AddFileToPasteboardTest However, the tests work fine on the other bots and locally, they only fail on the valgrind builder. Which is however still green. On 9/24/09, Mike Pinkerton pinker...@chromium.org wrote: We've got a bug that covers some strange issues with pasteboards on the valgrind bot, but the exact bug escapes me. Were you seeing outright test failures or new leaks? I think Mark was poking into it at one point, but I don't think we got anywhere closer to resolving the underlying issue. On Thu, Sep 24, 2009 at 3:21 AM, Nico Weber tha...@chromium.org wrote: Hi, Chromium Mac (valgrind) and I just had a good time. The bot is green now, but some tests still finish as FAILED (they just don't leak). Most of them were in that state before my CL made me look into this. Most of the failing tests seem to be related to NSPasteboard. 1. Does the valgrind builder only become red on memory leaks but not on any test failures? 2. It looks like there was some trouble with NSPasteboards in the past. Do we know why these tests work fine locally and on the test bots, but fail on the valgrind bot? Thanks, Nico -- 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: Pasteboards and the mac valgrind builder
Yes, I was poking this a little bit last week, and a little bit the week before. It seems that under Valgrind, tests involving the pasteboard, and maybe a couple of other things too, will always fail. In some cases, the test failures result in certain things not being cleaned up, which in turn results in something that Valgrind detects as a leak at the end of the run. I tried to fix some of these so that at least the tests always clean up after themselves, but was only partially successful. The underlying issue here is that the tests are failing, but only under Valgrind. Nico Weber wrote: [--] Global test environment tear-down [==] 981 tests from 219 test cases ran. (908043 ms total) [ PASSED ] 978 tests. [ FAILED ] 3 tests, listed below: [ FAILED ] AutocompleteTextFieldEditorTest.CutCopyTest [ FAILED ] BookmarkEditorControllerTest.UserEditsStuff [ FAILED ] DownloadUtilTest.AddFileToPasteboardTest However, the tests work fine on the other bots and locally, they only fail on the valgrind builder. Which is however still green. The Valgrind test step doesn't turn red for test failures, only for unsuppressed leaks. I wanted to ask dank about that last week, but he wasn't around when it initially upset me, so I moved on. Let's ask him now. dank? 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] Kiosk Mode for Chrome
At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] flaky resource failures
We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ 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: flaky resource failures
On Thu, Sep 24, 2009 at 3:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? It would be horrible. --~--~-~--~~~---~--~~ 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 don't think this is just about ignoring image-only results on mac for the short-term. My subjective sense is that we have many tests that start out as failing only image comparisons (e.g. due to theming), but over time another failure creeps in that causes a text failure that goes unnoticed. We'd ideally like to notice that extra regression when it happens as it might be easy to identify and fix right at the time the regression occurs. That said, I share your reluctance to add more complexity to this file. Consider me on the fence. :) Ojan On Wed, Sep 23, 2009 at 8:34 PM, Pam Greene p...@chromium.org wrote: Call me a wet blanket, but I don't think there's a strong need for more divergence in the file. Anything not passing is failing and needs looking at; having a way to say oh, it's 'only' the image that's bad will increase maintenance burden and support ignoring problems. Situations where we're willing to ignore one type of failure for an extended time should be rare. I'd vote for keeping FAIL meaning image and/or text, and IMAGEFAIL for temporary use meaning image-only. - Pam On Wed, Sep 23, 2009 at 6:52 PM, Ojan Vafai o...@chromium.org wrote: I prefer IMAGE and TEXT since people maintaining these lists need to type these all the time. Also, longer names make for more bloat in the file and in the dashboard. Anyone who works with these lists even a small amount will know that IMAGE and TEXT refer to failures. We should really get rid of FAIL as a valid expectation (forces us to be more strict about what kind of failure it is), so the overlap of FAIL with IMAGE and TEXT is just temporary. Really, the FAIL part is redundant, no? Why not rename TIMEOUT/CRASH to TIMEOUT-FAIL/CRASH-FAIL? Ojan On Wed, Sep 23, 2009 at 6:32 PM, Dirk Pranke dpra...@google.com wrote: I think this plan sounds good, too. I'm mucking with those scripts a bit at the moment for the LTTF reporting, so I can make this change tomorrow, unless someone else would rather do it. I might actually prefer FAIL-TEXT and FAIL-IMAGE, but that's just me. I agree that TEXTFAIL is better than TEXT. Anyone else care to express a preference? -- Dirk On Wed, Sep 23, 2009 at 1:50 PM, Stephen White senorbla...@chromium.org wrote: Could we make them TEXTFAIL and IMAGEFAIL, just to be clear? Stephen (And then post them to failblog if they're really embarassing.. J/K ;) On Wed, Sep 23, 2009 at 3:33 PM, Ojan Vafai o...@chromium.org wrote: +pam, tc, darin in case they disagree with what I'm saying here. Also a bunch of current expectations would need to be modified. All the cases where there is currently FAIL would need to be changed to either FAIL or IMAGE or both if it's a text and image failure. You should be able to get most of the data for this by looking at the layout test dashboard. The only exception is you won't be able to distinguish tests that fail both image and text from tests that only fail image. A short-term solution could be to leave FAIL meaning IMAGE and/or TEXT and adding IMAGE and TEXT for image-only and text-only failures. Then we can gradually excise the FAIL lines from text_expectations. I think this would be a good permanent change, but I can see arguments to the contrary. Ojan On Wed, Sep 23, 2009 at 12:25 PM, Ojan Vafai o...@chromium.org wrote: There is not. But adding it would be easy. There's been mention of doing this for a while, but noone has made the effort to make it work. All you'd have to do is: -modify a few lines in TestExpectationsFile in src/webkit/tools/layout_tests/layout_package/test_expectations.py to add support for IMAGE in test_expectations. -treat IMAGE and other failures separately in src/webkit/tools/layout_tests/layout_package/compare_failures.py. Specifically, take test_failures.FailureImageHashMismatch out of FAILURE_TYPES and add an IMAGE_FAILURE_TYPE and use it below. Ojan On Wed, Sep 23, 2009 at 12:16 PM, Avi Drissman a...@google.com wrote: I've been looking into the pixel test situation on the Mac, and it isn't bad at all. Of ~5300 tests that have png results, we're failing ~800, most of which fall into huge buckets of easily-separable fail. Is there a way to specify that we're expecting an image compare to fail but still want the layout to succeed? We don't want to turn off the tests entirely while we fix them and run the chance of breaking something that layout would have caught. Avi -- All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident. -- Schopenhauer --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: flaky resource failures
Which build was this? I checked in a change that changes how grit generates IDs. This type of change requires a clobber since I don't think we depend on all the grit .py files. I think these changes are rare enough that we can just clobber as needed. On Thu, Sep 24, 2009 at 12:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ 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: flaky resource failures
You can't clobber when it's flaky. I think I can extract the build ID from the flakiness report... On Thu, Sep 24, 2009 at 12:19, Tony Chang t...@chromium.org wrote: Which build was this? I checked in a change that changes how grit generates IDs. This type of change requires a clobber since I don't think we depend on all the grit .py files. I think these changes are rare enough that we can just clobber as needed. On Thu, Sep 24, 2009 at 12:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ 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
Right--the question is for the long term if this will be a useful feature to keep around or if we'll be dropping it once the Mac tests work. I'll take the change either way but I can appreciate the extra granularity that this would provide. Pam: having a way to say oh, it's 'only' the image that's bad will increase maintenance burden and support ignoring problems. We already have layout tests that deserve more attention than they get (thus the LTTF). IMAGEFAIL tests are no less broken than TEXTFAIL, and if the long-term aim is to not have *any* FAILs in the file anyway then I can see real use in the granularity. Avi On Thu, Sep 24, 2009 at 3:15 PM, Amanda Walker ama...@chromium.org wrote: On Thu, Sep 24, 2009 at 3:11 PM, Ojan Vafai o...@chromium.org wrote: I don't think this is just about ignoring image-only results on mac for the short-term. My subjective sense is that we have many tests that start out as failing only image comparisons (e.g. due to theming), but over time another failure creeps in that causes a text failure that goes unnoticed. We'd ideally like to notice that extra regression when it happens as it might be easy to identify and fix right at the time the regression occurs. That's pretty much where we are with the Mac pixel tests--we do want to know if layout geometry regresses, even if there's a known pixel expectation failure (a color, or a missing spelling underline, or whatever it is for that test). --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: flaky resource failures
On Thu, Sep 24, 2009 at 3:19 PM, Tony Chang t...@chromium.org wrote: Which build was this? I checked in a change that changes how grit generates IDs. This type of change requires a clobber since I don't think we depend on all the grit .py files. I think these changes are rare enough that we can just clobber as needed. Brad landed support for depending on all the python files that go into grit, so that part would have worked. The not always rebuilding for .h files is the problem. TVL On Thu, Sep 24, 2009 at 12:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [DESIGN DOC] registerProtocolHandler HTML5 API
I've shared a document with you: [HTML5] registerProtocolHandler API http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZrhl=eninvite=CI6z8vgG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. This is a design document for the worked needed to resolve http://crbug.com/11359 beyond the webkit implementation. Please feel free to comment inline or in this thread. I look forward to your critics and suggestions. --~--~-~--~~~---~--~~ 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 Thu, Sep 24, 2009 at 3:11 PM, Ojan Vafai o...@chromium.org wrote: I don't think this is just about ignoring image-only results on mac for the short-term. My subjective sense is that we have many tests that start out as failing only image comparisons (e.g. due to theming), but over time another failure creeps in that causes a text failure that goes unnoticed. We'd ideally like to notice that extra regression when it happens as it might be easy to identify and fix right at the time the regression occurs. That's pretty much where we are with the Mac pixel tests--we do want to know if layout geometry regresses, even if there's a known pixel expectation failure (a color, or a missing spelling underline, or whatever it is for that test). --Amanda I'm on record earlier as wanting to know when even the expected errors change, so this seems to me like a nice half-way compromise. Pam is right, of course, that we should be targeting zero errors, but I don't think this will really slow us much in that effort (and it'll probably help). -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Debugging CachedResource memory leak in test_shell
Hi All, I'm trying to debug the leak of CachedResource objects in test_shell. Every time I browse to a page that contains an image or CSS file a new CachedResource object is created in Cache.cpp createResource(). However, none of these objects are ever freed. Does anyone happen to know where/how the CachedResource objects should be freed so that I can figure out why they're getting lost? Thanks, 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: WebKit Hygiene: Please be kind. Test your patches. Warn about two-sided patches.
On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? --~--~-~--~~~---~--~~ 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.
Yes. With git:git try -b bot --webkit webkit branch chromium branch With gcl: Manually create a patch by concatenating two (chromium + webkit) patches. Make sure that the webkit patches have the right prefixes by using --src-prefix=src/third_party/WebKit --dst-prefix=src/third_party/WebKit on your diff command. On Thu, Sep 24, 2009 at 1:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? --~--~-~--~~~---~--~~ 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 Thu, Sep 24, 2009 at 1:49 PM, Yaar Schnitman y...@chromium.org wrote: Yes. With git:git try -b bot --webkit webkit branch chromium branch With gcl: Manually create a patch by concatenating two (chromium + webkit) patches. Make sure that the webkit patches have the right prefixes by using --src-prefix=src/third_party/WebKit --dst-prefix=src/third_party/WebKit on your diff command. On Thu, Sep 24, 2009 at 1:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? For gcl, you can also gcl try change -f wekitfile1,webkitfile2,etc. You can also synthesize a change with webkit files by creating a file in .svn/gcl_info/changes and then gcl try chrome_change,webkit_change. -- Steve --~--~-~--~~~---~--~~ 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.
Before we start enforcing penalties for people who screw this up, we need to do some tools work to make this less error prone/manual-hackery, I think. -atw On Thu, Sep 24, 2009 at 1:56 PM, Steve Vandebogart vand...@chromium.orgwrote: On Thu, Sep 24, 2009 at 1:49 PM, Yaar Schnitman y...@chromium.org wrote: Yes. With git:git try -b bot --webkit webkit branch chromium branch With gcl: Manually create a patch by concatenating two (chromium + webkit) patches. Make sure that the webkit patches have the right prefixes by using --src-prefix=src/third_party/WebKit --dst-prefix=src/third_party/WebKit on your diff command. On Thu, Sep 24, 2009 at 1:43 PM, Jeremy Orlow jor...@chromium.orgwrote: On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? For gcl, you can also gcl try change -f wekitfile1,webkitfile2,etc. You can also synthesize a change with webkit files by creating a file in .svn/gcl_info/changes and then gcl try chrome_change,webkit_change. -- Steve --~--~-~--~~~---~--~~ 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.
Maybe this is something that one of the task forces should address? On Thu, Sep 24, 2009 at 2:20 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Thanks for proposing yourself in improving gcl.py and trychange.py. On Thu, Sep 24, 2009 at 5:18 PM, Drew Wilson atwil...@chromium.org wrote: Before we start enforcing penalties for people who screw this up, we need to do some tools work to make this less error prone/manual-hackery, I think. -atw On Thu, Sep 24, 2009 at 1:56 PM, Steve Vandebogart vand...@chromium.org wrote: On Thu, Sep 24, 2009 at 1:49 PM, Yaar Schnitman y...@chromium.org wrote: Yes. With git: git try -b bot --webkit webkit branch chromium branch With gcl: Manually create a patch by concatenating two (chromium + webkit) patches. Make sure that the webkit patches have the right prefixes by using --src-prefix=src/third_party/WebKit --dst-prefix=src/third_party/WebKit on your diff command. On Thu, Sep 24, 2009 at 1:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? For gcl, you can also gcl try change -f wekitfile1,webkitfile2,etc. You can also synthesize a change with webkit files by creating a file in .svn/gcl_info/changes and then gcl try chrome_change,webkit_change. -- Steve --~--~-~--~~~---~--~~ 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.
Why the snark? Is it inappropriate to point out pain points in a proposed process without attaching a patch to my email? As someone who happily spent an hour+ yesterday tracking down an obscure bug in trychange.py, I don't think I'm someone who just sits on the sidelines making work for other people. -atw On Thu, Sep 24, 2009 at 2:20 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: Thanks for proposing yourself in improving gcl.py and trychange.py. On Thu, Sep 24, 2009 at 5:18 PM, Drew Wilson atwil...@chromium.org wrote: Before we start enforcing penalties for people who screw this up, we need to do some tools work to make this less error prone/manual-hackery, I think. -atw On Thu, Sep 24, 2009 at 1:56 PM, Steve Vandebogart vand...@chromium.org wrote: On Thu, Sep 24, 2009 at 1:49 PM, Yaar Schnitman y...@chromium.org wrote: Yes. With git: git try -b bot --webkit webkit branch chromium branch With gcl: Manually create a patch by concatenating two (chromium + webkit) patches. Make sure that the webkit patches have the right prefixes by using --src-prefix=src/third_party/WebKit --dst-prefix=src/third_party/WebKit on your diff command. On Thu, Sep 24, 2009 at 1:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? For gcl, you can also gcl try change -f wekitfile1,webkitfile2,etc. You can also synthesize a change with webkit files by creating a file in .svn/gcl_info/changes and then gcl try chrome_change,webkit_change. -- Steve --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Skipping reference_build ?
The src/chrome_frame/tools/test/reference_build directory takes ages to svn up, is there a way to skip it? I don't think I really need all those .dll and .exe files on Linux anyway... --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
Have you considered using Google Chrome Frame instead? That would let you keep all your existing IE7 integration points but have the rendering speed up by the factor of 10 that you cited. Adam On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.org wrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. --~--~-~--~~~---~--~~ 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.
That wasn't meant to be snarky at all! Contributions are always appreciated. One thing that is helpful is filing feature request (and assigning them to me) so I can better prioritize the feature request and not forget about them. M-A On Thu, Sep 24, 2009 at 5:25 PM, Drew Wilson atwil...@chromium.org wrote: Why the snark? Is it inappropriate to point out pain points in a proposed process without attaching a patch to my email? As someone who happily spent an hour+ yesterday tracking down an obscure bug in trychange.py, I don't think I'm someone who just sits on the sidelines making work for other people. -atw On Thu, Sep 24, 2009 at 2:20 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Thanks for proposing yourself in improving gcl.py and trychange.py. On Thu, Sep 24, 2009 at 5:18 PM, Drew Wilson atwil...@chromium.org wrote: Before we start enforcing penalties for people who screw this up, we need to do some tools work to make this less error prone/manual-hackery, I think. -atw On Thu, Sep 24, 2009 at 1:56 PM, Steve Vandebogart vand...@chromium.org wrote: On Thu, Sep 24, 2009 at 1:49 PM, Yaar Schnitman y...@chromium.org wrote: Yes. With git: git try -b bot --webkit webkit branch chromium branch With gcl: Manually create a patch by concatenating two (chromium + webkit) patches. Make sure that the webkit patches have the right prefixes by using --src-prefix=src/third_party/WebKit --dst-prefix=src/third_party/WebKit on your diff command. On Thu, Sep 24, 2009 at 1:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Tue, Sep 22, 2009 at 6: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 What about 2 sided patches. Is it possible to test those? For gcl, you can also gcl try change -f wekitfile1,webkitfile2,etc. You can also synthesize a change with webkit files by creating a file in .svn/gcl_info/changes and then gcl try chrome_change,webkit_change. -- Steve --~--~-~--~~~---~--~~ 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: flaky resource failures
On Thu, Sep 24, 2009 at 12:24, Thomas Van Lenten thoma...@chromium.orgwrote: Brad landed support for depending on all the python files that go into grit, so that part would have worked. The not always rebuilding for .h files is the problem. Does it mean we're missing some deps in the gyp files? --~--~-~--~~~---~--~~ 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: Skipping reference_build ?
We have already scolded Alex about this, but it's too late now. Repeat PSA: plz to not be dumping large Windows binaries into the tree. We have DEPS for a reason. On Thu, Sep 24, 2009 at 3:20 PM, Michael michael.monr...@gmail.com wrote: The src/chrome_frame/tools/test/reference_build directory takes ages to svn up, is there a way to skip it? I don't think I really need all those .dll and .exe files on Linux anyway... --~--~-~--~~~---~--~~ 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: Kiosk Mode for Chrome
IIRC, someone asked this a couple months ago. I believe the answer was that http://code.google.com/p/chromiumembedded/ might be of interest. I could see patches being welcome as long as they were fairly clean. I know that's not an official answer, but you're probably not going to get a yes from anyone unless they can see the impact it'd have. J On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.org wrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Build time doubled since May - what gives?
I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Build time doubled since May - what gives?
Hey Ben, same here ... I see this additional message today (havn't seen it before) 59LINK : C:\Sandbox\Code\Chrome\src\chrome\Debug\chrome.dll not found or not built by the last incremental link; performing full link Changing one file used to take me 5 minutes to build. But now it takes me ~10-15 minutes. -Mohamed On Thu, Sep 24, 2009 at 10:06 PM, Ben Goodger (Google) b...@chromium.orgwrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Build time doubled since May - what gives?
Not sure, but it's possible shutting off precompiled headers is part of it. In addition, I'm sure the code base has grown. It'd be interesting to know how many lines of code there are now vs. then. Even if those are major contributors, I'd find it surprising if they were enough to double the compile times, though. On Thu, Sep 24, 2009 at 7:06 PM, Ben Goodger (Google) b...@chromium.orgwrote: I just ran a build here at home on my i7 workstation. It took 14 minutes. This is the same system that would build in 7 minutes when I set it up in May. What gives? We need to figure this out ASAP. -Ben --~--~-~--~~~---~--~~ 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?
I think in our current model, the outside entity that wants to sync stuff with us needs to maintain a separate copy of their data. In the future, if we sync other types, i'm not sure whether they want to do that or not. If that's true, then we don't really need to provide a read write lock. However, if we're used as a general database, we do. Is there a compelling reason to use us as a database? It seems like a bad idea. 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 -- 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?
+Adding back chromium-dev -Munjal On Wed, Sep 23, 2009 at 5:22 PM, Munjal Doshi mun...@chromium.org wrote: I am not sure. But it doesn't seem crazy to use sync data as a database directly for certain data types. -Munjal On Wed, Sep 23, 2009 at 5:04 PM, Jonathan Huang ch...@google.com wrote: I think in our current model, the outside entity that wants to sync stuff with us needs to maintain a separate copy of their data. If that's true, then we don't really need to provide a read write lock. However, if we're used as a general database, we do. Is there a compelling reason to use us as a database? On Wed, Sep 23, 2009 at 5:02 PM, Munjal Doshi mun...@chromium.org wrote: One thing to think about is what would happen if we have multiple data types? If the lock is going to be scoped on the entire user directory versus specific data type umbrella then we would have more contention. Of course, this can happen in both simple lock or read/write lock world but depending on how other data types are used (if many concurrent reads are needed for example) read-write lock model might do better. In other words, even though read-write locks might not do much better than simple locks today, they might do better in future. But I am not necessarily opposed to using simple locks right now.. -Munjal On Wed, Sep 23, 2009 at 4:07 PM, brg b...@chromium.org wrote: Startup sync has little chance of collision as it is uncoordinated between machines, but model association occurs here and can cause a bit of a lag. Notifications incur a read immediately after being received from a write. When a user has more than one client open, these will collide. I think we can mitigate any problems with a small random wait which occurs between receiving a notification and doing the sync. Polling should have little chance of collision. 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 -- 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] seeking advice on writing a unittest in test_shell_tests that needs to use an IO thread
Hi,
I'm writing some unittests in test_shell_tests. Some of the tests need to
run on the IO thread, but test_shell_tests uses the UI thread for its tests.
Can anyone point me to some sample code (preferably a test_shell_test) that
uses an IO thread in the test?
So far, what I've tried is failing DCHECKS and throwing exceptions.
TEST_F(MyTest, OneCase) {
base::WaitableEvent event(false, false);
base::Thread io_thread(My test thread);
base::Thread::Options options(MessageLoop::TYPE_IO, 0);
io_thread.StartWithOptions(options);
io_thread.message_loop()-PostTask(FROM_HERE,
method_factory_.NewRunnableMethod(MyTest::OneCaseOnIO, event));
// Wait until task is done before exiting the test.
event.Wait();
// :-( fails NonThreadSafe::CalledOnValidThread() when task is deleted
// :-( access violation (on IO thread after this exits)
}
Appreciate any pointers on how to do this correctly.
Thanks,
Jenn
--~--~-~--~~~---~--~~
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
Preliminary feedback shows that people are having a hard time fully embracing the new tab page. While they love the fact that now they can move, pin, hide thumbnails, other more vocal users are really missing the customized search boxes. We'll continue to monitor. On Wed, Sep 23, 2009 at 10:43 PM, Brian Rakowski br...@chromium.org wrote: We did test it in the lab, though we focused on new users who seemed to like it. We also looked at stats which indicated that the Most visited and Recently closed items were the only things that were actually used. The few people who used Recent bookmarks and Searches have been vocal, but we know there weren't many of them. We are also listening to user support (Alice tells us that feedback is mixed between love it an hate it). A more in-depth user support report is coming soon. We expect to continue trying to improve the NTP, so feedback is definitely welcome. -Brian On Wed, Sep 23, 2009 at 9:38 PM, Mike Belshe mbel...@google.com wrote: 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 -- Alice Lin | Google, Inc. | Senior Strategist, Consumer Operations | 650.253.6827 | a...@google.com This email and the information it contains are confidential and may be privileged. If you have received this email in error please notify me immediately. You should not copy it for any purpose, or disclose its contents to any other person. Internet communications are not secure and, therefore, Google does not accept legal responsibility for the contents of this message as it has been transmitted over a public network. If you suspect the message may have been intercepted or amended please contact me. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: seeking advice on writing a unittest in test_shell_tests that needs to use an IO thread
Answering my own question:
* Don't use ScopedRunnableMethodFactory to create a task to be run on a
different thread. Either create a subclass of RefCountedThreadSafe or Task
to PostTask() to a different thread. Do not make the test class a subclass
of RefCountedThreadSafe as the GTest code will not treat your test class as
a refcounted class.
* Access violation was my own (lame) bug.
Jenn
On Thu, Sep 24, 2009 at 11:38 AM, Jenn Braithwaite (胡慧鋒)
je...@google.comwrote:
Hi,
I'm writing some unittests in test_shell_tests. Some of the tests need to
run on the IO thread, but test_shell_tests uses the UI thread for its tests.
Can anyone point me to some sample code (preferably a test_shell_test) that
uses an IO thread in the test?
So far, what I've tried is failing DCHECKS and throwing exceptions.
TEST_F(MyTest, OneCase) {
base::WaitableEvent event(false, false);
base::Thread io_thread(My test thread);
base::Thread::Options options(MessageLoop::TYPE_IO, 0);
io_thread.StartWithOptions(options);
io_thread.message_loop()-PostTask(FROM_HERE,
method_factory_.NewRunnableMethod(MyTest::OneCaseOnIO, event));
// Wait until task is done before exiting the test.
event.Wait();
// :-( fails NonThreadSafe::CalledOnValidThread() when task is deleted
// :-( access violation (on IO thread after this exits)
}
Appreciate any pointers on how to do this correctly.
Thanks,
Jenn
--~--~-~--~~~---~--~~
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: seeking advice on writing a unittest in test_shell_tests that needs to use an IO thread
On Thu, Sep 24, 2009 at 9:46 PM, Jenn Braithwaite (胡慧鋒) je...@google.com wrote: Answering my own question: * Don't use ScopedRunnableMethodFactory to create a task to be run on a different thread. Yeah, that doesn't work. If you can think of more DCHECKs we can add to help you figure that out more quickly, send me a code review. :) Adam --~--~-~--~~~---~--~~ 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: seeking advice on writing a unittest in test_shell_tests that needs to use an IO thread
On Thu, Sep 24, 2009 at 9:57 PM, Adam Barth aba...@chromium.org wrote: On Thu, Sep 24, 2009 at 9:46 PM, Jenn Braithwaite (胡慧鋒) je...@google.com wrote: Answering my own question: * Don't use ScopedRunnableMethodFactory to create a task to be run on a different thread. Yeah, that doesn't work. If you can think of more DCHECKs we can add to help you figure that out more quickly, send me a code review. :) Adam Actually, if we just port ScopedRunnableMethodFactory over to WeakPtrFactory, we'll get those additional DCHECKs for free. I was planning on doing this once I have some free cycles, but if someone wants to beat me to it, no prob :-) -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: Kiosk Mode for Chrome
On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.org wrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -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: Kiosk Mode for Chrome
I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -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: Kiosk Mode for Chrome
On Thu, Sep 24, 2009 at 10:32 PM, Adam Barth aba...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.org wrote: Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? Darin is right that this is easy to do and support. We could also turn off other features that don't make sense for kiosks, like downloading files. But doing this stuff you added is when the support costs start getting nontrivial and why these features are often a risky road to travel. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -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: Kiosk Mode for Chrome
Actually, ChromeFrame is not yet an option on Mac or Linux.-Darin On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.org wrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -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: Kiosk Mode for Chrome
On Thu, Sep 24, 2009 at 10:47 PM, Darin Fisher da...@chromium.org wrote: Chrome Frame is a good option, but you'd still need a way to turn off some features. For example, a kiosk probably doesn't want to have a context menu. Chrome Frame can/will offer control over the context menu. This is exactly the kind of customization Chrome Frame can offer. Too bad we don't have Linux, Mac versions yet, but we are open source now so patches welcome :) -Darin On Thu, Sep 24, 2009 at 10:24 PM, Amit Joshi a...@chromium.org wrote: I think you should really consider embedding chrome frame ActiveX in your own simple shell. That will not only enable the application to be started with desired real estate and get rid of status bubble but allow you to customize it further if needed. On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher da...@chromium.orgwrote: On Thu, Sep 24, 2009 at 11:37 AM, Mohamed Mansour m...@chromium.orgwrote: At work today, I talked to the CEO of my company to ship Chrome browser with all our Kiosk's and recommended Chrome to be our default browser for our web products. I bench marked our current web applications with Chrome (ToT) vs IE 7, and our applications run at average 10 times faster. (For windows, Mac speed differed) There are some stuff that he didn't like: 1. Status Bubble: for a cashiering application, it keeps popping up every second since buttons are all over the place. It was distracting him from the main product. 2. Full screen mode always = Kiosk Mode. He wants the web app to stay full screen, in IE, there is kiosk mode command line switch. In FF there is a plugin. 3. JavaScript errors kept appearing intermittently (on the Mac), would work on initial deploy but require a Clear browsing data on subsequent runs. Works great on windows (chrome). I guess we would be using linux/windows for kiosk anyhow. Will there be plans for us to introduce Kiosk Mode in Chrome? It seems the current audience is just targeted towards home users and there is no way to use Google Chrome for other usages. Sure we could compile our own Chromium version, but many people (Chrome forums and elsewhere) would like to use Chrome commercially. In the meantime, I am going to compile a version with no status bar, but I believe it would be nice to include it in future versions. Maybe we could allow extensions to control (hide/show) different areas in chrome. Maybe I'm in the minority, but it doesn't sound that unreasonable to support command line options for disabling the status bubble and starting in full screen mode. We could lump these together into a --kiosk-mode command line flag. This seems like something that could be done in a fairly lightweight manner. Maybe others object? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
