[chromium-dev] Build weekly newsletter
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. - Unit tests are now timed! Look at the stdio to see which tests cost the most money! (Time is money) - ui_tests is now built on linux and mac and run on the try slaves and build slaves (thanks mark and evan!). Ok they run no test yet but still! media_unittests was added too. - The tree is now automatically closed on critical step failure on critical builders. We'll try to improve it in the next days if it goes well. - I hope you enjoy the new try server html emails. - The try server has only three builders now, one per platform. So if you want to try only on one platform, use «gcl try mychange --bot linux» for example. M-A --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 startup and shutdown as necessary. It is a shame that some items are just put into this group without an explanation of dependencies (...must come before X and/or must come after Y). For best performance, I don't believe lazy initialization is a win when a large group of resources all must *definately* be initialized before some key point. I believe that better absolute throughput can be achieved by prescheduling, but at times, we're lazy, and lazy initialization serves us well enough. Although I think it would be premature optimization to insist on either approach (all lazy, or all sequenced), I think it would also be premature deoptimization to insist on either. I think we'll end up with both, and so I'd rather see authors make their best guess at optimality (including ease of implementation and performance). ...but it sure would be nice to list dependencies (if not assert/DCHECK) so that folks have a fighting change of moving stuff around and optimizing! Jim On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) b...@chromium.orgwrote: It looks like everyone and their dog adds init code to the startup sequence. This takes the form of first time initialization, command line switch parsing, etc. Is there any special reason why it's done in the startup flow vs. in a static method the first time a service is created or used? I think moving a lot of this stuff out of the following places: BrowserMain BrowserInit::LaunchWithProfile::Launch BrowserInit::LaunchBrowserImpl ... might make the startup flow easier to understand. As it stands, there's first-time init code for various services sprinkled across these methods and it's not clear why they are done in one function and not another - since there aren't any explanatory comments it seems a case of i'll just shove this here for now. It seems like adding some phase notifications here might also help. Also, does anyone know why BrowserInit::MessageWindow is inside BrowserInit? It seems to be only used by BrowserMain. BrowserInit is higher level and has to do with the creation of the initial set of browser windows. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 constraint on code that's actually (b). Documenting ordering constraints is good; implementing them in code would be even better (assert/DCHECK would be a good start, but code that actually does the ordering would be even better). Apple did a great job of this a few revs back of Mac OS X when they made most of the OS boot in parallel--each module and driver is tagged with what it depends on rather than insisting on being in a single place in a single-threaded startup routine or script, and the startup code orders them at runtime. It seems like we could do something similar for application startup--a middle ground between initialize everything sequentially in a single thread and initialize everything lazily. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Qt now a possibility?
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 choose what Chromium to install? I figured it would be unsupported. If somebody asked me that they want to contribute a port of chrome on Windows UI using MFC, I would say no. I just don't see the cost/ benefit. Here's an analogy. Say I argued we should only target GTK because it runs on Windows just fine, so we'd be able to share UI test code between Windows and Mac. You'd (hopefully) say it'd be terrible because it's non-native. That's the situation between GTK and Qt these days. The OS underneath is the same, but running apps targeting one in an environment targeting the other in terms of user experience feels much like GTK apps feel on Windows. Unfortunately we don't have the resources to target both, but if someone else is willing to provide the patches I'm willing to review them. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] UTF8
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 bytes per character, which leads to a lot of wasted memory. - Even on Windows, wchar_t is 2 bytes, doubling the size for a lot of strings that are ASCII. - On Linux, wchar_t is not really used, and is just there to conform to POSIX, so it's sort of abnormal to be using it. We've solved some of these problems by trying to hide the underlying string, like FilePath. Others have been solved with overloaded functions, templates, ifdefs, etc. We've converted a few bits over to ASCII already (StatsTable). I am not suggesting we stop using wide, I just wanted some opinions. I feel like wide is often used in situations where it would be simpler, more efficient, and more portable to use a UTF8 string. In the case it needs to go wide at some Windows API, it is easy to UTF8ToWide. If there are concerns about UTF8 conversion performance, I think we'll find out it's not a problem. If it does show up to be, I have some ideas about how we could make it faster for most of these cases. I think a good example is chrome_constants.cc, I don't see why any of these should have to be wide. Some of them may make their way into filenames, etc, in which case they could be easily converted or be handled directly by FilePath methods, etc. Another good example would be chrome_switches, these will always be ASCII. So far I just mentioned constants, but I think this also applies to a lot of other parts to our code, and it makes sense to shift to UTF8 in a lot of our internal representations. It would be an interesting experiment to see how much of our memory usage on the browser side is strings, and how much of that is strings that could be represented in 7 bits per character. Just wanted to solicit thoughts, and make sure there is some sort of agreement and support if we start trying to UTF8 some pieces of Chrome. Also, when this has come up before, I've heard the argument that this means strings are no longer directly indexable (ie blah[3] gets you the 4th character). Well, this isn't true for wchar_t on Windows either. Since it is UTF16, it can have surrogate pairs (Unicode is current defined for something like 20-21 bits?). It depends what operations you need to do, but most are UTF8 / UTF16 safe even using direct indexing. Things like finding a substring, splitting on a known character / substring, etc are all safe on UTF8 strings, and the encoding was intentionally designed this way. If we have places where we're directly indexing wchar_t and that would break in UTF8, that means it was actually incorrect to begin with. These cases should be using proper ICU iterators. So in moving to UTF8, we might actually uncover some bugs, but anything that would break was broken before. Thanks -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 suggested moving init to the components just because it'd group the init code with the code being init'ed. Another option would be to do something like how Browser prefs are initialized and have functions that do all the init steps with understandable names, then it'd be clearer where to add your code. A less effective option IMO is to add comments, since the files are so long I'm not convinced people entering from one place will read a comment somewhere else in the file. -Ben On Thu, Jan 15, 2009 at 8: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. The first group effectively replaced the Google-style-illegal global static initializers, and allows slight variation of ordering between startup and shutdown as necessary. It is a shame that some items are just put into this group without an explanation of dependencies (...must come before X and/or must come after Y). For best performance, I don't believe lazy initialization is a win when a large group of resources all must *definately* be initialized before some key point. I believe that better absolute throughput can be achieved by prescheduling, but at times, we're lazy, and lazy initialization serves us well enough. Although I think it would be premature optimization to insist on either approach (all lazy, or all sequenced), I think it would also be premature deoptimization to insist on either. I think we'll end up with both, and so I'd rather see authors make their best guess at optimality (including ease of implementation and performance). ...but it sure would be nice to list dependencies (if not assert/DCHECK) so that folks have a fighting change of moving stuff around and optimizing! Jim On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) b...@chromium.org wrote: It looks like everyone and their dog adds init code to the startup sequence. This takes the form of first time initialization, command line switch parsing, etc. Is there any special reason why it's done in the startup flow vs. in a static method the first time a service is created or used? I think moving a lot of this stuff out of the following places: BrowserMain BrowserInit::LaunchWithProfile::Launch BrowserInit::LaunchBrowserImpl ... might make the startup flow easier to understand. As it stands, there's first-time init code for various services sprinkled across these methods and it's not clear why they are done in one function and not another - since there aren't any explanatory comments it seems a case of i'll just shove this here for now. It seems like adding some phase notifications here might also help. Also, does anyone know why BrowserInit::MessageWindow is inside BrowserInit? It seems to be only used by BrowserMain. BrowserInit is higher level and has to do with the creation of the initial set of browser windows. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Qt now a possibility?
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 discussed long time ago. If somebody asked me that they want to contribute a port of chrome on Windows UI using MFC, I would say no. I just don't see the cost/ benefit. Personally, Qt seems now the stronger toolkit, but I really don't have a clue about linux development. -cpu On Jan 14, 9:55 am, Evan Martin e...@chromium.org wrote: On Wed, Jan 14, 2009 at 9:50 AM, andrewg droi...@gmail.com wrote: On Jan 14, 11:44 am, Evan Martin e...@chromium.org wrote: I'm no lawyer, but it appears there was already an exception list[1] for the GPL-licensed code that would've covered us anyway? So I believe this LGPL thing has no affect on us, except in its potential broader implications for the space of other software in the future. I, too, would be happy to review patches for Qt support. [1]http://doc.trolltech.com/4.3/license-gpl-exceptions.html I'm no lawyer either, but I am pretty sure the GPL would have required Chromium to be released under the GPL as well, instead of its BSD license (unless all of the contributors had a commercial license to Qt). Ah, my misreading -- that page doesn't apply to the Open Source Edition. I do remember reading about BSD-licensed software needing to make licensing exceptions to link against Qt. (I apologize for my misinformation; I never looked into Qt too closely exactly because of these licensing shenanigans.) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Stabilization Effort Daily Report
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 we are preparing at http://www/~jonc/layout1-2.m4v (assuming you don't all click at the same time and can play MPEG4). Send internal links to internal mailing lists. It's frustrating to be told to check something out and then realize you're forbidden from accessing it. This really is great progress and the sooner we get past these issues the better! I still need an owner for this bug: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering *Layout Tests* We had a net gain of 34 passing unit tests yesterday! We are closing in on 95% of Want to Pass! [image: All+Tests=76.9][image: Want+To+Pass=94.5] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw Be sure to sign up at http://spreadsheets.google.com/ccc?key=pMwul3Seofg448Q1VFJjsJAhl=en if you are going to work on a layout test. We don't want to step on each other's toes. All Tests is based on all available layout tests including those that we are currently not trying to pass. There are tests in this group which are known to be bad or relate to future technologies. Want to Pass is based on the tests that we need to be passing before we will ship a revision of the browser. Getting this number as high as possible is the goal of the stabilization effort. Some of these tests are failing due to subtle changes that require the test to be re-baselined. Crashers Of the 22 crashers we have assigned to stable we have resolved 5. As we get more data from the dev channel we have been adding crashers to this list. *Purify Bugs (Memory)* We have resolved 29 of the 43 Purify issues. We resolved 6 additional Purify bugs since the last email. *Regressions* We have resolved 17 of 28 regressions. We resolved two additional regressions. *Other bugs* We have also resolved 21 of the 47 other bugs. We resolved one more. So our bug burndown chart looks like this: We have popped above the blue line but we are making great progress on layout tests. As long as we keep the red line below the blue line we are on track for the bugs. Keep in mind that this does not include the work on Layout Tests. You will find a lot more information about the Stabilization effort on the Wiki at http://code.google.com/p/chromium/wiki/StabilizeTrunk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] 2-day merges and the cleanup schedule
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. This is how we get a monotonically increasing list of broken tests at the end of the tests fixable. I'm pretty certain this happens faster than the tests are getting fixed because nobody wants to fix them. I'm sort of tempted to just fix the ones my merge broke now, but that will put me behind for my next merge, so I don't do that. I propose a different rotation schedule for WebKit merges. You would do one day of merges, and the next day you would have to clean up all the regressed and new layout tests your merge introduced. The layout tests usually aren't that hard, so it normally wouldn't take the whole day. This way we can be in a good steady state of WebKit merges. It should also have a big advantage for fixing the broken tests since the things that changed, the build numbers involved, etc. are still fresh in the merger's head, and it won't be like approaching a random layout test from the list with no context. The disadvantage of doing this is that we have to find people to do the merges faster (we should probably formalize the schedule), and you'll lose some advantage the second day of having all the instructions and gotchas of the merge fresh in your mind. I was thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but that seems too heavyweight for the people volunteering to do this. Anybody have any comments? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 should dismiss it if it happens to make startup faster as a result as well. :-) The gist would be to have some way for a given service to specify its startup dependencies. Once you do that, then you can essentially list your startup services in pretty much any order since the dependencies would get worked out correctly. It would also allow us to catch things like dependency cycles and to more clearly figure out how to optimize startup time by perhaps figuring out how to remove unnecessary dependencies. Finally, it would allow easier unit testing since you'd be able to safely grab a subset of the services you want to test and to have a system that knows how to initialize properly (addressing Scott's issue). Of course, coming up with a nice way to express these dependencies cleanly and actually figuring out what all of the dependencies are are both easier said than done. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 startup as a sequence of, say: Initializer foo(foo); foo.DependsOn(bar); foo.DependsOn(zot); Initializer alice(alice); alice.DependsOn(bob); alice.DependsOn(eve); [...] Initializer::LaunchAll(); (or, more generally, Initializer:::Launch(chromium); where chromium is a top level module, so that the general framework could be used for things besides app launch) Just some ideas, --Amanda On Thu, Jan 15, 2009 at 4:04 PM, Erik Kay erik...@chromium.org wrote: 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 should dismiss it if it happens to make startup faster as a result as well. :-) The gist would be to have some way for a given service to specify its startup dependencies. Once you do that, then you can essentially list your startup services in pretty much any order since the dependencies would get worked out correctly. It would also allow us to catch things like dependency cycles and to more clearly figure out how to optimize startup time by perhaps figuring out how to remove unnecessary dependencies. Finally, it would allow easier unit testing since you'd be able to safely grab a subset of the services you want to test and to have a system that knows how to initialize properly (addressing Scott's issue). Of course, coming up with a nice way to express these dependencies cleanly and actually figuring out what all of the dependencies are are both easier said than done. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. - Pam On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote: 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. This is how we get a monotonically increasing list of broken tests at the end of the tests fixable. I'm pretty certain this happens faster than the tests are getting fixed because nobody wants to fix them. I'm sort of tempted to just fix the ones my merge broke now, but that will put me behind for my next merge, so I don't do that. I propose a different rotation schedule for WebKit merges. You would do one day of merges, and the next day you would have to clean up all the regressed and new layout tests your merge introduced. The layout tests usually aren't that hard, so it normally wouldn't take the whole day. This way we can be in a good steady state of WebKit merges. It should also have a big advantage for fixing the broken tests since the things that changed, the build numbers involved, etc. are still fresh in the merger's head, and it won't be like approaching a random layout test from the list with no context. The disadvantage of doing this is that we have to find people to do the merges faster (we should probably formalize the schedule), and you'll lose some advantage the second day of having all the instructions and gotchas of the merge fresh in your mind. I was thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but that seems too heavyweight for the people volunteering to do this. Anybody have any comments? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 know how a mailman feels! -Scott On Thu, Jan 15, 2009 at 1:03 PM, Brett Wilson bre...@chromium.org wrote: 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. This is how we get a monotonically increasing list of broken tests at the end of the tests fixable. I'm pretty certain this happens faster than the tests are getting fixed because nobody wants to fix them. I'm sort of tempted to just fix the ones my merge broke now, but that will put me behind for my next merge, so I don't do that. I propose a different rotation schedule for WebKit merges. You would do one day of merges, and the next day you would have to clean up all the regressed and new layout tests your merge introduced. The layout tests usually aren't that hard, so it normally wouldn't take the whole day. This way we can be in a good steady state of WebKit merges. It should also have a big advantage for fixing the broken tests since the things that changed, the build numbers involved, etc. are still fresh in the merger's head, and it won't be like approaching a random layout test from the list with no context. The disadvantage of doing this is that we have to find people to do the merges faster (we should probably formalize the schedule), and you'll lose some advantage the second day of having all the instructions and gotchas of the merge fresh in your mind. I was thinking of a 3 day schedule (2 days of merging, 1 day of fixing) but that seems too heavyweight for the people volunteering to do this. Anybody have any comments? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 fix them in one day). So perhaps clean up in this context means re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. I think our tendency to file bugs and forget about it is part of the problem. I am at least as guilty as anybody else. I think the merger should have the responsibility to get their regressions fixed. They will have to talk with some other people to get input. If they aren't the right person to fix a problem, it should be their responsibility as part of the cleanup to make sure that the right person has been assigned to it and is actually working on it. When people are assigned merge bugs, they should be treated as important regressions and prioritized over other work. We currently had a whole lot of layout tests bugs filed that are getting no love. The only way to not keep getting behind is to be much more proactive. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. I'm proposing overlapping so we merge every day. I think there is an advantage in having the same person who did the merge do the fixing. This hopefully also makes the merge less tedious since you have different tasks your two days. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 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 fix them in one day). So perhaps clean up in this context means re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. I think our tendency to file bugs and forget about it is part of the problem. I am at least as guilty as anybody else. I think the merger should have the responsibility to get their regressions fixed. They will have to talk with some other people to get input. If they aren't the right person to fix a problem, it should be their responsibility as part of the cleanup to make sure that the right person has been assigned to it and is actually working on it. When people are assigned merge bugs, they should be treated as important regressions and prioritized over other work. We currently had a whole lot of layout tests bugs filed that are getting no love. The only way to not keep getting behind is to be much more proactive. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. I'm proposing overlapping so we merge every day. I think there is an advantage in having the same person who did the merge do the fixing. This hopefully also makes the merge less tedious since you have different tasks your two days. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 course, but having code do the ordering still seems like a win to me. Consider startup as a sequence of, say: Initializer foo(foo); foo.DependsOn(bar); foo.DependsOn(zot); Initializer alice(alice); alice.DependsOn(bob); alice.DependsOn(eve); [...] Initializer::LaunchAll(); (or, more generally, Initializer:::Launch(chromium); where chromium is a top level module, so that the general framework could be used for things besides app launch) I have a hard time thinking about this with your abstract example. I also have a hard time believing we have so many interdependencies that it requires writing a makefile to start the program, and that such a syntax is easier to read than just listing out in comments why things are done in this order. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Sending -m patchset description on gcl upload
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 change_name -m description of the patchset --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 On Thu, Jan 15, 2009 at 4:37 PM, Brett Wilson bre...@chromium.org wrote: 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 course, but having code do the ordering still seems like a win to me. Consider startup as a sequence of, say: Initializer foo(foo); foo.DependsOn(bar); foo.DependsOn(zot); Initializer alice(alice); alice.DependsOn(bob); alice.DependsOn(eve); [...] Initializer::LaunchAll(); (or, more generally, Initializer:::Launch(chromium); where chromium is a top level module, so that the general framework could be used for things besides app launch) I have a hard time thinking about this with your abstract example. I also have a hard time believing we have so many interdependencies that it requires writing a makefile to start the program, and that such a syntax is easier to read than just listing out in comments why things are done in this order. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 further steps are needed. -Ben On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay erik...@chromium.org wrote: On Thu, Jan 15, 2009 at 1:37 PM, Brett Wilson bre...@chromium.org wrote: 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 course, but having code do the ordering still seems like a win to me. Consider startup as a sequence of, say: Initializer foo(foo); foo.DependsOn(bar); foo.DependsOn(zot); Initializer alice(alice); alice.DependsOn(bob); alice.DependsOn(eve); [...] Initializer::LaunchAll(); (or, more generally, Initializer:::Launch(chromium); where chromium is a top level module, so that the general framework could be used for things besides app launch) I have a hard time thinking about this with your abstract example. I also have a hard time believing we have so many interdependencies that it requires writing a makefile to start the program, and that such a syntax is easier to read than just listing out in comments why things are done in this order. 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 code. Depending on your dependencies, your new service may require a complex re-ordering of initialization. If we actually explicitly express dependencies and automatically manage them, then we can be precise about it. Maybe we'd have to see an example to know for sure, but it feels like it would be easier to read startup dependencies if they were expressed explicitly as opposed to comments which don't need to be complete and can drift from reality. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 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 re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. I think our tendency to file bugs and forget about it is part of the problem. I am at least as guilty as anybody else. I think the merger should have the responsibility to get their regressions fixed. They will have to talk with some other people to get input. If they aren't the right person to fix a problem, it should be their responsibility as part of the cleanup to make sure that the right person has been assigned to it and is actually working on it. Taking responsibility, check. Making sure someone is assigned, check. Fixing tricky regressions yourself may not be the most efficient use of time, and would be a strong deterrent to volunteer for a merge. Merging isn't much fun; fixing layout tests isn't much fun. Let's spread the pain where suitable, rather than piling it all on the person who volunteers for one part. In fact, I'd ask the merger to fix the easy problems (tests changed, new tests need baselines) before committing the merge. When people are assigned merge bugs, they should be treated as important regressions and prioritized over other work. We currently had a whole lot of layout tests bugs filed that are getting no love. The only way to not keep getting behind is to be much more proactive. Absolutely. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. I'm proposing overlapping so we merge every day. I think there is an advantage in having the same person who did the merge do the fixing. This hopefully also makes the merge less tedious since you have different tasks your two days. Sounds fine. People can always trade if they want. - Pam Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 merges should do more, please volunteer to do a merge so at least you'll know what it is like -- Sorry Scott but I'm looking at you :) On Thu, Jan 15, 2009 at 2:26 PM, Pam Greene p...@chromium.org wrote: 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 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 re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. I think our tendency to file bugs and forget about it is part of the problem. I am at least as guilty as anybody else. I think the merger should have the responsibility to get their regressions fixed. They will have to talk with some other people to get input. If they aren't the right person to fix a problem, it should be their responsibility as part of the cleanup to make sure that the right person has been assigned to it and is actually working on it. Taking responsibility, check. Making sure someone is assigned, check. Fixing tricky regressions yourself may not be the most efficient use of time, and would be a strong deterrent to volunteer for a merge. Merging isn't much fun; fixing layout tests isn't much fun. Let's spread the pain where suitable, rather than piling it all on the person who volunteers for one part. In fact, I'd ask the merger to fix the easy problems (tests changed, new tests need baselines) before committing the merge. When people are assigned merge bugs, they should be treated as important regressions and prioritized over other work. We currently had a whole lot of layout tests bugs filed that are getting no love. The only way to not keep getting behind is to be much more proactive. Absolutely. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. I'm proposing overlapping so we merge every day. I think there is an advantage in having the same person who did the merge do the fixing. This hopefully also makes the merge less tedious since you have different tasks your two days. Sounds fine. People can always trade if they want. - Pam Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 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 further steps are needed. -Ben On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay erik...@chromium.org wrote: On Thu, Jan 15, 2009 at 1:37 PM, Brett Wilson bre...@chromium.org wrote: 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 course, but having code do the ordering still seems like a win to me. Consider startup as a sequence of, say: Initializer foo(foo); foo.DependsOn(bar); foo.DependsOn(zot); Initializer alice(alice); alice.DependsOn(bob); alice.DependsOn(eve); [...] Initializer::LaunchAll(); (or, more generally, Initializer:::Launch(chromium); where chromium is a top level module, so that the general framework could be used for things besides app launch) I have a hard time thinking about this with your abstract example. I also have a hard time believing we have so many interdependencies that it requires writing a makefile to start the program, and that such a syntax is easier to read than just listing out in comments why things are done in this order. 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 code. Depending on your dependencies, your new service may require a complex re-ordering of initialization. If we actually explicitly express dependencies and automatically manage them, then we can be precise about it. Maybe we'd have to see an example to know for sure, but it feels like it would be easier to read startup dependencies if they were expressed explicitly as opposed to comments which don't need to be complete and can drift from reality. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] OSX 10.4 and PPC support?
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 xcode using the 10.4 SDK and it failed with a decent amount of build errors. So, are there any plans for supporting OSX 10.4 in the future? Also, on a related note, are there also any plans for supporting the PPC architecture in the future? Thanks in advance, Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: 2-day merges and the cleanup schedule
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 addressing the issue. Unfortunately, currently we have engineers fixing layout tests and making changes to our WebKit fork, which makes integration model ... complicated. What if we go with an integration-merge model, which works as follows: 1) we have a separate WebKit git repository (hosted on someone's machine even), which has a branch with all of our changes applied as one (or more) patch. 2) you pull WebKit changes, rebase (in other words, re-apply our change patches), see if the changes broke anything. 3) if they did, identify the changeset that breaks stuff by using git bisect (nifty stuff, I might say), then mark it in text_fixable and file a bug 4) merge integrated changes into main svn repository. ... or something like that? Somebody take this idea and flesh it out to make it excellent! :) :DG On Thu, Jan 15, 2009 at 2:51 PM, Scott Violet s...@chromium.org wrote: 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 merges should do more, please volunteer to do a merge so at least you'll know what it is like -- Sorry Scott but I'm looking at you :) On Thu, Jan 15, 2009 at 2:26 PM, Pam Greene p...@chromium.org wrote: 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 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 re-baseline if that's all it needs, and file individual bugs on specific people for bigger brokenness. I think our tendency to file bugs and forget about it is part of the problem. I am at least as guilty as anybody else. I think the merger should have the responsibility to get their regressions fixed. They will have to talk with some other people to get input. If they aren't the right person to fix a problem, it should be their responsibility as part of the cleanup to make sure that the right person has been assigned to it and is actually working on it. Taking responsibility, check. Making sure someone is assigned, check. Fixing tricky regressions yourself may not be the most efficient use of time, and would be a strong deterrent to volunteer for a merge. Merging isn't much fun; fixing layout tests isn't much fun. Let's spread the pain where suitable, rather than piling it all on the person who volunteers for one part. In fact, I'd ask the merger to fix the easy problems (tests changed, new tests need baselines) before committing the merge. When people are assigned merge bugs, they should be treated as important regressions and prioritized over other work. We currently had a whole lot of layout tests bugs filed that are getting no love. The only way to not keep getting behind is to be much more proactive. Absolutely. Also, to clarify, are you proposing that we only merge every other day, or that we have two people assigned each day: one to merge and one to clean up the previous day's layout-test breakage? If the latter, we could also split the job in the other direction, and have one person merging two days in a row and one fixing up the test list both days. I could imagine people's tastes running more to one job or the other, and we don't really care who does what as long as it gets done. I'm proposing overlapping so we merge every day. I think there is an advantage in having the same person who did the merge do the fixing. This hopefully also makes the merge less tedious since you have different tasks your two days. Sounds fine. People can always trade if they want. - Pam Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: OSX 10.4 and PPC support?
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 work. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: OSX 10.4 and PPC support?
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 all those users still on Tiger could make its way in eventually. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: OSX 10.4 and PPC support?
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 for it, but neither would we discourage anyone from working on it. 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, it's enough work that it's not part of our current plans. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: OSX 10.4 and PPC support?
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, it's enough work that it's not part of our current plans. Wouldn't it be possible to fall back to the other javascript engine on non-x86 platforms? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: OSX 10.4 and PPC support?
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 other things, a PPC code generator for V8. While this is not impossible, it's enough work that it's not part of our current plans. Wouldn't it be possible to fall back to the other javascript engine on non-x86 platforms? No, not really. Long story short, we have completely different binding layers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 code. Depending on your dependencies, your new service may require a complex re-ordering of initialization. If we actually explicitly express dependencies and automatically manage them, then we can be precise about it. I'm still a bit skeptical of how complex these dependencies are. Can somebody give an example of such a service that required complex interdependencies on startup and required very specific ordering? see browser_main.cc at line 164 : -=-=-=-=-=-= // Start tracking the creation and deletion of Task instance. // This construction MUST be done before main_message_loop, so that it is // destroyed after the main_message_loop. tracked_objects::AutoTracking tracking_objects; MessageLoop main_message_loop(MessageLoop::TYPE_UI); -=-=-=-=-=-= If we move main_message_loop above tracking_objects, when the function ends and all the local objects are deleted, tracking objects will be deleted first and that will caused a crash in the destructor of MessageLoop. Nicolas Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Making sense of startup
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 code. Depending on your dependencies, your new service may require a complex re-ordering of initialization. If we actually explicitly express dependencies and automatically manage them, then we can be precise about it. I'm still a bit skeptical of how complex these dependencies are. Can somebody give an example of such a service that required complex interdependencies on startup and required very specific ordering? Another one http://src.chromium.org/viewvc/chrome?view=revrevision=5069 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: If you're feeling bored
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 bit confused (ok really confused, I don't want to submit a patch that I don't understand): This is one of the static initializers in browser_view.cc SkBitmap BrowserView::default_favicon_; And within the header file (browser_view.h) default_favicon_ is defined there as well: static SkBitmap* default_favicon_ My first question, why is that done like that? Why do we have default_fav_icon_ defined in the class and header file? And why couldn't we just have it defined in the header file as this: SkBitmap* default_fav_icon_ And if we want it as static to make it one instance, we could just add static at the beginning default_favicon_ is only initialized within the function InitClass (which is static) where it is being initialized like this: default_favicon_ = *rb.GetBitmapNamed(); Since we wanted to ensure a singleton (unless I am mistaken), should we check if that variable is already initialized? From what I understand (mind you I am very new to c++, and am reading books that were recommended to me) I would just delete the field declared in the class: void BrowserView::InitClass() And define it as a pointer in the header file: static SkBitmap* default_favicon_ And within the init function I check if its valid and if it isn't I set it. if (default_favicon_) default_favicon_ = *rb.GetBitmapNamed(); I have submitted two patches for remove static initializers but then deleted them because I really didn't understand what is going on. If anyone could shed some light, it would be highly appreciated! I am coming from a Java background if that would help. Thanks! And sorry for this long email. On Tue, Jan 13, 2009 at 12:50 PM, Dmitry Titov dim...@chromium.org wrote: They also contribute to launch time. Generally speaking, the less code we have to execute during startup, the better it is for the user experience. This is especially important, because even though initialization is often trivial, the page with the code for each initializer should be loaded from disk into memory on startup. This paging often constitutes most of the app startup time. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
