I "wrote" most of this code in the sense that I took the old garbage
collector design and refactored it to make isolated worlds possible.
I don't understand the MessagePorts lifetime issues in detail,
however.
Adam
On Fri, Nov 20, 2009 at 7:02 PM, Drew Wilson wrote:
> So I looked into the probl
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
This happened several times (at least 6) throughout the day, alternating
with successful passes.
It seems bad (as in an actual error, rather than a FLAKY_ test) if it
actually takes more than 5 seconds for a new tab, warm or otherwise.
I filed http://crbug.com/28448 as a perf regression -- not exa
On Fri, Nov 20, 2009 at 03:06:21PM -0800, James Robinson wrote:
> On Fri, Nov 20, 2009 at 3:01 PM, Jacob Mandelson wrote:
>
> > On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote:
> > > On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson > >wrote:
> > >
> > > > http://codereview.chromium.
On Fri, Nov 20, 2009 at 3:06 PM, James Robinson 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 I'll let you guys
On Fri, Nov 20, 2009 at 6:00 PM, Mark Mentovai 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
> don't cons
On Fri, Nov 20, 2009 at 3:01 PM, Jacob Mandelson wrote:
> On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote:
> > On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson >wrote:
> >
> > > http://codereview.chromium.org/201100/show
> > >
> >
> > Yes, that caused a large subsequent discussion a
On Fri, Nov 20, 2009 at 3:01 PM, Jacob Mandelson wrote:
> 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 rules. Let me know
On Fri, Nov 20, 2009 at 02:55:17PM -0800, Peter Kasting wrote:
> On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson wrote:
>
> > 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 s
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
don't consider either of these advantages compelling. I agree that
it's over
On Fri, Nov 20, 2009 at 2:53 PM, Jacob Mandelson wrote:
> 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 assumed you'd already c
On Fri, Nov 20, 2009 at 02:47:56PM -0800, Peter Kasting wrote:
> On Fri, Nov 20, 2009 at 1:31 PM, James Robinson 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 statement th
On Fri, Nov 20, 2009 at 1:31 PM, James Robinson wrote:
> On Fri, Nov 20, 2009 at 12:59 PM, Peter Kasting wrote:
>
>> For a concrete example, take AutocompleteEditController, which is declared
>> in autocomplete_edit.h. This is an abstract base class that names several
>> different methods. 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 re
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 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 unexpected
> flaky
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.
Q
On Fri, Nov 20, 2009 at 4:31 PM, James Robinson 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 for the class. In
>
> 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 descript
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
unco
On Fri, Nov 20, 2009 at 12:59 PM, Peter Kasting wrote:
> On Fri, Nov 20, 2009 at 12:42 PM, Mark Mentovai 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, tak
On Fri, Nov 20, 2009 at 12:42 PM, Mark Mentovai 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 autocomplete_edi
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 wa
On Fri, Nov 20, 2009 at 21:05, Evan Martin 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 decided to not
On Fri, Nov 20, 2009 at 12:05:55PM -0800, Evan Martin wrote:
> On Fri, Nov 20, 2009 at 4:23 AM, rahul 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 dele
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 wrote:
> +msb
>
> but I think your depot_tools is old.
>
> Also your question
On Fri, Nov 20, 2009 at 4:23 AM, rahul 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.
>
> How
+msb
but I think your depot_tools is old.
Also your question is probably better directed at chromium-os-dev@ (well,
next time)
M-A
On Fri, Nov 20, 2009 at 10:08 AM, Mr. Gecko wrote:
> When syncing chromium with --deps="unix,chromeos", it gives me the
> error below
> Traceback (most recent cal
What class do you get this error on?
On Fri, Nov 20, 2009 at 4:23 AM, rahul wrote:
> Hi,
>
> 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 -
Hi,
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.
However, this error intrigued me. I saw through the code
Chromium must be use an easy platform as Launchpad :O
Has a hundred of languages is a win factor.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Chromium must be use an easy platform as Launchpad :O
Has a hundred of languages is a win factor.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
When syncing chromium with --deps="unix,chromeos", it gives me the
error below
Traceback (most recent call last):
File "/bin/gclient.py", line 1681, in
result = Main(sys.argv)
File "/bin/gclient.py", line 1676, in Main
return DispatchCommand(command, options, args)
File "/bin/gclient
My talk covers much of this, but I'll be sure to look back through
the feedback from this thread and re-write it before I give it again
in December.
Here are the slides from the talk I gave in Sydney (which was
specifically directed at answering questions about WebKit which had
come up for Maps a
Jeremy noted yet another omission: I also clear the memory backing the
LocalStorage sqlite DBs in the browser.
PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
2009/11/10 Roberto :
> Hello,
>
> As you know, Chromium is a huge project, only checking out the code
> and compiling it is a very costly task.
> Some time ago I was browsing the Code, compiled it and also made some
> changes in order to patch some bug ( the one about drag & dropping a
> items in M
On Thu, Nov 19, 2009 at 5:58 PM, Aaron Boodman wrote:
> We're going to have to explain again when we actually remove
> toolstrips, because some people won't have seen the first announcement
> (understandably):
>
> http://www.guyvider.com/2009/11/i-love-chrome-extensions.html
It wouldn't be too ha
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 p
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 y
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 wrote:
> On Thu, Nov 19, 2009 at 2:17 PM, Evan Martin wrote:
>>
>> A
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 wrote:
> We'
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 wr
41 matches
Mail list logo
