On Aug 24, 3:58 am, Peter Kasting pkast...@google.com wrote:
We already have this since web pages take over things like ctrl-w and ctrl-f
(and we wouldn't want to change that since in many cases it's important that
they do so).
AFAICT, at least Alt+Shift+T and Alt+D seem not to be preventable
I'm looking at the about:memory page and am wondering how useful is the
private VM field? Would it be just as good to have a total VM instead? The
reason I ask is because private VM doesn't map easily to Linux where private
pages can be shared becuase of copy-on-write.
Also, in general, how
phajdan: Feel free to add a link at the top of the waterfall. Maybe beside
perf at the top left corner.
You just need to edit
http://src.chromium.org/viewvc/chrome/trunk/tools/buildbot/master.chromium/public_html/announce.html?view=markup
Hello,
On Mon, Aug 24, 2009 at 22:48, Anand Mistryakmis...@gmail.com wrote:
Also, in general, how useful is knowing VM size considering it's not
necessarily corollated with actual memory usage?
I chatted with a few people when doing doing my memory work. Based on
this, I think we should
I'll let Paul Wicks chime in on his own experience, but we've been
able to successfully integrate the Mac OS X spell checker with the
Chromium infrastructure, including introducing platform support for a
spelling window. Paul is also in the process of adding OCMock to our
build, which we
On Mon, Aug 24, 2009 at 6:18 AM, Anand Mistryakmis...@gmail.com wrote:
I'm looking at the about:memory page and am wondering how useful is the
private VM field? Would it be just as good to have a total VM instead? The
reason I ask is because private VM doesn't map easily to Linux where
On Mon, Aug 24, 2009 at 6:18 AM, Anand Mistry akmis...@gmail.com wrote:
I'm looking at the about:memory page and am wondering how useful is the
private VM field? Would it be just as good to have a total VM instead? The
reason I ask is because private VM doesn't map easily to Linux where
On Mon, Aug 24, 2009 at 8:13 AM, Anand Mistry akmis...@gmail.com wrote:
On Mon, Aug 24, 2009 at 11:42 PM, Joel Stanley j...@jms.id.au wrote:
Hello,
On Mon, Aug 24, 2009 at 22:48, Anand Mistryakmis...@gmail.com wrote:
Also, in general, how useful is knowing VM size considering it's not
On Mon, Aug 24, 2009 at 11:42 PM, Joel Stanley j...@jms.id.au wrote:
Hello,
On Mon, Aug 24, 2009 at 22:48, Anand Mistryakmis...@gmail.com wrote:
Also, in general, how useful is knowing VM size considering it's not
necessarily corollated with actual memory usage?
I chatted with a few
On Mon, Aug 24, 2009 at 8:13 AM, Anand Mistryakmis...@gmail.com wrote:
Also, by not trying to display the exact same columns as windows does,
hopefully there will be fewer uninformed comparisons of the numbers
between platforms.
Which bring about another question, how consistent should we be
On Mon, Aug 24, 2009 at 10:08 AM, Jeremy Moskovichjer...@chromium.org wrote:
* Due to some technical limitations with the FF libraries, we need to load
them in a separate process. It also doesn't seem like a good idea to run
code out of an arbitrary library in the main process.
On Fri, Aug 21, 2009 at 7:15 PM, Evan Martin e...@chromium.org wrote:
What's the motivation?
* Due to some technical limitations with the FF libraries, we need to load
them in a separate process. It also doesn't seem like a good idea to run
code out of an arbitrary library in the main
On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting pkast...@chromium.orgwrote:
On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow jor...@chromium.orgwrote:
1) We don't have notes on why tests are failing. = Why not annotate
I'm with Matt on this one but if there are serious objections I'll let this
die
http://codereview.chromium.org/173234/show
On Fri, Aug 21, 2009 at 10:27 AM, Matt Perry mpcompl...@chromium.orgwrote:
Defining operator is fine. Other types do this:
On Sun, Aug 23, 2009 at 11:14 PM, zeniko zen...@gmail.com wrote:
Then again: Is accessibility one of the goals for Chrome at all? Or is
it just not tested for for lack of manpower? As it currently stands,
it can get quite frustrating to use without a mouse (double accesskeys
in menus, no
We have that operator defined for a bunch of random types (gfx::Rect
comes to mind) so I think if there's a compilation overheard it should
be fixed in other places as well.
On Mon, Aug 24, 2009 at 10:26 AM, Andrew Scherkusscher...@chromium.org wrote:
I'm with Matt on this one but if there are
From
http://dev.chromium.org/developers/design-documents/multi-process-architecture,
Resoruce dispatcher Host should have the list of all the channel opened with
each Renderer Process. But when I look at the resource_dispatcher_host.h, I
dont' find any attribute of ResourceDispatcherHost which
On Mon, Aug 24, 2009 at 10:37 AM, Pam Greene p...@chromium.org wrote:
On Sat, Aug 22, 2009 at 4:29 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sat, Aug 22, 2009 at 4:00 PM, Peter Kasting pkast...@chromium.orgwrote:
On Fri, Aug 21, 2009 at 8:07 PM, Jeremy Orlow jor...@chromium.orgwrote:
There's one host per renderer, so there's no need for any list.
On Mon, Aug 24, 2009 at 11:22 AM, hap 497 hap...@gmail.com wrote:
From
http://dev.chromium.org/developers/design-documents/multi-process-architecture,
Resoruce dispatcher Host should have the list of all the channel opened with
Thanks. But the picture in the document shows there is only 1
ResourceDispatcherHost and there are 2 Renderer Processes:
http://dev.chromium.org/developers/design-documents/multi-process-architecture
And the ResourceDispatcherHost has access to both Channels for each Renderer
Process.
On Mon,
There's one ResourceDispatcherHost for all renderers (but there is one
ResourceMessageFilter per renderer process).
That graph shows a connection between the filter (ResourceMessageFilter) and
the ResourceDispatcherHost, but it's the former that has a pointer to the
latter. RDH doesn't have a
Indeed. The diagram could certainly be improved. If you are
artistically inclined, I hope you'll consider improving the diagram
after you gain a solid understanding of how the components fit
together.
Adam
On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote:
Thanks. But the
On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote:
Thanks. But the picture in the document shows there is only 1
ResourceDispatcherHost and there are 2 Renderer Processes:
http://dev.chromium.org/developers/design-documents/multi-process-architecture
And the
On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.org wrote:
On Mon, Aug 24, 2009 at 12:49 PM, hap 497hap...@gmail.com wrote:
Thanks. But the picture in the document shows there is only 1
ResourceDispatcherHost and there are 2 Renderer Processes:
On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafaio...@chromium.org wrote:
The end goal is to be in a state where we have near zero failing tests that
are not for unimplemented features. And new failures from the merge get
addressed within a week.
Once we're at that point, would this new
Would it be possible/reasonable to use distcc plus a farm of
cross-compiler machines to let you do faster self-hosted builds? It's
not the right solution, but in the past I've found it to sometimes
be an easier path to take in the short term while you're working on
fixing all the little
On Mon, Aug 24, 2009 at 1:52 PM, David Levinle...@google.com wrote:
On Mon, Aug 24, 2009 at 1:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafaio...@chromium.org wrote:
The end goal is to be in a state where we have near zero failing tests
that
On Mon, Aug 24, 2009 at 1:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Mon, Aug 24, 2009 at 11:37 AM, Ojan Vafaio...@chromium.org wrote:
The end goal is to be in a state where we have near zero failing tests
that
are not for unimplemented features. And new failures from the merge get
That still requires you to link locally, and I don't think we have any
ARM machines with enough memory to do that.
On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess sh...@chromium.org wrote:
Would it be possible/reasonable to use distcc plus a farm of
cross-compiler machines to let you do faster
Even with gold?
On Mon, Aug 24, 2009 at 5:14 PM, Dean McNamee de...@chromium.org wrote:
That still requires you to link locally, and I don't think we have any
ARM machines with enough memory to do that.
On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess sh...@chromium.org wrote:
Would it be
Oops...sorry for the misinformation...should have double checked before I
said anything. :-)
On Mon, Aug 24, 2009 at 1:26 PM, John Abd-El-Malek j...@chromium.org wrote:
On Mon, Aug 24, 2009 at 1:06 PM, Brett Wilson bre...@chromium.org wrote:
On Mon, Aug 24, 2009 at 12:49 PM, hap
On Aug 24, 10:14 am, Evan Martin e...@chromium.org wrote:
On Mon, Aug 24, 2009 at 10:08 AM, Jeremy Moskovichjer...@chromium.org wrote:
* Due to some technical limitations with the FF libraries, we need to load
them in a separate process. It also doesn't seem like a good idea to run
code
On Aug 24, 7:42 pm, Peter Kasting pkast...@google.com wrote:
Please file bugs on all these.
Filed http://code.google.com/p/chromium/issues/detail?id=20086 ,
http://code.google.com/p/chromium/issues/detail?id=20160 ,
http://code.google.com/p/chromium/issues/detail?id=20164 ,
On Sat, Aug 22, 2009 at 6:18 PM, Evan Martine...@chromium.org wrote:
On Fri, Aug 21, 2009 at 11:05 PM, zenikozen...@gmail.com wrote:
If you e.g. use Alt+F for Chrome, you break quick access to
Wikipedia's in-page search box.
It's already the case that if a page grabs a key it overrides the
On Mon, Aug 24, 2009 at 1:53 PM, Scott Hesssh...@chromium.org wrote:
Would it be possible/reasonable to use distcc plus a farm of
cross-compiler machines to let you do faster self-hosted builds? It's
not the right solution, but in the past I've found it to sometimes
be an easier path to take
hi, all
While compiling chrome, I get an error :error C2065:
'LOG_CHANNEL_PREFIXFATAL' : undeclared identifier.
I locate this error at some codes just like:
static CommandLine* ForCurrentProcessMutable() {
---DCHECK(current_process_commandline_);
return current_process_commandline_;
A first version of the layout test flakiness dashboard is up.
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html
Some of the key features:
- updates roughly as quickly as the bots have run the tests (no
post-processing, stdio parsing or
On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafai o...@chromium.org wrote:
A first version of the layout test flakiness dashboard is up.
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html
AWESOME O RAMA
Seriously, this has been critically needed,
Great work, dude. Seriously good stuff. I'll be digging through this tomorrow.
Now, how do I change the theme on this thing? ;P
:DG
On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafaio...@chromium.org wrote:
A first version of the layout test flakiness dashboard is up.
39 matches
Mail list logo