John, I'll try to reproduce the error as you suggested tomorrow. In
the mean time, I enlisted from another (much cleaner) Win7-x64 box and
was able to build successfully.
With respect to your question about the crash, please refer to my
initial post. Yes, gclient sync finished successfully.
On
The targets need a type so it knows what to build. I guess the different
generators are defaulting differently.
TVL
On Thu, Oct 1, 2009 at 2:45 PM, brymcq bmcqu...@gmail.com wrote:
I'm working on some code that uses the gyp build system. I find that
there are cases where I want to aggregate
I'm turning on the Mac pixel tests today. There's two parts to this. First
is the new expectations (http://codereview.chromium.org/249043) which just
adds IMAGE failures and won't affect anything. The second is telling the
bots to run the pixel tests (http://codereview.chromium.org/242099) and
A Fedora user recently reported that loading www.msnbc.com causes the
Oh snap! and unhappy mac, which I was able to reproduce.
The gory details are filed here:
http://code.google.com/p/chromium/issues/detail?id=23635
I hate to just open bugs and say go fix it!, at least not without
Automatically closing tree for net_unittests on Modules XP
http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP/builds/16575
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP
--= Automatically closing tree for net_unittests on Modules XP =--
Revision:
Hi
I want to explain that if you want me to scale, we need to follow some
rules. Sorry for being somewhat rude sometimes, it's usually not
deserved. In particular I apologize for the last thread to Jenn.
This is really about scalability. There is 100+ try server users. They
run a few try a day
That didn't turn out so bad. Pixel tests turned on as of r27839. The first
batch had failures
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4417/steps/webkit_tests/logs/stdio
but the second one had just a timeout:
Avi, thanks!
We should also keep an eye on the cycle times for the bots to see how much
more time they take with the pixel tests enabled.
TVL
On Fri, Oct 2, 2009 at 11:55 AM, Avi Drissman a...@google.com wrote:
That didn't turn out so bad. Pixel tests turned on as of r27839. The first
batch
The first step is usually to build a reduced test case. The MSNBC
home page is pretty complex. Try removing things until you find the
simplest thing that still exhibits the bug.
Adam
On Fri, Oct 2, 2009 at 7:32 AM, spotrh spo...@gmail.com wrote:
A Fedora user recently reported that loading
Latest Mac pixel test result is here:
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4420/steps/webkit_tests/logs/stdio
:
Regressions: Unexpected failures (2):
LayoutTests/svg/custom/js-late-marker-and-object-creation.svg = FAIL
I think that's a Release builder, and the tests are marked DEBUG, no?
Stephen
On Fri, Oct 2, 2009 at 12:34 PM, Avi Drissman a...@google.com wrote:
Latest Mac pixel test result is here:
The windows slaves are really having a hard time to compile, if it
fails, just try again :(
The command is or s/gcl/git/:
gcl try foo --bot win
In the short term, I'm disabling debug info on windows so they are at
least somewhat useful. I'll probably restart the master in the middle
of the day
Hi All,
I tried to build chromium by following the Windows Build Instructions
for the first time today :). But unfortunately after opening the
chrome.sln file when I build the project, I got three build errors.
All the build errors reported the same problem The binary is not a
valid windows
Also you should get webkit/tools/tests_shell.sln
-BradN
On Thu, Oct 1, 2009 at 10:45 AM, Peter Kasting pkast...@google.com wrote:
On Wed, Sep 30, 2009 at 4:06 AM, plafayette pierre.lafaye...@gmail.comwrote:
Is there a good, and less painful, way to extract test_shell into its
own project?
[from correct addr this time]
I've noticed that most animation frame rates in chrome are hard-coded
to values around 50 or 60. Certainly 50 or 60 is a good upper bound
and there's no point in going higher. But when the system is under
load or is just plain slow to begin with, having a value this
On Thu, Oct 1, 2009 at 10:02 PM, Bala balaraj...@gmail.com wrote:
Hi All,
I tried to build chromium by following the Windows Build Instructions
for the first time today :). But unfortunately after opening the
chrome.sln file when I build the project, I got three build errors.
All the build
On Fri, Oct 2, 2009 at 11:57 AM, Evan Stade est...@chromium.org wrote:
It would be nice to have some mechanism for telling the animation we
are done with the last update, ready for another.
AFAIK this is already what effectively happens. We try to fire the timer
rapidly, but if we get bogged
Automatically closing tree for net_unittests on Modules XP (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16419
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29
--= Automatically closing tree for net_unittests
Automatically closing tree for installer_util_unittests on XP Tests (dbg)(1)
http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests%20%28dbg%29%281%29/builds/13092
http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests%20%28dbg%29%281%29
--= Automatically closing
Automatically closing tree for installer_util_unittests on XP Tests
http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/12838
http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests
--= Automatically closing tree for installer_util_unittests on XP Tests
We try to fire the timer rapidly, but if we get bogged down, it just won't
fire until later; when it actually does fire, we update our state
based on how much time has really passed instead of how many times the timer
has triggered.
In this case, something is not working as expected (at
Stephen's right; if that doesn't fix things, let me know and I'll look at it.
-- Dirk
On Fri, Oct 2, 2009 at 9:59 AM, Stephen White senorbla...@chromium.org wrote:
I think that's a Release builder, and the tests are marked DEBUG, no?
Stephen
On Fri, Oct 2, 2009 at 12:34 PM, Avi Drissman
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote:
In this case, something is not working as expected (at least on
Linux), because when I test on the download shelf slide animation, the
number of AnimationProgressed calls is exactly what one would
calculate based on the
Automatically closing tree for compile on Linux Builder (Views dbg)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28Views%20dbg%29/builds/1701
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28Views%20dbg%29
--= Automatically closing
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote:
We try to fire the timer rapidly, but if we get bogged down, it just
won't fire until later; when it actually does fire, we update our state
based on how much time has really passed instead of how many times the
timer
On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek j...@chromium.org wrote:
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote:
We try to fire the timer rapidly, but if we get bogged down, it just
won't fire until later; when it actually does fire, we update our state
So I got a reply from Apple saying this should be fixed in Snow Leopard. Is
it closable? Certainly keep it in the suppression list until we upgrade the
bots.
Avi
On Wed, Sep 23, 2009 at 12:46 AM, Erik Kay erik...@chromium.org wrote:
I didn't say it would be easy. ;-) I also wouldn't be
On Fri, Oct 2, 2009 at 2:26 PM, Ben Laurie b...@chromium.org wrote:
zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather
than the more usual SOCK_STREAM? Before I trawl through code, does
anyone know why? This is a problem for the FreeBSD port: FreeBSD
doesn't support
On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote:
There was some concern that a renderer could use sendto on a
SOCK_DGRAM to direct packets to other destinations. However, when
created with socketpair, this isn't an issue as I recall.
Wait a minute. Idiot alert; I got that
zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather
than the more usual SOCK_STREAM? Before I trawl through code, does
anyone know why? This is a problem for the FreeBSD port: FreeBSD
doesn't support SOCK_SEQPACKET for unix domain sockets...
On Fri, Oct 2, 2009 at 2:30 PM, Adam Langley a...@chromium.org wrote:
On Fri, Oct 2, 2009 at 2:26 PM, Ben Laurie b...@chromium.org wrote:
zygote_host_linux.cc creates a socketpair using SOCK_SEQPACKET rather
than the more usual SOCK_STREAM? Before I trawl through code, does
anyone know why?
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote:
Why will it certainly not work? From what (little) I understand,
SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably
one could simulate that over SOCK_STREAM?
There are multiple, concurrent writers to the
BTW I think this API (and the associated registerContentHandler)
aren't that great... imagine a feed reader that wants to handle feed
types and feed protocol links... do they need to call these functions
one per protocol scheme and per feed content type (there are several),
showing a UI for each?
I'd say when we verify and remove the suppression, it's closable.
From a triage perspective, I think it's fine to lower priority, etc.
Erik
On Fri, Oct 2, 2009 at 2:11 PM, Avi Drissman a...@google.com wrote:
So I got a reply from Apple saying this should be fixed in Snow Leopard. Is
it
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote:
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote:
Why will it certainly not work? From what (little) I understand,
SOCK_SEQPACKET adds record boundaries to SOCK_STREAM ... presumably
one could simulate
I totally agree. I envision it being something much more like RSS feeds.
In my mind, it should always advertise itself to the browser and then the
browser should decide how to advertise it to the user. Requiring scripts to
initiate things seems silly to me.
Is this API even part of any
On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote:
Is this API even part of any standard? Maybe we should bring this up on
WhatWG?
The thread title is a clue that these are specced in HTML5 :)
PK
--~--~-~--~~~---~--~~
Chromium Developers
On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote:
On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote:
Is this API even part of any standard? Maybe we should bring this up on
WhatWG?
The thread title is a clue that these are specced in HTML5 :)
I had included the link to the specification in the design document:
http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler
-brad
On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote:
I totally agree. I envision it being something much more like RSS
On Fri, Oct 2, 2009 at 2:07 PM, Antoine Labour pi...@google.com wrote:
On Fri, Oct 2, 2009 at 2:02 PM, John Abd-El-Malek j...@chromium.org wrote:
On Fri, Oct 2, 2009 at 12:54 PM, Evan Stade est...@chromium.org wrote:
We try to fire the timer rapidly, but if we get bogged down, it just
On Fri, Oct 02, 2009 at 02:45:21PM -0700, Ben Laurie wrote:
On Fri, Oct 2, 2009 at 2:40 PM, Adam Langley a...@chromium.org wrote:
On Fri, Oct 2, 2009 at 2:37 PM, Ben Laurie b...@chromium.org wrote:
Why will it certainly not work? From what (little) I understand,
SOCK_SEQPACKET adds record
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote:
There are multiple, concurrent writers to the socket. If you make
assumptions about the kernel's behaviour, you might be able to come up
with a workable framing protocol, but it's much better to use the
correct
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote:
The Linux send(2) man page explicitly says the message is all-or-nothing,
I don't think so. It says:
If the message is too long to pass atomically through the underlying
protocol, the error EMSGSIZE is returned, and
On Fri, Oct 02, 2009 at 03:48:02PM -0700, Adam Langley wrote:
On Fri, Oct 2, 2009 at 3:44 PM, Jacob Mandelson ja...@mandelson.org wrote:
The Linux send(2) man page explicitly says the message is all-or-nothing,
I don't think so. It says:
If the message is too long to pass atomically
Automatically closing tree for compile on Chromium Builder
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder/builds/16572
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder
--= Automatically closing tree for compile on Chromium Builder =--
This relates somewhat to how we'd like people to install web applications.
For that we figured a site would publish a manifest in some format
(there was some talk about something like the extensions manifest)
that specifies all kinds of appy things a site can do, like large
icons, protocol
Automatically closing tree for compile on Chromium Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/11423
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29
--= Automatically closing tree for
On Fri, Oct 2, 2009 at 4:02 PM, Jacob Mandelson ja...@mandelson.org wrote:
Which reads like all or nothing to me, though I could imagine a (perverse?)
implementation with each writer having a send buffer lower layer pulling
data from multiple writers' send buffers in an interleaved manner.
That seems like a good plan. Has anyone ever tried formalizing it and
floating it around to other vendors?
On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote:
This relates somewhat to how we'd like people to install web
applications.
For that we figured a site would
On Fri, Oct 2, 2009 at 4:20 PM, Dan Kegel d...@kegel.com wrote:
(I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.)
I seem to recall that pipe buf is a page and /usr/include/linux/limits.h
says
#define PIPE_BUF4096
--
Steve
I don't think Hixie was a huge fan of it iirc ;-) He didn't like the
idea of installing webapps... though that's just a UA defined
semantic.
-Ben
On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote:
That seems like a good plan. Has anyone ever tried formalizing it and
BTW this is something that we want to pursue independently of whether
or not it's in HTML5... we already have app frames/app shortcuts, we
would like to streamline this some. If someone wants to work with
other vendors to come up with a standardized version great, so long as
the UA controls the
On Fri, Oct 2, 2009 at 4:25 PM, Steve Vandebogart vand...@chromium.org wrote:
(I think PIPE_BUF is 64K on modern Linux, but might be smaller elsewhere.)
I seem to recall that pipe buf is a page and /usr/include/linux/limits.h
says
#define PIPE_BUF 4096
Yeah, I got PIPE_BUF and pipe
Automatically closing tree for net_unittests on Modules XP (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/16452
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29
--= Automatically closing tree for net_unittests
The windows try slaves are now back up with the symbols disabled. A
side-effect is that process dump will always be red, since the symbols
cannot be found.
I'll remove this step soon.
M-A
On Fri, Oct 2, 2009 at 1:10 PM, Marc-Antoine Ruel mar...@chromium.org wrote:
The windows slaves are
Automatically closing tree for compile on Webkit Builder (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Builder%20%28dbg%29/builds/17198
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Builder%20%28dbg%29
--= Automatically closing tree for compile
Automatically closing tree for compile on Linux Builder (ChromeOS)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3966
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29
--= Automatically closing tree
Automatically closing tree for compile on Linux Builder (ChromeOS)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromeOS%29/builds/3967
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromeOS%29
--= Automatically closing tree
Automatically closing tree for check deps on Chromium XP
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/7758
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP
--= Automatically closing tree for check deps on Chromium XP =--
Revision:
59 matches
Mail list logo
