[chromium-dev] compile error on Snow Leopard
I get this when compiling unit_tests on Mac OS X 10.6 Snow Leopard: /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689:0 /Users/ph/chromium/src/chrome/browser/cocoa/ bookmark_bar_controller_unittest.mm:689: warning: 'stringWithCString:' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:364) And warnings are treated as errors so it breaks the build. Mac OS X build is healthy on the buildbot, so it's either something on my machine, or the GCC in Snow Leopard has more warnings. Is there some easy workaround? I don't know what's the correct fix for this. --~--~-~--~~~---~--~~ 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: compile error on Snow Leopard
thakis r29990 (http://codereview.chromium.org/336001) -[NSString stringWithCString:] is deprecated as of Mac OS X 10.4. The replacement is -[NSString stringWithCString:encoding:]. We also have base::SysUTF8ToNSString from base/sys_string_conversions.h. Mark Paweł Hajdan Jr. wrote: I get this when compiling unit_tests on Mac OS X 10.6 Snow Leopard: /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689:0 /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689: warning: 'stringWithCString:' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:364) And warnings are treated as errors so it breaks the build. Mac OS X build is healthy on the buildbot, so it's either something on my machine, or the GCC in Snow Leopard has more warnings. Is there some easy workaround? I don't know what's the correct fix for this. --~--~-~--~~~---~--~~ 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: compile error on Snow Leopard
Sorry 'bout that. FIxing. On Sat, Oct 24, 2009 at 11:33 AM, Mark Mentovai m...@chromium.org wrote: thakis r29990 (http://codereview.chromium.org/336001) -[NSString stringWithCString:] is deprecated as of Mac OS X 10.4. The replacement is -[NSString stringWithCString:encoding:]. We also have base::SysUTF8ToNSString from base/sys_string_conversions.h. Mark Paweł Hajdan Jr. wrote: I get this when compiling unit_tests on Mac OS X 10.6 Snow Leopard: /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689:0 /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689: warning: 'stringWithCString:' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:364) And warnings are treated as errors so it breaks the build. Mac OS X build is healthy on the buildbot, so it's either something on my machine, or the GCC in Snow Leopard has more warnings. Is there some easy workaround? I don't know what's the correct fix for this. --~--~-~--~~~---~--~~ 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: compile error on Snow Leopard
Done. Is SL a supported platform for building? If so, should we have an SL buildbot? On Sat, Oct 24, 2009 at 11:39 AM, Nico Weber tha...@chromium.org wrote: Sorry 'bout that. FIxing. On Sat, Oct 24, 2009 at 11:33 AM, Mark Mentovai m...@chromium.org wrote: thakis r29990 (http://codereview.chromium.org/336001) -[NSString stringWithCString:] is deprecated as of Mac OS X 10.4. The replacement is -[NSString stringWithCString:encoding:]. We also have base::SysUTF8ToNSString from base/sys_string_conversions.h. Mark Paweł Hajdan Jr. wrote: I get this when compiling unit_tests on Mac OS X 10.6 Snow Leopard: /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689:0 /Users/ph/chromium/src/chrome/browser/cocoa/bookmark_bar_controller_unittest.mm:689: warning: 'stringWithCString:' is deprecated (declared at /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSString.h:364) And warnings are treated as errors so it breaks the build. Mac OS X build is healthy on the buildbot, so it's either something on my machine, or the GCC in Snow Leopard has more warnings. Is there some easy workaround? I don't know what's the correct fix for this. --~--~-~--~~~---~--~~ 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: compile error on Snow Leopard
Nico Weber wrote: Is SL a supported platform for building? Certainly. If so, should we have an SL buildbot? Yes, but Tom and I have other priorities right now. We should have 10.6 bots running next month. Mark --~--~-~--~~~---~--~~ 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: revising the output from run_webkit_tests
Sure. I was floating the idea first before doing any work, but I'll just grab an existing text run and hack it up for comparison ... -- Dirk On Fri, Oct 23, 2009 at 3:51 PM, Ojan Vafai o...@chromium.org wrote: Can you give example outputs for the common cases? It would be easier to discuss those. On Fri, Oct 23, 2009 at 3:43 PM, Dirk Pranke dpra...@chromium.org wrote: If you've never run run_webkit_tests to run the layout test regression, or don't care about it, you can stop reading ... If you have run it, and you're like me, you've probably wondered a lot about the output ... questions like: 1) what do the numbers printed at the beginning of the test mean? 2) what do all of these test failed messages mean, and are they bad? 3) what do the numbers printed at the end of the test mean? 4) why are the numbers at the end different from the numbers at the beginning? 5) did my regression run cleanly, or not? You may have also wondered a couple of other things: 6) What do we expect this test to do? 7) Where is the baseline for this test? 8) What is the baseline search path for this test? Having just spent a week trying (again), to reconcile the numbers I'm getting on the LTTF dashboard with what we print out in the test, I'm thinking about drastically revising the output from the script, roughly as follows: * print the information needed to reproduce the test and look at the results * print the expected results in summary form (roughly the expanded version of the first table in the dashboard - # of tests by (wontfix/fix/defer x pass/fail/are flaky). * don't print out failure text to the screen during the run * print out any *unexpected* results at the end (like we do today) The goal would be that if all of your tests pass, you get less than a small screenful of output from running the tests. In addition, we would record a full log of (test,expectation,result) to the results directory (and this would also be available onscreen with --verbose) Lastly, I'll add a flag to re-run the tests that just failed, so it's easy to test if the failures were flaky. Then I'll rip out as much of the set logic in test_expectations.py as we can possibly get away with, so that no one has to spend the week I just did again. I'll probably replace it with much of the logic I use to generate the dashboard, which is much more flexible in terms of extracting different types of queries and numbers. I think the net result will be the same level of information that we get today, just in much more meaningful form. Thoughts? Comments? Is anyone particularly wedded to the existing output, or worried about losing a particular piece of info? -- Dirk --~--~-~--~~~---~--~~ 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: Flaky layout tests and WebKit Linux (dbg)(3)
On Fri, Oct 23, 2009 at 2:16 PM, Andrew Scherkus scher...@chromium.orgwrote: On Fri, Oct 23, 2009 at 12:28 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Fri, Oct 23, 2009 at 12:21 PM, Andrew Scherkus scher...@chromium.orgwrote: I've never witnessed these tests taking an extra 10-20 seconds on my local machine, no. I don't doubt that some of the tests might be flaky themselves, but that machine does run tests slower. Take a look at the SVG tests, for example: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests=LayoutTests%2Fsvg Are there other tricks I do on my local machine to simulate running on the bots? I usually try to test for these things by maxing out my CPU then running layout tests but even then they run smoothly. This machine is one of the oldest linux machine we have in the lab. I'll recreate it, make sure it run fast, and see if it helps. Thanks Nicolas. I changed the machine, and so far so good. The time to run the layout tests on this machine went from 11minutes to 5 minutes. Looks like something was wrong on the machine after all. There are still some flakiness... but at least they are not TIMEOUT. Thanks Nicolas I'm wondering if it's slow disk access... know of any simple commands I can use to simulate disk thrashing? Nicolas Andrew On Fri, Oct 23, 2009 at 12:02 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Fri, Oct 23, 2009 at 11:59 AM, Andrew Scherkus scher...@chromium.org wrote: I've been trying to get the media layout tests passing consistently, but WebKit Linux (dbg)(3) takes an absurdly longer time to run tests and I don't know why. For example: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html#tests=video-played To keep the tree green (and collect data), I've marked all media layout tests on Linux debug as pass/fail/timeout. My hope is if the bot was less bogged down, it would lead to faster build times (GTTF) and less flaky results/timeouts (LTTF). This machine is supposed to be fast. Are you saying that this flakiness never happens on your machine? Are you sure the bot is really to blame here? Nicolas Any ideas? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
