Automatically closing tree for test_shell_tests on Webkit (dbg)(1)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20%28dbg%29%281%29/builds/14333
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20%28dbg%29%281%29
--= Automatically closing tree for
Random hang unrelated to my change AFAICS ... looks like it's going green on
the next build.
--Craig
On Thu, Jan 7, 2010 at 12:55 PM, build...@chromium.org wrote:
http://build.chromium.org/buildbot/waterfall/
Automatically closing tree for test_shell_tests on Webkit (dbg)(1)
Yeah, so my question was, does that mean test_shell would have a
separate mechanism (the current one?) for file:/// listings?
On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher da...@chromium.org wrote:
DOM UI implies chrome://, which is implemented by the ChromeURLDataManager
(in browser/dom_ui/).
It could... but, I though the conclusion was to avoid DOM UI for file:// and
ftp:// directory listings (for other reasons). In that case, we should be
able to continue using the same UI. I think there is just the open question
of how to provide icon resources to the page.
-Darin
On Thu, Jan
Automatically closing tree for compile on Linux Perf
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/4822
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf
--= Automatically closing tree for compile on Linux Perf =--
Revision: 35706, 35707
Thanks a lot, Chase.
When will it become feasible to run the perf tests as part of the WebKit
canary process? We seem to have all the code necessary to catch these
regressions at the exact WebKit revision that causes them.
- James
On Thu, Jan 7, 2010 at 11:13 AM, Chase Phillips
Charles, I've read your paper and ultimately I think my goal may be
somewhere along the lines of making the DOM tree thread-safe by applying my
research in iterators and lock-free data structures.
A tricky question: What can be parallelized here? What level of atomicity
is required by scripts.
On Thu, Jan 7, 2010 at 12:43 PM, Fady Samuel fadysam...@gmail.com wrote:
Charles, I've read your paper and ultimately I think my goal may be
somewhere along the lines of making the DOM tree thread-safe by applying my
research in iterators and lock-free data structures.
A tricky question:
On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote:
Charles, I've read your paper and ultimately I think my goal may be
somewhere along the lines of making the DOM tree thread-safe by applying my
research in iterators and lock-free data structures.
A tricky question:
On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie b...@google.com wrote:
On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote:
Charles, I've read your paper and ultimately I think my goal may be
somewhere along the lines of making the DOM tree thread-safe by applying my
On Thu, Jan 7, 2010 at 1:10 PM, Charlie Reis cr...@chromium.org wrote:
On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie b...@google.com wrote:
On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel fadysam...@gmail.com wrote:
Charles, I've read your paper and ultimately I think my goal may be
somewhere
If you have ever used any of the EmptyXXX() functions, or ever will, please
read on.
These functions (in string_util.h and gurl.h) are meant for a single,
specific use case:
const std::string MyClass::foo() const {
return (everything == OK) ? member_string : EmptyString();
}
Here you cannot
What about allowing the renderer to run asynchronously with the
script? Right now you're either producing the view or you're running script
but never both concurrently, correct? Parallelizing them should not
introduce issues I think (assuming the renderer has the equivalent of a
snapshot view of
On Thu, Jan 7, 2010 at 1:30 PM, Fady Samuel fadysam...@gmail.com wrote:
What about allowing the renderer to run asynchronously with the
script? Right now you're either producing the view or you're running script
but never both concurrently, correct? Parallelizing them should not
introduce
(As discussed during lunch...) Why not just do this in this case and remove
EmptyString() altogether?
const std::string MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ? member_string : empty;
}
I forget if this runs the constructor on first use or
Hmm, I wonder if strict two-phase locking can be here to solve this?
Fady
That's correct. However, Fady is referring to an observation in my paper
that race conditions are actually possible in cross-window JavaScript calls
in Internet Explorer and Opera. Those browsers allow pages in
The catch is that you don't know what locks you need to acquire in advance,
especially in the presence of things like eval. (And of course, you can't
roll back any JavaScript you've already run, so you would need to know the
locks in advance.)
Charlie
On Thu, Jan 7, 2010 at 1:35 PM, Fady
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ?
Well you can't know the precise set of locks you need obviously without
solving the halting problem. But maybe a static analysis can give you a
conservative set of DOM trees you might access. Sorry, just thinking out
loud I guess.
Fady
On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis
And before you suggest using software transactional memory, keep in mind
that side effects (XHRs and other network activity for example)
are prevalent in normal JavaScript usage.
I don't mean to discourage you too muchespecially if you were interested
in digging really deeply into this
On Thu, Jan 7, 2010 at 11:22 AM, James Robinson jam...@google.com wrote:
Thanks a lot, Chase.
When will it become feasible to run the perf tests as part of the WebKit
canary process? We seem to have all the code necessary to catch these
regressions at the exact WebKit revision that causes
On Thu, Jan 7, 2010 at 1:38 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
There's a group at UC Berkeley that was (is?) working on a similar idea, you
can read about it here:
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/With a discussion
that happened a few months back here:
What about renaming the function? EmptyStringHACK() or something?
On Thu, Jan 7, 2010 at 1:49 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow jor...@chromium.org wrote:
You ignored the second half of my suggestion.
The second half of your
On Thu, Jan 7, 2010 at 1:50 PM, Jeremy Orlow jor...@chromium.org wrote:
What about renaming the function? EmptyStringHACK() or something?
It's not a hack. It's a perfectly legitimate thing to use, and not
something we're going to get rid of, unlike ToWStringHack().
Darin suggested we could
Which brings me back to the original topic of replicated state. Is there any
reason not to have a single monolithic cache (or other similar state) across
all processes other than synchronization issues or fault tolerance?
I have a technique to give me a consistent, snapshot view of data
Hi,
I wrote up a document that's relevant not only for people working on
chromium, but for (small parts of) the world in general (under which
circumstances does google chrome display idn urls as punycode? I
mean, who's not dying to know?).
Where do documents like these go?
Nico
--
Chromium
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ?
Perhaps a silly question but what about plugins? Charlie mentioned in his
paper that plugins run in a separate process.
Does the renderer also respond to draw requests from plugins such as Flash?
So by running the renderer asynchronously from script, maybe one can allow
it to respond more rapidly
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
remove EmptyString() altogether?
const std::string MyClass::foo() const {
On Thu, Jan 7, 2010 at 2:53 PM, Victor Khimenko k...@google.com wrote:
On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑)
ajw...@chromium.orgwrote:
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow
On Thu, Jan 7, 2010 at 2:50 PM, Albert Wong (王重傑) ajw...@google.com wrote:
Is there something wrong with returning by copy, and relying on the
compiler to execute a return value optimization?
I'm not totally sure what your comment is saying.
If you are saying that everywhere in the code can
[ resending from correct e-mail ]
If you are saying that everywhere in the code can return by value instead
of by const ref and the compiler will optimize it equivalently, you are
wrong; I was under the same misapprehension until yesterday. We've verified
that even in the best case
That's
On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting pkast...@google.com wrote:
If you have ever used any of the EmptyXXX() functions, or ever will, please
read on.
These functions (in string_util.h and gurl.h) are meant for a single,
specific use case:
const std::string MyClass::foo() const {
On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman a...@google.com wrote:
Out of curiosity, what is wrong with using EmptyString() in those
cases? Is there a correctness problem? Unnecessary inclusion of
string_util.h?
There are a couple reasons. Code clarity and consistency is a primary one;
On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman a...@google.com wrote:
On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting pkast...@google.com wrote:
If you have ever used any of the EmptyXXX() functions, or ever will,
please
read on.
These functions (in string_util.h and gurl.h) are meant for a
On Thu, Jan 7, 2010 at 2:31 PM, Nico Weber tha...@chromium.org wrote:
I wrote up a document that's relevant not only for people working on
chromium, but for (small parts of) the world in general (under which
circumstances does google chrome display idn urls as punycode? I
mean, who's not dying
Adam reverted WebKit r52847 which appears to fix the regression. In
Chromium's r35744, Dimitri picked up Adam's fix, perf tests are green now.
Thanks Adam and Dimitri!
On Thu, Jan 7, 2010 at 11:13, Chase Phillips ch...@chromium.org wrote:
I'll take the bug for now to identify the WebKit rev
On Fri, Jan 8, 2010 at 2:10 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
According to wikipedia,
http://en.wikipedia.org/wiki/Return_value_optimization, msvc, g++, and
icc, all support it...or am I missing something about this situation that
makes RVO inapplicable?
Yes. Starting from
I'll take the bug for now to identify the WebKit rev that caused the
regression.
On Wed, Jan 6, 2010 at 20:10, Robert Sesek rse...@chromium.org wrote:
Good evening,
At 9pm ET, the tree was significantly red and Erik Kay closed the tree: Win
browser_tests, Win Mac perf, Linux views, and Win
Any idea what could be causing this thing? It's been going on for
some time now. All of my research turns up nothing.
CXX(target) out/Release/obj.target/command_buffer_service/gpu/
command_buffer/service/gles2_cmd_decoder.o
In file included from ./gpu/command_buffer/common/gles2_cmd_format.h:
On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote:
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow jor...@chromium.org wrote:
(As discussed during lunch...) Why not just do this in this case and
See the email from 3 days ago titled PSA: new dev packages needed on linux
On Thu, Jan 7, 2010 at 8:14 AM, Aaron donnythebow...@gmail.com wrote:
Any idea what could be causing this thing? It's been going on for
some time now. All of my research turns up nothing.
CXX(target)
On Thu, Jan 7, 2010 at 8:14 AM, Aaron donnythebow...@gmail.com wrote:
Any idea what could be causing this thing? It's been going on for
some time now. All of my research turns up nothing.
piman writes:
For the incoming gpu plugin on linux, the following new packages are needed:
*
Automatically closing tree for compile on Linux Builder (ChromiumOS)
http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2050
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29
--= Automatically closing
On Thu, Jan 7, 2010 at 5:31 PM, Evan Martin e...@chromium.org wrote:
On Thu, Jan 7, 2010 at 2:31 PM, Nico Weber tha...@chromium.org wrote:
I wrote up a document that's relevant not only for people working on
chromium, but for (small parts of) the world in general (under which
circumstances
On Thu, Jan 7, 2010 at 4:02 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman a...@google.com wrote:
On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting pkast...@google.com
wrote:
If you have ever used any of the EmptyXXX() functions, or ever will,
please
On Thu, Jan 7, 2010 at 8:00 PM, Michael Nordman micha...@google.com wrote:
Where as It looks like GURL::EmptyGURL() may be a tad less costly than
GURL().
Not if you ever need to initialize another GURL with it (since the compiler
can't collapse the copy). Which is true much of the time that
Automatically closing tree for test_shell_tests on Chromium Linux
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux/builds/8936
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux
--= Automatically closing tree for test_shell_tests on Chromium
49 matches
Mail list logo
