[chromium-dev] FYI: added a dep for Chromium OS build
Building Chromium for Chromium OS now depends on libpam0g-dev. cheers, cmasone -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on "// NOLINT"?
2009/12/10 John Abd-El-Malek > > On Thu, Dec 10, 2009 at 1:22 PM, Evan Stade wrote: > >> On Thu, Dec 10, 2009 at 10:58 AM, Peter Kasting wrote: >> >>> On Thu, Dec 10, 2009 at 10:45 AM, Jonathan Dixon wrote: >>> In essence: return DoWork(&foo) #if defined(OS_POSIX) && DoWork(&posix_specific) #endif ; // <-- Lint complains about this guy >>> >>> I'd prefer this: >>> >>> #if defined(OS_POSIX) >>> return DoWork(&foo) && DoWork(&posix_specific); >>> #else >>> return DoWork(&foo); >>> #endif >>> >>> The same number of lines, but much easier to read. >>> >> >> disagree. It's harder to read because it's not immediately obvious that >> some of the code overlaps. Scott's solution seems best to me. >> > > +1 Scott's solution seems best for me. The problem with the above solution > is that it contains code duplication. For DoWork(&foo), that might seem > small, but as parameters get added, functions get renamed, etc, it's more > work (and error prone) to update two locations instead of one. > > >> > Opps sorry for delay in following up (I'm still tuning my filters to cope with @chromium) Scott's solution was also the first thought of, so very happy to go with that instead :-) What stopped me proposing this in the CL was I had noticed some nearby code does it via multiple returns, so I had attempted to keep consistent with the pattern:- if (!DoWork(&foo)) return false; #if defined(OS_POSIX) if (!DoWork(&posix_specific)) return false; #end return true; Quite agree this doesn't look so obvious though. Cheers! -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Cannot find -lffmpegasm
There have been some changes to the ffmpeg.gyp file recently. Dominic makes a good point that the GYP_DEFINES will make a large difference. Thiago, what GYP_DEFINES do you have set? Note that ffmpeg_asm is not a build dependency. It's a target in the ffmpeg.gyp file that must somehow be getting excluded in your build. On Mon, Dec 14, 2009 at 10:34 AM, Dominic Mazzoni wrote: > What do you have GYP_DEFINES set to? I got a compilation error > involving ffmpeg last week, but then I tried again with an empty > GYP_DEFINES and it worked fine. > > - Dominic > > On Sun, Dec 13, 2009 at 9:32 AM, Thiago Farina > wrote: > > Sorry for posting here, but I didn't find other place to ask, also I > > didn't find a solution too, so... > > > > I already tried everything, like, clobbering the out directory, > > synching again with 'gclient sync --force'. > > What I usually do is, in the trunk branch: > > $ git pull > > $ gclient sync > > $ time make CC="ccache gcc" CXX="ccache g++" -k chrome > > > > But since friday this is not working and I'm getting weird errors. > > After some searching I ending up with this following line, but remaing > > this last error. > > > > $time make CC="ccache gcc" CXX="ccache g++" LDFLAGS+=-ldl LDFLAGS+=- > > lpthread -k chrome > > SOLINK(target) out/Debug/lib.target/third_party/ffmpeg/ > > libffmpegsumo.so > > /usr/bin/ld: error: cannot find -lffmpegasm > > collect2: ld returned 1 exit status > > make: *** [out/Debug/lib.target/third_party/ffmpeg/libffmpegsumo.so] > > Error 1 > > make: Target `chrome' not remade because of errors. > > > > real1m3.344s > > user0m23.237s > > sys 0m7.532s > > > > I hope someone could give me a hint how to make this work again. > > > > Ah, I ran build/install-build-deps.sh to see if I was missing some dev > > package, but it says that everything is installed. > > > > PS: without these LDFLAGS , the compilation don't work also. > > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > >http://groups.google.com/group/chromium-dev > > > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 18:24, Aaron Boodman wrote: > On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay wrote: >> On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: >>> >>> Seems like a bad idea. >>> >>> Extensions and DOMUI are basically two competing systems for doing the >>> same thing, it would get confusing combining them. >> >> While I can see this in principle, I'm not sure I see what the problems are >> in practice. What kinds of problems do you envision? >> I think it would be nice for our current DOMUI pages to be built on top of >> the extensions APIs, but potentially have access to a few special APIs that >> extensions don't. It seems like it would be painful to try to cut them over >> to such a system all at once, so adding extensions APIs to DOMUI pages could >> be a nice bridge. > > When you say "built on top of the extensions APIs" do you mean have > access to, eg, chrome.tabs.*? Or do you mean use our > ExtensionFunctionDispatcher and json schema infrastructure, but not > use any of our APIs? I looked at the latter once before and it was a > serious project. There is a lot of knowledge about the extension > system baked into ExtensionFunctionDispatcher, such as who the current > extension is and knowledge of the json schema system in the renderer. > > I think a simpler approach to get the benefits of the extension system > is to just make the bookmark manager an extension. We'd have to filter > it out of the chrome://extensions/ page and change its icon in the > task manager, but those are fairly trivial changes compared to tearing > all the knowledge of extensions out of ExtensionFunctionDispatcher > system. > > If we want the bookmark manager to have some special APIs that other > extensions don't, that also seems fairly easy to do once the bookmark > manager is indeed an extension. > > To be clear, I'm also open to lower-level refactorings. I'm just > warning that I suspect it's a serious project. A couple weeks at > least. The goal is to have a working bookmark manager at the end of January and a complete one at the end of Q1. That makes me think that making a DOM UI version that uses the extension API would not be feasible. I also don't think that doing it as an extension is something that can be done in the same time frame due to lacking APIs. I think I'll just do an old school DOM UI and emulate the extensions bookmark API so that the same code can be used. > > - a > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 5:43 PM, Erik Kay wrote: > On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: >> >> Seems like a bad idea. >> >> Extensions and DOMUI are basically two competing systems for doing the >> same thing, it would get confusing combining them. > > While I can see this in principle, I'm not sure I see what the problems are > in practice. What kinds of problems do you envision? > I think it would be nice for our current DOMUI pages to be built on top of > the extensions APIs, but potentially have access to a few special APIs that > extensions don't. It seems like it would be painful to try to cut them over > to such a system all at once, so adding extensions APIs to DOMUI pages could > be a nice bridge. When you say "built on top of the extensions APIs" do you mean have access to, eg, chrome.tabs.*? Or do you mean use our ExtensionFunctionDispatcher and json schema infrastructure, but not use any of our APIs? I looked at the latter once before and it was a serious project. There is a lot of knowledge about the extension system baked into ExtensionFunctionDispatcher, such as who the current extension is and knowledge of the json schema system in the renderer. I think a simpler approach to get the benefits of the extension system is to just make the bookmark manager an extension. We'd have to filter it out of the chrome://extensions/ page and change its icon in the task manager, but those are fairly trivial changes compared to tearing all the knowledge of extensions out of ExtensionFunctionDispatcher system. If we want the bookmark manager to have some special APIs that other extensions don't, that also seems fairly easy to do once the bookmark manager is indeed an extension. To be clear, I'm also open to lower-level refactorings. I'm just warning that I suspect it's a serious project. A couple weeks at least. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [extensions] bug gardening, stable version
I've gone through and gardened the bugs per our goals for stable: Win, linux: http://bit.ly/5s4lrp Mac: http://bit.ly/8hHpdO Surely I'm missing some, but this should be a start. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 4:48 PM, Aaron Boodman wrote: > Seems like a bad idea. > > Extensions and DOMUI are basically two competing systems for doing the > same thing, it would get confusing combining them. While I can see this in principle, I'm not sure I see what the problems are in practice. What kinds of problems do you envision? I think it would be nice for our current DOMUI pages to be built on top of the extensions APIs, but potentially have access to a few special APIs that extensions don't. It seems like it would be painful to try to cut them over to such a system all at once, so adding extensions APIs to DOMUI pages could be a nice bridge. Erik > I would rather > either: > > a) add new (possibly experimental) APIs for the issues you've run into. > b) manually plumb the extension APIs you need through DOMUI (this is > basically composition instead of inheritance) > > Is this the complete list of bugs? > > http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv > > Context menu is potentially on the M5 list. Depending on how complex a > context menu API you want, this might not be too bad. We should just > implement the chrome:// urls one I guess. > > - a > > On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson wrote: > > I'm in the process of writing a bookmark manager in HTML. So far I've > > written it as an extension but I'm now considering changing this to a > > DOM UI page instead. [*] > > > > I would like to be able to expose the extensions API for bookmarks to > > the DOM UI (and eventually make all DOM UI pages use extension APIs). > > Where do I start? Is this a bad idea? > > > > Another option is to keep the bookmarks manager as a special extension > > that is always turned on. > > > > [*] Extensions do not have enough privileges and there aren't enough > > hooks to allow extensions to do all the things the bookmark manager > > needs to do. I've filed bugs for everything I've run into. > > > > erik > > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 5:29 PM, Erik Arvidsson wrote: > On Mon, Dec 14, 2009 at 16:48, Aaron Boodman wrote: >> Seems like a bad idea. >> >> Extensions and DOMUI are basically two competing systems for doing the >> same thing, it would get confusing combining them. I would rather >> either: >> >> a) add new (possibly experimental) APIs for the issues you've run into. >> b) manually plumb the extension APIs you need through DOMUI (this is >> basically composition instead of inheritance) > > Seems like b then. However, the extensions APIs are much nicer than > all the ad-hoc chrome.send + CallJavascriptFunction we are currently > using and having the same API seems like a win for maintainability. I agree the current DOM UI method of sending calls stinks. I've looked at using the extension system's mechanism before but it will be a lot of work to decouple from the extension system I think. But feel free to take a fresh look if you want. >> Is this the complete list of bugs? >> http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv >> >> Context menu is potentially on the M5 list. Depending on how complex a >> context menu API you want, this might not be too bad. We should just >> implement the chrome:// urls one I guess. > > If we make the bookmark manager completely as an extension extensions > need to be able to hook up global keyboard shortcuts (27702) as well > as some way to hook into the wrench and system menus on mac. I don't see why. We can implement those things in Chrome directly. Chrome can know about this special extension. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 16:48, Aaron Boodman wrote: > Seems like a bad idea. > > Extensions and DOMUI are basically two competing systems for doing the > same thing, it would get confusing combining them. I would rather > either: > > a) add new (possibly experimental) APIs for the issues you've run into. > b) manually plumb the extension APIs you need through DOMUI (this is > basically composition instead of inheritance) Seems like b then. However, the extensions APIs are much nicer than all the ad-hoc chrome.send + CallJavascriptFunction we are currently using and having the same API seems like a win for maintainability. > > Is this the complete list of bugs? > http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv > > Context menu is potentially on the M5 list. Depending on how complex a > context menu API you want, this might not be too bad. We should just > implement the chrome:// urls one I guess. If we make the bookmark manager completely as an extension extensions need to be able to hook up global keyboard shortcuts (27702) as well as some way to hook into the wrench and system menus on mac. > > - a > > On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson wrote: >> I'm in the process of writing a bookmark manager in HTML. So far I've >> written it as an extension but I'm now considering changing this to a >> DOM UI page instead. [*] >> >> I would like to be able to expose the extensions API for bookmarks to >> the DOM UI (and eventually make all DOM UI pages use extension APIs). >> Where do I start? Is this a bad idea? >> >> Another option is to keep the bookmarks manager as a special extension >> that is always turned on. >> >> [*] Extensions do not have enough privileges and there aren't enough >> hooks to allow extensions to do all the things the bookmark manager >> needs to do. I've filed bugs for everything I've run into. >> >> erik >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Layout Tests Task Force meeting notes 12/14/2009
Layout Tests Task Force meeting notes 12/14/2009 * * AI for jeffreyc/dglazkov: We will be sending out a spreadsheet tomorrow with general future areas of work that folks can sign up for. "LTTF and Beyond" Next steps: - Fix or triage remaining failures (short-term) - Drain the finders pool - Assign milestones/priority/owner to all fixer bugs - Migrate layout tests upstream (longer-term) - Harness - Test expectations - DumpRenderTree - V8 + JSC = <3 (somehow) - infrastructure (dashboard, rebaseline tools, bot config, etc.) - Maintain compatibility (long-term) - WebKit gardening += test gardening - Gardeners = committers - inactive committers. - Improve gardening tools: - new/regression detection, notifications, etc. - Expert list and possibly semi-automated routing of bugs - keeping accurate expectations (no orange!) -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: [chromium-reviews] Re: By popular (?) demand, add some more options for different styles of output.... (issue495006)
OK. Dirk and I talked offline and we came to this conclusion: We default to "--log detailed-progress,unexpected". For now, detailed-progress does nothing if --experimental-fully-parallel isn't also specified. If it is also specified, then it logs directories + dots a la upstream webkit. In a followup patch, I'll make it print out each shard as we go for the default case of sharding by directory. Ojan On Mon, Dec 14, 2009 at 4:46 PM, Ojan Vafai wrote: > +chromium-dev > > I don't think having a third mode makes sense. We should have terse > (default) and verbose (--verbose). One is for running locally and one is for > the bots. Having the flexibility of the --log option is fine, but we should > pick a default for terse mode that most people are happy with. > > My intuition is that most people running the tests locally want: > 1. To see unexpected results (passes and failures) as they happen > 2. To know roughly which tests have run. The directories + dots gives this > feedback. Just directories is probably sufficient though. > > I'd be OK with not printing out unexpected results at the end in terse mode > and instead printing them out as we go, or making that a --log option. > > I think the default should be what you're currently calling third_mode, but > if you pass in --log "" then it could log as we do today. > > As you said though, the current implementation of third_mode doesn't make > sense when we're sharding by directory. So, for this change, it's fine to > have (2) above addressed only for --experimental-fully-parallel, but (1) > should be done for both fully-parallel and directory-sharded. > > Ojan > > On Mon, Dec 14, 2009 at 4:17 PM, Dirk Pranke wrote: > >> Okay, for further clarification ... >> >> There are currently (as checked in), two modes of output, the one-line >> version (default, aka "terse" mode) and --verbose. The patch adds a >> "third mode", which effectively disables sharding and enables >> --fully-parallel. >> >> Note that it is possible to run sharding or fully-parallel without "third >> mode". >> >> Which of the following are you suggesting (multiple are okay): >> >> 1) Do nothing (drop the patch) >> >> 2) Submit the patch as is - this adds a "third" mode enabled by a new >> command line flag which prints directories and dots but does not print >> unexpected results by default. >>"third" mode disables sharding. In either "terse" mode or "third" >> adding "--log failures" will log unexpected failures in real time but >> not passes. >> >> 3) Add another flag for unexpected passes in either mode, e.g. "--log >> passes" >> >> 4) Change "--log failures" to "--log unexpected" so that you get both >> or neither. >> >> 5) Always log unexpected failures in terse mode (no flag needed) >> >> 6) Always log unexpected passes in terse mode (no flag needed) >> >> 7) Always log unexpected failures in "third" mode >> >> 8) Always log unexpected passes in "third" mode >> >> 9) Modify the patch so that --experimental-fully-parallel enables >> "third mode". This means that you get "terse + sharding" or "third >> mode + fully-parallel" >> >> 10) Eliminate "terse" mode, so that we only have two modes - "third" >> and "verbose" >> >> I am fine with (1), (2), (3), (4), (7), and (8). I would prefer (3) or >> (4), and am happy with (2) with or without (7) and/or (8) even though >> I won't (often) use it. I could grudgingly accept (5) and (6), >> although I don't think it's as clean as making logging of unexpected >> results a separate feature (since we log the unexpected results at the >> end, I don't think they always need to be in the middle). I don't like >> (9), and I like (10) even less, since both of these options actually >> undo much of my previous work and produce test scripts that I want to >> use less than the versions that exist now. >> >> -- Dirk >> >> On Mon, Dec 14, 2009 at 3:37 PM, Ojan Vafai wrote: >> > On Mon, Dec 14, 2009 at 3:19 PM, Dirk Pranke >> wrote: >> >> >> >> (1) We can leave the output as is (discarding this patch) >> >> + It is the tersest >> >> + It works fine regardless of what order tests are executed in, and >> >> whether or not you are sharding or running in full parallel mode >> >> + It has the minimum amount of code >> >> - It loses the incremental "." output that webkit has >> >> - It loses the directory by directory output that webkit has >> >> - It loses the printing of unexpected test failures in real time >> >> that webkit has >> >> >> >> (1a) I can add the realtime printout of unexpected failures >> >> (1b) I can add the realtime printout of unexpected passes >> > >> > At least printing out unexpected failures in real-time seems to me to be >> a >> > non-negotiable requirement. I think we may as well printout unexpected >> > passes. It's useful information when running the tests. >> > >> >> >> >> (2) We can take the patch as is (with the minor cleanup Ojan >> >> suggested, of course) >> >> + It adds printout of unexpected failures >> >> + It
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Mon, Dec 14, 2009 at 4:47 PM, Evan Stade wrote: > we have had a lot of bug reports asking for NEW_WINDOW, but none for these > two dispositions. What use cases do you envisage? > Wanting to open pages in either of these ways? Firefox used to have options to control this and I was sad when they removed them. CURRENT_TAB is useful for people who like only using one tab (there are some) and for using Chrome as an external viewer for HTML-based content. NEW_BACKGROUND_TAB is useful for shoveling stuff in without disturbing whatever the user is doing. To put it a different way, the cost of supporting these now is basically indistinguishable from the cost of just adding --new-window. We're never going to remove them, so there won't be any maintenance burden. But if we implement --new-window and decide we need to support one of these, we have to add a new option. Same if we ever add any other useful disposition and want to support it. So this ensures we won't ever need to add more options. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Exposing Chrome Extensions APIs to DOM UI.
Seems like a bad idea. Extensions and DOMUI are basically two competing systems for doing the same thing, it would get confusing combining them. I would rather either: a) add new (possibly experimental) APIs for the issues you've run into. b) manually plumb the extension APIs you need through DOMUI (this is basically composition instead of inheritance) Is this the complete list of bugs? http://code.google.com/p/chromium/issues/list?can=2&q=feature:extensions+reporter:arv Context menu is potentially on the M5 list. Depending on how complex a context menu API you want, this might not be too bad. We should just implement the chrome:// urls one I guess. - a On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson wrote: > I'm in the process of writing a bookmark manager in HTML. So far I've > written it as an extension but I'm now considering changing this to a > DOM UI page instead. [*] > > I would like to be able to expose the extensions API for bookmarks to > the DOM UI (and eventually make all DOM UI pages use extension APIs). > Where do I start? Is this a bad idea? > > Another option is to keep the bookmarks manager as a special extension > that is always turned on. > > [*] Extensions do not have enough privileges and there aren't enough > hooks to allow extensions to do all the things the bookmark manager > needs to do. I've filed bugs for everything I've run into. > > erik > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: [chromium-reviews] Re: By popular (?) demand, add some more options for different styles of output.... (issue495006)
+chromium-dev I don't think having a third mode makes sense. We should have terse (default) and verbose (--verbose). One is for running locally and one is for the bots. Having the flexibility of the --log option is fine, but we should pick a default for terse mode that most people are happy with. My intuition is that most people running the tests locally want: 1. To see unexpected results (passes and failures) as they happen 2. To know roughly which tests have run. The directories + dots gives this feedback. Just directories is probably sufficient though. I'd be OK with not printing out unexpected results at the end in terse mode and instead printing them out as we go, or making that a --log option. I think the default should be what you're currently calling third_mode, but if you pass in --log "" then it could log as we do today. As you said though, the current implementation of third_mode doesn't make sense when we're sharding by directory. So, for this change, it's fine to have (2) above addressed only for --experimental-fully-parallel, but (1) should be done for both fully-parallel and directory-sharded. Ojan On Mon, Dec 14, 2009 at 4:17 PM, Dirk Pranke wrote: > Okay, for further clarification ... > > There are currently (as checked in), two modes of output, the one-line > version (default, aka "terse" mode) and --verbose. The patch adds a > "third mode", which effectively disables sharding and enables > --fully-parallel. > > Note that it is possible to run sharding or fully-parallel without "third > mode". > > Which of the following are you suggesting (multiple are okay): > > 1) Do nothing (drop the patch) > > 2) Submit the patch as is - this adds a "third" mode enabled by a new > command line flag which prints directories and dots but does not print > unexpected results by default. >"third" mode disables sharding. In either "terse" mode or "third" > adding "--log failures" will log unexpected failures in real time but > not passes. > > 3) Add another flag for unexpected passes in either mode, e.g. "--log > passes" > > 4) Change "--log failures" to "--log unexpected" so that you get both > or neither. > > 5) Always log unexpected failures in terse mode (no flag needed) > > 6) Always log unexpected passes in terse mode (no flag needed) > > 7) Always log unexpected failures in "third" mode > > 8) Always log unexpected passes in "third" mode > > 9) Modify the patch so that --experimental-fully-parallel enables > "third mode". This means that you get "terse + sharding" or "third > mode + fully-parallel" > > 10) Eliminate "terse" mode, so that we only have two modes - "third" > and "verbose" > > I am fine with (1), (2), (3), (4), (7), and (8). I would prefer (3) or > (4), and am happy with (2) with or without (7) and/or (8) even though > I won't (often) use it. I could grudgingly accept (5) and (6), > although I don't think it's as clean as making logging of unexpected > results a separate feature (since we log the unexpected results at the > end, I don't think they always need to be in the middle). I don't like > (9), and I like (10) even less, since both of these options actually > undo much of my previous work and produce test scripts that I want to > use less than the versions that exist now. > > -- Dirk > > On Mon, Dec 14, 2009 at 3:37 PM, Ojan Vafai wrote: > > On Mon, Dec 14, 2009 at 3:19 PM, Dirk Pranke > wrote: > >> > >> (1) We can leave the output as is (discarding this patch) > >> + It is the tersest > >> + It works fine regardless of what order tests are executed in, and > >> whether or not you are sharding or running in full parallel mode > >> + It has the minimum amount of code > >> - It loses the incremental "." output that webkit has > >> - It loses the directory by directory output that webkit has > >> - It loses the printing of unexpected test failures in real time > >> that webkit has > >> > >> (1a) I can add the realtime printout of unexpected failures > >> (1b) I can add the realtime printout of unexpected passes > > > > At least printing out unexpected failures in real-time seems to me to be > a > > non-negotiable requirement. I think we may as well printout unexpected > > passes. It's useful information when running the tests. > > > >> > >> (2) We can take the patch as is (with the minor cleanup Ojan > >> suggested, of course) > >> + It adds printout of unexpected failures > >> + It adds the "." output > >> + It adds the directory by directory output > >> + This is as webkit-compatible as we can get > >> - It loses sharding (I believe you can't do sharding and print > >> directory-by-directory completion or "."s in any meaningful way; I > >> don't know what the output would have to look like since the > >> interleaving would be all over the place) > >> - It introduces additional complexity (a manageable amount) > >> > >> (2a) I can add the realtime printout of unexpected passes as well > > > > I think this is fine. I just think we should tie this to > >
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Mon, Dec 14, 2009 at 4:43 PM, Peter Kasting wrote: > On Mon, Dec 14, 2009 at 4:34 PM, Evan Stade wrote: > >> I think adding a --disposition= field is overkill and will be harder to >> maintain (which is the worst part about command line flags). If a new >> disposition is added to webkit, one is renamed, or one is deleted, are you >> willing to either maintain this code or have users' desktop shortcuts break? >> > > Given that I'm the one that created the dispositions in the first place, > yeah, I am. > > CURRENT_TAB and NEW_BACKGROUND_TAB are pretty useful. The rest aren't, so > I'd only add those two alongside the two you mentioned. > we have had a lot of bug reports asking for NEW_WINDOW, but none for these two dispositions. What use cases do you envisage? > > I don't know why we have both SUPPRESS_OPEN and IGNORE_ACTION; I added the > first and Ojan added the second. At this point it looks like we only ever > set IGNORE_ACTION, and we only ever act on SUPPRESS_OPEN, so something is > really messed up. > > PK > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Mon, Dec 14, 2009 at 4:34 PM, Evan Stade wrote: > I think adding a --disposition= field is overkill and will be harder to > maintain (which is the worst part about command line flags). If a new > disposition is added to webkit, one is renamed, or one is deleted, are you > willing to either maintain this code or have users' desktop shortcuts break? > Given that I'm the one that created the dispositions in the first place, yeah, I am. CURRENT_TAB and NEW_BACKGROUND_TAB are pretty useful. The rest aren't, so I'd only add those two alongside the two you mentioned. I don't know why we have both SUPPRESS_OPEN and IGNORE_ACTION; I added the first and Ojan added the second. At this point it looks like we only ever set IGNORE_ACTION, and we only ever act on SUPPRESS_OPEN, so something is really messed up. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Mon, Dec 14, 2009 at 11:06 AM, Peter Kasting wrote: > On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote: > >> I think for parity with other apps, we should provide a command line >> switch >> to force the WindowOpenDisposition to NEW_WINDOW. For bonus points, >> we could expose other dispositions. >> > > Given mdm's explanation, I agree. And I agree that it would be nice to > expose other dispositions. It's not particularly more difficult to do this, > so we could just implement "--disposition=" with a few different possible > strings. > > I think adding a --disposition= field is overkill and will be harder to maintain (which is the worst part about command line flags). If a new disposition is added to webkit, one is renamed, or one is deleted, are you willing to either maintain this code or have users' desktop shortcuts break? I only see two dispositions worth supporting: NEW_FOREGROUND_TAB, NEW_WINDOW, these don't look worth it: SUPPRESS_OPEN, (don't actually know what this is) CURRENT_TAB, (no use case) SINGLETON_TAB, (no use case) NEW_BACKGROUND_TAB, (not different enough from foreground tab to care) NEW_POPUP, (i.e. app mode) SAVE_TO_DISK, (no use case) OFF_THE_RECORD, (exists via --incognito) IGNORE_ACTION (don't actually know what this is) as such, that patch LGTM if you add yourself to the authors file. > PK > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Exposing Chrome Extensions APIs to DOM UI.
I'm in the process of writing a bookmark manager in HTML. So far I've written it as an extension but I'm now considering changing this to a DOM UI page instead. [*] I would like to be able to expose the extensions API for bookmarks to the DOM UI (and eventually make all DOM UI pages use extension APIs). Where do I start? Is this a bad idea? Another option is to keep the bookmarks manager as a special extension that is always turned on. [*] Extensions do not have enough privileges and there aren't enough hooks to allow extensions to do all the things the bookmark manager needs to do. I've filed bugs for everything I've run into. erik -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Building chromium for arm--erroring out
On Mon, Dec 14, 2009 at 1:30 PM, Sofia Tahseen wrote: > Hi Antoine/All, > > This is what I did: > export GYP_DEFINES="target_arch=arm > sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root > disable_nacl=1 use_system_ffmpeg=1" > gclient runhooks --force > gclient sync > > export > CROSSTOOL=/home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/arm-none-linux-gnueabi > export CXX=$CROSSTOOL-g++ > export CC=$CROSSTOOL-gcc > export AR=$CROSSTOOL-ar > export AS=$CROSSTOOL-as > export RANLIB=$CROSSTOOL-ranlib > export LD=$CROSSTOOL-ld > > And then I run the make command > make -r -j6 BUILDTYPE=Release chrome 2>&1 |tee ./makelog.txt > > To my suprise, the build is erroring out... I am attaching the makelog for > this. > Really appreciate your help on this. > > Thanks, > Sofia > The very first target compilation steps fails with missing standard headers, which would point at a sysroot problem... Antoine > > On Mon, Dec 14, 2009 at 2:19 PM, Sofia Tahseen wrote: > >> Yes it was erroring out at the same point S32A_Opaque_BlitRow32_neon...but >> I had not done gclient runhooks --force...Now I am re-doing it...Lets wait >> and see how this works. >> >> >> >> On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry wrote: >> >>> >>> >>> 2009/12/14 Sofia Tahseen >>> >>> Hi Antoine, I did exactly what you said-- not set armv7=1 in gyp_defines. export GYP_DEFINES="target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1" I rebuilt chromium. And then I reset my kernel so that it does not use NEON. This does not help and the browser keeps crashing again even though I do not set armv7=1 in gyp_defines. So is there a way to disable neon settings on chromium browser and make chromium working on a hardware that does not support NEON? >>> Is it still crashing in S32A_Opaque_BlitRow32_neon ? >>> >>> Thanks, Sofia On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour wrote: > > > On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen < > sofia.tahs...@gmail.com> wrote: > >> Hi Joel/Erik/All, >> >> I don't think armv5 is an issue. Reason being I used the jaunty armv5 >> libraries to build chrome. >> >> I tried to debug the issue with gdb. >> gdb chrome >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show >> copying" >> and "show warranty" for details. >> This GDB was configured as "arm-linux-gnueabi"... >> >> (gdb) >> (gdb) run >> Starting program: /home/adas/Release/chrome >> [Thread debugging using libthread_db enabled] >> [New Thread 0x4112ac80 (LWP 9722)] >> [New Thread 0x41d49440 (LWP 9727)] >> [New Thread 0x42549440 (LWP 9728)] >> [New Thread 0x42d49440 (LWP 9729)] >> [New Thread 0x43549440 (LWP 9730)] >> [New Thread 0x43d49440 (LWP 9731)] >> [New Thread 0x44549440 (LWP 9732)] >> [New Thread 0x44d49440 (LWP 9733)] >> [New Thread 0x44d69440 (LWP 9734)] >> [New Thread 0x458ff440 (LWP 9738)] >> [New Thread 0x460ff440 (LWP 9739)] >> [Thread 0x460ff440 (LWP 9739) exited] >> >> Program received signal SIGILL, Illegal instruction. >> [Switching to Thread 0x4112ac80 (LWP 9722)] >> 0x0081caec in S32A_Opaque_BlitRow32_neon () >> Current language: auto; currently asm >> >> >> The error S32A_Opaque_BlitRow32_neon () had to do something with the >> floating point setting of the kernel. I checked my kernel configuration >> and >> neon was not set. So I set it and it rebuild my kernel and booted my >> jaunty. >> Now it works perfectly...without any crashes. >> >> Key : In order to run chromium we need to set the neon in the kernel >> configuration. >> > > Note, if you don't set armv7=1 when you build chromium, it shouldn't > use the NEON paths, so you shouldn't run into that problem. But it's > better > to enable it in the kernel if your hardware supports it. > > Antoine > > >> Regards, >> Sofia >> >> >> On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry wrote: >> >>> 2009/12/10 Sofia Tahseen : >>> > You are so right, Joel... I corrected my .so and now I could build >>> the >>> > chrome browser ...finally!! I copied the whole /src/out/Release >>> directory >>> > to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome >>> through: >>> > ./chrome >>> > It starts up chrome, and then immediately kills chrome. I get an >>> Illegal >>> > Instruction. I restart and I ca
[chromium-dev] UI Jank Task Force Status Update
UI Jank Task Force Status Update Last meeting until 2010. *Status* Carlos - Keep trying to build PGO. Trying to build just a part of Chrome (instrument just the ‘browser’ project) to get around the problem. Chase - Tab switching tests problem resolved; re-enabled. Cause is unclear (interactive perf), bug filed. - Patch for reference build for tab switching tests in the works, will send to John. John - Fixing the whole browser hang with Target’s flyer site. Turned out to be an evangelism issue -- reported upstream. Tony - Profiling renderer startup; most slowness is when renderer is waiting from the browser. Not much to be done here. - Will try to move the visited database loading on the file thread. (Will still block UI thread if it takes a long time to load) - Writes may be on IO thread, will look into moving them too. Evan - Looking at tabstrip on Linux, found an improvement in tab-dragging. - Working on extensions, bugs. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] http://build.chromium.org/buildbot/continuous/LATEST/REVISION has changed
If you're using the safesync URL http://build.chromium.org/buildbot/continuous/LATEST/REVISION in your .gclient file, your "gclient sync" command should be failing now. This is because the URL has been replaced by three platform-specific URLs: http://build.chromium.org/buildbot/continuous/linux/LATEST/REVISION http://build.chromium.org/buildbot/continuous/mac/LATEST/REVISION http://build.chromium.org/buildbot/continuous/win/LATEST/REVISION Please change the safesync_url field in your .gclient file to one of the new platform-specific URLs. I've updated the documentation at http://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code#TOC-Continuous-build Wan-Teh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
> > Anyhow, what's our best practices for disabling tests? I think ideally we'd > always log a tracking bug and add a comment, akin to what we do in the > test_expectations file for layout tests. This might be too much of a burden > on sheriffs, so an alternative is for people who are working on various > areas (like workers) track checkins to the associated files and add some > documentation after the fact. Or we can just live with the SVN logs, in > which case I need to get better about figuring out how to track through the > SVN/git history of the various files :) > I wrote up this section under our Tree Sheriff page: http://dev.chromium.org/developers/tree-sheriffs#TOC-Disabling-tests In summary: writing a bug, copying+pasting output, and assigning an owner. For code that was recently checked in but the person doesn't want to revert, I tend to file the bug as a P1 + Regression label. Andrew -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Building chromium for arm--erroring out
Yes it was erroring out at the same point S32A_Opaque_BlitRow32_neon...but I had not done gclient runhooks --force...Now I am re-doing it...Lets wait and see how this works. On Mon, Dec 14, 2009 at 1:07 PM, Erik Corry wrote: > > > 2009/12/14 Sofia Tahseen > > Hi Antoine, >> >> I did exactly what you said-- not set armv7=1 in gyp_defines. >> >> export GYP_DEFINES="target_arch=arm >> sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root >> disable_nacl=1 use_system_ffmpeg=1" >> >> I rebuilt chromium. >> >> And then I reset my kernel so that it does not use NEON. >> >> This does not help and the browser keeps crashing again even though I do >> not set armv7=1 in gyp_defines. So is there a way to disable neon settings >> on chromium browser and make chromium working on a hardware that does not >> support NEON? >> >> > Is it still crashing in S32A_Opaque_BlitRow32_neon ? > > >> Thanks, >> Sofia >> >> >> >> On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour wrote: >> >>> >>> >>> On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen >>> wrote: >>> Hi Joel/Erik/All, I don't think armv5 is an issue. Reason being I used the jaunty armv5 libraries to build chrome. I tried to debug the issue with gdb. gdb chrome GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabi"... (gdb) (gdb) run Starting program: /home/adas/Release/chrome [Thread debugging using libthread_db enabled] [New Thread 0x4112ac80 (LWP 9722)] [New Thread 0x41d49440 (LWP 9727)] [New Thread 0x42549440 (LWP 9728)] [New Thread 0x42d49440 (LWP 9729)] [New Thread 0x43549440 (LWP 9730)] [New Thread 0x43d49440 (LWP 9731)] [New Thread 0x44549440 (LWP 9732)] [New Thread 0x44d49440 (LWP 9733)] [New Thread 0x44d69440 (LWP 9734)] [New Thread 0x458ff440 (LWP 9738)] [New Thread 0x460ff440 (LWP 9739)] [Thread 0x460ff440 (LWP 9739) exited] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x4112ac80 (LWP 9722)] 0x0081caec in S32A_Opaque_BlitRow32_neon () Current language: auto; currently asm The error S32A_Opaque_BlitRow32_neon () had to do something with the floating point setting of the kernel. I checked my kernel configuration and neon was not set. So I set it and it rebuild my kernel and booted my jaunty. Now it works perfectly...without any crashes. Key : In order to run chromium we need to set the neon in the kernel configuration. >>> >>> Note, if you don't set armv7=1 when you build chromium, it shouldn't use >>> the NEON paths, so you shouldn't run into that problem. But it's better to >>> enable it in the kernel if your hardware supports it. >>> >>> Antoine >>> >>> Regards, Sofia On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry wrote: > 2009/12/10 Sofia Tahseen : > > You are so right, Joel... I corrected my .so and now I could build > the > > chrome browser ...finally!! I copied the whole /src/out/Release > directory > > to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome > through: > > ./chrome > > It starts up chrome, and then immediately kills chrome. I get an > Illegal > > Instruction. I restart and I can now see chrome as shown in the > attachment > > but I cannot browse. When I reload the page, it again kills chrome > saying > > Illegal instruction. Has anyone seen this before? I have my proxy > settings > > set too.. > > This could be anything, but it might be this bug in some versions of > gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 > > If that's it then adding -fno-tree-sink to the flags used for V8 will > help. It's a bug that only shows up on ARM and only on some versions > of gcc. > > > > > Any help is highly appreciated. > > Thanks, > > Sofia > > > > On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley > wrote: > >> > >> On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen < > sofia.tahs...@gmail.com> > >> wrote: > >> > >> > > >> > > /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: > >> > skipping incompatible > >> > > >> > > /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so > >> > when searching for -lrt > >> > >> The errors are indicative of trying to link against libraries from
Re: [chromium-dev] Embedding chrome.pak in the chrome binary for Linux?
On Mon, Dec 14, 2009 at 12:02 PM, Tony Chang wrote: > I have considered the possibility of moving the resources on Windows out of > chrome.dll. I made a change a few weeks back that moved theme resources > into chrome.dll and there was no noticeable change on the bots. I imagine > moving them back out (along with chrome resources) would not slow down > startup on the bots either. > > The benefit to doing this would be that small changes to the resources file > wouldn't cause a relink, which is exceptionally painful on Windows. > > > On Sat, Dec 12, 2009 at 9:33 PM, Satoru Takabayashi > wrote: > >> Evan, >> >> Thank you for the detailed feedback. It looks there won't be a much >> difference so I'll just forget about the idea. >> >> Thanks, >> Satoru >> >> On Sun, Dec 13, 2009 at 12:36 PM, Evan Martin wrote: >> > On Sat, Dec 12, 2009 at 4:52 AM, Satoru Takabayashi >> > wrote: >> >> The chrome binary for Linux seems to load resource bundles from a file >> >> named >> >> "chrome.pak", while the resource booundles are embedded in the chrome >> >> DLL in >> >> other platforms (correct me if I'm wrong). This makes me wonder if it's >> a >> >> good idea to embed chrome.pak in the chrome binary for Linux. This >> would >> >> save open+mmap cost (probably negligible though), and would make the >> >> package >> >> a bit simpler. I guess it can be done with objcopy, without too much >> >> work. >> >> Any thoughts? >> >> > I thought about this for a while and I'm not sure there is enough of a >> > difference either way to make it matter. It seems that having it >> > within the executable should be nearly identical in terms of startup >> > cost and memory usage. I guess the code might be slightly less >> > complicated, but we already pay complexity anyway for locating the >> > locale data, which remains separate. >> >> > If I have any preference, I would prefer it either all one way (all >> > static data embedded within the executable) or the other (all static >> > data external to the executable). Right now we're somewhere in the >> > middle (since ICU data is in the executable) and your proposed change >> > also leaves us in the middle (since it would leave locale data out of >> > the executable). >> >> > There's maybe one other benefit to consider: the simpler the >> > executable, the faster the iterative compile/link cycle will be. But >> > again I wonder if the difference would be enough to measure, since the >> > resources data is only 1.4mb. (The ICU data is something like 8mb, so >> > that ought to cost more.) >> >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >>http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: > Anyhow, what's our best practices for disabling tests? I think ideally we'd > always log a tracking bug and add a comment, akin to what we do in the > test_expectations file for layout tests. Another point to keep in mind - when you file a bug, do not write: "test foo.bar failed, here's the error: http://path/to/failed_test.log"; because we don't keep logs forever. Please paste the snippet of the log with the error instead. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Building chromium for arm--erroring out
2009/12/14 Sofia Tahseen > Hi Antoine, > > I did exactly what you said-- not set armv7=1 in gyp_defines. > > export GYP_DEFINES="target_arch=arm > sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root > disable_nacl=1 use_system_ffmpeg=1" > > I rebuilt chromium. > > And then I reset my kernel so that it does not use NEON. > > This does not help and the browser keeps crashing again even though I do > not set armv7=1 in gyp_defines. So is there a way to disable neon settings > on chromium browser and make chromium working on a hardware that does not > support NEON? > > Is it still crashing in S32A_Opaque_BlitRow32_neon ? > Thanks, > Sofia > > > > On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour wrote: > >> >> >> On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen >> wrote: >> >>> Hi Joel/Erik/All, >>> >>> I don't think armv5 is an issue. Reason being I used the jaunty armv5 >>> libraries to build chrome. >>> >>> I tried to debug the issue with gdb. >>> gdb chrome >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later < >>> http://gnu.org/licenses/gpl.html> >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "arm-linux-gnueabi"... >>> >>> (gdb) >>> (gdb) run >>> Starting program: /home/adas/Release/chrome >>> [Thread debugging using libthread_db enabled] >>> [New Thread 0x4112ac80 (LWP 9722)] >>> [New Thread 0x41d49440 (LWP 9727)] >>> [New Thread 0x42549440 (LWP 9728)] >>> [New Thread 0x42d49440 (LWP 9729)] >>> [New Thread 0x43549440 (LWP 9730)] >>> [New Thread 0x43d49440 (LWP 9731)] >>> [New Thread 0x44549440 (LWP 9732)] >>> [New Thread 0x44d49440 (LWP 9733)] >>> [New Thread 0x44d69440 (LWP 9734)] >>> [New Thread 0x458ff440 (LWP 9738)] >>> [New Thread 0x460ff440 (LWP 9739)] >>> [Thread 0x460ff440 (LWP 9739) exited] >>> >>> Program received signal SIGILL, Illegal instruction. >>> [Switching to Thread 0x4112ac80 (LWP 9722)] >>> 0x0081caec in S32A_Opaque_BlitRow32_neon () >>> Current language: auto; currently asm >>> >>> >>> The error S32A_Opaque_BlitRow32_neon () had to do something with the >>> floating point setting of the kernel. I checked my kernel configuration and >>> neon was not set. So I set it and it rebuild my kernel and booted my jaunty. >>> Now it works perfectly...without any crashes. >>> >>> Key : In order to run chromium we need to set the neon in the kernel >>> configuration. >>> >> >> Note, if you don't set armv7=1 when you build chromium, it shouldn't use >> the NEON paths, so you shouldn't run into that problem. But it's better to >> enable it in the kernel if your hardware supports it. >> >> Antoine >> >> >>> Regards, >>> Sofia >>> >>> >>> On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry wrote: >>> 2009/12/10 Sofia Tahseen : > You are so right, Joel... I corrected my .so and now I could build the > chrome browser ...finally!! I copied the whole /src/out/Release directory > to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: > ./chrome > It starts up chrome, and then immediately kills chrome. I get an Illegal > Instruction. I restart and I can now see chrome as shown in the attachment > but I cannot browse. When I reload the page, it again kills chrome saying > Illegal instruction. Has anyone seen this before? I have my proxy settings > set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. > Any help is highly appreciated. > Thanks, > Sofia > > On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley wrote: >> >> On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen < sofia.tahs...@gmail.com> >> wrote: >> >> > >> > /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: >> > skipping incompatible >> > >> > /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >> > when searching for -lrt >> >> The errors are indicative of trying to link against libraries from a >> different platform. To confirm: check the output of >> >> $ 'file >> /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >> >> I suspect it will tell you it's a symbolic link to /lib/librt.so.1, >> which itself is a symbolic link to >> /lib/librt-2.10.2.so - note these paths are relative to
Re: [chromium-dev] Re: Building chromium for arm--erroring out
On Mon, Dec 14, 2009 at 10:51 AM, Sofia Tahseen wrote: > Hi Antoine, > > I did exactly what you said-- not set armv7=1 in gyp_defines. > > export GYP_DEFINES="target_arch=arm > sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root > disable_nacl=1 use_system_ffmpeg=1" > > I rebuilt chromium. > Did you run "gclient runhooks --force" after changing GYP_DEFINES ? That's necessary to apply the changes. > > And then I reset my kernel so that it does not use NEON. > > This does not help and the browser keeps crashing again even though I do > not set armv7=1 in gyp_defines. So is there a way to disable neon settings > on chromium browser and make chromium working on a hardware that does not > support NEON? > If you build with "make chrome V=1" it shows the command line when it compile things. You should make sure that -march=armv7-a isn't present on the g++ lines. If it is not, the compiler should refuse NEON assembly... Antoine > Thanks, > Sofia > > > > On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour wrote: > >> >> >> On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen >> wrote: >> >>> Hi Joel/Erik/All, >>> >>> I don't think armv5 is an issue. Reason being I used the jaunty armv5 >>> libraries to build chrome. >>> >>> I tried to debug the issue with gdb. >>> gdb chrome >>> GNU gdb 6.8-debian >>> Copyright (C) 2008 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later < >>> http://gnu.org/licenses/gpl.html> >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show >>> copying" >>> and "show warranty" for details. >>> This GDB was configured as "arm-linux-gnueabi"... >>> >>> (gdb) >>> (gdb) run >>> Starting program: /home/adas/Release/chrome >>> [Thread debugging using libthread_db enabled] >>> [New Thread 0x4112ac80 (LWP 9722)] >>> [New Thread 0x41d49440 (LWP 9727)] >>> [New Thread 0x42549440 (LWP 9728)] >>> [New Thread 0x42d49440 (LWP 9729)] >>> [New Thread 0x43549440 (LWP 9730)] >>> [New Thread 0x43d49440 (LWP 9731)] >>> [New Thread 0x44549440 (LWP 9732)] >>> [New Thread 0x44d49440 (LWP 9733)] >>> [New Thread 0x44d69440 (LWP 9734)] >>> [New Thread 0x458ff440 (LWP 9738)] >>> [New Thread 0x460ff440 (LWP 9739)] >>> [Thread 0x460ff440 (LWP 9739) exited] >>> >>> Program received signal SIGILL, Illegal instruction. >>> [Switching to Thread 0x4112ac80 (LWP 9722)] >>> 0x0081caec in S32A_Opaque_BlitRow32_neon () >>> Current language: auto; currently asm >>> >>> >>> The error S32A_Opaque_BlitRow32_neon () had to do something with the >>> floating point setting of the kernel. I checked my kernel configuration and >>> neon was not set. So I set it and it rebuild my kernel and booted my jaunty. >>> Now it works perfectly...without any crashes. >>> >>> Key : In order to run chromium we need to set the neon in the kernel >>> configuration. >>> >> >> Note, if you don't set armv7=1 when you build chromium, it shouldn't use >> the NEON paths, so you shouldn't run into that problem. But it's better to >> enable it in the kernel if your hardware supports it. >> >> Antoine >> >> >>> Regards, >>> Sofia >>> >>> >>> On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry wrote: >>> 2009/12/10 Sofia Tahseen : > You are so right, Joel... I corrected my .so and now I could build the > chrome browser ...finally!! I copied the whole /src/out/Release directory > to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome through: > ./chrome > It starts up chrome, and then immediately kills chrome. I get an Illegal > Instruction. I restart and I can now see chrome as shown in the attachment > but I cannot browse. When I reload the page, it again kills chrome saying > Illegal instruction. Has anyone seen this before? I have my proxy settings > set too.. This could be anything, but it might be this bug in some versions of gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 If that's it then adding -fno-tree-sink to the flags used for V8 will help. It's a bug that only shows up on ARM and only on some versions of gcc. > Any help is highly appreciated. > Thanks, > Sofia > > On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley wrote: >> >> On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen < sofia.tahs...@gmail.com> >> wrote: >> >> > >> > /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: >> > skipping incompatible >> > >> > /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >> > when searching for -lrt >> >> The errors are indicative of trying to link against libraries from a >> different platform. To confirm: check the output of >> >
Re: [chromium-dev] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 10:55 AM, Ojan Vafai wrote: > On Mon, Dec 14, 2009 at 10:36 AM, David Levin wrote: > >> On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess wrote: >> >>> Also, last time I was looking through some valgrind suppressions, I >>> found that often enough the new suppression NEVER fired. I know this >>> is asking a lot, but if you throw down some new suppressions during >>> your tour of duty, it would be great if you check back in a few days >>> or a week later and if they aren't being applied, back them out (maybe >>> with a current sheriff as reviewer in case they pop back up). >>> [valgrind prints out the list of suppressions which fired at the end >>> of the run.] >>> >> >> Of course, it would be awesome if thus was automated in some way like the >> flaky layout tests. You get a list of tests that have been passing for the >> last 75 runs which are in test_expectations (because some suppressions >> aren't hit every time). If there were something similar for valgrind (e.g. >> "suppressions not used in the last 75 runs"), it would be great. >> > > The layout test dashboard was intentionally written test-suite agnostic. > Getting the layout test dashboard to work with other test suites (i.e. the > UI tests) would be super easy. 99% of the work is getting the bots to spit > out JSON for the results of each run. I'd be happy to work with someone to > generate this if anyone wants to volunteer. > > Ojan > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote: > I think for parity with other apps, we should provide a command line switch > to force the WindowOpenDisposition to NEW_WINDOW. For bonus points, > we could expose other dispositions. > Given mdm's explanation, I agree. And I agree that it would be nice to expose other dispositions. It's not particularly more difficult to do this, so we could just implement "--disposition=" with a few different possible strings. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Builder, revision 34472
Automatically closing tree for "compile" on "Chromium Builder" http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/20346 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder --=> Automatically closing tree for "compile" on "Chromium Builder" <=-- Revision: 34471, 34472 Blame list: cmas...@google.com,dglaz...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
Since I just excluded a lot of tests in valgrind last week, I'd like to give a background here. About a week ago, we noticed that we're ignoring failing tests in our valgrind tests, which means that the test results are not accurate. Even worse, unit test of valgrind/test was crashing in the middle, tuns, skipping a lot of testss. Last friday, I landed the change to fix the valgrind tests, and it uncovered a lot of faling tests as well as valgrind errors. I made series of changes to make valgrind test green with place holder bug, and am going to file bugs for each groups to keep track of them. I believe this is improvement because we now know the tests that are failing. I agree that we shouldn't have a lot of disabled tests nor suppressions because they'd easily be forgotten nor untracked. One thing we can do better is make the test result more visible, say have stats of disable/flaky/suppressions and coverage of the tests. That will help us understand how good (or bad) the situation is. Another thing is that since we now have many of these, it may make sense to have FixIt day or week to reduce the number of these tests. Just my 2c. - oshima On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess wrote: > Additionally, keep in mind that obscure bugs may take longer to find > an owner than the buildbots keep logs. So a bug like "Disable to > green the buildbots, " is not sufficient, include enough info so > that someone can figure out WHY you're disabling things. > > Also, last time I was looking through some valgrind suppressions, I > found that often enough the new suppression NEVER fired. I know this > is asking a lot, but if you throw down some new suppressions during > your tour of duty, it would be great if you check back in a few days > or a week later and if they aren't being applied, back them out (maybe > with a current sheriff as reviewer in case they pop back up). > [valgrind prints out the list of suppressions which fired at the end > of the run.] > > -scott > > > On Mon, Dec 14, 2009 at 10:00 AM, John Abd-El-Malek > wrote: > > (this topic has been on my mind a lot, so here's my vent :) ) > > I think we shouldn't allow any test to be disabled without a bug to track > it > > that includes an initially assigned owner. This shouldn't > > I've seen it happen too often that a test gets disabled to quickly turn > the > > tree green, and it stays disabled for a long time without anyone > noticing. > > This destroys the whole point of tests, since it's trivial to keep a > tree > > green by disabling each test when it fails. It's also a large burden to > > expect that people monitor checkins to files they're familiar with and > > create bugs when they find a disabled test. It's harder to enforce this, > > and it's also unclear who should be doing this when multiple people touch > an > > area. > > Filing a bug and looking at the annotations on viewvc to pick an initial > > owner shouldn't take more than a minute or two so I don't think it's a > large > > burden. > > On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson > wrote: > >> > >> I spent a few hours last week and this weekend trying to untangle the > mess > >> that was the worker ui_tests. The problem is that the tests have been > >> sporadically flakey due to various causes, and so various sheriffs/good > >> samaritans have disabled them to keep the trees green. Some of the tests > >> were disabled due to failing under valgrind, but now that we have a way > to > >> disable tests specifically for valgrind and some of the worker bugs have > >> been fixed upstream I figured it was a good time to clean house a bit > and > >> re-enable some of the tests. > >> I found when I was going through the worker_uitest file that it was hard > >> to figure out why a given test was disabled, so it was unclear whether > it > >> was safe to re-enable them - some of the tests had comments pointing at > a > >> tracking bug, but some of them didn't, and it was a pain to track the > root > >> cause especially since the specific lines of code had sometimes been > touched > >> multiple times (adding new platforms to disable, etc). > >> Anyhow, what's our best practices for disabling tests? I think ideally > >> we'd always log a tracking bug and add a comment, akin to what we do in > the > >> test_expectations file for layout tests. This might be too much of a > burden > >> on sheriffs, so an alternative is for people who are working on various > >> areas (like workers) track checkins to the associated files and add some > >> documentation after the fact. Or we can just live with the SVN logs, in > >> which case I need to get better about figuring out how to track through > the > >> SVN/git history of the various files :) > >> > >> -atw > >> > >> -- > >> Chromium Developers mailing list: chromium-dev@googlegroups.com > >> View archives, change email options, or unsubscribe: > >> http://groups.google.com/group/chromium-dev > > > > -- > > Chromium Developers mailing list: chromiu
Re: [chromium-dev] Best Practices when disabling tests?
OK, thanks for the clarification. I'll starting whinging at people who disable tests without a comment pointing at an associated bug. -atw On Mon, Dec 14, 2009 at 10:52 AM, Darin Fisher wrote: > On Mon, Dec 14, 2009 at 10:42 AM, Drew Wilson wrote: > >> They'll sometimes get disabled due to webkit updates, other times they'll >> get disabled due to other things (for example, we changed the valgrind bots >> to fail noisily if individual tests fail, regardless of whether they >> actually generate valgrind errors - this meant that previously-silent worker >> test failures suddenly started causing redness, leading to sheriffs >> disabling them). >> >> But, yeah, it'd be nice to have ui_tests run by the webkit.org bots, >> although in the case of flaky tests I'm not sure whether that'd help (not >> sure if the gardener would pick up on a 25% failure on the FYI bots). >> > > We have to start somewhere. That we have no coverage for worker related > things in the layout tests means that the gardener is flying blind w.r.t. > workers. I think it should be a priority for the canary bots to provide > coverage for all webkit features. > > > >> >> At this point, I'm just trying to figure out what people are *supposed* to >> do when disabling tests - should they always log a bug and add a comment? >> > > Yes. That has always been the rule. > -Darin > > > >> I'd say yes, that if you have time to babysit a CL through the build bot >> process, you have time to log a bug/add a comment, even if you don't know >> the correct owner. >> >> -atw >> >> >> On Mon, Dec 14, 2009 at 10:28 AM, Darin Fisher wrote: >> >>> I presume it is frequently the case that these tests get disabled after a >>> webkit update? >>> >>> Only the "Linux Perf (webkit.org)" bot appears to run the ui_tests. >>> Perhaps that is not sufficient? >>> >>> -Darin >>> >>> >>> >>> On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: >>> I spent a few hours last week and this weekend trying to untangle the mess that was the worker ui_tests. The problem is that the tests have been sporadically flakey due to various causes, and so various sheriffs/good samaritans have disabled them to keep the trees green. Some of the tests were disabled due to failing under valgrind, but now that we have a way to disable tests specifically for valgrind and some of the worker bugs have been fixed upstream I figured it was a good time to clean house a bit and re-enable some of the tests. I found when I was going through the worker_uitest file that it was hard to figure out why a given test was disabled, so it was unclear whether it was safe to re-enable them - some of the tests had comments pointing at a tracking bug, but some of them didn't, and it was a pain to track the root cause especially since the specific lines of code had sometimes been touched multiple times (adding new platforms to disable, etc). Anyhow, what's our best practices for disabling tests? I think ideally we'd always log a tracking bug and add a comment, akin to what we do in the test_expectations file for layout tests. This might be too much of a burden on sheriffs, so an alternative is for people who are working on various areas (like workers) track checkins to the associated files and add some documentation after the fact. Or we can just live with the SVN logs, in which case I need to get better about figuring out how to track through the SVN/git history of the various files :) -atw -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >>> >> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 10:42 AM, Drew Wilson wrote: > They'll sometimes get disabled due to webkit updates, other times they'll > get disabled due to other things (for example, we changed the valgrind bots > to fail noisily if individual tests fail, regardless of whether they > actually generate valgrind errors - this meant that previously-silent worker > test failures suddenly started causing redness, leading to sheriffs > disabling them). > > But, yeah, it'd be nice to have ui_tests run by the webkit.org bots, > although in the case of flaky tests I'm not sure whether that'd help (not > sure if the gardener would pick up on a 25% failure on the FYI bots). > We have to start somewhere. That we have no coverage for worker related things in the layout tests means that the gardener is flying blind w.r.t. workers. I think it should be a priority for the canary bots to provide coverage for all webkit features. > > At this point, I'm just trying to figure out what people are *supposed* to > do when disabling tests - should they always log a bug and add a comment? > Yes. That has always been the rule. -Darin > I'd say yes, that if you have time to babysit a CL through the build bot > process, you have time to log a bug/add a comment, even if you don't know > the correct owner. > > -atw > > > On Mon, Dec 14, 2009 at 10:28 AM, Darin Fisher wrote: > >> I presume it is frequently the case that these tests get disabled after a >> webkit update? >> >> Only the "Linux Perf (webkit.org)" bot appears to run the ui_tests. >> Perhaps that is not sufficient? >> >> -Darin >> >> >> >> On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: >> >>> I spent a few hours last week and this weekend trying to untangle the >>> mess that was the worker ui_tests. The problem is that the tests have been >>> sporadically flakey due to various causes, and so various sheriffs/good >>> samaritans have disabled them to keep the trees green. Some of the tests >>> were disabled due to failing under valgrind, but now that we have a way to >>> disable tests specifically for valgrind and some of the worker bugs have >>> been fixed upstream I figured it was a good time to clean house a bit and >>> re-enable some of the tests. >>> >>> I found when I was going through the worker_uitest file that it was hard >>> to figure out why a given test was disabled, so it was unclear whether it >>> was safe to re-enable them - some of the tests had comments pointing at a >>> tracking bug, but some of them didn't, and it was a pain to track the root >>> cause especially since the specific lines of code had sometimes been touched >>> multiple times (adding new platforms to disable, etc). >>> >>> Anyhow, what's our best practices for disabling tests? I think ideally >>> we'd always log a tracking bug and add a comment, akin to what we do in the >>> test_expectations file for layout tests. This might be too much of a burden >>> on sheriffs, so an alternative is for people who are working on various >>> areas (like workers) track checkins to the associated files and add some >>> documentation after the fact. Or we can just live with the SVN logs, in >>> which case I need to get better about figuring out how to track through the >>> SVN/git history of the various files :) >>> >>> -atw >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >>> >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 10:42 AM, Drew Wilson wrote: > They'll sometimes get disabled due to webkit updates, other times they'll > get disabled due to other things (for example, we changed the valgrind bots > to fail noisily if individual tests fail, regardless of whether they > actually generate valgrind errors - this meant that previously-silent worker > test failures suddenly started causing redness, leading to sheriffs > disabling them). > > But, yeah, it'd be nice to have ui_tests run by the webkit.org bots, > although in the case of flaky tests I'm not sure whether that'd help (not > sure if the gardener would pick up on a 25% failure on the FYI bots). > > At this point, I'm just trying to figure out what people are *supposed* to > do when disabling tests - should they always log a bug and add a comment? > I'd say yes, that if you have time to babysit a CL through the build bot > process, you have time to log a bug/add a comment, even if you don't know > the correct owner. > Note: I think a bug should always have an initial owner. It doesn't take much time to get an initial guess from the viewvc annotations page. I've seen bugs with no owner for failing tests that just sit there for months because no one has seen it. > > -atw > > > On Mon, Dec 14, 2009 at 10:28 AM, Darin Fisher wrote: > >> I presume it is frequently the case that these tests get disabled after a >> webkit update? >> >> Only the "Linux Perf (webkit.org)" bot appears to run the ui_tests. >> Perhaps that is not sufficient? >> >> -Darin >> >> >> >> On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: >> >>> I spent a few hours last week and this weekend trying to untangle the >>> mess that was the worker ui_tests. The problem is that the tests have been >>> sporadically flakey due to various causes, and so various sheriffs/good >>> samaritans have disabled them to keep the trees green. Some of the tests >>> were disabled due to failing under valgrind, but now that we have a way to >>> disable tests specifically for valgrind and some of the worker bugs have >>> been fixed upstream I figured it was a good time to clean house a bit and >>> re-enable some of the tests. >>> >>> I found when I was going through the worker_uitest file that it was hard >>> to figure out why a given test was disabled, so it was unclear whether it >>> was safe to re-enable them - some of the tests had comments pointing at a >>> tracking bug, but some of them didn't, and it was a pain to track the root >>> cause especially since the specific lines of code had sometimes been touched >>> multiple times (adding new platforms to disable, etc). >>> >>> Anyhow, what's our best practices for disabling tests? I think ideally >>> we'd always log a tracking bug and add a comment, akin to what we do in the >>> test_expectations file for layout tests. This might be too much of a burden >>> on sheriffs, so an alternative is for people who are working on various >>> areas (like workers) track checkins to the associated files and add some >>> documentation after the fact. Or we can just live with the SVN logs, in >>> which case I need to get better about figuring out how to track through the >>> SVN/git history of the various files :) >>> >>> -atw >>> >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >>> >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Building chromium for arm--erroring out
Hi Antoine, I did exactly what you said-- not set armv7=1 in gyp_defines. export GYP_DEFINES="target_arch=arm sysroot=~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root disable_nacl=1 use_system_ffmpeg=1" I rebuilt chromium. And then I reset my kernel so that it does not use NEON. This does not help and the browser keeps crashing again even though I do not set armv7=1 in gyp_defines. So is there a way to disable neon settings on chromium browser and make chromium working on a hardware that does not support NEON? Thanks, Sofia On Fri, Dec 11, 2009 at 5:39 PM, Antoine Labour wrote: > > > On Fri, Dec 11, 2009 at 3:28 PM, Sofia Tahseen wrote: > >> Hi Joel/Erik/All, >> >> I don't think armv5 is an issue. Reason being I used the jaunty armv5 >> libraries to build chrome. >> >> I tried to debug the issue with gdb. >> gdb chrome >> GNU gdb 6.8-debian >> Copyright (C) 2008 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later < >> http://gnu.org/licenses/gpl.html> >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "arm-linux-gnueabi"... >> >> (gdb) >> (gdb) run >> Starting program: /home/adas/Release/chrome >> [Thread debugging using libthread_db enabled] >> [New Thread 0x4112ac80 (LWP 9722)] >> [New Thread 0x41d49440 (LWP 9727)] >> [New Thread 0x42549440 (LWP 9728)] >> [New Thread 0x42d49440 (LWP 9729)] >> [New Thread 0x43549440 (LWP 9730)] >> [New Thread 0x43d49440 (LWP 9731)] >> [New Thread 0x44549440 (LWP 9732)] >> [New Thread 0x44d49440 (LWP 9733)] >> [New Thread 0x44d69440 (LWP 9734)] >> [New Thread 0x458ff440 (LWP 9738)] >> [New Thread 0x460ff440 (LWP 9739)] >> [Thread 0x460ff440 (LWP 9739) exited] >> >> Program received signal SIGILL, Illegal instruction. >> [Switching to Thread 0x4112ac80 (LWP 9722)] >> 0x0081caec in S32A_Opaque_BlitRow32_neon () >> Current language: auto; currently asm >> >> >> The error S32A_Opaque_BlitRow32_neon () had to do something with the >> floating point setting of the kernel. I checked my kernel configuration and >> neon was not set. So I set it and it rebuild my kernel and booted my jaunty. >> Now it works perfectly...without any crashes. >> >> Key : In order to run chromium we need to set the neon in the kernel >> configuration. >> > > Note, if you don't set armv7=1 when you build chromium, it shouldn't use > the NEON paths, so you shouldn't run into that problem. But it's better to > enable it in the kernel if your hardware supports it. > > Antoine > > >> Regards, >> Sofia >> >> >> On Fri, Dec 11, 2009 at 2:27 AM, Erik Corry wrote: >> >>> 2009/12/10 Sofia Tahseen : >>> > You are so right, Joel... I corrected my .so and now I could build the >>> > chrome browser ...finally!! I copied the whole /src/out/Release >>> directory >>> > to my jaunty on the BeagleBoard(256MB RAM). I try to launch chrome >>> through: >>> > ./chrome >>> > It starts up chrome, and then immediately kills chrome. I get an >>> Illegal >>> > Instruction. I restart and I can now see chrome as shown in the >>> attachment >>> > but I cannot browse. When I reload the page, it again kills chrome >>> saying >>> > Illegal instruction. Has anyone seen this before? I have my proxy >>> settings >>> > set too.. >>> >>> This could be anything, but it might be this bug in some versions of >>> gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604 >>> >>> If that's it then adding -fno-tree-sink to the flags used for V8 will >>> help. It's a bug that only shows up on ARM and only on some versions >>> of gcc. >>> >>> >>> >>> > Any help is highly appreciated. >>> > Thanks, >>> > Sofia >>> > >>> > On Wed, Dec 9, 2009 at 6:00 PM, Joel Stanley >>> wrote: >>> >> >>> >> On Thu, Dec 10, 2009 at 05:14, Sofia Tahseen >> > >>> >> wrote: >>> >> >>> >> > >>> >> > >>> /home/adas/0_Data/0_Lin/091203_Chromium_OS/toolchain/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/../../../../arm-none-linux-gnueabi/bin/ld: >>> >> > skipping incompatible >>> >> > >>> >> > >>> /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >>> >> > when searching for -lrt >>> >> >>> >> The errors are indicative of trying to link against libraries from a >>> >> different platform. To confirm: check the output of >>> >> >>> >> $ 'file >>> >> >>> /home/adas/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root/usr/lib/librt.so >>> >> >>> >> I suspect it will tell you it's a symbolic link to /lib/librt.so.1, >>> >> which itself is a symbolic link to >>> >> /lib/librt-2.10.2.so - note these paths are relative to /, not to >>> your >>> >> sysroot directory. >>> >> >>> >> You have two slightly solutions >>> >> - adjust the symlinks in sys-root/usr/lib so they point to the files >>> >> in sys-root//lib >>> >> - replace the smymlinks with the actual libraries, ie copy files from >>> >>
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
Ah, OK in that case it sounds fine.
-Ben
On Mon, Dec 14, 2009 at 10:48 AM, Darin Fisher wrote:
> This was explained by Mike Mammarella above.
> -Darin
>
>
> On Mon, Dec 14, 2009 at 10:46 AM, Ben Goodger (Google)
> wrote:
>
>> What does "proper desktop integration" mean?
>>
>> -Ben
>>
>>
>> On Mon, Dec 14, 2009 at 10:44 AM, Darin Fisher wrote:
>>
>>> This seems like a very small addition to support "proper desktop
>>> integration."
>>> -Darin
>>>
>>> On Mon, Dec 14, 2009 at 10:38 AM, Ben Goodger (Google) >> > wrote:
>>>
Why do we need to provide parity with other apps?
Do you understand how bloated we will become if we extend this to every
feature someone likes?
-Ben
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote:
> The popup blocker might interfere with that, but even if it doesn't, it
> seems
> unsavory to reveal these navigations to an existing page. (The page
> could
> override and intercept the 'open' method.)
>
> I think for parity with other apps, we should provide a command line
> switch
> to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
> we could expose other dispositions.
>
> -Darin
>
>
> On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin wrote:
>
>> On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting
>> wrote:
>> > On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth <
>> clem...@endorphin.org>
>> > wrote:
>> >>
>> >> http://codereview.chromium.org/464060 adds the small one-line
>> feature
>> >> to open an URL in a new window from commandline
>>
>> I wonder if you could hack it without a code change by converting URLs
>> into something like "javascript:window.open('http://myurl')" or
>> however that function works.
>>
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
>>>
>>>
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] buildbot cycle time dashboard?
On Tue, Dec 8, 2009 at 3:00 PM, James Hawkins wrote: > Thanks for the link Eric! Can someone explain what the "Percentage of > failures" graph is representing? > # failed build / # total builds. (over the last 300 builds). if it's 10, then that means that in the last 300 builds, 10% of them were red. Nicolas > > Thanks, > James Hawkins > > On Tue, Dec 8, 2009 at 2:56 PM, Eric Seidel wrote: > > http://build.chromium.org/buildbot/waterfall/stats > > > > On Tue, Dec 8, 2009 at 2:51 PM, Dan Kegel wrote: > >> Hey folks, > >> I seem to recall we have a dashboard somewhere showing > >> the cycle time of each of our build/test bots, but I can't > >> find it. Can somebody point me to it? > >> > >> If it doesn't exist, maybe I'll scrape one together. > >> > >> Thanks... > >> > >> -- > >> Chromium Developers mailing list: chromium-dev@googlegroups.com > >> View archives, change email options, or unsubscribe: > >>http://groups.google.com/group/chromium-dev > >> > > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > >http://groups.google.com/group/chromium-dev > > > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
This was explained by Mike Mammarella above.
-Darin
On Mon, Dec 14, 2009 at 10:46 AM, Ben Goodger (Google) wrote:
> What does "proper desktop integration" mean?
>
> -Ben
>
>
> On Mon, Dec 14, 2009 at 10:44 AM, Darin Fisher wrote:
>
>> This seems like a very small addition to support "proper desktop
>> integration."
>> -Darin
>>
>> On Mon, Dec 14, 2009 at 10:38 AM, Ben Goodger (Google)
>> wrote:
>>
>>> Why do we need to provide parity with other apps?
>>>
>>> Do you understand how bloated we will become if we extend this to every
>>> feature someone likes?
>>>
>>> -Ben
>>>
>>>
>>> On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote:
>>>
The popup blocker might interfere with that, but even if it doesn't, it
seems
unsavory to reveal these navigations to an existing page. (The page
could
override and intercept the 'open' method.)
I think for parity with other apps, we should provide a command line
switch
to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
we could expose other dispositions.
-Darin
On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin wrote:
> On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting
> wrote:
> > On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth <
> clem...@endorphin.org>
> > wrote:
> >>
> >> http://codereview.chromium.org/464060 adds the small one-line
> feature
> >> to open an URL in a new window from commandline
>
> I wonder if you could hack it without a code change by converting URLs
> into something like "javascript:window.open('http://myurl')" or
> however that function works.
>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
What does "proper desktop integration" mean?
-Ben
On Mon, Dec 14, 2009 at 10:44 AM, Darin Fisher wrote:
> This seems like a very small addition to support "proper desktop
> integration."
> -Darin
>
> On Mon, Dec 14, 2009 at 10:38 AM, Ben Goodger (Google)
> wrote:
>
>> Why do we need to provide parity with other apps?
>>
>> Do you understand how bloated we will become if we extend this to every
>> feature someone likes?
>>
>> -Ben
>>
>>
>> On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote:
>>
>>> The popup blocker might interfere with that, but even if it doesn't, it
>>> seems
>>> unsavory to reveal these navigations to an existing page. (The page
>>> could
>>> override and intercept the 'open' method.)
>>>
>>> I think for parity with other apps, we should provide a command line
>>> switch
>>> to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
>>> we could expose other dispositions.
>>>
>>> -Darin
>>>
>>>
>>> On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin wrote:
>>>
On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting
wrote:
> On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth <
clem...@endorphin.org>
> wrote:
>>
>> http://codereview.chromium.org/464060 adds the small one-line
feature
>> to open an URL in a new window from commandline
I wonder if you could hack it without a code change by converting URLs
into something like "javascript:window.open('http://myurl')" or
however that function works.
>>>
>>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
This seems like a very small addition to support "proper desktop
integration."
-Darin
On Mon, Dec 14, 2009 at 10:38 AM, Ben Goodger (Google) wrote:
> Why do we need to provide parity with other apps?
>
> Do you understand how bloated we will become if we extend this to every
> feature someone likes?
>
> -Ben
>
>
> On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote:
>
>> The popup blocker might interfere with that, but even if it doesn't, it
>> seems
>> unsavory to reveal these navigations to an existing page. (The page could
>> override and intercept the 'open' method.)
>>
>> I think for parity with other apps, we should provide a command line
>> switch
>> to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
>> we could expose other dispositions.
>>
>> -Darin
>>
>>
>> On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin wrote:
>>
>>> On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting
>>> wrote:
>>> > On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth <
>>> clem...@endorphin.org>
>>> > wrote:
>>> >>
>>> >> http://codereview.chromium.org/464060 adds the small one-line feature
>>> >> to open an URL in a new window from commandline
>>>
>>> I wonder if you could hack it without a code change by converting URLs
>>> into something like "javascript:window.open('http://myurl')" or
>>> however that function works.
>>>
>>
>>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
They'll sometimes get disabled due to webkit updates, other times they'll get disabled due to other things (for example, we changed the valgrind bots to fail noisily if individual tests fail, regardless of whether they actually generate valgrind errors - this meant that previously-silent worker test failures suddenly started causing redness, leading to sheriffs disabling them). But, yeah, it'd be nice to have ui_tests run by the webkit.org bots, although in the case of flaky tests I'm not sure whether that'd help (not sure if the gardener would pick up on a 25% failure on the FYI bots). At this point, I'm just trying to figure out what people are *supposed* to do when disabling tests - should they always log a bug and add a comment? I'd say yes, that if you have time to babysit a CL through the build bot process, you have time to log a bug/add a comment, even if you don't know the correct owner. -atw On Mon, Dec 14, 2009 at 10:28 AM, Darin Fisher wrote: > I presume it is frequently the case that these tests get disabled after a > webkit update? > > Only the "Linux Perf (webkit.org)" bot appears to run the ui_tests. > Perhaps that is not sufficient? > > -Darin > > > > On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: > >> I spent a few hours last week and this weekend trying to untangle the mess >> that was the worker ui_tests. The problem is that the tests have been >> sporadically flakey due to various causes, and so various sheriffs/good >> samaritans have disabled them to keep the trees green. Some of the tests >> were disabled due to failing under valgrind, but now that we have a way to >> disable tests specifically for valgrind and some of the worker bugs have >> been fixed upstream I figured it was a good time to clean house a bit and >> re-enable some of the tests. >> >> I found when I was going through the worker_uitest file that it was hard >> to figure out why a given test was disabled, so it was unclear whether it >> was safe to re-enable them - some of the tests had comments pointing at a >> tracking bug, but some of them didn't, and it was a pain to track the root >> cause especially since the specific lines of code had sometimes been touched >> multiple times (adding new platforms to disable, etc). >> >> Anyhow, what's our best practices for disabling tests? I think ideally >> we'd always log a tracking bug and add a comment, akin to what we do in the >> test_expectations file for layout tests. This might be too much of a burden >> on sheriffs, so an alternative is for people who are working on various >> areas (like workers) track checkins to the associated files and add some >> documentation after the fact. Or we can just live with the SVN logs, in >> which case I need to get better about figuring out how to track through the >> SVN/git history of the various files :) >> >> -atw >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
Sounds great. Thanks, -Darin On Mon, Dec 14, 2009 at 10:38 AM, Mark Mentovai wrote: > We will. It's on my plate and TVL's. We did have some hardware > slated to use for this, but we've slowly chipped away at that, so > it'll come out of the next batch. Bringing up the 10.6 bots had to > take a back seat to the other things that we needed to do in the beta > run-up, but 10.6 bots are a much higher priority now. > > Mark > > Darin Fisher wrote: > > It seems like we should have perf bots for 10.6 and 10.5. (We have perf > > bots for XP and Vista.) > > -Darin > > > > On Mon, Dec 14, 2009 at 9:03 AM, Jeremy Moskovich > > wrote: > >> > >> I'll put together some numbers. > >> Best regards, > >> Jeremy > >> On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai > wrote: > >>> > >>> Jeremy Moskovich wrote: > >>> > Yep, Avi's right - we don't really have that option here. ATSUI is > >>> > deprecated in 10.6 - we're seeing crashes and incorrect rendering. > >>> > If there are perf issues we can file radars against Core Text. > >>> > >>> We should at least know what this change does to us perf-wise. If > >>> we're not happy with the outcome, there may be things we can tune on > >>> our side or things that we can press on Apple to investigate on the > >>> CoreText side. > >>> > >>> Mark > >> > >> -- > >> Chromium Developers mailing list: chromium-dev@googlegroups.com > >> View archives, change email options, or unsubscribe: > >> http://groups.google.com/group/chromium-dev > > > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
Why do we need to provide parity with other apps?
Do you understand how bloated we will become if we extend this to every
feature someone likes?
-Ben
On Mon, Dec 14, 2009 at 10:33 AM, Darin Fisher wrote:
> The popup blocker might interfere with that, but even if it doesn't, it
> seems
> unsavory to reveal these navigations to an existing page. (The page could
> override and intercept the 'open' method.)
>
> I think for parity with other apps, we should provide a command line switch
> to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
> we could expose other dispositions.
>
> -Darin
>
>
> On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin wrote:
>
>> On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting
>> wrote:
>> > On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth <
>> clem...@endorphin.org>
>> > wrote:
>> >>
>> >> http://codereview.chromium.org/464060 adds the small one-line feature
>> >> to open an URL in a new window from commandline
>>
>> I wonder if you could hack it without a code change by converting URLs
>> into something like "javascript:window.open('http://myurl')" or
>> however that function works.
>>
>
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
We will. It's on my plate and TVL's. We did have some hardware slated to use for this, but we've slowly chipped away at that, so it'll come out of the next batch. Bringing up the 10.6 bots had to take a back seat to the other things that we needed to do in the beta run-up, but 10.6 bots are a much higher priority now. Mark Darin Fisher wrote: > It seems like we should have perf bots for 10.6 and 10.5. (We have perf > bots for XP and Vista.) > -Darin > > On Mon, Dec 14, 2009 at 9:03 AM, Jeremy Moskovich > wrote: >> >> I'll put together some numbers. >> Best regards, >> Jeremy >> On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai wrote: >>> >>> Jeremy Moskovich wrote: >>> > Yep, Avi's right - we don't really have that option here. ATSUI is >>> > deprecated in 10.6 - we're seeing crashes and incorrect rendering. >>> > If there are perf issues we can file radars against Core Text. >>> >>> We should at least know what this change does to us perf-wise. If >>> we're not happy with the outcome, there may be things we can tune on >>> our side or things that we can press on Apple to investigate on the >>> CoreText side. >>> >>> Mark >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
On Mon, Dec 14, 2009 at 10:24 AM, Scott Hess wrote: > Additionally, keep in mind that obscure bugs may take longer to find > an owner than the buildbots keep logs. So a bug like "Disable to > green the buildbots, " is not sufficient, include enough info so > that someone can figure out WHY you're disabling things. > > Also, last time I was looking through some valgrind suppressions, I > found that often enough the new suppression NEVER fired. I know this > is asking a lot, but if you throw down some new suppressions during > your tour of duty, it would be great if you check back in a few days > or a week later and if they aren't being applied, back them out (maybe > with a current sheriff as reviewer in case they pop back up). > [valgrind prints out the list of suppressions which fired at the end > of the run.] > Of course, it would be awesome if thus was automated in some way like the flaky layout tests. You get a list of tests that have been passing for the last 75 runs which are in test_expectations (because some suppressions aren't hit every time). If there were something similar for valgrind (e.g. "suppressions not used in the last 75 runs"), it would be great. dave > > -scott > > > On Mon, Dec 14, 2009 at 10:00 AM, John Abd-El-Malek > wrote: > > (this topic has been on my mind a lot, so here's my vent :) ) > > I think we shouldn't allow any test to be disabled without a bug to track > it > > that includes an initially assigned owner. This shouldn't > > I've seen it happen too often that a test gets disabled to quickly turn > the > > tree green, and it stays disabled for a long time without anyone > noticing. > > This destroys the whole point of tests, since it's trivial to keep a > tree > > green by disabling each test when it fails. It's also a large burden to > > expect that people monitor checkins to files they're familiar with and > > create bugs when they find a disabled test. It's harder to enforce this, > > and it's also unclear who should be doing this when multiple people touch > an > > area. > > Filing a bug and looking at the annotations on viewvc to pick an initial > > owner shouldn't take more than a minute or two so I don't think it's a > large > > burden. > > On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson > wrote: > >> > >> I spent a few hours last week and this weekend trying to untangle the > mess > >> that was the worker ui_tests. The problem is that the tests have been > >> sporadically flakey due to various causes, and so various sheriffs/good > >> samaritans have disabled them to keep the trees green. Some of the tests > >> were disabled due to failing under valgrind, but now that we have a way > to > >> disable tests specifically for valgrind and some of the worker bugs have > >> been fixed upstream I figured it was a good time to clean house a bit > and > >> re-enable some of the tests. > >> I found when I was going through the worker_uitest file that it was hard > >> to figure out why a given test was disabled, so it was unclear whether > it > >> was safe to re-enable them - some of the tests had comments pointing at > a > >> tracking bug, but some of them didn't, and it was a pain to track the > root > >> cause especially since the specific lines of code had sometimes been > touched > >> multiple times (adding new platforms to disable, etc). > >> Anyhow, what's our best practices for disabling tests? I think ideally > >> we'd always log a tracking bug and add a comment, akin to what we do in > the > >> test_expectations file for layout tests. This might be too much of a > burden > >> on sheriffs, so an alternative is for people who are working on various > >> areas (like workers) track checkins to the associated files and add some > >> documentation after the fact. Or we can just live with the SVN logs, in > >> which case I need to get better about figuring out how to track through > the > >> SVN/git history of the various files :) > >> > >> -atw > >> > >> -- > >> Chromium Developers mailing list: chromium-dev@googlegroups.com > >> View archives, change email options, or unsubscribe: > >> http://groups.google.com/group/chromium-dev > > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > > http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: >http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
The popup blocker might interfere with that, but even if it doesn't, it
seems
unsavory to reveal these navigations to an existing page. (The page could
override and intercept the 'open' method.)
I think for parity with other apps, we should provide a command line switch
to force the WindowOpenDisposition to NEW_WINDOW. For bonus points,
we could expose other dispositions.
-Darin
On Sat, Dec 12, 2009 at 9:54 AM, Evan Martin wrote:
> On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting
> wrote:
> > On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth <
> clem...@endorphin.org>
> > wrote:
> >>
> >> http://codereview.chromium.org/464060 adds the small one-line feature
> >> to open an URL in a new window from commandline
>
> I wonder if you could hack it without a code change by converting URLs
> into something like "javascript:window.open('http://myurl')" or
> however that function works.
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
It seems like we should have perf bots for 10.6 and 10.5. (We have perf bots for XP and Vista.) -Darin On Mon, Dec 14, 2009 at 9:03 AM, Jeremy Moskovich wrote: > I'll put together some numbers. > > Best regards, > Jeremy > > On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai wrote: > >> Jeremy Moskovich wrote: >> > Yep, Avi's right - we don't really have that option here. ATSUI is >> > deprecated in 10.6 - we're seeing crashes and incorrect rendering. >> > If there are perf issues we can file radars against Core Text. >> >> We should at least know what this change does to us perf-wise. If >> we're not happy with the outcome, there may be things we can tune on >> our side or things that we can press on Apple to investigate on the >> CoreText side. >> >> Mark >> > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
I presume it is frequently the case that these tests get disabled after a webkit update? Only the "Linux Perf (webkit.org)" bot appears to run the ui_tests. Perhaps that is not sufficient? -Darin On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: > I spent a few hours last week and this weekend trying to untangle the mess > that was the worker ui_tests. The problem is that the tests have been > sporadically flakey due to various causes, and so various sheriffs/good > samaritans have disabled them to keep the trees green. Some of the tests > were disabled due to failing under valgrind, but now that we have a way to > disable tests specifically for valgrind and some of the worker bugs have > been fixed upstream I figured it was a good time to clean house a bit and > re-enable some of the tests. > > I found when I was going through the worker_uitest file that it was hard to > figure out why a given test was disabled, so it was unclear whether it was > safe to re-enable them - some of the tests had comments pointing at a > tracking bug, but some of them didn't, and it was a pain to track the root > cause especially since the specific lines of code had sometimes been touched > multiple times (adding new platforms to disable, etc). > > Anyhow, what's our best practices for disabling tests? I think ideally we'd > always log a tracking bug and add a comment, akin to what we do in the > test_expectations file for layout tests. This might be too much of a burden > on sheriffs, so an alternative is for people who are working on various > areas (like workers) track checkins to the associated files and add some > documentation after the fact. Or we can just live with the SVN logs, in > which case I need to get better about figuring out how to track through the > SVN/git history of the various files :) > > -atw > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
Additionally, keep in mind that obscure bugs may take longer to find an owner than the buildbots keep logs. So a bug like "Disable to green the buildbots, " is not sufficient, include enough info so that someone can figure out WHY you're disabling things. Also, last time I was looking through some valgrind suppressions, I found that often enough the new suppression NEVER fired. I know this is asking a lot, but if you throw down some new suppressions during your tour of duty, it would be great if you check back in a few days or a week later and if they aren't being applied, back them out (maybe with a current sheriff as reviewer in case they pop back up). [valgrind prints out the list of suppressions which fired at the end of the run.] -scott On Mon, Dec 14, 2009 at 10:00 AM, John Abd-El-Malek wrote: > (this topic has been on my mind a lot, so here's my vent :) ) > I think we shouldn't allow any test to be disabled without a bug to track it > that includes an initially assigned owner. This shouldn't > I've seen it happen too often that a test gets disabled to quickly turn the > tree green, and it stays disabled for a long time without anyone noticing. > This destroys the whole point of tests, since it's trivial to keep a tree > green by disabling each test when it fails. It's also a large burden to > expect that people monitor checkins to files they're familiar with and > create bugs when they find a disabled test. It's harder to enforce this, > and it's also unclear who should be doing this when multiple people touch an > area. > Filing a bug and looking at the annotations on viewvc to pick an initial > owner shouldn't take more than a minute or two so I don't think it's a large > burden. > On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: >> >> I spent a few hours last week and this weekend trying to untangle the mess >> that was the worker ui_tests. The problem is that the tests have been >> sporadically flakey due to various causes, and so various sheriffs/good >> samaritans have disabled them to keep the trees green. Some of the tests >> were disabled due to failing under valgrind, but now that we have a way to >> disable tests specifically for valgrind and some of the worker bugs have >> been fixed upstream I figured it was a good time to clean house a bit and >> re-enable some of the tests. >> I found when I was going through the worker_uitest file that it was hard >> to figure out why a given test was disabled, so it was unclear whether it >> was safe to re-enable them - some of the tests had comments pointing at a >> tracking bug, but some of them didn't, and it was a pain to track the root >> cause especially since the specific lines of code had sometimes been touched >> multiple times (adding new platforms to disable, etc). >> Anyhow, what's our best practices for disabling tests? I think ideally >> we'd always log a tracking bug and add a comment, akin to what we do in the >> test_expectations file for layout tests. This might be too much of a burden >> on sheriffs, so an alternative is for people who are working on various >> areas (like workers) track checkins to the associated files and add some >> documentation after the fact. Or we can just live with the SVN logs, in >> which case I need to get better about figuring out how to track through the >> SVN/git history of the various files :) >> >> -atw >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Best Practices when disabling tests?
(this topic has been on my mind a lot, so here's my vent :) ) I think we shouldn't allow any test to be disabled without a bug to track it that includes an initially assigned owner. This shouldn't I've seen it happen too often that a test gets disabled to quickly turn the tree green, and it stays disabled for a long time without anyone noticing. This destroys the whole point of tests, since it's trivial to keep a tree green by disabling each test when it fails. It's also a large burden to expect that people monitor checkins to files they're familiar with and create bugs when they find a disabled test. It's harder to enforce this, and it's also unclear who should be doing this when multiple people touch an area. Filing a bug and looking at the annotations on viewvc to pick an initial owner shouldn't take more than a minute or two so I don't think it's a large burden. On Mon, Dec 14, 2009 at 8:54 AM, Drew Wilson wrote: > I spent a few hours last week and this weekend trying to untangle the mess > that was the worker ui_tests. The problem is that the tests have been > sporadically flakey due to various causes, and so various sheriffs/good > samaritans have disabled them to keep the trees green. Some of the tests > were disabled due to failing under valgrind, but now that we have a way to > disable tests specifically for valgrind and some of the worker bugs have > been fixed upstream I figured it was a good time to clean house a bit and > re-enable some of the tests. > > I found when I was going through the worker_uitest file that it was hard to > figure out why a given test was disabled, so it was unclear whether it was > safe to re-enable them - some of the tests had comments pointing at a > tracking bug, but some of them didn't, and it was a pain to track the root > cause especially since the specific lines of code had sometimes been touched > multiple times (adding new platforms to disable, etc). > > Anyhow, what's our best practices for disabling tests? I think ideally we'd > always log a tracking bug and add a comment, akin to what we do in the > test_expectations file for layout tests. This might be too much of a burden > on sheriffs, so an alternative is for people who are working on various > areas (like workers) track checkins to the associated files and add some > documentation after the fact. Or we can just live with the SVN logs, in > which case I need to get better about figuring out how to track through the > SVN/git history of the various files :) > > -atw > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 34463
Automatically closing tree for "update" on "Linux Builder (ChromiumOS)" http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/1317 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29 --=> Automatically closing tree for "update" on "Linux Builder (ChromiumOS)" <=-- Revision: 34463 Blame list: cmas...@google.com Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
I'll put together some numbers. Best regards, Jeremy On Mon, Dec 14, 2009 at 6:46 PM, Mark Mentovai wrote: > Jeremy Moskovich wrote: > > Yep, Avi's right - we don't really have that option here. ATSUI is > > deprecated in 10.6 - we're seeing crashes and incorrect rendering. > > If there are perf issues we can file radars against Core Text. > > We should at least know what this change does to us perf-wise. If > we're not happy with the outcome, there may be things we can tune on > our side or things that we can press on Apple to investigate on the > CoreText side. > > 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] Best Practices when disabling tests?
I spent a few hours last week and this weekend trying to untangle the mess that was the worker ui_tests. The problem is that the tests have been sporadically flakey due to various causes, and so various sheriffs/good samaritans have disabled them to keep the trees green. Some of the tests were disabled due to failing under valgrind, but now that we have a way to disable tests specifically for valgrind and some of the worker bugs have been fixed upstream I figured it was a good time to clean house a bit and re-enable some of the tests. I found when I was going through the worker_uitest file that it was hard to figure out why a given test was disabled, so it was unclear whether it was safe to re-enable them - some of the tests had comments pointing at a tracking bug, but some of them didn't, and it was a pain to track the root cause especially since the specific lines of code had sometimes been touched multiple times (adding new platforms to disable, etc). Anyhow, what's our best practices for disabling tests? I think ideally we'd always log a tracking bug and add a comment, akin to what we do in the test_expectations file for layout tests. This might be too much of a burden on sheriffs, so an alternative is for people who are working on various areas (like workers) track checkins to the associated files and add some documentation after the fact. Or we can just live with the SVN logs, in which case I need to get better about figuring out how to track through the SVN/git history of the various files :) -atw -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
Jeremy Moskovich wrote: > Yep, Avi's right - we don't really have that option here. ATSUI is > deprecated in 10.6 - we're seeing crashes and incorrect rendering. > If there are perf issues we can file radars against Core Text. We should at least know what this change does to us perf-wise. If we're not happy with the outcome, there may be things we can tune on our side or things that we can press on Apple to investigate on the CoreText side. Mark -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
Yep, Avi's right - we don't really have that option here. ATSUI is deprecated in 10.6 - we're seeing crashes and incorrect rendering. If there are perf issues we can file radars against Core Text. Best regards, Jeremy On Mon, Dec 14, 2009 at 5:46 PM, Avi Drissman wrote: > Even if there is a perf regression, we have to take it if we want to get > correct rendering. > > Avi > > On Mon, Dec 14, 2009 at 10:32 AM, Mike Pinkerton > wrote: > >> 2009/12/14 Jeremy Moskovich : >> > There should be no perf regression this time since we'll continue to use >> > ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari]. >> > This should also have the effect of fixing [or modifying the stack >> traces] >> > we've been seeing for ATSUI crashes on 10.6. >> >> How do we know there won't be a perf regression on 10.6.2? We haven't >> measured it, so we may still be slowing things down, correct? >> >> -- >> 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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
Even if there is a perf regression, we have to take it if we want to get correct rendering. Avi On Mon, Dec 14, 2009 at 10:32 AM, Mike Pinkerton wrote: > 2009/12/14 Jeremy Moskovich : > > There should be no perf regression this time since we'll continue to use > > ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari]. > > This should also have the effect of fixing [or modifying the stack > traces] > > we've been seeing for ATSUI crashes on 10.6. > > How do we know there won't be a perf regression on 10.6.2? We haven't > measured it, so we may still be slowing things down, correct? > > -- > 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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
pink wrote: > 2009/12/14 Jeremy Moskovich : >> There should be no perf regression this time since we'll continue to use >> ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari]. >> This should also have the effect of fixing [or modifying the stack traces] >> we've been seeing for ATSUI crashes on 10.6. > > How do we know there won't be a perf regression on 10.6.2? We haven't > measured it, so we may still be slowing things down, correct? Jeremy, if you haven't done so already, I suggest running the perf tests locally a few times, with ATSUI and CoreText rendering. Mark -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Cannot find -lffmpegasm
What do you have GYP_DEFINES set to? I got a compilation error involving ffmpeg last week, but then I tried again with an empty GYP_DEFINES and it worked fine. - Dominic On Sun, Dec 13, 2009 at 9:32 AM, Thiago Farina wrote: > Sorry for posting here, but I didn't find other place to ask, also I > didn't find a solution too, so... > > I already tried everything, like, clobbering the out directory, > synching again with 'gclient sync --force'. > What I usually do is, in the trunk branch: > $ git pull > $ gclient sync > $ time make CC="ccache gcc" CXX="ccache g++" -k chrome > > But since friday this is not working and I'm getting weird errors. > After some searching I ending up with this following line, but remaing > this last error. > > $time make CC="ccache gcc" CXX="ccache g++" LDFLAGS+=-ldl LDFLAGS+=- > lpthread -k chrome > SOLINK(target) out/Debug/lib.target/third_party/ffmpeg/ > libffmpegsumo.so > /usr/bin/ld: error: cannot find -lffmpegasm > collect2: ld returned 1 exit status > make: *** [out/Debug/lib.target/third_party/ffmpeg/libffmpegsumo.so] > Error 1 > make: Target `chrome' not remade because of errors. > > real 1m3.344s > user 0m23.237s > sys 0m7.532s > > I hope someone could give me a hint how to make this work again. > > Ah, I ran build/install-build-deps.sh to see if I was missing some dev > package, but it says that everything is installed. > > PS: without these LDFLAGS , the compilation don't work also. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
2009/12/14 Jeremy Moskovich : > There should be no perf regression this time since we'll continue to use > ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari]. > This should also have the effect of fixing [or modifying the stack traces] > we've been seeing for ATSUI crashes on 10.6. How do we know there won't be a perf regression on 10.6.2? We haven't measured it, so we may still be slowing things down, correct? -- 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
Re: [chromium-dev] Core Text
*10.6.2 <-> 10.6 2009/12/14 Jeremy Moskovich > OK, the runtime switch has landed in the WebKit tree as > http://trac.webkit.org/changeset/52067 . We should pick it up next time we > roll deps. > > There should be no perf regression this time since we'll continue to use > ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari]. > > This should also have the effect of fixing [or modifying the stack traces] > we've been seeing for ATSUI crashes on 10.6. > > Best regards, > Jeremy > > 2009/12/4 Jeremy Moskovich > > Thanks Drew, >> >> I'll look into toggling ATSUI/Core Text at runtime based on OS version >> then. >> >> Best regards, >> Jeremy >> >> >> On Fri, Dec 4, 2009 at 5:25 AM, Drew Wilson wrote: >> >>> It looks like this had some negative perf issues: >>> >>> >>> http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Perf%281%29/builds/6289/steps/page_cycler_intl2/logs/stdio >>> >>> >>> http://build.chromium.org/buildbot/perf/mac-release-10.5/intl2/report.html?history=150 >>> (my DEPS roll was 33776) >>> >>> I'm going to revert. >>> >>> -atw >>> >>> 2009/12/3 Jeremy Moskovich >>> Hi Drew & Albert, I picked your names off the WebKit sheriff calendar. I've landed a change to switch the Mac port over from ATSUI->Core Text APIs on the WebKit tree at http://trac.webkit.org/changeset/51633 . If you see stability or performance issues on the next WebKit roll then feel free to revert this CL (just drop me an email with a link to the bad run if you do so, please). Thanks, Jeremy 2009/11/24 Jeremy Moskovich Thanks Hironori, > > I thought so too at the beginning but it turns out that they > are available, just not declared in public headers. The WebKit bug I > linked > to has a patch that switches us to Core Text on 10.5 & 10.6. > > I'll do some perf tests and then we can make a decision based on that. > > Best regards, > Jeremy > > 2009/11/24 Hironori Bono (坊野 博典) > > Greetings Jeremy, >> >> This is just for your information. >> It seems >> "WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp" >> uses CTRunGetAdvancesPtr() and CTRunGetAdvances(), which are available >> only on 10.6 or later. (This might be a reason why WebKit doesn't use >> Core Text for Leopard?) >> >> (*1) < >> http://developer.apple.com/mac/library/documentation/Carbon/Reference/CTRunRef/Reference/reference.html#//apple_ref/c/func/CTRunGetAdvancesPtr >> > >> >> Best regards, >> >> Hironori Bono >> E-mail: hb...@chromium.org >> >> On Tue, Nov 24, 2009 at 6:17 AM, Jeremy Moskovich < >> jer...@chromium.org> wrote: >> > Thanks Nico, >> > I'll run some numbers. >> > Best regards, >> > Jeremy >> > >> > On Mon, Nov 23, 2009 at 11:15 PM, Nico Weber >> wrote: >> >> >> >> Did you do measuring if it's actually slower on 10.5? The CoreText >> backend >> >> for MacVim is much faster than the ATSUI backend from what I've >> heard (then >> >> again, MacVim doesn't do very complex text rendering). >> >> >> >> (Source: >> http://groups.google.com/group/vim_mac/browse_thread/thread/b93c6dd5183bdc5e >> ) >> >> On Mon, Nov 23, 2009 at 12:58 PM, Jeremy Moskovich < >> jer...@chromium.org> >> >> wrote: >> >>> >> >>> Re http://crbug.com/27195 & >> https://bugs.webkit.org/show_bug.cgi?id=31802 >> >>> : >> >>> >> >>> Dan Bernstein says that Core Text on Leopard has performance >> issues vs >> >>> ATSUI so I'm going to look into switching APIs at runtime rather >> than >> >>> compile time. >> >>> >> >>> So we'd use ATSUI < 10.6 & Core Text >= 10.6 . >> >>> >> >>> Best regards, >> >>> Jeremy >> >>> >> >>> >> >>> -- >> >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >> >>> View archives, change email options, or unsubscribe: >> >>> http://groups.google.com/group/chromium-dev >> > >> > -- >> > Chromium Developers mailing list: chromium-dev@googlegroups.com >> > View archives, change email options, or unsubscribe: >> > http://groups.google.com/group/chromium-dev >> > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev >>> >>> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Core Text
OK, the runtime switch has landed in the WebKit tree as http://trac.webkit.org/changeset/52067 . We should pick it up next time we roll deps. There should be no perf regression this time since we'll continue to use ATSUI on 10.5 and only switch to Core Text on 10.6.2 [like Safari]. This should also have the effect of fixing [or modifying the stack traces] we've been seeing for ATSUI crashes on 10.6. Best regards, Jeremy 2009/12/4 Jeremy Moskovich > Thanks Drew, > > I'll look into toggling ATSUI/Core Text at runtime based on OS version > then. > > Best regards, > Jeremy > > > On Fri, Dec 4, 2009 at 5:25 AM, Drew Wilson wrote: > >> It looks like this had some negative perf issues: >> >> >> http://build.chromium.org/buildbot/waterfall/builders/Mac10.5%20Perf%281%29/builds/6289/steps/page_cycler_intl2/logs/stdio >> >> >> http://build.chromium.org/buildbot/perf/mac-release-10.5/intl2/report.html?history=150 >> (my DEPS roll was 33776) >> >> I'm going to revert. >> >> -atw >> >> 2009/12/3 Jeremy Moskovich >> >>> Hi Drew & Albert, >>> >>> I picked your names off the WebKit sheriff calendar. >>> >>> I've landed a change to switch the Mac port over from ATSUI->Core Text >>> APIs on the WebKit tree at http://trac.webkit.org/changeset/51633 . >>> >>> If you see stability or performance issues on the next WebKit roll then >>> feel free to revert this CL (just drop me an email with a link to the bad >>> run if you do so, please). >>> >>> Thanks, >>> Jeremy >>> >>> 2009/11/24 Jeremy Moskovich >>> >>> Thanks Hironori, I thought so too at the beginning but it turns out that they are available, just not declared in public headers. The WebKit bug I linked to has a patch that switches us to Core Text on 10.5 & 10.6. I'll do some perf tests and then we can make a decision based on that. Best regards, Jeremy 2009/11/24 Hironori Bono (坊野 博典) Greetings Jeremy, > > This is just for your information. > It seems > "WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp" > uses CTRunGetAdvancesPtr() and CTRunGetAdvances(), which are available > only on 10.6 or later. (This might be a reason why WebKit doesn't use > Core Text for Leopard?) > > (*1) < > http://developer.apple.com/mac/library/documentation/Carbon/Reference/CTRunRef/Reference/reference.html#//apple_ref/c/func/CTRunGetAdvancesPtr > > > > Best regards, > > Hironori Bono > E-mail: hb...@chromium.org > > On Tue, Nov 24, 2009 at 6:17 AM, Jeremy Moskovich > wrote: > > Thanks Nico, > > I'll run some numbers. > > Best regards, > > Jeremy > > > > On Mon, Nov 23, 2009 at 11:15 PM, Nico Weber > wrote: > >> > >> Did you do measuring if it's actually slower on 10.5? The CoreText > backend > >> for MacVim is much faster than the ATSUI backend from what I've > heard (then > >> again, MacVim doesn't do very complex text rendering). > >> > >> (Source: > http://groups.google.com/group/vim_mac/browse_thread/thread/b93c6dd5183bdc5e > ) > >> On Mon, Nov 23, 2009 at 12:58 PM, Jeremy Moskovich < > jer...@chromium.org> > >> wrote: > >>> > >>> Re http://crbug.com/27195 & > https://bugs.webkit.org/show_bug.cgi?id=31802 > >>> : > >>> > >>> Dan Bernstein says that Core Text on Leopard has performance issues > vs > >>> ATSUI so I'm going to look into switching APIs at runtime rather > than > >>> compile time. > >>> > >>> So we'd use ATSUI < 10.6 & Core Text >= 10.6 . > >>> > >>> Best regards, > >>> Jeremy > >>> > >>> > >>> -- > >>> Chromium Developers mailing list: chromium-dev@googlegroups.com > >>> View archives, change email options, or unsubscribe: > >>> http://groups.google.com/group/chromium-dev > > > > -- > > Chromium Developers mailing list: chromium-dev@googlegroups.com > > View archives, change email options, or unsubscribe: > > http://groups.google.com/group/chromium-dev > >>> -- >>> Chromium Developers mailing list: chromium-dev@googlegroups.com >>> View archives, change email options, or unsubscribe: >>> http://groups.google.com/group/chromium-dev >>> >> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
