[chromium-dev] Re: Changes to using threads in the browser process
On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek j...@chromium.org wrote: *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread Awesome! 4: I've removed all the special casing and always made the objects in the browser code behave in one way. If you're writing a unit test and need to use an object that goes to a file thread (where before it would proceed synchronously), you just need: ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); foo-StartAsyncTaskOnFileThread(); MessageLoop::current()-RunAllPending(); There are plenty of examples now in the tests. Are there any examples for asynchronous processing (with a real backend thread)? I think that chrome/browser/privacy_blacklist/blacklist_manager.cc uses some of the anti-patterns you described (it caches base::Thread* instead of MessageLoop*, but I understand it's equally bad). And it will benefit a lot from ChromeThread::DeleteOnIOThread. The good part is that BlacklistManager is not yet used in the browser. I will fix the issues before the final integration of BlacklistManager. --~--~-~--~~~---~--~~ 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 security UI choices
Yeah, I understood :) I haven't seen much discussion of these issues so figured I'd try and start some - perhaps a lurker would be motivated to work on it. Or maybe the Chrome team in a later release. The force-ssl stuff seems like good progress. Still, Chrome takes a less aggressive stance than Firefox on things like click-through warnings and that doesn't seem like needing academic study to resolve. On Nov 3, 4:56 am, Adam Barth aba...@chromium.org wrote: I'm sorry if my email came off as dismissive. I really would like to see some serious study of user interfaces for certificate errors. I think everyone agrees that the current designs can be improved. We even know how to measure success (e.g.,http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf). What we don't know is how to design something measurably better. Adam On Mon, Nov 2, 2009 at 6:19 PM, Evan Stade est...@chromium.org wrote: I now have a new response ready for the next click to select all thread: the best way to make your case is to write an academic paper and conduct a user study that shows how the new UI out-performs the current UI. -- Evan Stade --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How much RAM needed to get past linking? (Linux)
Hi Adam/Evan/Pawell, thanks for the useful feedback. This gold sounds good, although if I want to install it on Fedora I note that there isn't package (yet) and the src/build/install-build-deps.sh script is apparently only for Ubuntu 8/9, so I will have to go the 'hard way' mentioned on the LinuxFasterBuilding wiki. (Accordingly I don't think it should be specified as a chromium build requirement until most distributions are supported.) By the sounds of it 2Gb of physical memory really is the minimum, and I better get upgrade my hardware. Technically my motherboard should support that (as a max) but I failed to boot the other day when trying to add different-sized DIMM. I will track down two identical 1Gb DIMMs and put them in. Reporting back later, Akira On Tue, Nov 3, 2009 at 3:02 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: If you have less than 1 GB of RAM, I wouldn't even try to link the biggest binaries. 2 GB of RAM should be sufficient, although with 4 and more it's better. And you will notice the change after switching to gold. On Mon, Nov 2, 2009 at 18:58, Adam Langley a...@chromium.org wrote: On Fri, Oct 30, 2009 at 9:10 AM, Akira ak...@yayakoshi.net wrote: I was building on Fedora 10 and was able to compile but the linking stage (see below) consumes more and more memory- the 500Mb of remaining memory, then another 1Gb of swap- before being killed. Are you using gold? http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Linking_using_gold If not, that's the single biggest win for linking size and speed. I know Evan builds on his laptop using gold, but I don't know the exact specs. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium security UI choices
On Tue, Nov 3, 2009 at 12:54 AM, Mike Hearn mh.in.engl...@gmail.com wrote: Yeah, I understood :) I haven't seen much discussion of these issues so figured I'd try and start some - perhaps a lurker would be motivated to work on it. Or maybe the Chrome team in a later release. We had a lot of discussion on this topic before we released the first beta because we wanted to get security right out of the box. I'd certainly be happy to revisit this topic when we have new information. It's tempting to re-arrange the deck chairs, so to speak, but we'd like to have solid data showing that we're going in the right direction first. The force-ssl stuff seems like good progress. Still, Chrome takes a less aggressive stance than Firefox on things like click-through warnings and that doesn't seem like needing academic study to resolve. You say what, but we have numbers on how often users click through the certificate errors, and they're commensurate with the data in this study: http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf I'm not sure the extra clicks are buying Firefox users much, if any, security. That particular study is really interesting because the authors find that users learned how to get past their even-more-elaborate error dialogs during the course of the study. Now imagine if they were to use the browser for more than an afternoon... I'd encourage you to think about this issue, come up with great ideas, and get the data to convince us. If there's one thing I've learned working on this project, it's that data trumps opinion every time. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Hard Refresh UI Option
Is it feasible to get an easy way to initiate a hard refresh (bypassing the cache)? There's a key-combo (CTRL + Refresh) in other browsers, not sure if it works in Chrome, but has anyone ever thought of building this functionality right into the button? Would be helpful if you could simply right-click the refresh button to bypass the cache. --~--~-~--~~~---~--~~ 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: Changes to using threads in the browser process
Can you put this information, as well as some examples for proper usage, on dev.chromium.org. I doubt this stuff is very well documented from the perspective of someone trying to use it, and this looks like a great start!!! On Tue, Nov 3, 2009 at 12:50 AM, John Abd-El-Malek j...@chromium.org wrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Perf tests to run?
Dear chromiumers, I've got a change (see https://bugs.webkit.org/show_bug.cgi?id=31051 solution for crbug.com/16821) which might have performance implications (it invokes WinAPI via couple of levels of indirection and might trigger V8's GC). There are various ways to make this check faster, but I am not sure if we should do it more complex right now (current simple approach might be good enough.) So the question: how could I check that I won't (notably) regress Chromium performance with this change? Overall, is it fine to commit this change now? It solves an important problem and could dramatically reduce memory usage for some scenarios, but might be too risky. Ideally I'd like to stage this change for some time, but not sure if the beta is a right place. Any advice is most appreciated. yours, anton. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How much RAM needed to get past linking? (Linux)
On Tue, Nov 3, 2009 at 1:01 AM, 黒鉄章 ak...@yayakoshi.net wrote: This gold sounds good, although if I want to install it on Fedora I note that there isn't package (yet) and the src/build/install-build-deps.sh script is apparently only for Ubuntu 8/9 Patches to fix this would be welcome. so I will have to go the 'hard way' mentioned on the LinuxFasterBuilding wiki. The gold-building part of that script is more distro-agnostic than http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Linking_using_gold so I'd run that part of the shell script if I were you. (Accordingly I don't think it should be specified as a chromium build requirement until most distributions are supported.) gold runs on all versions of Linux. (Or were you talking about the script?) - Dan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: refactoring and git
I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like git diff know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince git diff through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ 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: refactoring and git
On Tue, Nov 3, 2009 at 16:58, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To the one that the files are supposed to by svn-copied by git, that there is a command to check for that, and that you offered to help in case of problems. :) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Can't build chrome; NameError: name '_toolset' is not defined. Can't sync webkit. :-(
I get NameError: name '_toolset' is not defined while loading dependencies of base/base.gyp while loading dependencies of app/app.gyp while loading dependencies of build/all.gyp while trying to load build/all.gyp when building or even just running 'gclient runhooks --force'. Also, when I do 'gclient sync', it does the usual syncing... until it comes to webkit, where it hangs for a while, then reports svn: Can't read from connection: Connection reset by peer (This is with the committer repo from my home machine over the public internet.) Wonder if there's some connection between the two problems... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Chrome UI Jank Task Force Status Update
*Chrome UI Jank Task Force Status* The Chrome UI Jank Task Force is out to fix UI Jank and slowness in the browser. A list of open Jank bugs is here: http://code.google.com/p/chromium/issues/list?q=label:Jank (feel free to take one!) *Updates* * * Chase: working on disk access on startup, has a log of all disk accesses happening. - Cookie reads happening on UI thread? - Investigating more, will sync with Brett. - updated the windows reference build. - Enabled new tab warm load perf tests. Carlos: re-writing chrome.exe from scratch (lots of cruft.) - Some reading of DLL before DLL loads - rewrite will eliminate some I/Os. - Need another builder box for PGO on official builds (takes a long time.) - No good way to know the improvement without doing the build. - Need to choose how we want to optimize - can only optimize for one type of process...and some tests won't work. John: done with patch to simplify threading in browser process. - Simplifies moving things to different threads (won't have to hop threads to see if things are still alive.) Tony: killing off the theme.dll, may make cold startup faster. Evan: started moving spellchecker to renderer, lots of work to be done, in progress. --~--~-~--~~~---~--~~ 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: refactoring and git
Are there best practices we can follow that will help the scripts be more accurate? For example, if we move the file, make sure that we commit it in the new location before making any text changes? If so, we could at least document that. Erik On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like git diff know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince git diff through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ 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: refactoring and git
Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay erik...@chromium.org wrote: Are there best practices we can follow that will help the scripts be more accurate? For example, if we move the file, make sure that we commit it in the new location before making any text changes? If so, we could at least document that. Erik On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like git diff know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince git diff through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ 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: Can't build chrome; NameError: name '_toolset' is not defined. Can't sync webkit. :-(
On Tue, Nov 3, 2009 at 8:06 AM, Dan Kegel d...@kegel.com wrote: I get NameError: name '_toolset' is not defined while loading dependencies of base/base.gyp while loading dependencies of app/app.gyp while loading dependencies of build/all.gyp while trying to load build/all.gyp when building or even just running 'gclient runhooks --force'. Also, when I do 'gclient sync', it does the usual syncing... until it comes to webkit, where it hangs for a while, then reports svn: Can't read from connection: Connection reset by peer (This is with the committer repo from my home machine over the public internet.) Wonder if there's some connection between the two problems... It's possible that some of your svn checkouts weren't fully synced. Try gclient sync --force. --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
On Tue, Nov 3, 2009 at 19:08, Drew Wilson atwil...@chromium.org wrote: I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. I have it working. For reference, the file can be downloaded from http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el Maybe I should try the non-aqua Emacs, hm... How about building? Is using xcodebuild slower than running the build from Xcode? My simple testing shows that there is no big difference. --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
I heartily recommend MacVim ( http://code.google.com/p/macvim/ ). I hear its fullscreen mode is pretty rad :-P Having said that, XCode – like most OS X apps – support some emacs keybindings. Your Remove entire line example is ctrl-a ctrl-k ctrl-k in XCode. I usually use some mix of MacVim and XCode. On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
TextMate is pretty solid and very customizable. I wonder if we can get gyp to generate .tmproj files :P I also like it's command line tool mate for opening files from the Terminal. On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: refactoring and git
Another option is to do one TBR commit where you just fork the file with no changes, then work again as normal. May I suggest using gcl instead for this changelist... Would that be possible? I don't like the idea of losing all the commit history of the file he's working on, just because git doesn't correctly implement this... On Tue, Nov 3, 2009 at 09:50, Evan Martin e...@chromium.org wrote: Another option is to do one TBR commit where you just fork the file with no changes, then work again as normal. Pretty ugly though. :) On Tue, Nov 3, 2009 at 9:29 AM, Drew Wilson atwil...@chromium.org wrote: In my case, git didn't quite figure out that my refactoring (splitting a file into two) should also link up the new file to the history of the old. There are magic flags I could pass (-Cn) to make git more aggressive about matching up files to histories, but it turns out that passing those flags also generates a bunch of false positives (at least in my case): git thought that unrelated files were actually copies of one another. In the end, I'm probably just going to land the patch via svn and manually setup the history linkage via svn copy. -atw On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin e...@chromium.org wrote: Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay erik...@chromium.org wrote: Are there best practices we can follow that will help the scripts be more accurate? For example, if we move the file, make sure that we commit it in the new location before making any text changes? If so, we could at least document that. Erik On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like git diff know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince git diff through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ 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: Perf tests to run?
On Tue, Nov 3, 2009 at 7:30 AM, Anton Muhin ant...@chromium.org wrote: So the question: how could I check that I won't (notably) regress Chromium performance with this change? We have perf bots; you can check in and look at the effects there, and there might even be a way to get perf results from the tryservers. 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: Which editor do you recommend on Mac OS X?
2009/11/3 Paweł Hajdan Jr. phajdan...@chromium.org: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? Vim? --~--~-~--~~~---~--~~ 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: Can't build chrome; NameError: name '_toolset' is not defined. Can't sync webkit. :-(
On Tue, Nov 3, 2009 at 9:21 AM, Evan Martin e...@chromium.org wrote: On Tue, Nov 3, 2009 at 8:06 AM, Dan Kegel d...@kegel.com wrote: NameError: name '_toolset' is not defined while loading dependencies when building or even just running 'gclient runhooks --force'. Also, when I do 'gclient sync', it does the usual syncing... until it comes to webkit, where it hangs for a while, then reports svn: Can't read from connection: Connection reset by peer (This is with the committer repo from my home machine over the public internet.) It's possible that some of your svn checkouts weren't fully synced. Try gclient sync --force. See above :-) It fails with running 'svn update /home/dank/chromium/src/testing/gtest --revision 336' in '/home/dank/chromium' At revision 336. svn: Can't read from connection: Connection reset by peer Error: failed to run command: svn update /home/dank/chromium/src/third_party/WebKit --revision 27313 This is very strange, since syncing works in all other directories up to that point. Do we have an svn server problem? - Dan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: refactoring and git
In my case, git didn't quite figure out that my refactoring (splitting a file into two) should also link up the new file to the history of the old. There are magic flags I could pass (-Cn) to make git more aggressive about matching up files to histories, but it turns out that passing those flags also generates a bunch of false positives (at least in my case): git thought that unrelated files were actually copies of one another. In the end, I'm probably just going to land the patch via svn and manually setup the history linkage via svn copy. -atw On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin e...@chromium.org wrote: Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay erik...@chromium.org wrote: Are there best practices we can follow that will help the scripts be more accurate? For example, if we move the file, make sure that we commit it in the new location before making any text changes? If so, we could at least document that. Erik On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like git diff know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince git diff through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Which editor do you recommend on Mac OS X?
Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. Recommended. http://www.emacswiki.org/emacs/EmacsForMacOS http://www.emacswiki.org/emacs/CarbonEmacsPackage -Ken On Tue, Nov 3, 2009 at 10:08 AM, Drew Wilson atwil...@chromium.org wrote: I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: revert now, ask questions later? WAS: Reverting a change, the fast way
But this means that the person didn't use the trybot. I think we need to be harsher on people who commit with changes that didn't complete or failed on the trybot. They need to have a really good reason as to why they want to try their change on the buildbot and possibly delay many other engineers. On Tue, Nov 3, 2009 at 3:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: refactoring and git
On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin e...@chromium.org wrote: Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies FWIW, it never used to work at all for me, but it recently started working. Did you change something recently? (I also have been messing around with my env recently -- I may have been using an older version of git-cl accidentally). - 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: Changes to using threads in the browser process
On Tue, Nov 3, 2009 at 6:01 AM, Mike Pinkerton pinker...@chromium.org wrote: Can you put this information, as well as some examples for proper usage, on dev.chromium.org. I doubt this stuff is very well documented from the perspective of someone trying to use it, and this looks like a great start!!! The place to put it is here: http://dev.chromium.org/developers/design-documents/threading Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: refactoring and git
Another option is to do one TBR commit where you just fork the file with no changes, then work again as normal. Pretty ugly though. :) On Tue, Nov 3, 2009 at 9:29 AM, Drew Wilson atwil...@chromium.org wrote: In my case, git didn't quite figure out that my refactoring (splitting a file into two) should also link up the new file to the history of the old. There are magic flags I could pass (-Cn) to make git more aggressive about matching up files to histories, but it turns out that passing those flags also generates a bunch of false positives (at least in my case): git thought that unrelated files were actually copies of one another. In the end, I'm probably just going to land the patch via svn and manually setup the history linkage via svn copy. -atw On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin e...@chromium.org wrote: Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay erik...@chromium.org wrote: Are there best practices we can follow that will help the scripts be more accurate? For example, if we move the file, make sure that we commit it in the new location before making any text changes? If so, we could at least document that. Erik On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin e...@chromium.org wrote: I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like git diff know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince git diff through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: That's a good news. Can that info be put somewhere in the UsingGit wiki page? On Mon, Nov 2, 2009 at 23:56, Evan Martin e...@chromium.org wrote: On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson atwil...@chromium.org wrote: I'm doing some refactoring in the chromium worker code, and I got the following review feedback: small request: can the files that were branched from existing files be svn copy'd instead of copying manually and svn added? This will preserve history and will make it easier to see what changed in the review. Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult git diff -M -C --stat origin... and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style renames -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-list. :) --~--~-~--~~~---~--~~ 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: Perf tests to run?
Thanks a lot, Peter. Yes, I am aware of those. Just wanted to run something before committing :) I actually ran some DOM related tests. Adam (on IM) suggested to run SunSpider, V8 and page load cyclers. I am going to do it and if numbers are fine, then would try to commit my change. yours, anton. On Tue, Nov 3, 2009 at 9:25 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 7:30 AM, Anton Muhin ant...@chromium.org wrote: So the question: how could I check that I won't (notably) regress Chromium performance with this change? We have perf bots; you can check in and look at the effects there, and there might even be a way to get perf results from the tryservers. 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: Can't build chrome; NameError: name '_toolset' is not defined. Can't sync webkit. :-(
On Tue, Nov 3, 2009 at 8:06 AM, Dan Kegel d...@kegel.com wrote: I get NameError: name '_toolset' is not defined while loading dependencies of base/base.gyp while loading dependencies of app/app.gyp while loading dependencies of build/all.gyp while trying to load build/all.gyp when building or even just running 'gclient runhooks --force'. Also, when I do 'gclient sync', it does the usual syncing... until it comes to webkit, where it hangs for a while, then reports svn: Can't read from connection: Connection reset by peer (This is with the committer repo from my home machine over the public internet.) Wonder if there's some connection between the two problems... How old was your former checkout ? Could you check the version on src/tools/gyp (with svn info) ? The change introducing toolsets in chrome was more than a week ago I believe, so I don't know if there is something else going on here. Antoine --~--~-~--~~~---~--~~ 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: revert now, ask questions later? WAS: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 7:08 PM, Ben Goodger (Google) b...@chromium.orgwrote: I am supportive of auto-revert as long as we apply it universally. So many times the tree has been busted forever because of a vacuum of action by the sheriff. Also FYI - the trybots never work for me on my home system. No idea why. From home you to type something like : gcl try CHANGENAME --use_svn --svn_repo=svn://svn.chromium.org/chrome-try/try Nicolas -Ben On Tue, Nov 3, 2009 at 7:05 PM, John Abd-El-Malek j...@chromium.orgwrote: But this means that the person didn't use the trybot. I think we need to be harsher on people who commit with changes that didn't complete or failed on the trybot. They need to have a really good reason as to why they want to try their change on the buildbot and possibly delay many other engineers. On Tue, Nov 3, 2009 at 3:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: revert now, ask questions later? WAS: Reverting a change, the fast way
The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Reverting a change, the fast way
Drover is actually an order of magnitude faster than a standard svn merge/reverse, merge since it only affects the files that are involved with the CL (as opposed to trying to descending the entire trunk). A normal merge would take in the space of 8 minutes on my box (which required an existing working copy). In the case of drover, the same merge/revert can be performed in approximately 30 seconds to 1 minute (w/ out a pre existing working copy). Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Nov 3, 2009 at 2:01 PM, Eric Seidel esei...@chromium.org wrote: Interesting. WebKit has similar functionality as: bugzilla-tool rollout 12345 We've found that git reverts are at least an order of magnitude faster than SVN reverse merges. I wonder what bugzilla-tool/drover can learn from one another. -eric On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi One of the goal of the Green Tree Task Force was to make reverting a change easy and fast. This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. Turns out it was already easy and fast with Anthony's drover tool. If you have depot_tools in your path, just type : drover --revert where is the revision you want to revert. Since the tool creates temporary files, I suggest you go to the temp directory first. It should take only a few seconds, even for a really big change. You don't even need to have a chrome checkout on your machine. This tool should work on all platforms. You need svn 1.5 or above in your path. If you run into any issues with the tool, please let me know. Thank you, Nicolas If the tool does not work, you can revert the long way by doing: cd src/ svn update svn merge -c - . (the dot at the end of the previous line is important) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Reverting a change, the fast way
Hi One of the goal of the Green Tree Task Force was to make reverting a change easy and fast. This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. Turns out it was already easy and fast with Anthony's drover tool. If you have depot_tools in your path, just type : *drover --revert * where is the revision you want to revert. Since the tool creates temporary files, I suggest you go to the temp directory first. It should take only a few seconds, even for a really big change. You don't even need to have a chrome checkout on your machine. This tool should work on all platforms. You need svn 1.5 or above in your path. If you run into any issues with the tool, please let me know. Thank you, Nicolas If the tool does not work, you can revert the long way by doing: cd src/ svn update svn merge -c - . (the dot at the end of the previous line is important) --~--~-~--~~~---~--~~ 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: Compiling error after I did a 'gclient sync'
Thanks Kenneth. I tried this. But I get I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources/i386 -I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources -c /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/DerivedSources/Debug/webkit/HTMLElementFactory.cpp -o /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/Objects-normal/i386/HTMLElementFactory.o command-line: error: ENABLE_3D_CANVAS redefined command-line: error: this is the location of the previous definition command-line: error: this is the location of the previous definition and also: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:49: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Mon, Nov 2, 2009 at 10:38 PM, Kenneth Russell k...@chromium.org wrote: On Mon, Nov 2, 2009 at 10:27 PM, n179911 n179...@gmail.com wrote: Hi, I have tried syncing up chromium HEAD by doing this (since i use git for chromium and webkit). $ git pull (update chromium) $ gclient sync $ tools/sync-webkit-git.py (update webkit) But i got the following errors when I compile it. It appears the method 'CanvasRenderingContext3D::attachShader' is called with the wrong number of parameters. Does anyone know how to fix it? Thank you. chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*)' ../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are: void WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*, WebCore::ExceptionCode) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, unsigned int, WebCore::String)' ../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are: void WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, long unsigned int, const WebCore::String, WebCore::ExceptionCode) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int, WebCore::CanvasBuffer*)' ../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are: void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int, WebCore::CanvasBuffer*, WebCore::ExceptionCode) It looks like upstream WebKit changes have broken our WebGL implementation again. The reason you're running into this is probably that you synced a more recent version of WebKit than is described in the DEPS file. Your best bet to get things compiling again quickly is to set ENABLE_3D_CANVAS=0 in src/build/features_override.gypi, run gclient runhooks --force, and rebuild. -Ken --~--~-~--~~~---~--~~ 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: Inheritance in gyp configurations
I'd be willing to consider alternatives. The key thing here is that we need
a way to generate multiple configurations within a single expansion,
currently at least.
I suppose an alternative would be to have gyp expand things multiple times
with CONF or somesuch being each value from a list of config names. Then we
could use conditions gated the value of CONF.
This would have the drawback that we'd might have to expand large chunks of
the gyp files multiple times. But it might be more homogenous. Definitely
more major surgery.
For the example from before it would look something like:
'configurations': ['Debug', 'Debug_x64', 'Release', 'Release_x64'],
'configurations_settings': {
# bunch of global settings.
'conditions': [
['x64 in CONF', {
'defines': [
# bunch of 64-bit defines.
],
}, {
'defines': [
# bunch of 32-bit defines.
],
}],
],
['Debug' in CONF', {
# debug specific settings
}, {
# release specific settings
}],
},
I admit this syntax is slightly nicer, but I'm a little scared of the work
to get there.
Also, you'd still have the weird merging behavior for targets which alter
this per config. Though I guess that could also get changed:
'configurations': {
'Debug': {
'defines': ['extra_for_my_target_on_debug'],
},
},
==
'configuration_settings': [
'conditionals': {
[Debug in CONF': {
'defines': ['extra_for_my_target_on_debug'],
}],
],
},
I suppose the other route would be to refrain from configs altogether. This
is for instance how the linux folks have added 64-bit. They generate
different scons/make files at gyp time. Configurations are more limited, but
the IDE folks like being able to switch from a drop down.
-BradN
On Tue, Nov 3, 2009 at 1:33 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
On Mon, Nov 2, 2009 at 3:37 PM, Bradley Nelson bradnel...@google.comwrote:
S,o as it happens, I just had someone on nacl make the first use of
multiple inheritance this morning.
He hasn't checked it in yet, but the use case is:
'Common': {
# bunch of global stuff
'defines': [
# bunch of 32-bit defines.
],
},
'Debug': {
# bunch of general debug stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Release': {
# bunch of general release stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Common_x64': {
# Customizations to change 32-bit - 64-bit
'abstract': 1,
'defines!': [
# bunch of 32-bit defines
],
'defines': [
# bunch of 64-bit defines
],
},
'Debug_x64': {
'inherit_from': ['Debug', 'Common_x64'],
},
'Release_x64': {
'inherit_from': ['Release', 'Common_x64'],
},
This use case seems reasonable enough.
It might fit into something like (b), but at least as currently conceived,
'Common_x64' has overrides of stuff in 'Common'.
It might be possible to refactor Common and Common_x64 to avoid
collisions, maybe pull out all the 32-bit stuff into Common_x86 and leave
Common with truly common stuff. On the other hand, the current arrangement
allowed a fairly small modification while 64-bit is being experimented with.
Suggestions?
Sorry for the slow response to this...missed it in my inbox. :(
It's hard to see w/o a concrete example, but in general I would have wanted
to do it via conditionals inside 'Common.'
Why rely on shadowing when you can explicitly do it via conditionals here?
IMO, the more dimensions in which we have to alter how the final dictionary
is created, the harder it will be to maintain -- especially if there
construct is one which relies on order of lookup, and doesn't encourage
co-locating where the decision is made for which modifications are included
(with conditionals, you know the else portion is likely in the same file.
With inheritance, it's all over the place.)
-Albert
--~--~-~--~~~---~--~~
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: Lifehacker browser tests say Chrome uses the most memory
On Tue, Nov 3, 2009 at 12:55 PM, John Munro ghost...@gmail.com wrote: Lifehacker posted a series of browser benchmarks here http://lifehacker.com/539/browser-speed-tests-the-windows-7-results and in their memory use test Chrome came out using the most. It's entirely possible their benchmarking methodology was flawed, but in any case I thought you should be aware. Yes, we've long been aware that Chrome uses lots of memory. That's why there's a memory task force right now looking at memory use. 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: Compiling error after I did a 'gclient sync'
Thanks. Kenneth, I fixed the ENABLE_3D_CANVAS redefined error. But I still get the following compilation error: In file included from /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../bindings/v8/DerivedSourcesAllInOne.cpp:65: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:40: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Tue, Nov 3, 2009 at 6:40 PM, n179911 n179...@gmail.com wrote: Thanks Kenneth. I tried this. But I get I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources/i386 -I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources -c /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/DerivedSources/Debug/webkit/HTMLElementFactory.cpp -o /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/Objects-normal/i386/HTMLElementFactory.o command-line: error: ENABLE_3D_CANVAS redefined command-line: error: this is the location of the previous definition command-line: error: this is the location of the previous definition and also: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:49: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Mon, Nov 2, 2009 at 10:38 PM, Kenneth Russell k...@chromium.org wrote: On Mon, Nov 2, 2009 at 10:27 PM, n179911 n179...@gmail.com wrote: Hi, I have tried syncing up chromium HEAD by doing this (since i use git for chromium and webkit). $ git pull (update chromium) $ gclient sync $ tools/sync-webkit-git.py (update webkit) But i got the following errors when I compile it. It appears the method 'CanvasRenderingContext3D::attachShader' is called with the wrong number of parameters. Does anyone know how to fix it? Thank you. chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*)' ../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are: void WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*, WebCore::ExceptionCode) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, unsigned int, WebCore::String)' ../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are: void WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, long unsigned int, const WebCore::String, WebCore::ExceptionCode) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int, WebCore::CanvasBuffer*)' ../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are: void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int, WebCore::CanvasBuffer*, WebCore::ExceptionCode) It looks like upstream WebKit changes have broken our WebGL implementation again. The reason you're running into this is probably that you synced a more recent version of WebKit than is described in the DEPS file. Your best bet to get things compiling again quickly is to set ENABLE_3D_CANVAS=0 in src/build/features_override.gypi, run gclient runhooks --force, and rebuild. -Ken --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe:
[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 6:05 PM, John Abd-El-Malek j...@chromium.org wrote: But this means that the person didn't use the trybot. I think we need to be harsher on people who commit with changes that didn't complete or failed on the trybot. They need to have a really good reason as to why they want to try their change on the buildbot and possibly delay many other engineers. For the record, I completely support immediate backouts of changes that break the tree, and agree that all changes should go through the trybots -- but sometimes the trybots don't work. I don't know anything about the architectural differences between the trybots and buildbots, but from recent experience I think the trybots are trying to do incremental builds, when that isn't guaranteed to always work. If it's just a matter of throwing hardware at the problem of making the trybots nearly 100% reliable I think we should make that investment. -Ken On Tue, Nov 3, 2009 at 3:11 PM, Ben Goodger (Google) b...@chromium.org wrote: The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Perf tests to run?
One trick that I've regularly done when concerned about the perf impact of a patch is to: a) Wait till late at night pacific time, when very few checkins are landing (often there are multi-hour gaps). b) Land your change, and wait till the build bots all start building (about a minute later). c) Revert your change. You then get a PILE of perf stats with minimal effort. It is MUCH harder to try to emulate this effect on your own machine(s), as the perf bots are dedicated to the chore, and you have a control build to watch... and a before/after set of results to compare with. By doing this late at night you have the highest probability of getting the impact of ONLY your change, and not having a second contemporaneous landing add noise to your results. :-) If you don't use those computer cycles late at night... we were going to have to waste them! YMMV. Jim p.s., Be sure you are good at doing reverts before playing this game ;-). On Tue, Nov 3, 2009 at 2:04 PM, Anton Muhin ant...@chromium.org wrote: Thanks, James. So I ran SunSpider, V8 and page_cyclers. SunSpider and V8 are roughly the same. page_cyclers trickier. First of all, I failed to run some tests on my box (for both clean and patched builds)---all *Http tests just hang. I hope it's missetup on my part, but hopefully not crucial. Of tests ran for reference build second run (patched version) was slightly faster, so numbers of patched version should be higher just due to somewhat different state of my box. Still for most of the tests patched version performed slightly faster, the only problematic test was the first one (MozFile): 35326 ms total for clean vs. 38936 ms total for patched. Given that's the only one (e.g. Intl1File ran 115913 ms on clean vs. 94831 ms on patched), that might have been a spike. If that sounds reasonable to you all, I'd ask to commit-queue+ a patch and see how it'd perform on real buildbots. tia and yours, anton. On Tue, Nov 3, 2009 at 11:31 PM, James Robinson jam...@google.com wrote: Essentially this. Some of the page cyclers have fairly interesting data sets. I think we are fairly lacking in good real-world performance tests to do comparisons like this, which is kind of unfortunate. I'd love to be able to point a build with a speculative patch in it at the internet and then have it report back how well it did but there are a lot of variables to control. - James On Tue, Nov 3, 2009 at 10:38 AM, Anton Muhin ant...@chromium.org wrote: Thanks a lot, Peter. Yes, I am aware of those. Just wanted to run something before committing :) I actually ran some DOM related tests. Adam (on IM) suggested to run SunSpider, V8 and page load cyclers. I am going to do it and if numbers are fine, then would try to commit my change. yours, anton. On Tue, Nov 3, 2009 at 9:25 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 7:30 AM, Anton Muhin ant...@chromium.org wrote: So the question: how could I check that I won't (notably) regress Chromium performance with this change? We have perf bots; you can check in and look at the effects there, and there might even be a way to get perf results from the tryservers. 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: Which editor do you recommend on Mac OS X?
I've heard this suggested a few times (not just in this thread) - is there an advantage to running Carbon Emacs instead of plain-old-GNU-Emacs-in-a-terminal? -atw On Tue, Nov 3, 2009 at 1:14 PM, Scott Hess sh...@chromium.org wrote: +1. I found Aquamacs weird/annoying. Carbon Emacs seemed a lot better. [I come from a Linux background.] -scott On Tue, Nov 3, 2009 at 11:16 AM, Kenneth Russell k...@chromium.org wrote: There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. Recommended. http://www.emacswiki.org/emacs/EmacsForMacOS http://www.emacswiki.org/emacs/CarbonEmacsPackage -Ken On Tue, Nov 3, 2009 at 10:08 AM, Drew Wilson atwil...@chromium.org wrote: I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] revert now, ask questions later? WAS: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. We waver on this policy. Firstly, when does a fix ever take 2 minutes to commit? Maybe 1% of the time. More than that, this has happened a number of times already. A small subset of people who are responsible for keeping the tree healthy institute a revert-early policy. Then a small subset of people who get reverted get vocal and upset. Then we end up in the middle again where some reverts happen quickly and others take 30 minutes. Can we agree on this as a formal policy that we add to documentation somewhere? To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. The first part is important. We shouldn't be rolling back changes that wouldn't close the tree (e.g. a change that causes a single test to fail). Ojan --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. Pinging the author is important, especially if there are special circumstances (like it only fails on the bot and they want to ssh in to examine something). --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
Carbon Emacs makes the Alt key work right, and copy/paste to the system pasteboard works like I expect w/in emacs. I find using emacs w/in Terminal.app to be annoying enough that I use emacsclient to throw edits out to Emacs.app. -scott On Tue, Nov 3, 2009 at 2:21 PM, Drew Wilson atwil...@chromium.org wrote: I've heard this suggested a few times (not just in this thread) - is there an advantage to running Carbon Emacs instead of plain-old-GNU-Emacs-in-a-terminal? -atw On Tue, Nov 3, 2009 at 1:14 PM, Scott Hess sh...@chromium.org wrote: +1. I found Aquamacs weird/annoying. Carbon Emacs seemed a lot better. [I come from a Linux background.] -scott On Tue, Nov 3, 2009 at 11:16 AM, Kenneth Russell k...@chromium.org wrote: There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. Recommended. http://www.emacswiki.org/emacs/EmacsForMacOS http://www.emacswiki.org/emacs/CarbonEmacsPackage -Ken On Tue, Nov 3, 2009 at 10:08 AM, Drew Wilson atwil...@chromium.org wrote: I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: FYI: Linux interactive_ui_tests a bit hosed
FYI: http://codereview.chromium.org/341078 http://codereview.chromium.org/341078Linux interactive tests have finally gone green. On Mon, Nov 2, 2009 at 10:08 AM, John Abd-El-Malek j...@chromium.org wrote: (CCing today's sheriffs + Jay) I was thinking of marking the bug to P1, except that won't change much if no one has the time to work on it now. I think to keep tree green, the entire test should be disabled until singletons are cleared between each test, or it's switched to browser_tests launcher. On Mon, Nov 2, 2009 at 12:44 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I think that the right fix is to switch interactive_ui_tests to browser_tests launcher (jcampan did some great work to make the launcher more flexible, it may be quite simple to do the switch now - if there are no UI tests in interactive_ui_tests). I also suggest bumping the priority of http://crbug.com/25997 to P1 and possibly marking it with FlakyTest label. On Mon, Nov 2, 2009 at 09:37, John Abd-El-Malek j...@chromium.org wrote: This is related to bug 25997. The tests are inherently flakey because singeltons aren't released between runs, so cached MessageLoop pointers are bogus. Sometimes they're ok when the order of construction/destruction of MessageLoop pointers is the same. But if that changes, or other memory allocations change, the tests start failing. Just wanted to send a heads up since I spent a day debugging this last week, and now they're failing again. --~--~-~--~~~---~--~~ 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 can now be run on Win 7
Hi all, I have just checked in a new set of baselines that should allow you to run the layout tests on Win 7 as well as Vista and XP. For those of you playing along at home, this means that if you have a baseline that is windows 7 specific, or is the same across 7, Vista, and XP, check it into src/webkit/data/platform/chromium-win. If you have a baseline that is specific to Vista or is the same on Vista and XP, check it into src/webkit/data/platform/chromium-win-vista, and if you have an XP-specific baseline, check it into src/webkit/data/platform/chromium-win-xp. 99.9% of all of your baselines will be generic, so you can probably just check it into chromium-win and let me fix diffs when they crop up down the road. Also, if you have a test that only fails on Win 7, you can specify WIN-7 in test_expectations.txt. But, I wouldn't expect any of those. Cheers, and any questions or problems on this should go to me, -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
Ha. http://tech.slashdot.org/story/09/11/03/1334203/X11-Chrome-Reportedly-Outperforms-Windows-and-Mac-Versions On Fri, Oct 30, 2009 at 9:44 AM, Linus Upson li...@google.com wrote: scrolling jank in gmail http://crbug.com/25741 Linus On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin e...@chromium.org wrote: General comments: Linux tends to be lighter which means it does better on older hardware, so depending on what sorts of laptops you're talking about that could be a major factor. Windowses later than 2000 or so need surprising amounts of hardware to run well. (I don't mention Mac below because there hasn't been much performance work there yet.) I pulled out the laptops side-by-side to be more scientific about this. Here are the stats: XP: 2GB RAM, Core2 Duo, 2.00 GHz Ubuntu 9.10: 2GB RAM, Core 2 Duo, 2.40 GHz So, the Linux machine as 20% more CPU to work with. 1) Scroll performance is extremely good. Even on Gmail, I can only get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, it doesn't even look like I can do that. On plain pages (one scrollbar on the right, no Flash) scrolling is literally shifting the pixels down. On Linux we do this by sending a command to the X server, which is a single process that even has the graphics drivers built in so it talks directly to your graphics card and can in theory do a hardware-accelerated copy. I would expect this to be pretty fast. Looking at this more carefully, scroll performance on Slashdot is great in both Windows and Linux. On Gmail (no chat mole), there's a noticeable difference. Here's a visualization of the numb on the scroll bar: || || || || || || -- -- Click here and pull down -- -- -- Linux: mouse latency gets to here || || -- Windows: mouse latency gets to here || || || || Admittedly, it's hard to see precisely, but it affects the feel. Scroll on Windows feels slightly heavier. 2) Tab creation is very fast. Maybe the zygote is helping here? Can we pre-render the NTP on other platforms? The zygote is paused right at process start, before we've even started a renderer. On the other hand Windows process creation is more expensive. There is a new tab graph that attempts to measure this. The various lines on the graph are tracking how quickly we get to each stage in constructing the page. We hit the first line 20ms faster on Linux than Windows likely due to the zygote and slow Windows process creation, but process startup seems to be a relatively small part of the total time. Linux hits other lines later and Linux and Windows hit the finish line at around the same time. So, I retried this with a fresh profile on both. The differences are not as dramatic as I remember. I can't actually see a difference when I run them side-by-side. 3) Startup time is faster than calculator. I'm not sure if you're kidding. Do you mean Windows calculator? I meant Linux calculator. In the limit, I'd expect us to pay a lot more on Linux due to using more libraries, GTK initialization, round trips to the X server, etc. but I don't know much about Windows here. I tried turning on the GTK theme. That killed startup performance. Side-by-side startup easily noticeably faster in Linux. To be more precise, drawing the first pixel is noticeably faster. Total startup time is harder to say. Interestingly startup drawing is different between Windows and Linux. We might want to film with a high-speed camera to see exactly what's going on, but here are my impressions: Linux draw order: 1) Fill entire window with blue (This looks bad, can we use a different color? White?). 2) Paint main UI widgets, including NTP. 3) Paint NTP thumbnails. I bet that (2) is actually broken in to two pieces, I just can't see it. Window draw order: 1) Paint NC region (the blue border around the edge). 2) Paint main UI widgets (without omnibox). 3) Blit NTP content area (the sweep from top to bottom is noticeable). 4) Paint omnibox. 5) Paint NTP thumbnails. Keep in mind that this all happens very fast, so I could be imagining things. Ideas for improving perceived windows startup time: 1) Draw a fake omnibox with the rest of the main UI widgets. Currently we draw the omnibox really late and it looks slow and bad. You can see this if you have a dark desktop wallpaper and you focus on where the omnibox will be. You'll see a dark rectangle inside the main toolbar which is the desktop showing through. We should never show a dark rectangle there. 2) Fill the main content area with white when drawing the main UI widgets. You can see this if you focus on the bottom of where the bookmark bar is going to be (especially when the bookmark bar is set to show only on the NTP). You'll see an edge there when the bookmark bar is draw by while the main
[chromium-dev] Re: Which editor do you recommend on Mac OS X?
In Carbon emacs, the command key works as Meta, and copying/pasting is integrated with the system clipboard. There are probably other advantages. -Ken On Tue, Nov 3, 2009 at 1:21 PM, Drew Wilson atwil...@chromium.org wrote: I've heard this suggested a few times (not just in this thread) - is there an advantage to running Carbon Emacs instead of plain-old-GNU-Emacs-in-a-terminal? -atw On Tue, Nov 3, 2009 at 1:14 PM, Scott Hess sh...@chromium.org wrote: +1. I found Aquamacs weird/annoying. Carbon Emacs seemed a lot better. [I come from a Linux background.] -scott On Tue, Nov 3, 2009 at 11:16 AM, Kenneth Russell k...@chromium.org wrote: There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. Recommended. http://www.emacswiki.org/emacs/EmacsForMacOS http://www.emacswiki.org/emacs/CarbonEmacsPackage -Ken On Tue, Nov 3, 2009 at 10:08 AM, Drew Wilson atwil...@chromium.org wrote: I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: Reverting a change, the fast way
Interesting. WebKit has similar functionality as: bugzilla-tool rollout 12345 We've found that git reverts are at least an order of magnitude faster than SVN reverse merges. I wonder what bugzilla-tool/drover can learn from one another. -eric On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi One of the goal of the Green Tree Task Force was to make reverting a change easy and fast. This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. Turns out it was already easy and fast with Anthony's drover tool. If you have depot_tools in your path, just type : drover --revert where is the revision you want to revert. Since the tool creates temporary files, I suggest you go to the temp directory first. It should take only a few seconds, even for a really big change. You don't even need to have a chrome checkout on your machine. This tool should work on all platforms. You need svn 1.5 or above in your path. If you run into any issues with the tool, please let me know. Thank you, Nicolas If the tool does not work, you can revert the long way by doing: cd src/ svn update svn merge -c - . (the dot at the end of the previous line is important) --~--~-~--~~~---~--~~ 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: revert now, ask questions later? WAS: Reverting a change, the fast way
IMO, I wouldn't mind draconian reverts in the interest of keeping the tree open and allowing the sheriffs some semblance of productivity. OTOH, git makes it really easy for me to un-revert and try again, so maybe I'm biased there. - a On Tue, Nov 3, 2009 at 3:03 PM, Eric Seidel esei...@chromium.org wrote: Could we just automate rollouts and this 5-minute timer? If we have the tools to do automated rollouts, would it be reasonable to add them as a phase in the buildbot? On Tue, Nov 3, 2009 at 2:52 PM, Nicolas Sylvain nsylv...@chromium.org wrote: +1 On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman a...@chromium.org wrote: I'm OK with that. Just make it clear that the sheriff does have authority. One time when I was sheriff I wanted to revert a broken patch. The author insisted on patching it over and over. He finally got it working about about seven patches and nearly three hours or so, when I was insisting on backing it out after the first 30m. Yes, this is exactly what we want to avoid. The 2-minute rule usually includes: Oops, I forgot to commit a file Let me disable the test I just added, it clearly does not work Oops, before committing I renamed a variable and forgot to change it at one place It also use to mean: Oops, I forgot an include. But this one has been biting us to much in the past, so I leave it at the discretion of the sheriff. I think people need to use their good judgement too. The length of a minute should be inversely proportional to the number of people trying to commit during this time of the day. Nicolas Avi On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Perf tests to run?
Thanks, James. So I ran SunSpider, V8 and page_cyclers. SunSpider and V8 are roughly the same. page_cyclers trickier. First of all, I failed to run some tests on my box (for both clean and patched builds)---all *Http tests just hang. I hope it's missetup on my part, but hopefully not crucial. Of tests ran for reference build second run (patched version) was slightly faster, so numbers of patched version should be higher just due to somewhat different state of my box. Still for most of the tests patched version performed slightly faster, the only problematic test was the first one (MozFile): 35326 ms total for clean vs. 38936 ms total for patched. Given that's the only one (e.g. Intl1File ran 115913 ms on clean vs. 94831 ms on patched), that might have been a spike. If that sounds reasonable to you all, I'd ask to commit-queue+ a patch and see how it'd perform on real buildbots. tia and yours, anton. On Tue, Nov 3, 2009 at 11:31 PM, James Robinson jam...@google.com wrote: Essentially this. Some of the page cyclers have fairly interesting data sets. I think we are fairly lacking in good real-world performance tests to do comparisons like this, which is kind of unfortunate. I'd love to be able to point a build with a speculative patch in it at the internet and then have it report back how well it did but there are a lot of variables to control. - James On Tue, Nov 3, 2009 at 10:38 AM, Anton Muhin ant...@chromium.org wrote: Thanks a lot, Peter. Yes, I am aware of those. Just wanted to run something before committing :) I actually ran some DOM related tests. Adam (on IM) suggested to run SunSpider, V8 and page load cyclers. I am going to do it and if numbers are fine, then would try to commit my change. yours, anton. On Tue, Nov 3, 2009 at 9:25 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 7:30 AM, Anton Muhin ant...@chromium.org wrote: So the question: how could I check that I won't (notably) regress Chromium performance with this change? We have perf bots; you can check in and look at the effects there, and there might even be a way to get perf results from the tryservers. 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: Changes to using threads in the browser process
On Tue, Nov 3, 2009 at 12:03 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek j...@chromium.org wrote: *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread Awesome! 4: I've removed all the special casing and always made the objects in the browser code behave in one way. If you're writing a unit test and need to use an object that goes to a file thread (where before it would proceed synchronously), you just need: ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); foo-StartAsyncTaskOnFileThread(); MessageLoop::current()-RunAllPending(); There are plenty of examples now in the tests. Are there any examples for asynchronous processing (with a real backend thread)? Sure, look at BufferedResourceHandler or ResourceMessageFilter, which both need to load plugins on the file thread. I think that chrome/browser/privacy_blacklist/blacklist_manager.cc uses some of the anti-patterns you described (it caches base::Thread* instead of MessageLoop*, but I understand it's equally bad). And it will benefit a lot from ChromeThread::DeleteOnIOThread. The good part is that BlacklistManager is not yet used in the browser. I will fix the issues before the final integration of BlacklistManager. Great, I missed that one since I was just looking for caching of MessageLoop pointers. Thanks. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Which editor do you recommend on Mac OS X?
On Tue, Nov 3, 2009 at 10:12 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Tue, Nov 3, 2009 at 19:08, Drew Wilson atwil...@chromium.org wrote: I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. I have it working. For reference, the file can be downloaded from http://google-styleguide.googlecode.com/svn/trunk/google-c-style.el Maybe I should try the non-aqua Emacs, hm... How about building? Is using xcodebuild slower than running the build from Xcode? My simple testing shows that there is no big difference. On both my MacBook Pro and Mac Pro, I found that there was a fairly sizable difference doing incremental builds since XCode keeps track of dependencies between builds. When doing a full build, there's not much difference though. --~--~-~--~~~---~--~~ 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: Reverting a change, the fast way
I tried that a few days ago, and drover died with me with something along the lines of Can't talk to chrome-svn (which as far as I understand is some internal svn repo?). A quick glance at the source confirms that this is still the case. On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi One of the goal of the Green Tree Task Force was to make reverting a change easy and fast. This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. Turns out it was already easy and fast with Anthony's drover tool. If you have depot_tools in your path, just type : drover --revert where is the revision you want to revert. Since the tool creates temporary files, I suggest you go to the temp directory first. It should take only a few seconds, even for a really big change. You don't even need to have a chrome checkout on your machine. This tool should work on all platforms. You need svn 1.5 or above in your path. If you run into any issues with the tool, please let me know. Thank you, Nicolas If the tool does not work, you can revert the long way by doing: cd src/ svn update svn merge -c - . (the dot at the end of the previous line is important) --~--~-~--~~~---~--~~ 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: Inheritance in gyp configurations
On Mon, Nov 2, 2009 at 3:37 PM, Bradley Nelson bradnel...@google.comwrote:
S,o as it happens, I just had someone on nacl make the first use of
multiple inheritance this morning.
He hasn't checked it in yet, but the use case is:
'Common': {
# bunch of global stuff
'defines': [
# bunch of 32-bit defines.
],
},
'Debug': {
# bunch of general debug stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Release': {
# bunch of general release stuff assumes 32-bit
'inherit_from': ['Common'],
},
'Common_x64': {
# Customizations to change 32-bit - 64-bit
'abstract': 1,
'defines!': [
# bunch of 32-bit defines
],
'defines': [
# bunch of 64-bit defines
],
},
'Debug_x64': {
'inherit_from': ['Debug', 'Common_x64'],
},
'Release_x64': {
'inherit_from': ['Release', 'Common_x64'],
},
This use case seems reasonable enough.
It might fit into something like (b), but at least as currently conceived,
'Common_x64' has overrides of stuff in 'Common'.
It might be possible to refactor Common and Common_x64 to avoid collisions,
maybe pull out all the 32-bit stuff into Common_x86 and leave Common with
truly common stuff. On the other hand, the current arrangement allowed a
fairly small modification while 64-bit is being experimented with.
Suggestions?
Sorry for the slow response to this...missed it in my inbox. :(
It's hard to see w/o a concrete example, but in general I would have wanted
to do it via conditionals inside 'Common.'
Why rely on shadowing when you can explicitly do it via conditionals here?
IMO, the more dimensions in which we have to alter how the final dictionary
is created, the harder it will be to maintain -- especially if there
construct is one which relies on order of lookup, and doesn't encourage
co-locating where the decision is made for which modifications are included
(with conditionals, you know the else portion is likely in the same file.
With inheritance, it's all over the place.)
-Albert
--~--~-~--~~~---~--~~
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: Hard Refresh UI Option
On Tue, Nov 3, 2009 at 4:21 AM, Meok meok...@gmail.com wrote: Is it feasible to get an easy way to initiate a hard refresh (bypassing the cache)? There's a key-combo (CTRL + Refresh) in other browsers, not sure if it works in Chrome, but has anyone ever thought of building this functionality right into the button? Would be helpful if you could simply right-click the refresh button to bypass the cache. Please send these sorts of questions/comments to chromium-discuss or the help center. 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: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 3:01 PM, Nico Weber tha...@chromium.org wrote: I tried that a few days ago, and drover died with me with something along the lines of Can't talk to chrome-svn (which as far as I understand is some internal svn repo?). A quick glance at the source confirms that this is still the case. Good point, it should have a way to specify which url it should use to checkout from. by default it uses the internal url. I'll try to find a way to fix that. Nicolas On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi One of the goal of the Green Tree Task Force was to make reverting a change easy and fast. This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. Turns out it was already easy and fast with Anthony's drover tool. If you have depot_tools in your path, just type : drover --revert where is the revision you want to revert. Since the tool creates temporary files, I suggest you go to the temp directory first. It should take only a few seconds, even for a really big change. You don't even need to have a chrome checkout on your machine. This tool should work on all platforms. You need svn 1.5 or above in your path. If you run into any issues with the tool, please let me know. Thank you, Nicolas If the tool does not work, you can revert the long way by doing: cd src/ svn update svn merge -c - . (the dot at the end of the previous line is important) --~--~-~--~~~---~--~~ 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: revert now, ask questions later? WAS: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 7:46 PM, Kenneth Russell k...@chromium.org wrote: On Tue, Nov 3, 2009 at 6:05 PM, John Abd-El-Malek j...@chromium.org wrote: But this means that the person didn't use the trybot. I think we need to be harsher on people who commit with changes that didn't complete or failed on the trybot. They need to have a really good reason as to why they want to try their change on the buildbot and possibly delay many other engineers. For the record, I completely support immediate backouts of changes that break the tree, and agree that all changes should go through the trybots -- but sometimes the trybots don't work. I don't know anything about the architectural differences between the trybots and buildbots, but from recent experience I think the trybots are trying to do incremental builds, when that isn't guaranteed to always work. even the bots on the main waterfall do incremental builds (except some of them). If the change requires a clobber, use gcl try CHANGENAME -c to run the code on the try bot doing a full build. If it's just a matter of throwing hardware at the problem of making the trybots nearly 100% reliable I think we should make that investment. -Ken On Tue, Nov 3, 2009 at 3:11 PM, Ben Goodger (Google) b...@chromium.org wrote: The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: revert now, ask questions later? WAS: Reverting a change, the fast way
I'm OK with that. Just make it clear that the sheriff does have authority. One time when I was sheriff I wanted to revert a broken patch. The author insisted on patching it over and over. He finally got it working about about seven patches and nearly three hours or so, when I was insisting on backing it out after the first 30m. Avi On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: revert now, ask questions later? WAS: Reverting a change, the fast way
+100. This is very similar to getting paged about a production problem. Sometimes you get sucked into wasting an hour on easy fixes which don't fix anything. That sets you up for stupid mistakes. So, you broke the build. Take it like a man/woman, revert your change, and land it again when you've got it right. It happens to everyone. The goal here isn't to save YOU ten minutes of time, the goal is to save 5 minutes for each of the couple dozen co-workers which will be impacted by the broken tree. Only ask for grace to fix the breakage if you're 100% certain you can fix it right the first time. -scott On Tue, Nov 3, 2009 at 3:52 PM, Nicolas Sylvain nsylv...@chromium.org wrote: +1 On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman a...@chromium.org wrote: I'm OK with that. Just make it clear that the sheriff does have authority. One time when I was sheriff I wanted to revert a broken patch. The author insisted on patching it over and over. He finally got it working about about seven patches and nearly three hours or so, when I was insisting on backing it out after the first 30m. Yes, this is exactly what we want to avoid. The 2-minute rule usually includes: Oops, I forgot to commit a file Let me disable the test I just added, it clearly does not work Oops, before committing I renamed a variable and forgot to change it at one place It also use to mean: Oops, I forgot an include. But this one has been biting us to much in the past, so I leave it at the discretion of the sheriff. I think people need to use their good judgement too. The length of a minute should be inversely proportional to the number of people trying to commit during this time of the day. Nicolas Avi On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Compiling error after I did a 'gclient sync'
It has been working fine for me. Is it possible you have the wrong version of WebKit? What does tools/sync-webkit-git.py say? On Tue, Nov 3, 2009 at 6:46 PM, n179911 n179...@gmail.com wrote: Thanks. Kenneth, I fixed the ENABLE_3D_CANVAS redefined error. But I still get the following compilation error: In file included from /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../bindings/v8/DerivedSourcesAllInOne.cpp:65: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:40: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Tue, Nov 3, 2009 at 6:40 PM, n179911 n179...@gmail.com wrote: Thanks Kenneth. I tried this. But I get I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources/i386 -I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources -c /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/DerivedSources/Debug/webkit/HTMLElementFactory.cpp -o /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/Objects-normal/i386/HTMLElementFactory.o command-line: error: ENABLE_3D_CANVAS redefined command-line: error: this is the location of the previous definition command-line: error: this is the location of the previous definition and also: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:49: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Mon, Nov 2, 2009 at 10:38 PM, Kenneth Russell k...@chromium.org wrote: On Mon, Nov 2, 2009 at 10:27 PM, n179911 n179...@gmail.com wrote: Hi, I have tried syncing up chromium HEAD by doing this (since i use git for chromium and webkit). $ git pull (update chromium) $ gclient sync $ tools/sync-webkit-git.py (update webkit) But i got the following errors when I compile it. It appears the method 'CanvasRenderingContext3D::attachShader' is called with the wrong number of parameters. Does anyone know how to fix it? Thank you. chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*)' ../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are: void WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*, WebCore::ExceptionCode) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, unsigned int, WebCore::String)' ../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are: void WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, long unsigned int, const WebCore::String, WebCore::ExceptionCode) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int, WebCore::CanvasBuffer*)' ../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are: void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int, WebCore::CanvasBuffer*, WebCore::ExceptionCode) It looks like upstream WebKit changes have broken our WebGL implementation again. The reason you're running into this is probably that you synced a more recent version of WebKit than is described in the DEPS file. Your best bet to get things compiling again quickly is to set ENABLE_3D_CANVAS=0 in src/build/features_override.gypi, run gclient runhooks --force, and rebuild. -Ken
[chromium-dev] Re: revising the output from run_webkit_tests
Anyone who wants to follow along on this, I've filed http://code.google.com/p/chromium/issues/detail?id=26659 to track it. -- Dirk On Sat, Oct 24, 2009 at 5:01 PM, Dirk Pranke dpra...@chromium.org wrote: Sure. I was floating the idea first before doing any work, but I'll just grab an existing text run and hack it up for comparison ... -- Dirk On Fri, Oct 23, 2009 at 3:51 PM, Ojan Vafai o...@chromium.org wrote: Can you give example outputs for the common cases? It would be easier to discuss those. On Fri, Oct 23, 2009 at 3:43 PM, Dirk Pranke dpra...@chromium.org wrote: If you've never run run_webkit_tests to run the layout test regression, or don't care about it, you can stop reading ... If you have run it, and you're like me, you've probably wondered a lot about the output ... questions like: 1) what do the numbers printed at the beginning of the test mean? 2) what do all of these test failed messages mean, and are they bad? 3) what do the numbers printed at the end of the test mean? 4) why are the numbers at the end different from the numbers at the beginning? 5) did my regression run cleanly, or not? You may have also wondered a couple of other things: 6) What do we expect this test to do? 7) Where is the baseline for this test? 8) What is the baseline search path for this test? Having just spent a week trying (again), to reconcile the numbers I'm getting on the LTTF dashboard with what we print out in the test, I'm thinking about drastically revising the output from the script, roughly as follows: * print the information needed to reproduce the test and look at the results * print the expected results in summary form (roughly the expanded version of the first table in the dashboard - # of tests by (wontfix/fix/defer x pass/fail/are flaky). * don't print out failure text to the screen during the run * print out any *unexpected* results at the end (like we do today) The goal would be that if all of your tests pass, you get less than a small screenful of output from running the tests. In addition, we would record a full log of (test,expectation,result) to the results directory (and this would also be available onscreen with --verbose) Lastly, I'll add a flag to re-run the tests that just failed, so it's easy to test if the failures were flaky. Then I'll rip out as much of the set logic in test_expectations.py as we can possibly get away with, so that no one has to spend the week I just did again. I'll probably replace it with much of the logic I use to generate the dashboard, which is much more flexible in terms of extracting different types of queries and numbers. I think the net result will be the same level of information that we get today, just in much more meaningful form. Thoughts? Comments? Is anyone particularly wedded to the existing output, or worried about losing a particular piece of info? -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Lifehacker browser tests say Chrome uses the most memory
Forgive me if I shouldn't be posting this kind of thing to this group, but I've seen similar things posted here before. Lifehacker posted a series of browser benchmarks here http://lifehacker.com/539/browser-speed-tests-the-windows-7-results and in their memory use test Chrome came out using the most. It's entirely possible their benchmarking methodology was flawed, but in any case I thought you should be aware. John --~--~-~--~~~---~--~~ 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: Changes to using threads in the browser process
I've updated the wiki. I was wary of putting this stuff up because of bit rot, but since there's already documentation we won't be worse off. As for the renderer process: this object would have to be recreated. I'd prefer to keep ChromeThread just for one process to keep things clearer. I think this pattern doesn't happen often in child processes (yours is the first example I hear of), so it seems a one-off solution is ok for now. On Tue, Nov 3, 2009 at 11:49 AM, Andrew Scherkus scher...@chromium.orgwrote: Very cool! Could this idea be done in the render process? We try to keep the media processing code off the render thread but we've been bitten using cached MessageLoops which have been destructed (usually on tab close when the render thread goes away). On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread 4: I've removed all the special casing and always made the objects in the browser code behave in one way. If you're writing a unit test and need to use an object that goes to a file thread (where before it would proceed synchronously), you just need: ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); foo-StartAsyncTaskOnFileThread(); MessageLoop::current()-RunAllPending(); There are plenty of examples now in the tests. *Gotchas* -PostTask will silently delete a task if the thread doesn't exist. This is done to avoid having all the code that uses it have special cases if the target thread exists or not, and to make Valgrind happy. As usual, the task for
[chromium-dev] Re: Compiling error after I did a 'gclient sync'
Thanks for your help. It seems everything is in sync, but I still get the same compiling errors. ~/chromium3/src(trunk) $ git pull Already up-to-date. ~/chromium3/src(trunk) $ tools/sync-webkit-git.py Desired revision: r50487. Already on correct revision. ~/chromium3/src(trunk) $ gclient sync found .git directory; skipping src running '/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python src/build/gyp_chromium' in '/Users/samuel/chromium3' Updating projects from gyp files... running '/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python src/build/win/clobber_generated_headers.py' in '/Users/samuel/chromium3' running '/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python src/build/mac/clobber_generated_headers.py' in '/Users/samuel/chromium3' ~/chromium3/src(trunk) And when i got to a different directory trying to use git to get Webkit code, I get this error possible repository corruption on the remote side, not sure if these 2 are related. git clone git://git.webkit.org/WebKit.git . Initialized empty Git repository in /Users/samuel/Webkit/.git/ remote: error: failed to unpack compressed delta at offset 486539223 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: error: failed to read object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 at offset 486539219 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: fatal: object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed On Tue, Nov 3, 2009 at 8:20 PM, Evan Martin e...@chromium.org wrote: It has been working fine for me. Is it possible you have the wrong version of WebKit? What does tools/sync-webkit-git.py say? On Tue, Nov 3, 2009 at 6:46 PM, n179911 n179...@gmail.com wrote: Thanks. Kenneth, I fixed the ENABLE_3D_CANVAS redefined error. But I still get the following compilation error: In file included from /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../bindings/v8/DerivedSourcesAllInOne.cpp:65: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:40: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Tue, Nov 3, 2009 at 6:40 PM, n179911 n179...@gmail.com wrote: Thanks Kenneth. I tried this. But I get I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources/i386 -I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources -c /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/DerivedSources/Debug/webkit/HTMLElementFactory.cpp -o /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/Objects-normal/i386/HTMLElementFactory.o command-line: error: ENABLE_3D_CANVAS redefined command-line: error: this is the location of the previous definition command-line: error: this is the location of the previous definition and also: /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:49: error: no matching function for call to 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, int)' ../bindings/v8/ScriptCallStack.h:58: note: candidates are: WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments, unsigned int, WebCore::String, int) ../bindings/v8/ScriptCallStack.h:46: note: WebCore::ScriptCallStack::ScriptCallStack(const WebCore::ScriptCallStack) On Mon, Nov 2, 2009 at 10:38 PM, Kenneth Russell k...@chromium.org wrote: On Mon, Nov 2, 2009 at 10:27 PM, n179911 n179...@gmail.com wrote: Hi, I have tried syncing up chromium HEAD by doing this (since i use git for chromium and webkit). $ git pull (update chromium) $ gclient sync $ tools/sync-webkit-git.py (update webkit) But i got the following errors when I compile it. It appears the method 'CanvasRenderingContext3D::attachShader' is called with the wrong number of parameters. Does anyone know how to fix it? Thank you.
[chromium-dev] Re: Compiling error after I did a 'gclient sync'
On Tue, Nov 3, 2009 at 8:36 PM, n179911 n179...@gmail.com wrote: And when i got to a different directory trying to use git to get Webkit code, I get this error possible repository corruption on the remote side, not sure if these 2 are related. git clone git://git.webkit.org/WebKit.git . Initialized empty Git repository in /Users/samuel/Webkit/.git/ remote: error: failed to unpack compressed delta at offset 486539223 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: error: failed to read object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 at offset 486539219 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: fatal: object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed I wonder if you've ran out of disk space. If not, it is probably worth bringing that up on webkit-dev. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Compiling error after I did a 'gclient sync'
On Tue, Nov 3, 2009 at 8:39 PM, Evan Martin e...@chromium.org wrote: On Tue, Nov 3, 2009 at 8:36 PM, n179911 n179...@gmail.com wrote: And when i got to a different directory trying to use git to get Webkit code, I get this error possible repository corruption on the remote side, not sure if these 2 are related. git clone git://git.webkit.org/WebKit.git . Initialized empty Git repository in /Users/samuel/Webkit/.git/ remote: error: failed to unpack compressed delta at offset 486539223 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: error: failed to read object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 at offset 486539219 from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack remote: fatal: object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed I wonder if you've ran out of disk space. If not, it is probably worth bringing that up on webkit-dev. Thanks. But I have 27GB left. --~--~-~--~~~---~--~~ 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: How much RAM needed to get past linking? (Linux)
Hi, I've experienced the same problem before. As far as I tested, building Release mode binary (hammer --mode=Release) would require much less memory than Debug binary. If it's sufficient for you, you may want to try this. Thanks, Yuta On Tue, Nov 3, 2009 at 6:01 PM, 黒鉄章 ak...@yayakoshi.net wrote: Hi Adam/Evan/Pawell, thanks for the useful feedback. This gold sounds good, although if I want to install it on Fedora I note that there isn't package (yet) and the src/build/install-build-deps.sh script is apparently only for Ubuntu 8/9, so I will have to go the 'hard way' mentioned on the LinuxFasterBuilding wiki. (Accordingly I don't think it should be specified as a chromium build requirement until most distributions are supported.) By the sounds of it 2Gb of physical memory really is the minimum, and I better get upgrade my hardware. Technically my motherboard should support that (as a max) but I failed to boot the other day when trying to add different-sized DIMM. I will track down two identical 1Gb DIMMs and put them in. Reporting back later, Akira On Tue, Nov 3, 2009 at 3:02 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: If you have less than 1 GB of RAM, I wouldn't even try to link the biggest binaries. 2 GB of RAM should be sufficient, although with 4 and more it's better. And you will notice the change after switching to gold. On Mon, Nov 2, 2009 at 18:58, Adam Langley a...@chromium.org wrote: On Fri, Oct 30, 2009 at 9:10 AM, Akira ak...@yayakoshi.net wrote: I was building on Fedora 10 and was able to compile but the linking stage (see below) consumes more and more memory- the 500Mb of remaining memory, then another 1Gb of swap- before being killed. Are you using gold? http://code.google.com/p/chromium/wiki/LinuxFasterBuilds#Linking_using_gold If not, that's the single biggest win for linking size and speed. I know Evan builds on his laptop using gold, but I don't know the exact specs. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way
Do the trybots build the release version? Because I had a build break last week that passed the 3 basic trybots, but failed to compile on the release buildbots because of a missing include which was apparently pulled in through other means in the debug version. -atw On Tue, Nov 3, 2009 at 7:30 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Tue, Nov 3, 2009 at 7:46 PM, Kenneth Russell k...@chromium.org wrote: On Tue, Nov 3, 2009 at 6:05 PM, John Abd-El-Malek j...@chromium.org wrote: But this means that the person didn't use the trybot. I think we need to be harsher on people who commit with changes that didn't complete or failed on the trybot. They need to have a really good reason as to why they want to try their change on the buildbot and possibly delay many other engineers. For the record, I completely support immediate backouts of changes that break the tree, and agree that all changes should go through the trybots -- but sometimes the trybots don't work. I don't know anything about the architectural differences between the trybots and buildbots, but from recent experience I think the trybots are trying to do incremental builds, when that isn't guaranteed to always work. even the bots on the main waterfall do incremental builds (except some of them). If the change requires a clobber, use gcl try CHANGENAME -c to run the code on the try bot doing a full build. If it's just a matter of throwing hardware at the problem of making the trybots nearly 100% reliable I think we should make that investment. -Ken On Tue, Nov 3, 2009 at 3:11 PM, Ben Goodger (Google) b...@chromium.org wrote: The most common case of 5 minute bustage fix is file was omitted from changelist. -Ben On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Reverting a change, the fast way
Yeah, does anyone know why SVN does that? It seems like it could easily inspect the revision to see what files changed, and then only merge those files :-/ depot_tools/revert also works this way. Should we remove depot_tools/revert, or re-implement it on top of drover? -Darin On Tue, Nov 3, 2009 at 4:34 PM, Anthony LaForge lafo...@google.com wrote: Drover is actually an order of magnitude faster than a standard svn merge/reverse, merge since it only affects the files that are involved with the CL (as opposed to trying to descending the entire trunk). A normal merge would take in the space of 8 minutes on my box (which required an existing working copy). In the case of drover, the same merge/revert can be performed in approximately 30 seconds to 1 minute (w/ out a pre existing working copy). Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Nov 3, 2009 at 2:01 PM, Eric Seidel esei...@chromium.org wrote: Interesting. WebKit has similar functionality as: bugzilla-tool rollout 12345 We've found that git reverts are at least an order of magnitude faster than SVN reverse merges. I wonder what bugzilla-tool/drover can learn from one another. -eric On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain nsylv...@chromium.org wrote: Hi One of the goal of the Green Tree Task Force was to make reverting a change easy and fast. This is really important to keep the tree green and open. The old saying is Revert now, think later... If a change broke the build and the fix would take more than 1 or 2 minutes to be committed, or if the committer is not answering pings, then the change needs to be reverted asap. Turns out it was already easy and fast with Anthony's drover tool. If you have depot_tools in your path, just type : drover --revert where is the revision you want to revert. Since the tool creates temporary files, I suggest you go to the temp directory first. It should take only a few seconds, even for a really big change. You don't even need to have a chrome checkout on your machine. This tool should work on all platforms. You need svn 1.5 or above in your path. If you run into any issues with the tool, please let me know. Thank you, Nicolas If the tool does not work, you can revert the long way by doing: cd src/ svn update svn merge -c - . (the dot at the end of the previous line is important) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Layout tests can now be run on Win 7
Great to see this! Thanks, -Darin On Tue, Nov 3, 2009 at 6:31 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I have just checked in a new set of baselines that should allow you to run the layout tests on Win 7 as well as Vista and XP. For those of you playing along at home, this means that if you have a baseline that is windows 7 specific, or is the same across 7, Vista, and XP, check it into src/webkit/data/platform/chromium-win. If you have a baseline that is specific to Vista or is the same on Vista and XP, check it into src/webkit/data/platform/chromium-win-vista, and if you have an XP-specific baseline, check it into src/webkit/data/platform/chromium-win-xp. 99.9% of all of your baselines will be generic, so you can probably just check it into chromium-win and let me fix diffs when they crop up down the road. Also, if you have a test that only fails on Win 7, you can specify WIN-7 in test_expectations.txt. But, I wouldn't expect any of those. Cheers, and any questions or problems on this should go to me, -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Layout tests can now be run on Win 7
Great stuff! Thanks for working on this. No longer do I have to add --nocheck-sys-deps to all of my commands. fetch me a cofee no fetch me a coffee --nocheck-sys-deps ok. :DG On Tue, Nov 3, 2009 at 6:31 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I have just checked in a new set of baselines that should allow you to run the layout tests on Win 7 as well as Vista and XP. For those of you playing along at home, this means that if you have a baseline that is windows 7 specific, or is the same across 7, Vista, and XP, check it into src/webkit/data/platform/chromium-win. If you have a baseline that is specific to Vista or is the same on Vista and XP, check it into src/webkit/data/platform/chromium-win-vista, and if you have an XP-specific baseline, check it into src/webkit/data/platform/chromium-win-xp. 99.9% of all of your baselines will be generic, so you can probably just check it into chromium-win and let me fix diffs when they crop up down the road. Also, if you have a test that only fails on Win 7, you can specify WIN-7 in test_expectations.txt. But, I wouldn't expect any of those. Cheers, and any questions or problems on this should go to me, -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to using threads in the browser process
Very cool! Could this idea be done in the render process? We try to keep the media processing code off the render thread but we've been bitten using cached MessageLoops which have been destructed (usually on tab close when the render thread goes away). On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.org wrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread 4: I've removed all the special casing and always made the objects in the browser code behave in one way. If you're writing a unit test and need to use an object that goes to a file thread (where before it would proceed synchronously), you just need: ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); foo-StartAsyncTaskOnFileThread(); MessageLoop::current()-RunAllPending(); There are plenty of examples now in the tests. *Gotchas* -PostTask will silently delete a task if the thread doesn't exist. This is done to avoid having all the code that uses it have special cases if the target thread exists or not, and to make Valgrind happy. As usual, the task for DeleteSoon/ReleaseSoon doesn't do anything in its destructor, so this won't cause unexpected behavior with them. But be wary of posted Task objects which have non-trivial destructors or smart pointers as members. I'm still on the fence about this, since while the latter is theoretical now, it could lead to problems in the future. I might change it so that the tasks are not deleted when I'm ready for more Valgrind fun. If you absolutely must know if a task was posted or not, you can check the return value of PostTask
[chromium-dev] Singleton, LazyInstance, and testability
I encountered another problem related to Singletons in unit tests. PluginService is a Singleton, and it listens to extensions notifications. In one of my tests when I was using the extensions notifications the PluginService crashed because I passed NULL as the Extension* - because the listener I was testing didn't even read that value, but PluginService did (it was unexpected). I tried to fix the issue by adding a shadow AtExitManager to the test which instantiated PluginService (resource_dispatcher_host_unittest.cc). And then another crash appeared on Windows: NPAPI::PluginList is a LazyInstance, which means that the shadow AtExitManager destroyed it, but it didn't re-instantiate itself the next time it was used. Is there a big difference between a Singleton and LazyInstance? I was thinking about making NPAPI::PluginList a Singleton instead... By the way, I have a more general fix in the queue (an unwanted Singleton detector). If you're interested, please star http://crbug.com/12710. It seems that the most recent gtest (1.4.0) has necessary support. --~--~-~--~~~---~--~~ 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: Singleton, LazyInstance, and testability
Why don't you pass an Extension instance? It seems like you are violating the contract of that notification by not doing so, and even if you solve this problem, other similar problems would be likely to happen again in the future. - a On Tue, Nov 3, 2009 at 11:49 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I encountered another problem related to Singletons in unit tests. PluginService is a Singleton, and it listens to extensions notifications. In one of my tests when I was using the extensions notifications the PluginService crashed because I passed NULL as the Extension* - because the listener I was testing didn't even read that value, but PluginService did (it was unexpected). I tried to fix the issue by adding a shadow AtExitManager to the test which instantiated PluginService (resource_dispatcher_host_unittest.cc). And then another crash appeared on Windows: NPAPI::PluginList is a LazyInstance, which means that the shadow AtExitManager destroyed it, but it didn't re-instantiate itself the next time it was used. Is there a big difference between a Singleton and LazyInstance? I was thinking about making NPAPI::PluginList a Singleton instead... By the way, I have a more general fix in the queue (an unwanted Singleton detector). If you're interested, please star http://crbug.com/12710. It seems that the most recent gtest (1.4.0) has necessary support. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
