[chromium-dev] WebKit Layout Tests on the Mac
We've made a few changes the last few days to remove user level settings and improve the Mac's performance on pixel dumps during the WebKit Layout Tests. One change that just went in is while the tests are running TestShell will change your main display's Color Profile. This is done so the color correction from ColorSync won't cause false errors in the tests. Depending on your main display's normal color profile, *you will see a color change in your display while the tests are running* (laptop's tend to show a big change, desktops are usually a small change). The tests do their best to reset things when they finish, but in cases were we don't properly revert the setting, you can manually correct it by going to System Preferences - Displays - Color and picking the correct profile. TVL ps-DumpRenderTree has to do the same type of color profile management. --~--~-~--~~~---~--~~ 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: Windows SDK Configuration Tool failure workaround
Thanks Yury, I added this to the build instructions page. Brett On Thu, Jan 8, 2009 at 8:33 AM, Yury Semikhatsky yury.semikhat...@gmail.com wrote: If Windows SDK Configuration Tool fails with message Windows SDK Version Selection Tool has encountered a problem and needs to close. We are sorry for the inconvenience. try running it from command line with undocumented flag -legacy: windowssdkver -version:v6.1 -legacy I wasted quite a lot of time trying to figure out why it would fail when I started it from the menu and ran OK but didn't change anything when I launched it from command line. I found answer at: http://social.msdn.microsoft.com/forums/en-US/windowssdk/thread/2514049f-a9f7-4e16-85f6-c7970658271e/ Thanks, Yury On Jan 8, 4:38 am, idanan chr...@cybernium.net wrote: To be clear, developers must install the Platform SDK 6.1 which is part of Windows SDK for Windows Server 2008 and .NET Framework 3.5 and is available at the following link (repeated from above):http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74... This installer contains lots of stuff including VC++ 9.0 (which we don't use), so do not install it unless you know how to keep VC++ 8.0 (which we use) and make sure that it stays as the compiler for Chromium builds. When the installer completes you must use the Windows SDK Configuration Tool in the Start menu, under Microsoft Platform SDK, to enable this as the current SDK. Otherwise Chromium builds won't pick it up. After it is installed and configured you must clobber your build which means to recursively delete (rd /s /q) the src\Chrome\Debug and src\Chrome\Release directories under your SVN client. A gclient sync is also required. You can do the clobbering and SDK install in any order but the build must be done as the LAST step. - Itai --~--~-~--~~~---~--~~ 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: Is Chrome App-Mode discoverable?
If that's a serious problem, how about we just try loading the app w/ the flag enabled and if that fails retry w/o it? Defining fails is hard, but the user could tell us. I know that I'd want the flag for apps/frameworks I build, particularly if we're going to open up new/better/different APIs for app mode vs. page mode. Regards On Wed, Jan 7, 2009 at 5:07 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jan 7, 2009 at 4:34 PM, Brian Rakowski br...@chromium.org wrote: There's not currently, but we have considered it several times. I don't remember any arguments against it other than we weren't sure if it was going to be necessary. The main argument against it (IIRC) was that we were concerned web developers might discriminate against users in various ways, i.e. refuse to run their site if the user was in app (or not in app) mode. Not sure that's a big deal. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Stabilization Effort Daily Report
*Report for 2009-1-7* We need to make progress on the layout tests. Everyone should have their name next to at least one Layout Test. I still need owners for these two bugs, please take one of these: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering Issue 5559 http://code.google.com/p/chromium/issues/detail?id=5559: REGRESSION: cannot select text in gmail compose using shift+click if scroll between clicks *Layout Tests* No change since yesterday and the big jump was due to Ojan reclassifying a bunch of tests. We need to make progress. Layout tests are the bulk of the work and a day without progress is a big problem. 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. [image: All+Tests=76.5][image: Want+To+Pass=92.5] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw 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. *Purify Bugs (Memory)* We have resolved 23 of the 42 Purify issues. That is four more than yesterday. *Regressions* We have resolved 12 of 25 regressions. No progress yesterday. *Other bugs* We have also resolved 17 of the 42 other bugs. Only one more since yesterday. So our bug burndown chart looks like this: 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] Re: Stabilization Effort Daily Report
On Thu, Jan 8, 2009 at 11:13 AM, Jon j...@chromium.org wrote: *Report for 2009-1-7* We need to make progress on the layout tests. Everyone should have their name next to at least one Layout Test. I still need owners for these two bugs, please take one of these: Issue 5541 http://code.google.com/p/chromium/issues/detail?id=5541: REGRESSION: bad drop-shadow rendering Issue 5559 http://code.google.com/p/chromium/issues/detail?id=5559: REGRESSION: cannot select text in gmail compose using shift+click if scroll between clicks *Layout Tests* No change since yesterday and the big jump was due to Ojan reclassifying a bunch of tests. We need to make progress. Layout tests are the bulk of the work and a day without progress is a big problem. To clarify, there was change yesterday. At least me, Finnur, and Rahul committed some layout test patches. The issue is that the daily webkit merge added 20 regressions (canvas), so the cumulative progress is negative. http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/test_lists/tests_fixable.txt?r1=7684r2=7683pathrev=7684 Is anyone working on adding back the pixel array v8-binding? 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. [image: All+Tests=76.5][image: Want+To+Pass=92.5] http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw [image: History of passing tests %]http://spreadsheets.google.com/ccc?key=pMwul3Seofg4uTdanKb9iWw 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. *Purify Bugs (Memory)* We have resolved 23 of the 42 Purify issues. That is four more than yesterday. *Regressions* We have resolved 12 of 25 regressions. No progress yesterday. *Other bugs* We have also resolved 17 of the 42 other bugs. Only one more since yesterday. So our bug burndown chart looks like this: 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] Re: Proposal: enforcing unit testing in gcl
This sounds like a great idea to me.
-Darin
On Mon, Jan 5, 2009 at 3:25 PM, Pam Greene p...@chromium.org wrote:
We don't have very good unit test coverage (in the broad sense, including
ui_tests, test_shell_tests, etc.) for our code. We've always had a policy
that any new code had to have an associated test, but historically we've
been really bad about enforcing it.
As a way to help contributors and reviewers remember to add tests, here's a
proposal to have gcl report when they are (or might be) missing. It's a
very rough guess now, and will probably need some refinement as we see what
it misses and where its false positives are too annoying.
What changes might need tests?
- Any new source file (.cc, .cpp, .m, or .mm), or
- Any new method added to a source or header (.h file
- A new method is identified by a flush-left non-comment line that
has ( somewhere before the next flush-left line and either ends with {
or
has { at the start of the next flush-left line.
What counts as a test?
- Any change to any code file whose name ends in test.* or tests.*
- This is very rough, but at least it shows that the contributor
thought about testing when making the patch
What do we do if we don't find a test?
- On 'gcl change', report a warning to the user
- On 'gcl upload', add a warning to the change description so the
reviewer sees it too
- Add an option to override this
Future possibilities
- Is it worth restricting the check to only public or protected
methods?
- Since any real change ought to either fix a bug or add a feature
that should be tested, warn whenever there are no changes to any tests
(including layout tests) or a test_lists file, even when no source files or
methods were added. Alas, this is probably not feasible since we don't
keep
layout tests in the same repository
- Rather than adding a warning to the change description, it'd be nice
to have a separate warning in the review app, so it showed up no matter
what
and the path author didn't have to override anything. But since we want
the
warning in client-side 'gcl change' anyway, for now we'll keep it simple
and
trust people.
Comments and volunteers welcome.
- Pam
--~--~-~--~~~---~--~~
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: Proposal: enforcing unit testing in gcl
This sounds great. I'd like to get a unit test started for browser.cc
etc very soon.
-Ben
On Thu, Jan 8, 2009 at 1:24 PM, Darin Fisher da...@chromium.org wrote:
This sounds like a great idea to me.
-Darin
On Mon, Jan 5, 2009 at 3:25 PM, Pam Greene p...@chromium.org wrote:
We don't have very good unit test coverage (in the broad sense, including
ui_tests, test_shell_tests, etc.) for our code. We've always had a policy
that any new code had to have an associated test, but historically we've
been really bad about enforcing it.
As a way to help contributors and reviewers remember to add tests, here's
a proposal to have gcl report when they are (or might be) missing. It's a
very rough guess now, and will probably need some refinement as we see what
it misses and where its false positives are too annoying.
What changes might need tests?
Any new source file (.cc, .cpp, .m, or .mm), or
Any new method added to a source or header (.h file
A new method is identified by a flush-left non-comment line that has (
somewhere before the next flush-left line and either ends with { or has { at
the start of the next flush-left line.
What counts as a test?
Any change to any code file whose name ends in test.* or tests.*
This is very rough, but at least it shows that the contributor thought
about testing when making the patch
What do we do if we don't find a test?
On 'gcl change', report a warning to the user
On 'gcl upload', add a warning to the change description so the reviewer
sees it too
Add an option to override this
Future possibilities
Is it worth restricting the check to only public or protected methods?
Since any real change ought to either fix a bug or add a feature that
should be tested, warn whenever there are no changes to any tests (including
layout tests) or a test_lists file, even when no source files or methods
were added. Alas, this is probably not feasible since we don't keep layout
tests in the same repository
Rather than adding a warning to the change description, it'd be nice to
have a separate warning in the review app, so it showed up no matter what
and the path author didn't have to override anything. But since we want the
warning in client-side 'gcl change' anyway, for now we'll keep it simple and
trust people.
Comments and volunteers welcome.
- Pam
--~--~-~--~~~---~--~~
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: Has your computer melted?
I've heard it claimed that the reason it's undocumented in VS2005 is
because there are bugs that mean it can do the wrong thing from time
to time--perhaps this is why some people are seeing errors.
It's documented (and supposed to work properly) in VS2008, and I've
been using it for building chromium for many months without any
apparent problems. The ability to do parallel builds of single
projects (rather than merely build projects in parallel) makes it
quite desirable, IMO.
2009/1/6 Brett Wilson bre...@chromium.org:
On Jan 5, 4:32 pm, Brett Wilson bre...@chromium.org wrote:
I just checked in a change to use /MP for all compiles, which is a
secret undocumented flag that does parallel compiles within each
project.
Please let me know of your computer melts or becomes unusable during a
compile. It should more efficiently use all of your CPUs when doing
regular Visual Studio builds (it will have no effect on
IncrediBuilds). You can remove it from essential.vsprops if it's
causing problems.
We tested on Carlos' 2-processor system and it pegged the CPU more,
although it's not clear if it's a lot faster than before. On my
4-processor system, a build of just chrome_exe and all of it's
dependencies went from 25 to 16 minutes after using this flag. So if
you hate IncrediBuild, life might actually be tolerable without it for
fast systems.
This was backed out earlier today due to weird errors, especially with
regard to linking and symbols. Some people have also reported that
Visual Studio can think everything is out of date and rebuilds when
it's not necessary.
If you would like to keep trying this change out, do this locally:
http://chrome-svn/viewvc/chrome/trunk/src/build/internal/essential.vsprops?r1=7533r2=7573
and restart Visual Studio.
Brett
--
char a[9],*p=a;main(c,V)char**V;{char*v=c0?1[V]:V;if(c)for(;(c=*v)93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* drpi...@gmail.combrainf*** program as argv[1] */
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
