On Aug 20, 5:40 pm, Dean McNamee wrote:
> This thread is massive. Having been the one who wrote the majority of
> the Omnibox code on Linux, I can promise you that this debate has
> already happened about 15 times previously. I'm not sure there is any
> more information here, we've already deci
What exactly are you trying to do?
On Thu, Aug 20, 2009 at 11:27 PM, n179911 wrote:
>
> Hi,
>
> From this chromium document,
>
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/multi-process-architecture
>
> Browser has an IO thread which receives messages from each Render
You want to look at the MessageLoop and possibly RenderViewHost.
Adam
On Thu, Aug 20, 2009 at 11:27 PM, n179911 wrote:
>
> Hi,
>
> From this chromium document,
> http://sites.google.com/a/chromium.org/dev/developers/design-documents/multi-process-architecture
>
> Browser has an IO thread which
Hi,
>From this chromium document,
http://sites.google.com/a/chromium.org/dev/developers/design-documents/multi-process-architecture
Browser has an IO thread which receives messages from each Renderer
process and dispatch them to Browser Process.
But when I look at the code , the IOThread class
It would be easier to recommend advice if I could see / review the code.
Can you provide a link to the in-progress CL?
-Darin
On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote:
>
>
> On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote:
>
>> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wro
On Thu, Aug 20, 2009 at 7:17 PM, Marshall
Greenblatt wrote:
> Out of curiosity, what work remains to support a 64bit build on Windows?
V8 does not yet compile in 64-bit mode on Windows. We have focused on
making the 64-bit version of V8 work on Linux and Mac at first. We
are currently working o
I guess this is the command to checkout Webkit source using git
But I don't see 'git-chrome/src/DEPS' file when I checkout chromium source
using git.
And what is the purpose of the command 'git svn find-rev'? Isn't the code is
already checkout using the 'git checkout -b $i' command?
And what is t
We have focused on making the 64-bit version complete, so there is
still some performance tuning to be done. Currently, the performance
of the 64-bit version is pretty close to the performance of the 32-bit
version when Chrome 2 stable was released.
-- Mads
On Thu, Aug 20, 2009 at 7:26 PM, Evan
On Thu, Aug 20, 2009 at 10:58 PM, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote:
>
>> Speaking of which, how do we capture the idea of passing ownership of a
>> pointer? If this were in WebCore, I'd use WTF::OwnPtr/PassOwnPtr to signify
>> that I was passing off owners
On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote:
>
>
> On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote:
>
>> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote:
>>
>>> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson wrote:
>>>
I have to admit I'm somewhat fuzzy on the motivation behin
On Thu, Aug 20, 2009 at 9:46 PM, Drew Wilson wrote:
> Speaking of which, how do we capture the idea of passing ownership of a
> pointer? If this were in WebCore, I'd use WTF::OwnPtr/PassOwnPtr to signify
> that I was passing off ownership of a pointer. Is there an analogous idiom
> in the Chrome
On Thu, Aug 20, 2009 at 10:53 PM, Ryosuke Niwa wrote:
> In particular, *you need to resubmit all patches you've submitted in the
> past 17 hours.*
>
Clarity: That means "all patches you attached to bugs". Patches that you
committed to the SVN repository don't need to be re-landed; the SVN
repos
In particular, *you need to resubmit all patches you've submitted in the
past 17 hours.*
Ryosuke
On Thu, Aug 20, 2009 at 10:48 PM, Adam Barth wrote:
>
> In case not everyone follows webkit-dev, bugs.webkit.org has lost the
> last 17 hours of activity:
>
> https://lists.webkit.org/pipermail/webk
In case not everyone follows webkit-dev, bugs.webkit.org has lost the
last 17 hours of activity:
https://lists.webkit.org/pipermail/webkit-dev/2009-August/009535.html
If you made a change to WebKit's Bugzilla in the last 17 hours, you
should probably do it again.
Adam
--~--~-~--~~-
Looking at the example you gavehow about:
EXPECT_EQ(kExpected.InMilliseconds(), foo.InMilliseconds());
Is that really that painful to write?
...and you could get all the microseconds to compare if you wanted to via
...InMicroseconds().
I suspect you don't really want absolute comparisons at
On Thu, Aug 20, 2009 at 7:13 PM, Andrew Scherkus wrote:
> I know microseconds aren't a very user-friendly format, but for unit tests
> and DCHECKs I'm more interested in whether the assertion is simply true.
> Perhaps I'm lazy but I'd prefer:
> EXPECT_EQ(kExpected, foo);
> error: Value of: foo
>
awesome. thanks!
2009/8/20 Evan Stade
> ported:
> http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818&updated=Glossary
>
> -- Evan Stade
>
>
>
> On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong
> (王重傑) wrote:
> > Nope. Feel free to move it, or I'll do it tomorrow.
> > -A
> >
> > On Thu
On Thu, Aug 20, 2009 at 8:39 PM, Darin Fisher wrote:
> On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote:
>
>> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson wrote:
>>
>>> I have to admit I'm somewhat fuzzy on the motivation behind our webkit
>>> API, although I gather the plan is to eventually
ported:
http://code.google.com/p/chromium/wiki/Glossary?ts=1250828818&updated=Glossary
-- Evan Stade
On Thu, Aug 20, 2009 at 8:57 PM, Albert J. Wong
(王重傑) wrote:
> Nope. Feel free to move it, or I'll do it tomorrow.
> -A
>
> On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade wrote:
>>
>> is there
Nope. Feel free to move it, or I'll do it tomorrow.
-A
On Thu, Aug 20, 2009 at 7:41 PM, Evan Stade wrote:
> is there a reason this isn't on the wiki?
>
> -- Evan Stade
>
>
>
> On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong
> (王重傑) wrote:
> > I started a page to collect the common terms/lingo
Hi,
I have followed the steps here in checking out chromium using git and the
rest of the code using svn:
http://code.google.com/p/chromium/wiki/UsingGit
I am able to build successfully locally on my MacOSX.
>From this thread, it looks like I can use git to checkout WebKit source
(instead of SVN
I noticed that you haven't done any WebKit merges yet? ;-)
Kidding aside, this effort is about translating webkit/glue into a stable
API that we can live with. We built webkit/glue originally to shield the
majority of the Chromium code base from the constant churn of WebCore. It
helped reduce the
On Thu, Aug 20, 2009 at 8:37 PM, Darin Fisher wrote:
> On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson wrote:
>
>> I have to admit I'm somewhat fuzzy on the motivation behind our webkit
>> API, although I gather the plan is to eventually upstream it to WebKit, and
>> use it as our abstraction layer
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson wrote:
> I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
> although I gather the plan is to eventually upstream it to WebKit, and use
> it as our abstraction layer instead of using the (more mutable) WebCore
> APIs? Or is th
+1 Clobbering the primary selection when clicking in the url bar is
@#$ annoying and very un-Linux like.
On Thu, Aug 20, 2009 at 14:02, JT Olds wrote:
>
> Firefox on Linux doesn't. Wasn't one of the main goals to make the
> application feel native to the operating system? I could care less
> abo
I think the code path in this case is (as you suggest):
glue code creates vector of WebMessagePortChannels out of an array of
MessagePortChannels.
this gets passed down into WebMessagePortChannel.postMessage()
WebMessagePortChannelImpl.postMessage() sends it to the right thread,
then converts
On Aug 20, 3:14 pm, Peter Kasting wrote:
> I chatted with several people just now about the Mac behavior, since unlike
> Linux, there aren't "blowing away my clipboard" concerns and it seemed to me
> that the argument above was compelling. According to pinkerton, the
> behavior in Chrome Mac is
is there a reason this isn't on the wiki?
-- Evan Stade
On Thu, Aug 20, 2009 at 11:31 AM, Albert J. Wong
(王重傑) wrote:
> I started a page to collect the common terms/lingo that gets used in
> chromium development. It's pretty anemic right now, but if a term keeps
> needing to get reexplained t
On Aug 20, 2:56 pm, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth wrote:
> > On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
> > > 1) on a single click to the omnibox, the cursor should be placed. The
> > > contents of the omnibox should not be selected.
>
> > We violate
> I would plead strongly with the Mac people to change their decision;
I suspect this would not end well. Mac users in general strongly favor
consistency with the platform over saving a click or two. We've been
trained over the years to single-click to place the cursor, double-
click to highlight
On Aug 20, 3:18 pm, Evan Martin wrote:
> On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
> > 4) Any time content in the box is selected, it should be in the
> > PRIMARY buffer.
>
> This would mean that when you type a URL, the autocomplete will
> clobber your selection.
> Are you ok with that?
On Aug 20, 2:56 pm, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth wrote:
> > On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
> > > 1) on a single click to the omnibox, the cursor should be placed. The
> > > contents of the omnibox should not be selected.
>
> > We violate t
I know microseconds aren't a very user-friendly format, but for unit tests
and DCHECKs I'm more interested in whether the assertion is simply true.
Perhaps I'm lazy but I'd prefer:
EXPECT_EQ(kExpected, foo);
error: Value of: foo
Actual: 2100
Expected: kExpected
Which is: 2200
...over:
E
Andrew wants to be able to do:
DCHECK_EQ(expected_time_delta, time_delta);
This can't be done without operator<< support.
On Thu, Aug 20, 2009 at 6:46 PM, Jim Roskind wrote:
> +1 for Peter's suggestion.
> TimeDelta has an internal accuracy of microseconds. What
> resolution/scaling do you wan
+1 for Peter's suggestion.
TimeDelta has an internal accuracy of microseconds. What resolution/scaling
do you want to print in a check? Sometimes it is minutes, sometimes
seconds, sometimes milliseconds, I doubt that we want microseconds :-/.
Explicit conversion as suggested doesn't seem that pa
On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson wrote:
> I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
> although I gather the plan is to eventually upstream it to WebKit, and use
> it as our abstraction layer instead of using the (more mutable) WebCore
> APIs? Or is th
On Thu, Aug 20, 2009 at 9:17 PM, Drew Wilson wrote:
> I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
> although I gather the plan is to eventually upstream it to WebKit, and use
> it as our abstraction layer instead of using the (more mutable) WebCore
> APIs? Or is the
I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
although I gather the plan is to eventually upstream it to WebKit, and use
it as our abstraction layer instead of using the (more mutable) WebCore
APIs? Or is there another motivation?
I'm just curious because it seems like
This thread is massive. Having been the one who wrote the majority of
the Omnibox code on Linux, I can promise you that this debate has
already happened about 15 times previously. I'm not sure there is any
more information here, we've already decided how we want things to
work.
On Thu, Aug 20,
Oops, didn't see how long the thread was :-).
On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walker wrote:
> Safari does not. Single click sets the text caret where you click.
>
> On Thu, Aug 20, 2009 at 4:56 PM, Peter Kasting wrote:
>> On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth wrote:
>>>
>>> On Thu
Safari does not. Single click sets the text caret where you click.
On Thu, Aug 20, 2009 at 4:56 PM, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth wrote:
>>
>> On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
>> > 1) on a single click to the omnibox, the cursor should be pl
On Thu, Aug 20, 2009 at 16:02, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus wrote:
>
>> Any opposition to globally declaring an operator<< ostream overload for
>> TimeDelta in base/time.h?
>>
>
> This will pull the stream headers into all files that use time.h. Is that
On Thu, Aug 20, 2009 at 3:33 PM, Andrew Scherkus wrote:
> Any opposition to globally declaring an operator<< ostream overload for
> TimeDelta in base/time.h?
>
This will pull the stream headers into all files that use time.h. Is that
going to bloat any code or cost compile time?
Is there anothe
Andrew Scherkus wrote:
> Any opposition to globally declaring an operator<< ostream overload for
> TimeDelta in base/time.h?
> According to style guide it needs to be fully justified, but it'd be nice to
> use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas.
I think this is fine.
Mark
--~--~-
I left this comment on http://code.google.com/p/chromium/issues/detail?id=19879
but I'll reiterate here.
FWIW, the results from this statistics gathering really doesn't say
anything about how
many users are surprised or unhappy about how the selection interacts
with the
selection buffer in Linux.
Any opposition to globally declaring an operator<< ostream overload for
TimeDelta in base/time.h?
According to style guide it needs to be fully justified, but it'd be nice to
use DCHECK_xx/EXEPCT_xx/ASSERT_xx with TimeDeltas.
Andrew
--~--~-~--~~~---~--~~
Chromium D
Awesome, thanks guys.
On Thu, Aug 20, 2009 at 4:20 PM, James Hawkins wrote:
> On Thu, Aug 20, 2009 at 3:14 PM, Peter Kasting wrote:
>> On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins
>> wrote:
>>>
>>> Will you accept opinions of the opposite? I love our current behavior
>>> and can't stand havin
On Thu, Aug 20, 2009 at 3:14 PM, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins
> wrote:
>>
>> Will you accept opinions of the opposite? I love our current behavior
>> and can't stand having to triple-click in Firefox.
>>
>> Consider the following cases.
>>
>> a) The user
One other note: the other Mac browsers in question (Safari, Camino,
etc) provide a page proxy icon which can be clicked to select the
entire contents of the url bar (in case you don't want to use cmd-L).
Mac Chromium is lacking that as we put the favicon in the tab not the
url bar, though we have
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins wrote:
> Will you accept opinions of the opposite? I love our current behavior
> and can't stand having to triple-click in Firefox.
>
> Consider the following cases.
>
> a) The user is trying to completely change the contents of the omnibox.
> - Cur
jhawkins++
I am with James on this one. Would save numerous clicks.
-- Mohamed Mansour
On Thu, Aug 20, 2009 at 5:57 PM, James Hawkins wrote:
>
> On Thu, Aug 20, 2009 at 2:41 PM, Peter Kasting
> wrote:
> > On Thu, Aug 20, 2009 at 2:02 PM, JT Olds wrote:
> >>
> >> None of the below Linux browser
> Will you accept opinions of the opposite? I love our current behavior
> and can't stand having to triple-click in Firefox.
Sure. I totally expect that if the majority wants it the way it is
then that's how it will be. :) No hard feelings.
>
> Consider the following cases.
>
> a) The user is t
Since everyone has their own opinions on this, isn't it best to just
match platform standards? On Linux, that seems to be triple-click.
On Thu, Aug 20, 2009 at 2:57 PM, James Hawkins wrote:
>
> On Thu, Aug 20, 2009 at 2:41 PM, Peter Kasting wrote:
>> On Thu, Aug 20, 2009 at 2:02 PM, JT Olds wrot
On Thu, Aug 20, 2009 at 2:41 PM, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 2:02 PM, JT Olds wrote:
>>
>> None of the below Linux browsers select the entire URL on the first click:
>> Firefox
>> Epiphany
>> Seamonkey
>> Galeon
>> Midori
>> Konqueror
>> Dillo
>>
>> In fact, I can't find a sing
On Thu, Aug 20, 2009 at 2:48 PM, JT Olds wrote:
>> A lot of webpages highlight stuff without your input (with
>> javascript). Are you sure you want a webpage to be able to clobber
>> your clipboard?
>
> So, I've only really been talking about the Omnibox.
> So, actually, I mean, the more I think a
oops, forgot reply all
On Thu, Aug 20, 2009 at 3:48 PM, JT Olds wrote:
>> A lot of webpages highlight stuff without your input (with
>> javascript). Are you sure you want a webpage to be able to clobber
>> your clipboard?
>
> So, I've only really been talking about the Omnibox.
> So, actually, I
On Thu, Aug 20, 2009 at 2:42 PM, Evan Stade wrote:
> A lot of webpages highlight stuff without your input (with
> javascript). Are you sure you want a webpage to be able to clobber
> your clipboard?
In general, this is a bad idea. Imagine a web page selecting this text
cat /etc/passwd | netcat
On Thu, Aug 20, 2009 at 2:24 PM, JT Olds wrote:
> Oh yikes. Hmm. No, I'm not okay with that.
>
> Three solutions
> 1) don't select the autocomplete. Do it like Firefox (autocompletions
> are in the dropdown, don't mess with what the user is typing)
The entire omnibox hinges on this behavioral d
On Thu, Aug 20, 2009 at 2:30 PM, Viet-Trung Luu wrote:
> The observant will note that these same browsers (on Mac, at least)
> allow you to select everything by clicking on the border of the location
> bar.
That's pretty cool! The target area is kind of tiny though...
Adam
--~--~-~--~-
On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
>
> So, history of this discussion:
> http://code.google.com/p/chromium/issues/detail?id=19508
> http://code.google.com/p/chromium/issues/detail?id=19648#c15
>
> Basically, I feel that if the attempt is to make Chromium feel like a
> native applica
>> 3) make this be the one exception. I still guess I expect ^L to
>> clobber my selection.
>
> The behavior that Dan implemented is this "make an exception" one --
> with the addition that single-clicking the omnibox also doesn't
> clobber.
>
> ...whoa, the Firefox behavior is even stranger than
On Thu, Aug 20, 2009 at 2:02 PM, JT Olds wrote:
> None of the below Linux browsers select the entire URL on the first click:
> Firefox
> Epiphany
> Seamonkey
> Galeon
> Midori
> Konqueror
> Dillo
>
> In fact, I can't find a single browser that does what you claim on Linux.
I am on record (
http
On Thu, Aug 20, 2009 at 2:24 PM, JT Olds wrote:
> 1) don't select the autocomplete. Do it like Firefox (autocompletions
> are in the dropdown, don't mess with what the user is typing)
Non-starter.
> 2) select the autocomplete, but in a way that's clearly different from
> normal selection (like,
The observant will note that these same browsers (on Mac, at least)
allow you to select everything by clicking on the border of the location
bar.
Mike Pinkerton wrote:
> Safari, Camino, and Mac Chromium place the cursor on a single click.
>
> On Thu, Aug 20, 2009 at 4:56 PM, Peter Kasting wrot
On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
> 4) Any time content in the box is selected, it should be in the
> PRIMARY buffer.
This would mean that when you type a URL, the autocomplete will
clobber your selection.
Are you ok with that?
--~--~-~--~~~---~--~
Oh yikes. Hmm. No, I'm not okay with that.
Three solutions
1) don't select the autocomplete. Do it like Firefox (autocompletions
are in the dropdown, don't mess with what the user is typing)
2) select the autocomplete, but in a way that's clearly different from
normal selection (like, have the au
Safari, Camino, and Mac Chromium place the cursor on a single click.
On Thu, Aug 20, 2009 at 4:56 PM, Peter Kasting wrote:
> On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth wrote:
>>
>> On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
>> > 1) on a single click to the omnibox, the cursor should be p
Firefox on Linux doesn't. Wasn't one of the main goals to make the
application feel native to the operating system? I could care less
about Windows or OSX focus and selection behavior.
None of the below Linux browsers select the entire URL on the first click:
Firefox
Epiphany
Seamonkey
Galeon
Mid
On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth wrote:
> On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
> > 1) on a single click to the omnibox, the cursor should be placed. The
> > contents of the omnibox should not be selected.
>
> We violate this convention on Windows too.
Yep, and so does ev
On Thu, Aug 20, 2009 at 12:07 PM, JT Olds wrote:
> 1) on a single click to the omnibox, the cursor should be placed. The
> contents of the omnibox should not be selected.
We violate this convention on Windows too. We do this because the
most common reason to click in the omnibox is to replace i
On Wed, Aug 19, 2009 at 9:54 PM, Huan Ren wrote:
>
>
> On Thu, Aug 6, 2009 at 1:06 PM, John Abd-El-Malek wrote:
>
>> This is very cool, but I ran into a few problems when I tried to run it:
>> a:\chrome2\src\chrome>tools\test\smoketests.py --tests=ui
>>
>> >> You must have your local path of trun
So, history of this discussion:
http://code.google.com/p/chromium/issues/detail?id=19508
http://code.google.com/p/chromium/issues/detail?id=19648#c15
Basically, I feel that if the attempt is to make Chromium feel like a
native application on all operating systems, the standards of that
operating
On Thu, Aug 20, 2009 at 11:33 AM, Jeremy Orlow wrote:
> Are you positive it's the per-file presubmit checks slowing things down?
> If so, maybe the presubmit stuff needs to be re-factored? Right now, it
> does each presubmit check one by one (and each check might read in the
> files). If it we
On Thu, Aug 20, 2009 at 11:40 AM, Marc-Antoine Ruel wrote:
> The commit checks is bound to 2x appengine latency (hint hint) since
> it parses try job results registered on rietveld and looks up
> chromium-status to know if the tree is open.
>
I wasn't talking about commit check, just upload (alth
On Thu, Aug 20, 2009 at 9:38 AM, n179911 wrote:
> I don't want the renderer process to die. I just want it 'locked' so
> that i can dump out information of the page (DOM, CSS) of the page.
> And I want the page unchange during the information dumping.
SIGSTOP doesn't kill the process, it just, we
On Thu, Aug 20, 2009 at 1:17 PM, Marshall
Greenblatt wrote:
> Out of curiosity, what work remains to support a 64bit build on Windows?
Motivation.
Probably also some sandbox fixes.
A gyp update.
M--A
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chrom
That is just a utility program, no?
On Thu, Aug 20, 2009 at 12:06 PM, Michael Moss wrote:
> Anybody working on 64-bit breakpad yet?
>
> src/breakpad/linux/minidump-2-core.cc:303:2: error: #error "This code
> has not been ported to your platform yet"
>
> I guess worst case, I can turn this off fo
On Thu, Aug 20, 2009 at 12:12 PM, Adam Langley wrote:
> I think 64-bit breakpad is done. Are you sure you're up to date? (and
> using the files from breakpad/linux?)
Sorry Dean pointed out that it was minidump-2-core. That should be
removed really. It doesn't work.
AGL
--~--~-~--~~
On Thu, Aug 20, 2009 at 12:06 PM, Michael Moss wrote:
> Anybody working on 64-bit breakpad yet?
>
> src/breakpad/linux/minidump-2-core.cc:303:2: error: #error "This code
> has not been ported to your platform yet"
>
> I guess worst case, I can turn this off for official 64-bit builds right now.
I
Anybody working on 64-bit breakpad yet?
src/breakpad/linux/minidump-2-core.cc:303:2: error: #error "This code
has not been ported to your platform yet"
I guess worst case, I can turn this off for official 64-bit builds right now.
Michael
On Thu, Aug 20, 2009 at 8:44 AM, Dean McNamee wrote:
>
>
Out of curiosity, what work remains to support a 64bit build on Windows?
On Thu, Aug 20, 2009 at 11:44 AM, Dean McNamee wrote:
>
> The v8 team did some amazing work this quarter building a working
> 64-bit port. After a handful of changes on the Chromium side, I've
> had Chromium Linux building
On Thu, Aug 20, 2009 at 6:31 AM, Evan Martin wrote:
> kill -STOP
> ?
I don't want the renderer process to die. I just want it 'locked' so
that i can dump out information of the page (DOM, CSS) of the page.
And I want the page unchange during the information dumping.
Sorry for not making my ques
The commit checks is bound to 2x appengine latency (hint hint) since
it parses try job results registered on rietveld and looks up
chromium-status to know if the tree is open.
presubmit_support.py still reads the whole file. It's *supposed* to
only load the new lines from the diff. I just assumed
Hi Andrew.
This has been fixed.
- Bev
On Wed, Aug 19, 2009 at 2:00 PM, Andrew Scherkus wrote:
> Every so often I like peeking at the test coverage stats, but I'm seeing
> 403 Forbidden at the moment: http://build.chromium.org/buildbot/coverage/
>
> Andrew
>
> >
>
--~--~-~--~~--
On Thu, Aug 20, 2009 at 11:15 AM, Ben Laurie wrote:
> On Thu, Aug 20, 2009 at 2:26 PM, Evan Martin wrote:
>> On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurie wrote:
>>> I'd be happy to do that. When I do, there's something that's already
>>> puzzling me, and that's OS_POSIX.
>>>
>>> I don't have a copy
On Thu, Aug 20, 2009 at 7:32 PM, Evan Martin wrote:
> On Thu, Aug 20, 2009 at 11:15 AM, Ben Laurie wrote:
>> On Thu, Aug 20, 2009 at 2:26 PM, Evan Martin wrote:
>>> On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurie wrote:
I'd be happy to do that. When I do, there's something that's already
puz
Are you positive it's the per-file presubmit checks slowing things down? If
so, maybe the presubmit stuff needs to be re-factored? Right now, it does
each presubmit check one by one (and each check might read in the files).
If it were changed to go file by file (reading fully into memory, runnin
I started a page to collect the common terms/lingo that gets used in
chromium development. It's pretty anemic right now, but if a term keeps
needing to get reexplained to people, please add it to the page. Also, if
anyone has a better idea for formatting, please feel free to change it. I
tried me
Great! Please try to add this to an existing check, or do it in a way that
doesn't involve the files being read once for each presubmit check, as the
presubmit step is already too slow.
On Thu, Aug 20, 2009 at 11:16 AM, Paweł Hajdan Jr.
wrote:
> Cool! Thanks so much. I'm going to write a presubm
Cool! Thanks so much. I'm going to write a presubmit check for that.
On Thu, Aug 20, 2009 at 11:12, John Abd-El-Malek wrote:
> Including files like render_messages.h and automation_messages.h from other
> header files is unnecessary and slows down the build (adds about ~100K lines
> of headers t
On Thu, Aug 20, 2009 at 2:26 PM, Evan Martin wrote:
> On Thu, Aug 20, 2009 at 3:06 AM, Ben Laurie wrote:
>> I'd be happy to do that. When I do, there's something that's already
>> puzzling me, and that's OS_POSIX.
>>
>> I don't have a copy of the POSIX standard, at least not a recent one,
>> so it
Including files like render_messages.h and automation_messages.h from other
header files is unnecessary and slows down the build (adds about ~100K lines
of headers to each cc file). Last time I removed all these occurrences, it
improved the build time by 15%. Looks like a few more crept in now, s
On Thu, Aug 20, 2009 at 10:26 AM, Evan Martin wrote:
>
> How does the v8 perf look like relative to 32-bit?
>
> I guess we ought to set up perf bots for startup/memory/etc. as well;
> I'd expect we improve on those metrics on our 64-bit buildbots due to
> more sharing with other apps on the system
How does the v8 perf look like relative to 32-bit?
I guess we ought to set up perf bots for startup/memory/etc. as well;
I'd expect we improve on those metrics on our 64-bit buildbots due to
more sharing with other apps on the system.
On Thu, Aug 20, 2009 at 8:44 AM, Dean McNamee wrote:
>
> The
Awesome! :)
FYI, video will not work out of the box since the ffmpeg binaries we have
are 32-bit. We need a bit of work to shift them over. If you see bugs
there, it's expected.
-Albert
On Thu, Aug 20, 2009 at 10:18 AM, Michael Moss wrote:
>
> Awesome! I'll work on the buildbot, then start m
w00t, nice job.
On Thu, Aug 20, 2009 at 8:44 AM, Dean McNamee wrote:
>
> The v8 team did some amazing work this quarter building a working
> 64-bit port. After a handful of changes on the Chromium side, I've
> had Chromium Linux building on 64-bit for the last few weeks. I
> believe mmoss or to
Awesome! I'll work on the buildbot, then start marking all the
ia32-libs bugs invalid :)
On Thu, Aug 20, 2009 at 8:44 AM, Dean McNamee wrote:
>
> The v8 team did some amazing work this quarter building a working
> 64-bit port. After a handful of changes on the Chromium side, I've
> had Chromium
The v8 team did some amazing work this quarter building a working
64-bit port. After a handful of changes on the Chromium side, I've
had Chromium Linux building on 64-bit for the last few weeks. I
believe mmoss or tony is going to get a buildbot running, and working
on packaging.
You can follow
Sometimes all you have to do is send an email saying that you give up
in order to find a solution. ;-)
I did a little more poking around last night and found one test
(SpellCheckTest.SpellCheckText, which only recently landed) that was
contributing 300-400MB of private bytes to the address space
We do boot with /3GB on the bots already. I talked with M-A about
/LARGEADDRESSAWARE and apparently in the past we've had issues with it
and the sandbox and v8, so we're not using it anywhere. It's possible
that those issues have been addressed since the last time M-A looked
into this, but verif
1 - 100 of 118 matches
Mail list logo
