That showed up when I fixed a bug upstream by custom constructing a
CGDataProvider. It seems that internally when you do that, CG uses that
obsolete function. It's nothing we're doing directly.
Does it still do that for 10.6?
I can ask Apple.
Avi
On Thu, Nov 19, 2009 at 10:44 PM, Nico Weber
Agreed, some people won't have seen the announcement. Wouldn't a
surefire way for them to see the change is if you do really remove
all toolstrips support?
Isn't this pre-beta time exactly when you do want all toolstrip based
extensions to break?
On Nov 19, 5:58 pm, Aaron Boodman
Google already seems to have a frontend/mechanism for translations of
search/product UIs. It might be nice to also have chrome translations
there.
http://www.google.com/transconsole
On Thu, Nov 19, 2009 at 16:31, Peter Kasting pkast...@google.com wrote:
On Thu, Nov 19, 2009 at 2:17 PM, Evan
Continuing with this issue,
I'm not sure if this is possible, but the builbots can copy the library
builds to a revision based directory structure before the final executable
is built. For example, the buildbot which compile webkit module, and copy
the webkit library to that directory.
So, when
Yeah, I think this would be the general idea. I'm not sure if these files
are currently archived though. If not, we'd have to see whether doing so
would noticeably slow down builds. Another problem is that gclient by
default syncs to ToT but ToT is often still being built by the bots. So
we'd
I didn't know they had a group, and I just decided to download the
binary of Chromium for chrome os. How would i update the depot_tools
anyway? For people trying to figure this out.
On Nov 20, 2:02 pm, Marc-Antoine Ruel mar...@chromium.org wrote:
+msb
but I think your depot_tools is old.
On Fri, Nov 20, 2009 at 12:05:55PM -0800, Evan Martin wrote:
On Fri, Nov 20, 2009 at 4:23 AM, rahul rahulsin...@gmail.com wrote:
I was trying to compile chromium today on Linux and I got this error.
This error occurred because of -Werror CFLAG set in the Makefile. I
remedied by writing a
On Fri, Nov 20, 2009 at 21:05, Evan Martin e...@chromium.org wrote:
Your analysis is correct. However, a virtual destructor is not needed
in the case where you never delete through the Base*. It turns out
for our codebase that is very common (due to lots of observer-like
patterns), so we
rahulsin...@gmail.com wrote:
I was trying to compile chromium today on Linux and I got this error.
This error occurred because of -Werror CFLAG set in the Makefile. I
remedied by writing a one-liner to delete all occurrences of -Werror
from CFLAGS in all Makefiles.
I happen to find this
On Fri, Nov 20, 2009 at 12:42 PM, Mark Mentovai m...@chromium.org wrote:
As Evan points out, there are some cases when it's not absolutely
necessary to have a base or interface class declare a virtual
destructor.
For a concrete example, take AutocompleteEditController, which is declared
in
On Fri, Nov 20, 2009 at 12:59 PM, Peter Kasting pkast...@google.com wrote:
On Fri, Nov 20, 2009 at 12:42 PM, Mark Mentovai m...@chromium.org wrote:
As Evan points out, there are some cases when it's not absolutely
necessary to have a base or interface class declare a virtual
destructor.
Do you have some idea how to get rid of the Singletons in base/time_win.cc?
They don't play very well with base::SystemMonitor, MessageLoop, and test
code.
Here's the scenario we're hitting right now (in browser_tests):
1. HighResolutionTimerManager is created to enable high resolution timer
Let me know if you notice any problems or have any suggestions for making
this more useful.
My lone suggestion is that page-load-time isn't accurate for all rows --
for example, the SunSpider row is measuring a benchmark number. It would be
nice to have a more accurate description, which
On Fri, Nov 20, 2009 at 4:31 PM, James Robinson jam...@google.com wrote:
What's the benefit of omitting the virtual destructor?
There really shouldn't be any -- if you have any virtual functions at all,
you already have a vtbl entry and you are just adding at most one entry to a
single vtbl
As of yesterday, we now retry any unexpected webkit failures. If they pass
the second time around, then we turn the bot orange and list the unexpected
flaky tests on the waterfall and at the end of the stdio of
run_webkit_test.py. If they fail the second time around we turn the bot red
as usual.
That's about the awesomest thing ever. I want this in my build.webkit.org!
-eric
On Fri, Nov 20, 2009 at 1:58 PM, Ojan Vafai o...@chromium.org wrote:
As of yesterday, we now retry any unexpected webkit failures. If they pass
the second time around, then we turn the bot orange and list the
A few changes to the layout test dashboard you might not be aware of if you
haven't used it in a while:
- You can see the expected results, actual results and diffs between the
two for a given test. This is especially useful when doing rebaseline code
reviews. The results shown are the
On Fri, Nov 20, 2009 at 1:31 PM, James Robinson jam...@google.com wrote:
On Fri, Nov 20, 2009 at 12:59 PM, Peter Kasting pkast...@google.comwrote:
For a concrete example, take AutocompleteEditController, which is declared
in autocomplete_edit.h. This is an abstract base class that names
On Fri, Nov 20, 2009 at 02:47:56PM -0800, Peter Kasting wrote:
On Fri, Nov 20, 2009 at 1:31 PM, James Robinson jam...@google.com wrote:
What's the benefit of omitting the virtual destructor?
I'm not trying to say it has massive benefits. I'm trying to make concrete
the rather abstract
On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson ja...@mandelson.orgwrote:
http://codereview.chromium.org/201100/show
Yes, that caused a large subsequent discussion at which it seemed like it
was determined that this was fine. I was surprised to hear this issue come
up again because I'd
On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote:
On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson ja...@mandelson.orgwrote:
http://codereview.chromium.org/201100/show
Yes, that caused a large subsequent discussion at which it seemed like it
was determined that this was
On Fri, Nov 20, 2009 at 3:01 PM, Jacob Mandelson ja...@mandelson.orgwrote:
I had the impression that at the end of the discussion you were still
against. Can you LG 201100 and 200106 ?
Done. I didn't bother looking at the patch, I assume you did the right
thing and followed relevant style
On Fri, Nov 20, 2009 at 3:01 PM, Jacob Mandelson ja...@mandelson.orgwrote:
On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote:
On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson ja...@mandelson.org
wrote:
http://codereview.chromium.org/201100/show
Yes, that caused a large
On Fri, Nov 20, 2009 at 6:00 PM, Mark Mentovai m...@chromium.org wrote:
James Robinson wrote:
What's the benefit of omitting the virtual destructor?
The benefit is that the destructor stays out of the vtable, which will
potentially reduce the vtable size and save a layer of indirection. I
On Fri, Nov 20, 2009 at 3:06 PM, James Robinson jam...@google.com wrote:
I'd also favor just going with virtual d'tors rather than protected
non-virtual ones. Protected virtual if you want to enforce that the object
is never deleted via a ptr to the base class.
I have no opinion here so
So I looked into the problem further - the issue was that calling close()
would still leave MessagePorts in a seemingly entangled state, which meant
that they would never be freed (turns out this caused some related issues on
the WebKit side related to delaying worker exit).
I updated the code so
26 matches
Mail list logo
