Not that you're missing anything, but...
You can't overload C++ methods by return value. Thus, you can't just make a
string16 version of "std::wstring TreeNode::GetTitle()", the call used to
return a bookmark title. So you'll probably have to change a bunch of call
sites as part of your "add ove
x27;d guess that these aren't running either.
>
> Erik
>
> On Mon, Jan 4, 2010 at 10:00 AM, John Grabowski wrote:
>
>> At this time, just the tests which run successfully on all 3 platforms.
>> The list from chrome_tests.gypi:
>>
>>
;t be right, can it?
>
> On Mon, Jan 4, 2010 at 11:53 AM, Scott Violet wrote:
> > Are these numbers generated by running all tests, eg unit, ui,
> > browser, interactive .. ?
> >
> > -Scott
> >
> > On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski
> wrote:
platforms
(interactive_ui_tests, browser_tests, courgette_tests).
ui_tests runs on 3 platforms but chokes on OSX when run instrumented; I need
to track down why.
jrg
On Mon, Jan 4, 2010 at 8:53 AM, Scott Violet wrote:
> Are these numbers generated by running all tests, eg unit, ui,
> brows
I had an OKR to get code coverage working on 3 platforms for Chromium unit
test bundles in Q409.
If you're in PST, I made it!
Dashboard (overview):
http://build.chromium.org/buildbot/perf/dashboard/coverage.html
Sample output for
Windows:
http://build.chromium.org/buildbot/coverage/xp-debug/35420
>
>
>> The default max procs per userid on 10.5.8 is 266. With ~20 Chromes and
>> 10 tabs each you're starting to get real close. Perhaps that's the real
>> problem?
>>
>
> That's a fair reasoning but then it should have been so all along. And I
> reach the same state even with 10 chrome instance
e?
>> >
>> > Look at /Library/Preferences/com.apple.TimeMachine.plist, how big is it?
>> > When you run chromebot, what do you use for profile dirs?
>> > TVL
>> >
>> >>
>> >> Kris
>> >>
>> >> On Wed, Dec
build Chrome successfully even if
> the 64-bit targets fail.
> Please let me know if you have any problems building the 64-bit Windows
> targets.
> Greg
>
> On Dec 9, 2009 10:28 PM, "John Grabowski" wrote:
>
> I saw this on Vista64 today as well. We don'
I saw this on Vista64 today as well. We don't have a Vista64 bot so it
wouldn't have made the tree red.
To fix, GYP_DEFINES='disable_nacl=1' gclient runhooks (in cygwin), then
build.
The right parties have been notified.
jrg
On Wed, Dec 9, 2009 at 2:00 PM, Steve VanDeBogart wrote:
> My window
Macs appear to support MADV_DONTNEED (at least they are doc'ed as such).
However, wtf/Platform.h seems to imply Apple uses mmap/munmap instead of
madvise for their tcmalloc fork.
The tcmalloc in third_party does not appear to have the mmap/munmap support
seen in WTF's tcmalloc, so our TCMalloc_Sy
On Wed, Oct 21, 2009 at 11:37 AM, Jeremy Orlow wrote:
> Why did you use the "internal nacl mailing list"?
To keep things unambiguous and try for immediate action for a build-ish
break. Only members can view list members for the public lists. I didn't
want to join those lists just to confirm m
I sent mail to the nacl team and got reassurances(at 1138AM) that they will
hit it asap. I didn't cc chromium-dev because I used the internal nacl
mailing list.
jrg
On Tue, Oct 20, 2009 at 12:15 PM, Scott Violet wrote:
>
> I want to say this bug has existed for around a week now. Is anyone
>
Daniel, I think our current behavior is correct; Mac apps in general don't
grab focus on launch when launched from the command line. if this is the
only problem, I'd be happy to add a hook for you. E.g. an
"---activate-on-launch" command line arg.
While we are talking, is there anything else bloc
jam: It's a good idea; we came to the same conclusion.
I implemented the about:ipc UI as part of our performance focus last week.
However, when I hooked it up, I noticed the logging itself was never fully
ported from Windows; it uses a cross-process waitable event, but
waitable_event_posix.cc isn'
Use --gdb with test shell.
jrg
On Mon, Aug 31, 2009 at 2:38 PM, Avi Drissman wrote:
> Quite a few of those issues are now moot...
>
> Anyway, I'm trying to debug TestShell. I'm starting it with
> --testshell-startup-dialog, and attaching, but GDB never catches breakpoints
> and the shell dies be
Startup of Chrome in gdb after a rebuild is now >10 seconds faster!
Excellent!
jrg
On Wed, Aug 5, 2009 at 12:32 PM, Mark Mentovai wrote:
>
> I just checked in r22506, which alters the structure of the
> application on disk on the Mac slightly. The entire program has moved
> into a dylib (fram
Sure! For Mac and Linux I expect things will be fine no matter what you
throw in.
jrg
On Wed, Aug 5, 2009 at 12:43 PM, Paweł Hajdan Jr.
wrote:
> Thanks. Can I just try adding browser_tests to the list and send you a CL
> if it works?
>
> On Tue, Aug 4, 2009 at 11:33, John Grab
No. You can find the list of unittest files run by coverage in chrome.gyp;
look at the end of chrome.gyp for the coverage target and list of
dependencies.
I will be spending time on coverage to expand this and fix other related
problems (e.g. no win coverage builder yet).
jrg
On Mon, Aug 3, 2009
We can do this.
The priority is hooking up windows coverage; Randall finished his end (weeks
ago) and I've mostly finished mine but I haven't hooked things up
yet. Next is tracking down the "add more unit tests and coverage goes down"
problem reported by the media guys.
Once we're hooked up and c
;
> http://build.chromium.org/buildbot/coverage/mac-debug/20426/CHROMIUM/chrome/browser/tabs/index.html
>
> Andrew
>
> On Thu, Jul 16, 2009 at 4:06 PM, John Grabowski wrote:
>
>> For starters, thanks for caring about coverage
>>
>> It is possible your c
For starters, thanks for caring about coverage
It is possible your checkin was timed poorly (didn't land in time for the
bot
start), but looking at the coverage scripts I don't see how that could happen.
I noticed you landed, then reverted, this CL the day before. My best guess
is that such a
I believe Brett intended to watch only src/base/.If so, he can change the
regexp to be more specific, such as '^base/.*'
For a quick test you can run the watchlist.py program with a filename to
find out what matches.
E.g. $DEPOT_PATH/watchlist.py base/foo.py -> prints out the
watchers for that
No, for 2 reasons.One, we [NSApp mainApplication] before turning on the
sandbox. (Yes, that's bad.)
Two, the essence of the problem is that no thread in the renderer ever does
a MessageLoopForUI or [NSRunLoop run].
In the longer term we want to remove all Cocoa from the renderer. But in
the short
Avi, this is cool enough that you should do a blog post about it once
landed.
jrg
On Wed, May 20, 2009 at 3:06 PM, Avi Drissman wrote:
> OK, this fixes just about everything important.
>
> Known issues:
> - Expose funkiness with 10.5. Since that's fixed in 10.6, that's unlikely
> to get attentio
I like the variant model as well. Perhaps I can rephrase my question.
How can we not klobber each other here? Should I land what I've got, and
you can adapt it once you implement variants? Or should I throw it away?
jrg
On Thu, Apr 2, 2009 at 2:29 PM, Mark Mentovai wrote:
>
> Steven Knight w
Stephen, I've added coverage to the Mac side (and part way there on the
Linux side). I have LGTMs but haven't landed it yet. It's similar to your
changes but not exactly the same.
http://codereview.chromium.org/56136
http://codereview.chromium.org/57083
How can we not klobber each other here?
j
Dean, sounds like you have the seeds of a qual script. Perhaps you could
itemize them into a form which sgk can use as a proof test before the next
switch-over (assuming this gets reverted)?
jrg
On Thu, Apr 2, 2009 at 6:48 AM, Dean McNamee wrote:
>
> I confirmed the debug build line has no -g.
te:
>
>>
>> On Sun, Mar 29, 2009 at 1:02 PM, Thomas Van Lenten
>> wrote:
>> > Most mac apps solve this by having the app exit as part of the upgrade
>> > process, this way a new copy is launched w/ the new resources.
>>
>> yes, but this is the problem
>
>
> How will in-place updating work on the Mac and Linux?
>
To be frank, we haven't solved this problem on Mac.
Right now we're doing an rsync to klobber on update, which is fine for
pre-dogfood. E.g. our "normal" Mac crash rate far exceeds any possible
crashes caused by version mismatching in
Hi Andrew.
For the example you provide, the image is of radio buttons. These appear
natively drawn, so a difference between Mac and PC is expected.
Similarly, hi will look different on Mac and PC.
I can't explain why Safari/Win and Chrome/Win have different ideas of native
radio buttons; I don't
For Mac Chrome multiprocess bringup a group of us had been throwing diffs
around. There were various reasons for this; e.g. hacks which can't be
landed without more work, changes that need to be upstreamed, and so on.
The last of these has landed with http://codereview.chromium.org/27108.
In sho
(We talked about a spreadsheet for this... anyone have a link?)
I'm following the chain from " on URL in browser" --> "tell renderer do
something". This currently ends at tabs; I'm removing stubs (TabContents,
TabContentsDelegate, ...) and bringing in the real thing.
jrg
On Mon, Feb 9, 2009 at 1
32 matches
Mail list logo
