This newsletter is brought to you by Mr. Balmer who was recently heard
shouting Stability, Stability, Stability, Stability, Stability...
- Failing pixel layout tests are now archived! If you work on a pixel
layout test, grab layout_test_results from a webkit builder and grab
the .png file.
-
IMO, the big grouping distinction for startup code is a) code that needs to
be performed while single threaded; vs b) code that can run while
multi-threaded.
The first group effectively replaced the Google-style-illegal global static
initializers, and allows slight variation of ordering between
On Thu, Jan 15, 2009 at 11:55 AM, Jim Roskind j...@chromium.org wrote:
IMO, the big grouping distinction for startup code is a) code that needs to
be performed while single threaded; vs b) code that can run while
multi-threaded.
Agreed--but often (a) is used as a proxy for an ordering
On Thu, Jan 15, 2009 at 10:37 AM, cpu c...@chromium.org wrote:
When Dean and Evan say that they don't mind reviewing patches for Qt
ports, what we are saying is that
we don't mind having two UI versions of Chromium on linux?
How would this work in the long term? UI tests times 2? you get to
We use a lot of wide character strings in Chrome. We also use a lot
of wide character constants in Chrome. In most cases this isn't
really necessary, it's just we went wide everywhere in the beginning
for simplicity / consistency.
There are a few problems:
- On Linux and Mac, wchar_t is 4
I'm not coming at this from an optimization perspective, I'm thinking
more of making the startup flow understandable to mere mortals. Sadly
the sequence now is complex enough that people are jamming in their
init code wherever because by all appearances that's what everyone
else has done. I
When Dean and Evan say that they don't mind reviewing patches for Qt
ports, what we are saying is that
we don't mind having two UI versions of Chromium on linux?
How would this work in the long term? UI tests times 2? you get to
choose what Chromium to install?
Apologies if this was already
On Thu, Jan 15, 2009 at 11:08, Jon j...@chromium.org wrote:
*Report for 2009-1-14*
With a single check-in from Finnur we got a huge boost toward our goal of
resolving all the layout test failures! If you would like to try your hand
at fixing a layout test you can preview the 10 minute video
I'm currently doing a 2-day merge rotation.As part of this, various
layout tests are regressing or getting added that I'm inserting into
the tests_fixable list.
But, like every other layout test fixer, after my merges are done,
I'll finally go back to my old work and not think about it any more.
On Thu, Jan 15, 2009 at 11:11 AM, Ben Goodger (Google) b...@chromium.org
wrote:
I'm not coming at this from an optimization perspective, I'm thinking
more of making the startup flow understandable to mere mortals.
Amanda's suggestion would likely actually accomplish both, so I don't
think we
That's true. In the example I gave (Mac driver loading), each module
has a property list that lists its dependencies (and version
requirements, etc.). That's not quite as simple to do inside a single
application, of course, but having code do the ordering still seems
like a win to me.
Consider
When fixing layout tests only means re-baselining, that's easy. But
sometimes they break (or new ones fail) for deeper reasons, and the person
doing the merge may not be the right one to make the fix (or may not be able
to fix them in one day). So perhaps clean up in this context means
As someone sitting on the other side only fixing layout tests this
sounds great. The current mode of operation where a merge is landed
and others are left to fix the new failures is very disheartening in
that we'll make progress only to have a new merge land breaking the
progress we made. I now
On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org wrote:
When fixing layout tests only means re-baselining, that's easy. But
sometimes they break (or new ones fail) for deeper reasons, and the person
doing the merge may not be the right one to make the fix (or may not be able
to
Generally +1, except I just imagined the situation where the merger
collides with the fixer. So maybe no overlapping, just do the merge
every other day?
:DG
On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org
On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker ama...@chromium.org wrote:
That's true. In the example I gave (Mac driver loading), each module
has a property list that lists its dependencies (and version
requirements, etc.). That's not quite as simple to do inside a single
application, of
Just a heads up about a very small gcl change which allows a description to
be added on an upload. This doesn't work on the first upload (since that
uses the description). You might find this useful when uploading new
versions of a change, to let the reviewer know what changed.
gcl upload
I don't know how many interdependencies we have--I was relying on
ben's everyone and their dog assessment :-). That said, I write a
makefile (or equivalent) for anything with 2 source files, so writing
the dependencies in code rather than comments doesn't strike me as a
large cost.
--Amanda
Here's my plan. The Mac and Linux people are probably going to proceed
just by using ifdefs to get the startup sequence up and running, but
in the process learn more about what goes on where. We can first split
into separate phase functions for readability, and then after that
figure out if any
On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene p...@chromium.org wrote:
When fixing layout tests only means re-baselining, that's easy. But
sometimes they break (or new ones fail) for deeper reasons, and the
person
I definitely get that a merge is no trivial amount of work, and my
expectations are probably unrealistic without more than one person
working on a merge at a time. I was hoping for a magic bullet, but
those are only in movies:(
-Scott
PS If anyone not doing merges feels like the people doing
Separate phase functions sounds good to me. We should make it clear that
stuff within a phase should not be interdependent, but that might be hard to
verify and enforce :-/
-Darin
On Thu, Jan 15, 2009 at 2:18 PM, Ben Goodger (Google) b...@chromium.orgwrote:
Here's my plan. The Mac and Linux
First off, thanks for this awesome open-source gem-- Chrome has now
been my official browser for three months.
I noticed on the Mac Build Instructions page that building Chromium
requires OSX 10.5. Interpreting this as just a requirement for the
compiling system, I tried to build Chromium in
This is veering wildly off-topic, but I think the key to solving merge
regressions is in moving to an integration model. With the integration
model, we can integrate one WebKit changeset at a time, and clearly
identify the regressions. This would go a long way in identifying the
cause and
On Thu, Jan 15, 2009 at 3:04 PM, Peter Kasting pkast...@chromium.org wrote:
Also, on a related note, are there also any plans for supporting the
PPC architecture in the future?
Almost certainly not going to happen.
To clarify: v8 depends on x86 and porting to a new architecture is a
lot of
Thanks for the prompt replies!
I understand the decision not to support PPC with V8, thanks for the
clarification.
Even if there are no current plans for OSX 10.4 (naturally, getting
Chrome stable on 10.5 should be the priority right now)-- I'd be very
happy if such backward-compatibility for
On Thu, Jan 15, 2009 at 5:59 PM, AJS ajs15...@gmail.com wrote:
So, are there any plans for supporting OSX 10.4 in the future?
Our initial focus is on 10.5, so 10.4 support will probably depend on
someone taking it on closer to (or after) it's feature complete. We
don't have any active plans
On Thu, Jan 15, 2009 at 3:26 PM, Amanda Walker ama...@chromium.org wrote:
Also, on a related note, are there also any plans for supporting the
PPC architecture in the future?
Not currently. It would require, among other things, a PPC code
generator for V8. While this is not impossible,
On Fri, Jan 16, 2009 at 12:38 AM, Dan Kegel daniel.r.ke...@gmail.com wrote:
On Thu, Jan 15, 2009 at 3:26 PM, Amanda Walker ama...@chromium.org wrote:
Also, on a related note, are there also any plans for supporting the
PPC architecture in the future?
Not currently. It would require, among
On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay erik...@chromium.org wrote:
The issue is one of maintenance. A lot happens at startup. As people
make changes, it's not necessarily obvious where to insert your
On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay erik...@chromium.org wrote:
The issue is one of maintenance. A lot happens at startup. As people
make changes, it's not necessarily obvious where to insert your
initialization
Hi,
I would need some advice on how to do one static initializer when it is
contained within the UI Thread. I want to try a simple example
like: /src/chrome/browser/views/frame/browser_view.cc Can I get a
confirmation whether what I am doing would be correct, and I have some
questions that I am a
32 matches
Mail list logo
