[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. wrote: > I

[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 wa

[chromium-dev] Re: Reverting a change, the fast way

Can there be a way to apply this to a local tree only so that you can revert then revert the revert quickly locally so you can figure out why your change broke? -Ben On Tue, Nov 3, 2009 at 2:53 PM, Nicolas Sylvain wrote: > Hi > > One of the goal of the Green Tree Task Force was to make reverting

[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

[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 wrote: > > Hi all, > > I have just checked in a new set of baseline

[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 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

[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, 2

[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

[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, 黒鉄章 wrote: > Hi Adam/Evan/

[chromium-dev] Re: Compiling error after I did a 'gclient sync'

On Tue, Nov 3, 2009 at 8:39 PM, Evan Martin wrote: > On Tue, Nov 3, 2009 at 8:36 PM, n179911 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. >> >>

[chromium-dev] Re: Compiling error after I did a 'gclient sync'

On Tue, Nov 3, 2009 at 8:36 PM, n179911 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

[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 __

[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

[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

[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 wrote: > Sure. I was floating the idea first before doing any work, but I'll > just grab an existing text run and hack

[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 wrote: > > Thanks. Kenneth, > > I fixed the "ENABLE_3D_CANVAS" redefined error. But I still get the > following compilation erro

[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 yo

[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 back

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

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 wrote: > +1 > > On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman wrote: >> >> I'm

[chromium-dev] Re: Webkit Gyp Changes

Is it possible to name these differently? Especially when editing in xcode it can be kind of annoying having multiple project files named the same thing. On Tue, Nov 3, 2009 at 2:40 PM, Yaar Schnitman wrote: > A few changes have been made around the webkit.gyp in our ongoing effort to > upstrea

[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 wrote: > On Tue, Nov 3, 2009 at 6:05 PM, John Abd-El-Malek > 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. T

[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 wrote: > > Coul

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

+1 On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman 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

[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 wrote: > scrolling jank in gmail > http://crbug.com/25741 > > Linus > > > On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth wrote: > >> >> On We

[chromium-dev] Re: FYI: Linux interactive_ui_tests a bit hosed

FYI: http://codereview.chromium.org/341078 Linux interactive tests have finally gone green. On Mon, Nov 2, 2009 at 10:08 AM, John Abd-El-Malek wrote: > (CCing today's sheriffs + Jay) > > I was thinking of marking the bug to P1, except that won't change muc

[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 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. P

[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 wrote: > 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 > answerin

[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).

[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 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 t

[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_part

[chromium-dev] Re: Lifehacker browser tests say Chrome uses the most memory

On Tue, Nov 3, 2009 at 12:55 PM, John Munro 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 methodo

[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 confi

[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.bu

[chromium-dev] Re: Compiling error after I did a 'gclient sync'

Thanks. Chase. I tried this, I get the same error. error: no matching function for call to 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*&, WebCore::CanvasShader*&)' ../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are: void WebCore::CanvasRenderingCo

[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 s

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

On Tue, Nov 3, 2009 at 4:03 PM, Eric Seidel 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? > I looked into this, and implemented a proof of concept, but ditche

[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 wrote: > I've heard this suggested a few times (not just in this thread) - is there > an advantage t

[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

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

On Tue, Nov 3, 2009 at 9:16 PM, John Abd-El-Malek wrote: > > > On Tue, Nov 3, 2009 at 6:08 PM, Ben Goodger (Google) wrote: > >> 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. >>

[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 wo

[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 wrote: > On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai wrote: >> >> To be clear, here's the proposed policy: Any change that would close the >> tree can be re

[chromium-dev] Re: Perf tests to run?

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

[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 w

[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 wrote: > +1. I found Aquamacs weird/annoying. Carbon Emacs seemed a lot > better. [I c

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

On Tue, Nov 3, 2009 at 6:08 PM, Ben Goodger (Google) wrote: > 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

[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) wrote: > 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

[chromium-dev] Re: Reverting a change, the fast way

On Tue, Nov 3, 2009 at 3:01 PM, Nico Weber 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.

[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 wrote: > I'v

[chromium-dev] Re: Changes to using threads in the browser process

On Tue, Nov 3, 2009 at 12:03 AM, Paweł Hajdan Jr. wrote: > On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek 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 targ

[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.

[chromium-dev] Re: Which editor do you recommend on Mac OS X?

+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 wrote: > > There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. > Recommended. > > http://www.emacswiki.org/emacs/E

[chromium-dev] Re: Inheritance in gyp configurations

On Mon, Nov 2, 2009 at 3:37 PM, Bradley Nelson wrote: > 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

[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 wrote: >

[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 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 ev

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

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. -Ben On Tue, Nov 3, 2009 at 7:05 PM, John Abd-El-Malek wrote:

[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, a

[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 wrote: > In my case, git didn't quite figure out that my refactoring (splitting a > file into two) should also link

[chromium-dev] Re: Which editor do you recommend on Mac OS X?

On Tue, Nov 3, 2009 at 10:12 AM, Paweł Hajdan Jr. wrote: > On Tue, Nov 3, 2009 at 19:08, Drew Wilson 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 y

[chromium-dev] Re: Changes to using threads in the browser process

On Tue, Nov 3, 2009 at 6:01 AM, Mike Pinkerton 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 plac

[chromium-dev] Re: refactoring and git

On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin 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 somet

[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 engineer

[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 wrote: > I've been using Aquamacs, although I don't like the fact tha

[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

[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 wrote: > On Tue, Nov 3, 2009 at 8:06 AM, Dan Kegel 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

[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 (-C) to make git more aggressive about matching up files to histories, but it turns out that passing those flags al

[chromium-dev] Re: Which editor do you recommend on Mac OS X?

2009/11/3 Paweł Hajdan Jr. : > 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 launchin

[chromium-dev] Re: Perf tests to run?

On Tue, Nov 3, 2009 at 7:30 AM, Anton Muhin 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 tryserver

[chromium-dev] Re: compile fails on Ubuntu 9.04

On Mon, Nov 2, 2009 at 20:29, Mark Mentovai wrote: > If you don't have that file, start looking at how things were checked out, > and maybe try a "gclient sync --force". Indeed, running client correctly fixed the issue. I was trying to be too "smart" to save some time, but it didn't work (I cop

[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 d

[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. wrote: > Recently I started working more and more on Mac OS X,

[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

[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,

[chromium-dev] Re: Hard Refresh UI Option

On Tue, Nov 3, 2009 at 4:21 AM, Meok 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

[chromium-dev] Webkit Gyp Changes

A few changes have been made around the webkit.gyp in our ongoing effort to upstream the Webkit api: 1. The WebKit API target has been split out of src/webkit/webkit.gyp and into src/webkit/api/WebKit.gyp (new), in preparation for its eventual move upstream to src/third_party/WebKit/WebKit/chromiu

[chromium-dev] Re: Which editor do you recommend on Mac OS X?

On Tue, Nov 3, 2009 at 19:08, Drew Wilson 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 t

[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way

On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai 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 chang

[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 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 ev

[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 wrote: > Are there best practices we can follow that will help the scripts be > more accurate?  For example, if w

[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 wrote

[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

[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 'gc

[chromium-dev] Re: refactoring and git

On Tue, Nov 3, 2009 at 16:58, Evan Martin 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-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 coll

[chromium-dev] Re: How much RAM needed to get past linking? (Linux)

On Tue, Nov 3, 2009 at 1:01 AM, 黒鉄章 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 g

[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

[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 wrote: > Over the las

[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-c

[chromium-dev] Re: Chromium security UI choices

On Tue, Nov 3, 2009 at 12:54 AM, Mike Hearn 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 top

[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 Linu

[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

[chromium-dev] Re: Changes to using threads in the browser process

On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek 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 > sta