Re: [chromium-dev] Re: try failure for 'pinkerton: appmode' try job on win @ r36656
DownloadFilename is a strings error, the bot needs a clobber. We had this on the main waterfall yesterday morning also and the few that saw it got fixed by a clobber. TVL On Thu, Jan 21, 2010 at 9:36 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: [+chromium-dev and sheriffs] These are flaky tests. It is disturbing since there is a crash in a really normal UI workflow (bookmarks) Whoever knows about these tests should work on fixing these or putting these as flaky (except the last one since it's a crasher): - DownloadManagerTest.TestDownloadFilename - BookmarkCodecTest.PersistIDsTest - BookmarkContextMenuTest.DeleteURL M-A On Wed, Jan 20, 2010 at 5:16 PM, Mike Pinkerton pinker...@chromium.orgwrote: I don't see how these tests could fail with my (effectively) mac-only change. On Wed, Jan 20, 2010 at 5:14 PM, tryser...@chromium.org wrote: http://build.chromium.org/buildbot/try-server/ TRY FAILED *If you think the try slave is broken (it happens!), please REPLY to this email, don't ask on irc, mailing list or IM.* Thanks! http://build.chromium.org/buildbot/try-server/builders/win/builds/15281 win Build 15281http://build.chromium.org/buildbot/try-server/builders/win/builds/15281 'pinkerton: appmode' try job svnkill stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/shell_1/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/shell_2/logs/stdio update patchhttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/gclient/logs/patch stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/gclient/logs/stdio compile stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/compile/logs/stdio Start Crash Handler stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/Start%20Crash%20Handler/logs/stdio check deps stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/check%20deps/logs/stdio ipc_tests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/ipc_tests/logs/stdio installer_util_unittests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/installer_util_unittests/logs/stdio sync_unit_tests 1 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/sync_unit_tests/logs/stdio unit_tests did not complete failed 2 stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/unit_tests/logs/stdio PersistIDsTesthttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/unit_tests/logs/PersistIDsTest TestDownloadFilenamehttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/unit_tests/logs/TestDownloadFilename app_unittests 1 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/app_unittests/logs/stdio ui_tests 27 disabled 38 flaky failed 1 stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/ui_tests/logs/stdio FLAKY_LocationReplacehttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/ui_tests/logs/FLAKY_LocationReplace test_shell_tests 2 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/test_shell_tests/logs/stdio webkit_unit_tests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/webkit_unit_tests/logs/stdio base_unittests 1 disabled 2 flaky stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/base_unittests/logs/stdio net_unittests 7 disabled 7 flaky stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/net_unittests/logs/stdio googleurl_unittests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/googleurl_unittests/logs/stdio media_unittests 1 disabled stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/media_unittests/logs/stdio printing_unittests stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/printing_unittests/logs/stdio browser_tests 1001 flaky failed 1 stdiohttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/browser_tests/logs/stdio FLAKY_Popuphttp://build.chromium.org/buildbot/try-server/builders/win/builds/15281/steps/browser_tests/logs/FLAKY_Popup FAQ: http://dev.chromium.org/developers/try-server-usage -- Mike Pinkerton Mac Weenie pinker...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing
Re: [chromium-dev] How to rebuild after modifying extension_api.json?
Actually, it think it's sorta captured -- chrome.gyp has chrome_resources_inputs, which is created by running a script to figure out the input from the grd files. Looking at my xcode project, there is a dependency on common/extensions/api/extension_api.json for the grd files listed in chrome_resources_grds. TVL On Fri, Jan 15, 2010 at 12:50 PM, Evan Martin e...@chromium.org wrote: On Fri, Jan 15, 2010 at 9:19 AM, Dominic Mazzoni dmazz...@google.com wrote: I've observed that after modifying extension_api.json and rebuilding on Linux (using make via distcc), often the entire extension api stops working, with no error message. A clean build always solves the problem. Is there some file I need to touch after modifying extension_api.json in order for the correct dependencies to rebuild? $ git grep extension_api.json -- '*.gyp*' | wc -l 0 That is, this file is not ever mentioned to the build system. The problem is that a .grd file uses the .json file when building but that isn't explicitly told to gyp. In C++ we rely on the per-platform build system to figure out they do the same thing (an #include); for gyp we should just require people to keep the gyp file in sync. The place to look at fixing this is the .gyp* files where common_resources.grd is built; it should list this .json file as an input and it doesn't. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: Running Chromebot on official builds from trunk
On Wed, Dec 30, 2009 at 10:42 PM, John Grabowski j...@chromium.org wrote: Your log seems fine so it's probably not the Avi/Trung/breakpad bug. I'm not aware of any case where Chrome launches 'ps' other than about:memory (Mac only). Some quick tests with about:memory on 249.30 do not create ps zombies. I could not see any obvious path in base/process_util_posix.cc's GetAppOutputInternal() which would not hit the wait() call. Nirnimesh, are you using about:memory? Do you know of a trigger for 'ps' process creation or zombification? The default max procs per userid on 10.5.8 is 266. With ~20 Chromes and 10 tabs each you're starting to get real close. Perhaps that's the real problem? Heck, if you add in plugin processes (flash), and you've probably hit it. Maybe as plugin support got better, that's what caused you to run into it? TVL jrg On Wed, Dec 30, 2009 at 1:13 PM, Nirnimesh nirnim...@google.com wrote: +chromium-dev. This is mac only. Trung, Mark: I did see ps zombies, but they were from my long-standing chrome, not from chromebot. I'm on 10.5.8. Kris: I'm pretty sure chromebot worked fine on the 249 branch, at least until 2 weeks ago. TVL: Time Machine is off and /Library/Preferences/com.apple.TimeMachine.plist is modest. I run chromebot with each chrome instance running with its own profile dir. John: output of launchctl bslist over time attached. It goes from 196 to a high of 244. Is this significant considering there are 20 instances of chrome running? This number does however go down when chromebot kills some chrome processes and then climbs back again when new instances are fired. I did notice one other interesting thing related to ps. As long as chromebot runs, there were a number of stuck (though not zombies) ps processes. Any additional ps commands in terminal gets stuck too. On Wed, Dec 30, 2009 at 10:37 AM, Viet-trung Luu v...@google.com wrote: There may be several (possibly related) problems. I'm definitely seeing zombie ps-es on 249.43 (the released beta). What Nirnimesh said about not being able to fork processes (until Chrome gets killed) could be caused by zombies. Is anyone else seeing zombies? - Trung On Wed, Dec 30, 2009 at 1:28 PM, Thomas Van Lenten thoma...@google.com wrote: On Wed, Dec 30, 2009 at 1:22 PM, Kris Rambish kr...@google.com wrote: A few questions: - Does this happen with the 249 (Beta) branch? - Do we know when this has gotten worse on TOT? + If we don't, does it make sense to fire up 15 minis with different builds and see where it breaks/gets worse? Look at /Library/Preferences/com.apple.TimeMachine.plist, how big is it? When you run chromebot, what do you use for profile dirs? TVL Kris On Wed, Dec 30, 2009 at 12:33 AM, Viet-trung Luu v...@google.com wrote: We're (or at least I am) seeing ps zombies (which I thought had been resolved). See http://code.google.com/p/chromium/issues/detail?id=28547#c29 (I see it on 10.5.8 also). Anyone who has the cycles-- please feel free to investigate - Trung On Wed, Dec 30, 2009 at 3:08 AM, John Grabowski j...@google.com wrote: I agree; this sounds a lot like the Avi bug (worked around by trung on http://crbug.com/28547). Nirnimesh: you can test this by doing a launchctl bslist | wc -l and see if that number keeps rising to infinity (at which point the system chokes). jrg On Tue, Dec 29, 2009 at 9:01 PM, Thomas Van Lenten thoma...@google.com wrote: I think there is a fix/hack on trunk for the issue Avi had brought up. Are they really stuck, or are they just really slow to respond? This could be the issue we are seeing with browser_tests and some of the perf tests where things are getting slower with time. What really confuses me here, is the reference build doesn't show this problem, and it's been updated to be a build from within the range that started showing this slowdown with time... TVL On Tue, Dec 29, 2009 at 11:52 PM, Nirnimesh nirnim...@google.com wrote: Here is what happens when running chromebot on builds from the trunk for some time now: Chromebot fires off 20 instances of Chrome. It starts off fine but within a few minutes you cannot do anything on the machine and chrome too appears to be hung (until it gets killed by chromebot). Until then you cannot fork any processes, cannot launch any app, nothing. Is this similar to the other bug in beta about running out of resources (which avi brought up), or does this sound different? Thanks -- ../NiR -- ../NiR -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Embedding chrome.pak in the chrome binary for Linux?
[From the right address this time] There is a pak file for each language, so you'd have in include all language pak files in the binary, and only one would be used at any given time, so there would be some overhead as far a memory, etc. TVL On Sat, Dec 12, 2009 at 7:52 AM, Satoru Takabayashi sato...@chromium.orgwrote: The chrome binary for Linux seems to load resource bundles from a file named chrome.pak, while the resource booundles are embedded in the chrome DLL in other platforms (correct me if I'm wrong). This makes me wonder if it's a good idea to embed chrome.pak in the chrome binary for Linux. This would save open+mmap cost (probably negligible though), and would make the package a bit simpler. I guess it can be done with objcopy, without too much work. Any thoughts? Satoru -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Fwd: [chromium-dev] Where buildbot outputs the intermediate builds?
repost from right account... -- Forwarded message -- Date: Tue, Dec 1, 2009 at 10:50 AM Subject: Re: [chromium-dev] Where buildbot outputs the intermediate builds? To: robj.pe...@gmail.com Cc: Chromium-dev chromium-dev@googlegroups.com On Tue, Dec 1, 2009 at 10:27 AM, Roberto robj.pe...@gmail.com wrote: Are the buildbots archiving the intermediate builds before building the final executable? If they do, where are they saving them? are they available to download? I don't believe we save all of them, some might get included in what is liked to off the waterfall. If they don't, it would be pretty good if the masters of buildbots could assist in this topic :) As we talked in this thread: http://groups.google.com/group/chromium-dev/browse_thread/thread/301e4963629ce6bb/03e5d21c77d6f9a1#03e5d21c77d6f9a1 It would be quite useful in order to avoid the first big and time- consuming build. So the first issue is probably disk space it would take, especially for debug bits, we would quickly chew through a *lot* of disk space. I haven't looked, but how many platform end up with full paths on debug symbols? ie-would they even work? I want to give a try to the possibility of incorporating to the first check out the built libraries for each module. If it works, the next point would be to modify gclient in order to automatically checkout this built libraries as well. So we'd need to have built libraries for just about every possible revision as a checkout point? Even the build bots don't always do that as their cycling can result in a few cls being lumped together for a given spin. The other trick would be to make sure the process by which they get dropped on the local machine works for timestamps with different timezones to make sure it really doesn't rebuild things. The catch is if you have a local edit, and you last changed it before the sync would the built libraries have newer timestamps (because the bot happened to cycle in time), you'd actually want to make sure you get rebuilds for that case. So off the cuff, this sounds like it could be a win, but when weighted against the work it would take and how often it might not find said bits, I'm not so sure. The existing work on the webkit api so that could become a binary we use, is more limited, but seems like it might be a more attainable win. TVL Thanks :) Roberto. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Xcode builds and dependencies
Last week Mark and I talked with someone in Apple's devtools team about some of the dependency problems we've seen in our builds. We have a radar open with some repro steps, but we got a workaround for what we think we're seeing. I just rolled in a GYP change that applies this workaround(*). If you see any new cases where a you have to build twice to get everything rebuilt, please send me an email with what files you edited/changed and the raw build logs/transcripts of the extra builds so I can try to figure out what else might be going wrong and needs extra builds to fix. TVL (*) - The workaround is to move all actions/rules out of targets that compile sources. So you'll see a foo target and foo Support target, where the Support one has the actions/rules and is depended on by the target listed in the GYP file. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Xcode builds and dependencies
On Tue, Nov 24, 2009 at 1:01 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: You mean you implemented http://code.google.com/p/gyp/issues/detail?id=42 but for xcode only? Basically, the work is generator specific, Mark and I had talked about trying to figure out how to do this in the core (in input.py), but the catch the the treating of outputs as sources, that needs to be done in the generators, so there really a good way to deal with it. TVL On Tue, Nov 24, 2009 at 9:51 AM, Thomas Van Lenten thoma...@chromium.orgwrote: Last week Mark and I talked with someone in Apple's devtools team about some of the dependency problems we've seen in our builds. We have a radar open with some repro steps, but we got a workaround for what we think we're seeing. I just rolled in a GYP change that applies this workaround(*). If you see any new cases where a you have to build twice to get everything rebuilt, please send me an email with what files you edited/changed and the raw build logs/transcripts of the extra builds so I can try to figure out what else might be going wrong and needs extra builds to fix. TVL (*) - The workaround is to move all actions/rules out of targets that compile sources. So you'll see a foo target and foo Support target, where the Support one has the actions/rules and is depended on by the target listed in the GYP file. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: 437k files checked out for an official build
Right, but the builds need these files to run the tests to make sure the bits are good. The problem is some tests leave logs and such in the tree after running, if we could ensure nothing changes in the tree, we might be able to change the scripts to simply update. Or maybe we do the same gclient revert the trybots do to make sure it is a completely clean tree for the build. TVL On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow jor...@chromium.org wrote: This is related to the thread (last Friday?) about making a light weight checkout of Chromium the default. Btw a quick look indicates that 100k are Google specific files (hermetic build environment and such). 200k are layout tests. So that leaves only 150k filesprobably many of which are still test related. On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge lafo...@google.comwrote: Howdy, Was just clobbering a build directory this morning, and noticed it was deleting ~437 thousand files from a single Chrome official windows build directory, which took approximately 20-30 minutes to do a delete. Perhaps my view isn't oriented correctly, but this seems like a very high number of files. This isn't a high priority issue for the 4.0 timeframe, indeed may not be a high priority issue at all, but I'd like to turn it over to our developer community to see if anyone has any thoughts on the matter. So w/ that... Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac UI Types
Gentle reminder: NSRect, NSPoint, NSSize are all defined based on CGFloat. In 64bit, this is a double, not a float. So please make sure all code dealing with these is using CGFloat so we don't have issues in the future. TVL --~--~-~--~~~---~--~~ 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: Change to default build architecture
You need it defined when doing the gclient sync/runhooks, not when building. TVL On Sun, Oct 18, 2009 at 12:46 AM, Issac issac.tro...@gmail.com wrote: On Oct 15, 9:27 pm, Antoine Labour pi...@google.com wrote: On Thu, Oct 15, 2009 at 9:04 PM, Michael Moss mm...@chromium.org wrote: On Thu, Oct 15, 2009 at 8:59 PM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpG oogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES=target_arch=ia32, of course. I haven't looked into it yet, but NaCl apparently has it's own notion of target_arch. For now, the best bet is probably explicitly setting GYP_DEFINES as you're doing. Michael You can also disable NaCl with disable_nacl=1 in GYP_DEFINES. I tried both ideas GYP_DEFINES=disable_nacl=1 hammer chrome GYP_DEFINES=target_arch=ia32 hammer chrome but got the same error in both cases: /usr/bin/ld: cannot find - lnpGoogleNaClPluginChrome. In src/build/common.gypi I made this change -'disable_nacl%': 0, +'disable_nacl%': 1, and ran rm -rf src/sconsbuild/Debug/ followed by hammer chrome. It still fails with Copying /usr/local/google/home/issactrotts/dev/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/ id.pak to /usr/local/google/home/issactrotts/dev/home/chrome-svn/ tarball/chromium/src/sconsbuild/Debug/locales/id.pak ... /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status I'll keep looking... --~--~-~--~~~---~--~~ 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: No co-sheriff today
I'll keep an eye on things tomorrow morning (east coast hours). TVL On Thu, Oct 15, 2009 at 4:06 PM, Mark Mentovai m...@chromium.org wrote: I've been sheriffing for Munjal for the past hour, when I found the tree in a bad state. I'm happy to keep helping, but it'd be great if some other folks would step up too. Mark Munjal wrote: I am the only scheduled sheriff today and there is no co-sheriff. I was out for 5 minutes to grab lunch and ran to my desk. The tree became red in the meantime. Sorry for not being thoughful to aks someone to cover for me during those 5 minutes. It would be great if someone can help me out today and tomorrow. --~--~-~--~~~---~--~~ 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: [Mac] Chromium terminates when running from Terminal
How exactly are you launching it? ie-what are you typing into the terminal. it might be the executable path change last night. TVL On Thu, Oct 15, 2009 at 6:07 PM, Mikhail Naganov mnaga...@chromium.orgwrote: Hi all, Starting from today, I can't run Chromium from Terminal, unless I'm running it under gdb. I'm getting the following bunch of error messages (on a Release build): 2009-10-16 01:58:30.040 Chromium[48250:10b] *** Assertion failure in -[BrowserWindowController initWithWindowNibPath:owner:], /SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSWindowController.m:107 2009-10-16 01:58:30.042 Chromium[48250:10b] An uncaught exception was raised 2009-10-16 01:58:30.043 Chromium[48250:10b] Invalid parameter not satisfying: windowNibPath 2009-10-16 01:58:30.043 Chromium[48250:10b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not satisfying: windowNibPath' 2009-10-16 01:58:30.044 Chromium[48250:10b] Stack: ( 2417545195, 2485780027, 2417544651, 2463723204, 2433132475, 36896176, 36889665, 36840062, 36542144, 36543780, 36611717, 36618850, 36622599, 36646971, 35731773 ) Trace/BPT trap If I launch Chromium from Finder, XCode, or under gdb in Terminal, it works fine. I've done a clean rebuild of Chromium, and I'm seeing this behavior on two machines. Does anyone have a similar problem, or maybe have a clue what goes wrong? --~--~-~--~~~---~--~~ 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 get gcl error ['svn', 'cat', somefile]
Not really sure since the snips you list are two different files, but the warning is not about eol-style, it's about lines ending with spaces, looks on the lines listed for things like: [space][space][real_code][space][space][LF] [space][space][LF] And take the spaces at the *end* of those lines out. TVL On Wed, Oct 14, 2009 at 5:13 AM, Tim Steele t...@chromium.org wrote: I'm getting such an error message for 'chrome/browser/sync/resources/merge_and_sync.html' come up after the presubmit checks have run (output shows snip ** Presubmit Warnings ** Found line ending with white spaces in ... chrome\browser\sync\resources\gaia_login.html, line 353 Presubmit checks took 2.2s to calculate. There were presubmit warnings. Are you sure you wish to continue? (y/N): y Got error status from ['svn', 'cat', 'chrome/browser/sync/resources/merge_and_sync.html']: snip svn:eol-style is set to LF for the file, and I went to 'Advanced Save Options' in visual studio, selected LF, and saved, and I still get this error :( Is there something else I can try? On Wed, Jun 10, 2009 at 9:59 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: No, Marc-Antoine will enable a presubmit check today (tentative) so it won't happen anymore. And if you are a git user, ya better not break anything. M-A On Wed, Jun 10, 2009 at 12:32 PM, cpuc...@chromium.org wrote: I spent a ton of time tracking this so for the record: If you made a change to some files and gcl change works but when you try to do gcl upload you get this error: Got error status from ['svn', 'cat', 'somefile'] // Copyright (c) 2006-2009 The Chromim authors .. partial dump of the file here Then there are two likely possibilities: 1) the file somefile has inconsistent line endings in your copy 2) the file somefile has a problem as it exists in the svn server For #1 you can fix in your copy (not my case), for #2 you need to contact Marc-Antoine :) Actually Marc-Antoine will post the magic trick here so he would not get pestered again. --~--~-~--~~~---~--~~ 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: Buildbot upgrade
On Mon, Oct 12, 2009 at 10:45 AM, Nicolas Sylvain nsylv...@chromium.orgwrote: On Sun, Oct 11, 2009 at 6:50 PM, Thomas Van Lenten thoma...@chromium.orgwrote: Looks like the failures link needs to be updated in waterfall header. I'm pretty sure I did, can you show me which one is not updated? http://build.chromium.org/buildbot/waterfall/console, Navigate section in the top left has a failures links. fyi - I updated the Sheriff wiki page on dev.chromium.org. TVL TVL On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ 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: Buildbot upgrade
Looks like the failures link needs to be updated in waterfall header. TVL On Sat, Oct 10, 2009 at 9:25 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: Hello, Today I upgraded buildbot to the latest version. If you have a bookmark for the failures only waterfall, you will need to change it. Previously it was failures=1 and it is now show_events=truefailures_only=true Other than that, nothing should have changed. If you see any issues with the new version, please let me know! Thank you, Nicolas --~--~-~--~~~---~--~~ 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: [mac] Chromium Helper + ffmpeg binary location == no video
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html sorta relative to the thing loading this TVL On Wed, Oct 7, 2009 at 3:52 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: What is @loader_path relative off of? On Wed, Oct 7, 2009 at 12:35 PM, Mark Mentovai m...@chromium.org wrote: My preference would be to place them inside Chromium Framework.framework, then. If you need to, you can put them inside Chromium Helper.app/Contents/MacOS instead, but I'm trying really hard to minimize the amount of stuff inside the app and the helper app. You can get the framework as a bundle from mac_util::MainAppBundle() since r28262. If you put the dylibs in the framework and they depend on one another, you may need to switch them to refer to each other using @loader_path instead of @executable_path. Mark scherkus wrote: On Wed, Oct 7, 2009 at 12:17 PM, Mark Mentovai m...@chromium.org wrote: Which processes need to load these libraries? Render process. Are these libraries loaded at launch time or by dlopen? dlopen() 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: GYP and cross-compiling
It seems like another approach would be to use the target types to indicate if the library or executable is for the host or native (ie-add types for host vs. target), then you could use target_conditions to have different flags. TVL On Wed, Oct 7, 2009 at 10:06 PM, Antoine Labour pi...@google.com wrote: If you don't care about gyp or cross-compiling, you can skip this message. I've been experimenting with adding host support for cross-compiling into gyp. By this, I mean being able to use the cross-compiler to build Chrome, but still using the host compiler for build tools. Regular Chrome, with v8 snapshotting and nacl disabled doesn't currently need this but for example if you enable nacl, or compile the chromeos version you end up building tools necessary to generate headers or source files needed for the target (e.g. protocol buffer compiler). Currently if you use a cross-compiler, those tools are built for the target, so you can't run them. What I've done is tweak the make generator to add an option on every target to compile it for host, target or both. Here are the CLs: - chrome side: http://codereview.chromium.org/265031 - gyp side: http://codereview.chromium.org/271019 Basically on the make generator side, every rule can be duplicated, for the host version and the target version, based on a parameter on the gyp rule (default is target only). Furthermore, cflags, ldflags and libraries are cut into a common part, a host-specific part and a target-specific part. It keeps target objects and host objects in separate trees. It's very crude, but it solves the problem for the protobuf compiler, which is promising. Also, it makes the changes to the gyp definitions extremely simple an non-intrusive (see chrome-side patch) - one of the simplest methods I've ever seen for this sort of things. I think this solution should also fix the nacl issues. I'm not yet sure about v8 snapshotting. Several issues: 1- It's basically a big hack. The level of control between host and target compiles boils down to compile and link flags (and compiler/linker). No way to have different dependencies, different files to compile etc. 2- Generally, target rules depend on other target rules, host rules depend on other host rules. The way you make the bridge (when you need a target rule to depend on executing the host tool) is by having the host tool installed at a particular location, and have the target rule depend on that file (which is the way the protobuf compiler is called now, but that's very limited). 3- Well, it only works for the make build. The current patch probably breaks the scons one. XCode and MSVS should be mostly unaffected - but won't supposrt this, which I don't think is a big deal. Anyway I'm looking for feedback on the above, and guidance on the following: What I'd like to do is find a way to keep a similar syntax for host vs target selection, but change the way cflags etc. differences are dealt with into something that looks more like conditions which would allow more control over deps, sources, etc. which would make it I think a very powerful and general way of dealing with this whole thing. To you gyp gurus, do you see a simple way of doing this ? Thanks, Antoine --~--~-~--~~~---~--~~ 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: library targets with no sources fail to build on OS X
The targets need a type so it knows what to build. I guess the different
generators are defaulting differently.
TVL
On Thu, Oct 1, 2009 at 2:45 PM, brymcq bmcqu...@gmail.com wrote:
I'm working on some code that uses the gyp build system. I find that
there are cases where I want to aggregate several libraries into a
single library target so other clients can depend on one public
library target instead of having to reference a bunch of individual
library targets. For instance I might have:
'targets': [
{
'target_name': 'foo',
'dependencies': [
some deps here
],
'sources': [
some sources here
]
},
{
'target_name': 'bar',
'dependencies': [
some deps here
],
'sources': [
some sources here
]
},
{
'target_name': 'public',
'dependencies': [
'foo',
'bar',
],
},
]
I then have consumers of my library depend on the 'public' target
rather than depending on 'foo' and 'bar'
This actually works fine on Linux and Windows builds, but on OS X
using xcodebuild, my builds fail with:
libpublic.a: No such file or directory
Is there some way to get the xcodebuilds to properly build these stub
libraries that don't have any source files? Does the gyp-xcode
generation code need to change to support 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: Turning on Mac pixel tests! Heads-up!
Avi, thanks! We should also keep an eye on the cycle times for the bots to see how much more time they take with the pixel tests enabled. TVL On Fri, Oct 2, 2009 at 11:55 AM, Avi Drissman a...@google.com wrote: That didn't turn out so bad. Pixel tests turned on as of r27839. The first batch had failures http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5/builds/4417/steps/webkit_tests/logs/stdio but the second one had just a timeout: http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%281%29/builds/4845/steps/webkit_tests/logs/stdio I think that'll do it. Let's let this run for a few cycles and throw flaky tests into the expectations. Avi On Fri, Oct 2, 2009 at 9:52 AM, Avi Drissman a...@google.com wrote: I'm turning on the Mac pixel tests today. There's two parts to this. First is the new expectations (http://codereview.chromium.org/249043) which just adds IMAGE failures and won't affect anything. The second is telling the bots to run the pixel tests (http://codereview.chromium.org/242099) and that might be an issue. If everything goes as planned, no one will notice. If things do not go as planned, the first build after the second checkin might fail with pixel issues. If that happens, blame me. Avi --~--~-~--~~~---~--~~ 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: gclient fails to update gyp files
Did you get any errors in the gclient sync? There is an entry for that dir within the DEPs file. TVL On Tue, Sep 29, 2009 at 12:52 PM, Nebojša Ćirić c...@chromium.org wrote: This is a (read-only) client that synced without problems 4 days ago. Today gclient sync failed with: running '/usr/bin/python src/build/gyp_chromium' in '/home/nebojsa/chromium' Updating projects from gyp files... Traceback (most recent call last): File src/build/gyp_chromium, line 78, in module sys.exit(gyp.main(args)) File src/tools/gyp/pylib/gyp/__init__.py, line 406, in main params, options.check) File src/tools/gyp/pylib/gyp/__init__.py, line 76, in Load depth, generator_input_info, check) File src/tools/gyp/pylib/gyp/input.py, line 1844, in Load depth, check) File src/tools/gyp/pylib/gyp/input.py, line 342, in LoadTargetBuildFile includes, depth, check) File src/tools/gyp/pylib/gyp/input.py, line 342, in LoadTargetBuildFile includes, depth, check) File src/tools/gyp/pylib/gyp/input.py, line 278, in LoadTargetBuildFile includes, True, check) File src/tools/gyp/pylib/gyp/input.py, line 170, in LoadOneBuildFile raise Exception(%s not found (cwd: %s) % (build_file_path, os.getcwd())) Exception: /home/nebojsa/chromium/src/native_client/src/trusted/plugin/plugin_chrome.gyp not found (cwd: /home/nebojsa/chromium) while loading dependencies of /home/nebojsa/chromium/src/chrome/chrome.gyp while loading dependencies of /home/nebojsa/chromium/src/build/all.gyp while trying to load src/build/all.gyp failed to run command: /usr/bin/python src/build/gyp_chromium I am on amd64 machine, Ubuntu 9.04. --~--~-~--~~~---~--~~ 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: gclient fails to update gyp files
It's not in src.chromium.org, it comes in via DEPS: src/native_client: http://nativeclient.googlecode.com/svn/trunk/src/native_cli...@797;, TVL On Tue, Sep 29, 2009 at 3:32 PM, Nebojša Ćirić c...@chromium.org wrote: Hi Nick, As Chris said, src/native_client is missing from the trunk (and I don't have it in my client). Cira On Tue, Sep 29, 2009 at 12:28 PM, Nick Carter n...@chromium.org wrote: FWIW, on my (healthy) client, svn info inside of the native_client dir looks like: ncarter /cygdrive/d/src/crgit/src/native_client/src $ svn info Path: . URL: http://nativeclient.googlecode.com/svn/trunk/src/native_client/src Repository Root: http://nativeclient.googlecode.com/svn Repository UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 Revision: 730 Node Kind: directory Schedule: normal Last Changed Author: kschi...@google.com Last Changed Rev: 728 Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) How does that compare with your checkout? - nick On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić c...@chromium.orgwrote: Still the same message (after gclient sync --force). On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai m...@chromium.orgwrote: gclient may have gotten confused in a previous run. Try gclient sync --force and let us know if you still have a problem with that. 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: gclient fails to update gyp files
We could also make the tarball script remove the None dep at the end so on a sync the person gets the bits? TVL On Tue, Sep 29, 2009 at 4:02 PM, Bradley Nelson bradnel...@google.comwrote: The idea is that nacl will be baked in, and eventually be active by default.They've pared things down a good bit already. How far out of the ballpark is this on size? -BradN On Tue, Sep 29, 2009 at 12:45 PM, Nicolas Sylvain nsylv...@chromium.orgwrote: you need to edit your .gclient and remove the line that says: src/native_client: None Is native_client really required? Why? We don't want to build this by default, do we? it's too big and it does not fit in the tarball, so it has been excluded there. Nicolas On Tue, Sep 29, 2009 at 12:40 PM, Thomas Van Lenten thoma...@chromium.org wrote: It's not in src.chromium.org, it comes in via DEPS: src/native_client: http://nativeclient.googlecode.com/svn/trunk/src/native_cli...@797 , TVL On Tue, Sep 29, 2009 at 3:32 PM, Nebojša Ćirić c...@chromium.orgwrote: Hi Nick, As Chris said, src/native_client is missing from the trunk (and I don't have it in my client). Cira On Tue, Sep 29, 2009 at 12:28 PM, Nick Carter n...@chromium.orgwrote: FWIW, on my (healthy) client, svn info inside of the native_client dir looks like: ncarter /cygdrive/d/src/crgit/src/native_client/src $ svn info Path: . URL: http://nativeclient.googlecode.com/svn/trunk/src/native_client/src Repository Root: http://nativeclient.googlecode.com/svn Repository UUID: fcba33aa-ac0c-11dd-b9e7-8d5594d729c2 Revision: 730 Node Kind: directory Schedule: normal Last Changed Author: kschi...@google.com Last Changed Rev: 728 Last Changed Date: 2009-09-16 14:58:52 -0700 (Wed, 16 Sep 2009) How does that compare with your checkout? - nick On Tue, Sep 29, 2009 at 12:23 PM, Nebojša Ćirić c...@chromium.orgwrote: Still the same message (after gclient sync --force). On Tue, Sep 29, 2009 at 10:53 AM, Mark Mentovai m...@chromium.orgwrote: gclient may have gotten confused in a previous run. Try gclient sync --force and let us know if you still have a problem with that. 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: flaky resource failures
On Thu, Sep 24, 2009 at 6:24 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: On Thu, Sep 24, 2009 at 12:24, Thomas Van Lenten thoma...@chromium.orgwrote: Brad landed support for depending on all the python files that go into grit, so that part would have worked. The not always rebuilding for .h files is the problem. Does it mean we're missing some deps in the gyp files? Shouldn't. The IDEs should be figuring out what .h files are included by each .cc/.m/.mm/.etc and rebuild as needed. TVL --~--~-~--~~~---~--~~ 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: Question about UI and classic views
The other part of this might just be messaging. It's not uncommon for websites to have a link to let users try out the new experience before it launches. And once it does launch, they always seem to include a Check out our new look and cool new features... blurb. So it's sudden switch, but messaged/introduced. At times, we seem to forget the impact of our silent updates. They are great for bug/security fixes, but when we do roll out something like NNTP, it can lead to a 'WTF' moment. For future changes like this, it might make sense to put in messaging for the upgrade so the users get lead through the transition instead of their routine suddenly changing on them. TVL On Fri, Sep 25, 2009 at 10:07 AM, Amanda Walker ama...@chromium.org wrote: On Thu, Sep 24, 2009 at 3:11 AM, Darin Fisher da...@chromium.org wrote: Do websites provide users with previous versions after overhauling their UX? Some do (gmail seems to), but most do not. You just get to surf the latest. Hopefully, the website changes for the better. That's our burden to bear. And other browsers are just a double-click away :-). One difference between the NTP and a random website is that users think of the NTP as their content (see for example the wording in the complaint from Mike's sister at the start of this thread). Web sites that show user-generated (or in this case, user-arranged) content tend to get more complaints about large visual changes than more passive or static sites (example: see all of the uproar whenever Facebook changes their UI). Personally, I like the latest version of the NTP, but I would be wary of lumping it in with websites in general when we're trying to understand user expectations. --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: flaky resource failures
On Thu, Sep 24, 2009 at 3:19 PM, Tony Chang t...@chromium.org wrote: Which build was this? I checked in a change that changes how grit generates IDs. This type of change requires a clobber since I don't think we depend on all the grit .py files. I think these changes are rare enough that we can just clobber as needed. Brad landed support for depending on all the python files that go into grit, so that part would have worked. The not always rebuilding for .h files is the problem. TVL On Thu, Sep 24, 2009 at 12:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Xcode dependency analysis
I've confirmed this with Xcode 3.2; but my suspicion is it also happens with Xcode 3.1.x, just less frequently. In our build process, we run scripts in a few places to generate headers. Those steps are usually done via Actions on targets. We have listed all of the outputs generated so the tool chains can properly track the dependencies and figure out what needs to be rebuilt. It appears that Xcode has some bugs in this space. So it's possible to make changes to the input for one of these scripts (say a GRD files), and on your next build, the script will run to generate the new header, but Xcode appears to be checking the header before the script has run, so it doesn't always rebuild all the sources that include the headers. Most of the time, on the next build, the compiles will happen and your build will be back in a good state. So far my attempts to create a small test case have failed (the exact same setup, just will all the other sources removed, suddenly works). So if you are working on GRDs or localized XIB; and see odds issues with strings, you might have gotten bitten by this, a rebuild should fix it. Failing that, go for a clean build before spending too much time debugging just to make sure you aren't fighting the tool chain. TVL ps-this doesn't seem to be an issue with us missing dependencies for build order, this happens within a single target. I can get it to happen on a 4 core box, so it is not something that only shows with more parallelization. --~--~-~--~~~---~--~~ 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: Link error for KeystoneGlue on mac ui_tests?
The unittest should be able to skip keystone, since it's part of the update system for official builds. Either we have a shim, or we're pulling in something we've been able to avoid in the past. TVL On Sun, Sep 20, 2009 at 12:47 PM, Drew Wilson atwil...@chromium.org wrote: Hi all, I'm trying to fix up some of the worker layout tests. worker_uitests is currently disabled on the mac, and when I enable it in chrome.gyp (it's currently added to the !sources line for the mac version of ui_tests due to broken tests), I get the following link error: Undefined symbols: .objc_class_name_KeystoneGlue, referenced from: literal-poin...@__objc@__cls_r...@keystoneglue in libbrowser.a(about_window_controller.o) This used to work just fine before I synced with the recent chrome.gyp refactoring - anyone have any insights about this before I launch a painful hunt for missing dependencies? -atw --~--~-~--~~~---~--~~ 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: custom built chromium *much* slower than chrome
On Thu, Sep 17, 2009 at 4:41 PM, Rozenkraft rozenkr...@gmail.com wrote: The corresponding revision is not the right revision.Did you try to sync your Chromium source code to the 196 branch? This is the source code used for the 3.x release, not the corresponding revision you mentioned. Many improvements, code and bug fixes were merged into the branch after that revision, so it is not the right one to sync to. The branch is available here - http://src.chromium.org/viewvc/chrome/branches/196/ I downloaded the chrome I wanted to compare to (Stable 3.0.195.21). Then visited about:version, looked at the revision number, 26042, and synced to that revision with gclient sync --revision s...@26042. So, are you saying that about:version is unreliable cause Google manually adds patches after syncing? *confused* No, the revision is right, but that doesn't say what build directory kicked it all off. We don't build releases off the trunk, instead they are off a branch (http://src.chromium.org/viewvc/chrome/branches/), so you need to use the information in right branch at that revision. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Spike in Linux Reference times on Perf tests
A few of the perf runs for linux shows a sudden change in the reference build performance. These show a slow down: Page Cycler Intl2 Page Cycler DHTML These show a speed up/improvement: Page Cycler Moz Page Cycler Intl1 Startup SunSpider V8 Benchmark Page Cycler Morejs The other odd part is the run before these runs show's agl's checkin to move and maybe update the reference builds? So why it took a cycle to show up I'm not sure. TVL --~--~-~--~~~---~--~~ 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: Building Mac Chrome on 10.6 with Xcode 3.2 tool chain
Quick update: Apple has confirms on the Xcode mailing list they are working on the issue. TVL On Mon, Aug 31, 2009 at 2:44 PM, Thomas Van Lenten thoma...@chromium.orgwrote: Just a quick heads up, if you are building on 10.6 with Xcode 3.2, you might hit some hiccups with distributed builds. An all local build seems like it is working ok, but we're seeing a few different issues with distributed builds and Apple's distcc support (not finding remote machines, compiler crashes, etc.). Mark and I are looking to get our heads around it, but it might be safer to turn of distributed builds until we get things sorted out. TVL --~--~-~--~~~---~--~~ 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: Major tab cold regression on mac around r24415
On Wed, Aug 26, 2009 at 12:32 PM, Thomas Van Lenten thoma...@chromium.orgwrote: On Wed, Aug 26, 2009 at 12:28 PM, Evan Martin e...@chromium.org wrote: PS Every time I want to call it the EPIC CHANGE. On Wed, Aug 26, 2009 at 9:27 AM, Evan Martine...@chromium.org wrote: Here's a guess: the history file is restored each time the test runs, and Brett's epoch change means that we need to re-migrate the history file every time we start. (I don't recall how this test works, but it seems logical to test NTP performance you'd want some data that the NTP would make use of...) Wouldn't linux show this data also? or the non theme test also show it? I spoke too soon: http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150 looks like linux also sees it. TVL TVL On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkertonpinker...@chromium.org wrote: If you look at http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150 You'll see a pretty big spike in new tab performance between r24415 and r24419 http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcmode=htmlrange=24415:24419 Anyone know what's going on? This is a very serious regression and there were no Mac-specific changes anywhere in the vicinity that I could see. I filed http://code.google.com/p/chromium/issues/detail?id=20312 to cover the regression. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Major tab cold regression on mac around r24415
On Wed, Aug 26, 2009 at 12:28 PM, Evan Martin e...@chromium.org wrote: PS Every time I want to call it the EPIC CHANGE. On Wed, Aug 26, 2009 at 9:27 AM, Evan Martine...@chromium.org wrote: Here's a guess: the history file is restored each time the test runs, and Brett's epoch change means that we need to re-migrate the history file every time we start. (I don't recall how this test works, but it seems logical to test NTP performance you'd want some data that the NTP would make use of...) Wouldn't linux show this data also? or the non theme test also show it? TVL On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkertonpinker...@chromium.org wrote: If you look at http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150 You'll see a pretty big spike in new tab performance between r24415 and r24419 http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcmode=htmlrange=24415:24419 Anyone know what's going on? This is a very serious regression and there were no Mac-specific changes anywhere in the vicinity that I could see. I filed http://code.google.com/p/chromium/issues/detail?id=20312 to cover the regression. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Stack traces on layout test crashes
ObjC 2.0 apis should provide pretty clean ways to get all the data for ObjC classes, see http://code.google.com/p/google-toolbox-for-mac/source/browse/trunk/Foundation/GTMStackTrace.m(we already use some of GTM in Chrome/Chromium). TVL On Tue, Aug 18, 2009 at 12:16 AM, Viet-Trung Luu viettrung...@gmail.comwrote: I don't know what I was thinking (the only explanation: a moment of severe masochism), but I completely rewrote my Mac-stacktracing patch. It now finds Objective-C symbols too (so, in my limited testing, yields basically the same results as gdb's backtrace). Same place as before: http://codereview.chromium.org/165224 I think I need a drink. - Trung Viet-Trung Luu wrote: Here's a slightly improved (well, much improved, in that it doesn't crash[*]) version, [...] --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac resources and bundles
Anyone adding more resources (xibs, etc.) to the Mac, please remember always fetch them from mac_util::MainAppBundle() (base/mac_util.h) and do *not* use any Cocoa apis that assume [NSBundle mainBundle]. As part of the l10n, packaging, and updating, where resources live and what bundle is running as the main bundle isn't always what you expect. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac l10n Notes
Folks may have noticed the Mac L10n work has started to land in the tree. Apple's normal model of doing L10n would result in a *lot* of nib files for us to maintain, so we're going more our own path so we can reuse the strings in the pak files (generated from the GRDs). I'm putting the details into follow up page on the current UI Localization design doc. Mac specific notes on Chromium UI Localization: http://dev.chromium.org/developers/design-documents/ui-localization/mac-notes We're building on the support in GTM (which was grew out of other products (QSB)). GTM's UI Localization doc: http://code.google.com/p/google-toolbox-for-mac/wiki/UILocalization Anyone working on Mac UI with questions, please feel free to ping me with questions. TVL --~--~-~--~~~---~--~~ 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: tryserver flakiness
On Wed, Aug 12, 2009 at 5:03 PM, Bradley Nelson bradnel...@google.comwrote: That one is know (we have a gyp issue filed from a while back).The problem is that visual studio doesn't detect command line changes (well actually it does as long as you do them in the IDE and don't leave the sln). We believe we can 'fix' this limitation by having gyp emit a file containing command line garp for each project and then having the relevant files treat that as an additional dependency. But its been on the back burner. This doesn't sound like something for GYP to fix, the fix is detecting what visual studio doesn't and clobbering the build. I don't think we want any generators nuking output directories, etc? (the Mac generator doesn't even know about output dirs, the output dirs is completely controlled by the GYP files themselves.) TVL -BradN On Wed, Aug 12, 2009 at 1:59 PM, Jeremy Orlow jor...@google.com wrote: Brad, looks like we might have another dependency bug in GYP? J On Wed, Aug 12, 2009 at 1:57 PM, Michael Nordman micha...@google.comwrote: I just submitted the change that ENABLE's that flag a moment ago... we're clobbering things now On Wed, Aug 12, 2009 at 1:55 PM, Jeremy Orlow jor...@google.com wrote: Clobber needed? I know Michael just enabled this within the last 24 hours. On Wed, Aug 12, 2009 at 1:49 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Just got this on the Windows tryserver: C:\b\slave\win\build\src\chrome\renderer\renderer_webkitclient_impl.cc : error C2220: warning treated as error - no 'object' file generated C:\b\slave\win\build\src\chrome\renderer\renderer_webkitclient_impl.cc : warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but not for current compile render_thread.cc C:\b\slave\win\build\src\chrome\renderer\render_thread.cc : error C2220: warning treated as error - no 'object' file generated C:\b\slave\win\build\src\chrome\renderer\render_thread.cc : warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but not for current compile renderer_glue.cc C:\b\slave\win\build\src\chrome\renderer\renderer_glue.cc : error C2220: warning treated as error - no 'object' file generated C:\b\slave\win\build\src\chrome\renderer\renderer_glue.cc : warning C4651: '/DENABLE_OFFLINE_WEB_APPLICATIONS=1' specified for precompiled header but not for current compile It's a bit annoying... Is it easily fixable? --~--~-~--~~~---~--~~ 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: tryserver flakiness
On Wed, Aug 12, 2009 at 5:32 PM, Bradley Nelson bradnel...@google.comwrote: I would argue this does fall in the domain of something gyp should be able to do. Scons for instance detects when command lines have changed. If I recall correctly, xcode does as well. This wouldn't involve gyp touching the output directory at all, it would be more like how you can list a makefile as an input to some of its own rules. Ok, so the build within Visual Studio is what's actually gonna nuke everything, not the generator run? Yes, that's different and make more sense. It would be nice if you could do this entirely within the GYP files and not extra magic from the generator, but that might not be easily doable. -BradN On Aug 12, 2009 2:22 PM, Thomas Van Lenten thoma...@chromium.org wrote: On Wed, Aug 12, 2009 at 5:03 PM, Bradley Nelson bradnel...@google.com wrote: That one is know ... This doesn't sound like something for GYP to fix, the fix is detecting what visual studio doesn't and clobbering the build. I don't think we want any generators nuking output directories, etc? (the Mac generator doesn't even know about output dirs, the output dirs is completely controlled by the GYP files themselves.) TVL -BradNOn Wed, Aug 12, 2009 at 1:59 PM, Jeremy Orlow jor...@google.com wrote: Br... --~--~-~--~~~---~--~~ 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: Flakiness. Please help.
On Fri, Aug 7, 2009 at 6:46 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: On Thu, Aug 6, 2009 at 5:05 PM, Jeremy Orlowjor...@chromium.org wrote: On Thu, Aug 6, 2009 at 2:02 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Thu, Aug 6, 2009 at 1:05 PM, Scott Violet s...@chromium.org wrote: Not sure, perhaps Huan could answer that. That said, --enable-dcheck certainly works on the Chromium release builds from the buildbot: http://build.chromium.org/buildbot/continuous/LATEST/ . Yes, --enable-dcheck is supposed to be disabled in Google Chrome build. Disabled or optimized out (so all that code isn't in the resulting binary). Hopefully the latter. Optimized out. Actually, it only goes away on Windows at the moment. http://crbug.com/16512 Quick summary from the bug: logging.cc uses a CPP symbol of OFFICIAL_BUILD, which only exists in Windows builds (it's not in GYP it's in props files). mmoss can also expand on what it would take to clean up/use OFFICIAL_BUILD since I believe he's looked into that. Anyway, I made one run at getting it to go away (CL and revert cl are in the bug), but the Mac build started hanging in unittests when these got optimized away, I've made one pass looking for things in DCHECKs that have side effects without any luck. TVL --~--~-~--~~~---~--~~ 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: gcl change that you should be aware of
On Thu, Aug 6, 2009 at 3:51 AM, Adam Barth aba...@chromium.org wrote: Perhaps a better default is to use this behavior when first creating a changelist and to use the old behavior when modifying a changelist. +1 TVL Adam On Thu, Aug 6, 2009 at 12:37 AM, Dirk Prankedpra...@google.com wrote: I also fear that I may have unwanted files sneaking in. This was less of an issue with Perforce since you have to manually 'p4 edit' files first anyway. I'll be curious to see if there's a consensus preference one way or another. Maybe we can make this a gclient config setting or something? -- Dirk On Thu, Aug 6, 2009 at 12:20 AM, Darin Fisherda...@chromium.org wrote: This seemed really great at first, but after some use, I find it a bit frustrating since each time I run gcl change, I now have to be mindful that gcl may add unwanted files to the CL. The only way I've found to avoid this is to make sure that unwanted files are part of a dummy CL :-( -Darin On Wed, Aug 5, 2009 at 5:56 PM, Anthony LaForge lafo...@google.com wrote: Howdy, Quick little change to gcl that everyone should be aware of. When you execute the script it will now automatically pull all physically modified files into the Paths in this changelist section, which means no more copying and pasting the files you changed into your CL. The behavior is closer to that of P4 (where we delete files as opposed to adding them). All the unchanged files are still below. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA --~--~-~--~~~---~--~~ 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: Urgent, a very evil site i think which does evil things (no joke)
On Thu, Aug 6, 2009 at 1:16 PM, Miguel F Mascarenhas Sousa Filipe miguel.fil...@gmail.com wrote: Hi, On Thu, Aug 6, 2009 at 6:08 PM, Jeremy Orlow jor...@chromium.org wrote: Yoav everyone on this thread is a Chromium developer and almost everyone posting in this thread (not me) are some of the top developers working on Chrome and many of them have spent a good deal of time working on sandbox related issues. All of us have a healthy disrespect for the impossible and would definitely like to see plugin's sandboxed by default, but it's a very difficult problem. We're working hard on many fronts like making more stuff possible without plugins (HTML 5), new technologies (NaCl), etc to change the status quo. Sorry to intrude, but can you explain what NaCl are you talking ? Is it this one: http://nacl.cr.yp.to/ And what kind of work/use is being thought for NaCl + chromium. I'm asking this because I've looked at NaCl recently and seems very interesting.. Nope, this one: http://code.google.com/p/nativeclient/ TVL kind regards, I know it doesn't mean much to you, but I've met and/or worked with many of the developers that reached the conclusion that sandboxing plugins isn't practical (at least by default) and I can say that they're not only some of the smartest developers I've ever met, but that the decision was also painful to them. If you wanted to help, patches would be great. But I think it'd also be helpful if you turned it on and filed bugs when you hit compat issues. I'm not sure there's much else to say on the topic... J On Thu, Aug 6, 2009 at 9:50 AM, Adam Barth aba...@chromium.org wrote: I don't really understand why you find Alex's message so frustrating. We'd love to make --safe-plugins the default. One road to getting there is having more people use the option and find the incompatibilities. We'd certainly welcome patches that improve it's compatibility. If we can make it work well enough, then we can turn it on by default and everyone wins. Adam On Thu, Aug 6, 2009 at 9:46 AM, yoav zilberbergyoav.zilberb...@gmail.com wrote: Alex, let me get it, are you part of the chrome team ? i don't recall accusing anyone from chrome but i do recall not liking your reply, so just let me know if you are part of the devs of chrome please i will be honest, if you are, then i think it is time for me to move to a different browser, if you are not then don't decide if i accuse the chrome team or not, let them tell me, and like i said i would remove myself in a second and with no hard feelings -- Miguel Sousa Filipe --~--~-~--~~~---~--~~ 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: gyp failing while triggering gclient sync in linux with git
What version of GYP do you have in tools?
Do you have any GYP_* env var set?
Do you have anything in ~/.gyp/*
TVL
On Thu, Aug 6, 2009 at 11:58 PM, Mohamed Mansour
m0.interact...@gmail.comwrote:
Tonight I was trying to sync my project so I did git pull and it worked
fine, then I did gclient sync as well as --force. But gyp is failing:
m...@m0-desktop:~/chrome/src$ gclient sync found .git directory;
skipping src
running '/usr/bin/python src/tools/gyp/gyp_chromium' in
'/home/m0/chrome'
Updating projects from gyp files...
Traceback (most recent call last):
File src/tools/gyp/gyp_chromium, line 34, in module
sys.exit(gyp.main(args))
File src/tools/gyp/pylib/gyp/__init__.py, line 262, in main
params)
File src/tools/gyp/pylib/gyp/__init__.py, line 75, in Load
depth, generator_input_info)
File src/tools/gyp/pylib/gyp/input.py, line 1644, in Load
LoadTargetBuildFile(build_file, data, aux_data, variables, includes,
depth)
File src/tools/gyp/pylib/gyp/input.py, line 280, in LoadTargetBuildFile
includes, depth)
File src/tools/gyp/pylib/gyp/input.py, line 280, in LoadTargetBuildFile
includes, depth)
File src/tools/gyp/pylib/gyp/input.py, line 224, in LoadTargetBuildFile
includes, True)
File src/tools/gyp/pylib/gyp/input.py, line 129, in LoadOneBuildFile
build_file_data = eval(build_file_contents, {'__builtins__': None},
None)
File /home/m0/chrome/src/chrome/third_party/hunspell/hunspell.gyp, line
4
^
SyntaxError: invalid syntax
failed to run command: /usr/bin/python src/tools/gyp/gyp_chromium
I made sure I have no local changes (fresh out of git)
m...@m0-desktop:~/chrome/src$ git log
commit 0954eb9b2987d50c54cb9c62ba3dfdeec1f1b01b
Author: gspen...@google.com gspen...@google.com
@0039d316-1c4b-4281-b951-d872f2087c98
Date: Fri Aug 7 03:38:01 2009 +
This adds a stub for the mac installer so that the gyp generation won't
fail on Macs.
Review URL: http://codereview.chromium.org/165109
git-svn-id:
svn://svn.chromium.org/chrome/trunk/s...@227170039d316-1c4b-4281-b951-d872f2087c98
But I still get the error. My git status is:
m...@m0-desktop:~/chrome/src$ git status
# On branch trunk# Untracked files:
# (use git add file... to include in what will be committed)
#
# chrome/test/data/layout_tests/LayoutTests/
# valgrind-20090715/
# valgrind.tmp/
nothing added to commit but untracked files present (use git add to
track)
I really don't understand why it is happening, I diffed my hunspell.gyp wrt
to the version online and they are identical.
Any help is appreciated, I would like to work a bit this weekend but
valgrind requires linux and I can't seem to gclient sync it :/
Thanks!
-- Mohamed Mansour
--~--~-~--~~~---~--~~
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: code coverage and browser_tests
I don't think Mac passes browser_test, I believe it hangs. I opened a bug on this a little while ago: http://crbug.com/16322 TVL On Wed, Aug 5, 2009 at 3:49 PM, John Grabowski j...@chromium.org wrote: Sure! For Mac and Linux I expect things will be fine no matter what you throw in. jrg On Wed, Aug 5, 2009 at 12:43 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Thanks. Can I just try adding browser_tests to the list and send you a CL if it works? On Tue, Aug 4, 2009 at 11:33, John Grabowski j...@chromium.org wrote: No. You can find the list of unittest files run by coverage in chrome.gyp; look at the end of chrome.gyp for the coverage target and list of dependencies. I will be spending time on coverage to expand this and fix other related problems (e.g. no win coverage builder yet). jrg On Mon, Aug 3, 2009 at 9:21 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Does code coverage run browser_tests? It seems that not. --~--~-~--~~~---~--~~ 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: Trick question: Who is responsible for repairing a red tree?
One thing the mozilla waterfall has (or did have at one time) is the ability to add comments to any build column/step. I've seen it used so someone can hang a quick comment of reverting or ### pushed with fix. That way right next to a specific problem you can have any extra info, and unlike irc, it's there if you come looking after it's been said. Does it make sense to support something like that? TVL On Wed, Aug 5, 2009 at 5:55 PM, Tim Steele t...@chromium.org wrote: On Wed, Aug 5, 2009 at 2:49 PM, Peter Kasting pkast...@google.com wrote: On Wed, Aug 5, 2009 at 2:45 PM, Tim Steele t...@chromium.org wrote: A constant place to go looking for this would make it easier, at least in my opinion. Like right now I don't know what's up with Chromium Mac (valgrind) or Webkit dbg (12) to name a few; they're red but the tree is open. If you ever see a case like this, go ahead and close the tree yourself until you get an explanation for every bit of redness. Then put the explanation into the tree status. I know people hate having the tree closed, but we need to be hard-nosed about closing it for _anything_ red. This is the approach I default to, because I'm just pessimistic by nature :) I think the one time I closed the tree in the last 5 months was one of these cases, and I was scolded because it wasn't necessary, so in true Pavlovian fashion I'm now afraid to do it again. Nevertheless, dually noted! Maybe just a way to have a bit more verbose tree status? A details link that would just expand below the status header to show the rest of the text? I'll tell you what, I'll build up a bit more experience as a sheriff myself before I start making grand plans to redesign things :) 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] Re: Question about chromium sandbox on Mac OSX
Those constants are pre-configured settings. The NAMED_EXTERNAL flag lets us pass in our own config, which is the renderer.sb. Apple hasn't really documented the file format, but if you do some searching on the web, you'll find some documentation folks have figured out and I believe there was a talk given at one point by some of the Apple folks that work on it. TVL On Thu, Jul 30, 2009 at 2:32 AM, n179911 n179...@gmail.com wrote: Hi, I read this article: http://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing-design It said Mac OSX supports five constants for sandbox access restrictions: * kSBXProfileNoInternet * kSBXProfileNoNetwork * kSBXProfileNoWrite * kSBXProfileNoWriteExceptTemporary * kSBXProfilePureComputation In the renderer, we would probably want to use a combination of kSBXProfileNoNetwork and kSBXProfileNoWrite. If possible, we would like to get by with kSBXProfilePureComputation, Can you please which access restrictions the renderer of chromium is currently set to? I have looked at renderer_main_platform_delegate_mac.mm, which I believe is how/where chromium set the access restrictions to. But from the code, i can't tell which access restrictions it assigns to renderer. int error = sandbox_init(sandbox_profile, SANDBOX_NAMED_EXTERNAL, error_buff); And I have looked at the file 'renderer.sb', it does not contains any of the above 5 access restrictions string either. Thank you for your help. Regards, --~--~-~--~~~---~--~~ 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: packaging, locale .paks
We haven't done the work in the chrome.gyp yet. Some folks where looking at the work. mmoss and mark? TVL On Fri, Jul 24, 2009 at 2:42 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: How do I force scons to build all language .paks, like locales/en-US.pak ? I don't want to build everything. I want to build chrome and all .paks. --~--~-~--~~~---~--~~ 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: avoiding compile failures on buildbot
Just to be complete, linux can have the same issue, and I'd expect Windows also to be able too. This is one class of things the try server doesn't catch because it is building debug/unoptimized. TVL On Wed, Jul 22, 2009 at 10:09 PM, Andrew Scherkus scher...@chromium.orgwrote: On Wed, Jul 22, 2009 at 7:07 PM, Dan Kegel d...@kegel.com wrote: That's consistent with trybots doing debug builds. Uninitialized var warnings only show up in optimized builds, nothing we can do there but turn on optimizations. Gotcha -- thanks for the explanation! Andrew On Thu, Jul 23, 2009 at 2:00 AM, Andrew Scherkusscher...@chromium.org wrote: On a related note, Frank (cc'd) ran into an issue where the mac try bots have a less-strict compiler warning error than the build bots, which led to a broken build once he checked in: http://codereview.chromium.org/155834 Probably a simple config tweak somewhere, but interesting nonetheless. Andrew On Wed, Jul 22, 2009 at 6:19 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 22, 2009 at 5:59 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: One thing that would help us keep the tree more green is avoiding compile failures. A compile failure is very bad, because without binaries the tests can't run, and then we have to wait for all of them to run, which may reveal additional failures etc. I'm actually surprised by some failures on buildbot, but at least one thing was not surprising for me: Windows Release compile failures when the Debug compiles fine (because we don't have Release trybot). How often does something run in Windows when compiled with the release configuration but not the debug? I've definitely seen it, but I'm not sure it's terribly common. My guess is that there are other causes of the build breaking that should be addressed first. Are there any stats on this? My gut feeling is that many of the build breaks are for things that never passed on a try bot. For example, WebKit gardening patches almost never work on the try bots so we just ignore them. I think working on stuff like this will bear more fruit. Not to mention that each bot costs a lot in terms of the machine, power, maintenance time, etc. What do you think? Do you have any ideas how we could avoid more compile failures, even if they are not possible to apply now due to lack of resources? (for example adding trybots, which seems to not happen soon). I was also thinking about allowing simple check-ins when the tree is waiting for cycle state (when the sheriff wants to verify that bots cycle green after a lot of redness). The status would say (Tree closed, waiting for cycle; ask sheriff to commit a simple change), or maybe some abbreviation for that. It would help people getting code in, and the sheriff could require really a lot from that change (like full green trybot pass etc). What do you think about that (especially sheriffs)? I think you can always ask the sheriffs if you can put something small in. I don't see the point of making any such message policy or a convention. That said, unless it doesn't compile or is REALLY obviously OK, I don't think it's a good idea. --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
On Thu, Jul 23, 2009 at 12:00 PM, Dan Kegel d...@kegel.com wrote: On Thu, Jul 23, 2009 at 2:28 PM, Darin Fisherda...@chromium.org wrote: An objdir-ish solution would make sense, except the native build systems we use don't really work in terms of objdirs, so we'd just wind up generating a parallel directory structure with nothing but xcode projects, Makefiles, and other similar junk. Plus, it means that we can't supply a pre-gypped srcdir tarball, which can frustrate the snot out of casual developers. Maybe this could be an optional mode? Perhaps we could use this mode on the build slaves? I forgot to mention that I would personally much prefer this mode than having generated files in my checked out source tree. I guess I'm very accustomed to an objdir solution from my Mozilla days (autoconf). Perhaps this objdir could even be married to the current output dirs used by the builds (xcodebuild, sconsbuild, chrome/Debug, etc.). Indeed. Here's my christmas wish: I'd like gyp and chrome to support cross-compilation, so that I could (on my Linux box) kick off distcc-accelerated builds for all three platforms, each one going into a separate objdir. It's not as farfetched as it sounds; Mac can already be built on Linux, I hear, and a Windows build on Linux is within reach (just have to remove the last bits of ATL and apply some elbow grease, I think). A mac build still needs a Mac to drive it. We simply did the work to distribute the compiling to linux also. But the build is driven by xcode, and you need a bunch of other mac tools for the scripts to be able to invoke. Window is probably in a similar boat, you'd need the tools for compiling resources, etc. That desire is part of what makes me want gyp output to go into objdir -- because gyp's output is going to depend on which platform you're building for. At the moment, each platform is generating a native for a different build system. So the xcode project can live on disk next to the windows solution, and the makefile/scons files too. As far as object dirs go, i believe all three now already write the output into a different directory (supporting both debug and release in there). So the configure world need of different output dirs isn't the exact same situation. TVL - Dan --~--~-~--~~~---~--~~ 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: Generating files in source tree considered harmful
The other thing to remember is the buildbot scripts and a bunch of build scripts on all platforms are full of assumptions about the relationships between projects and the tree. :( TVL On Thu, Jul 23, 2009 at 12:11 PM, Dan Kegel d...@kegel.com wrote: On Thu, Jul 23, 2009 at 9:07 AM, Thomas Van Lententhoma...@chromium.org wrote: Here's my christmas wish: I'd like gyp and chrome to support cross-compilation, so that I could (on my Linux box) kick off distcc-accelerated builds for all three platforms, each one going into a separate objdir. It's not as farfetched as it sounds; Mac can already be built on Linux, I hear, and a Windows build on Linux is within reach (just have to remove the last bits of ATL and apply some elbow grease, I think). A mac build still needs a Mac to drive it. We simply did the work to distribute the compiling to linux also. But the build is driven by xcode, and you need a bunch of other mac tools for the scripts to be able to invoke. OK then, let's make a Mac drive all three builds :-) Window is probably in a similar boat, you'd need the tools for compiling resources, etc. Those are all in. mingw32 is quite complete. At the moment, each platform is generating a native for a different build system. But in the cross-compiling scenario, we'd have gyp generate makefiles for everything. - Dan --~--~-~--~~~---~--~~ 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: valgrind help office hours
On Mon, Jul 20, 2009 at 10:04 PM, John Abd-El-Malek j...@chromium.orgwrote: I have a leak after a check-in. I tried following the instructions on my Linux box, but couldn't (I hardly develop on Linux). jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh tools/valgrind/chrome_tests.sh --generate_suppressions -t ui Usage: chrome_tests.py -b dir -t test [-t test ...] chrome_tests.py: error: no such option: --generate_suppressions I had tried to follow the getting started instructions in installing and building valgrind from source so that it works in ui_tests, but the first line fails for me: jabdelma...@jabdelmalek:/usr/local/google/chrome/src$ sh autogen.sh sh: autogen.sh: No such file or directory Did you checkout the valgrind source into this dir? The directions you're starting with are talking about building it in the directory you downloaded the source too. In a lot of cases, simply by looking at the data from the bots you can see what the leak is likely to be to fix it without having to run locally. When you do need to run it under valgrind, the stdio log from the bot can help give you the command line the bot is using which you can then start with locally. TVL So I'm unable to fix the regressions from my checkin. I think it's difficult to require people to keep the tree green on all these builders, if it's this hard for developers on other platforms to reproduce the problems. On Mon, Jul 20, 2009 at 10:40 AM, Dan Kegel d...@kegel.com wrote: On Mon, Jul 20, 2009 at 3:48 PM, Dan Kegeld...@kegel.com wrote: If you'd like to help with the stability fixit week ( http://code.google.com/p/chromium/wiki/StabilityFixitWeek ) but valgrind is giving you trouble, I'll be available from 10am to 4pm PST today to help; contact me via email, chat, or IRC with your chromium valgrind questions and I'll try to answer them. forgot to mention: my preferred chromium chat is daniel.r.ke...@gmail.com --~--~-~--~~~---~--~~ 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: gyp variants?
One advantage loops might have over this approach is it keeps the support more portable. This approach requires requires invoking a shell, which could be harder to keep portable, no? I was thinking of some cases where a loop that defined actions could be handy, but this style approach might also work for that. TVL On Fri, Jul 17, 2009 at 4:40 PM, Mark Mentovai m...@chromium.org wrote: Michael Moss wrote: I agree. I thought we wanted to avoid that kind of bloat, which is why I went the helper script route instead of pestering for loops. If we add too many features, pretty soon we'll just have scons-NG (not that there's anything wrong with that, but I don't understand that to be the goal of gyp). It's not, but loops weren't supposed to be too ridiculous. I'll reserve further judgment until I've digested what you've come up with for localizations. 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] Mac Valgrind Bots
We've finished the shuffle of the Mac Valgrind bots over to release builds. It looks like some of the slower tests now run 2x as fast, so the cycles types seem to be a lot better (fewer cls per cycle). There are two bots on the main waterfall, and a few more on the fyi waterfall. Nirnimesh Stuart have been doing a great job working through the data on the FYI so we can get those green and move them over where folks will see them. With the faster cycle times, please make sure you help keep an eye on them as cls land. We're still finding some leaks in the System Libs that we have to add suppressions for, but we're also find valid leaks in the core code too. TVL --~--~-~--~~~---~--~~ 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: Mac Valgrind Bots
On Fri, Jul 17, 2009 at 10:31 AM, Dan Kegel d...@kegel.com wrote: On Fri, Jul 17, 2009 at 2:07 PM, Nicolas Sylvainnsylv...@chromium.org wrote: We've finished the shuffle of the Mac Valgrind bots over to release builds. It looks like some of the slower tests now run 2x as fast, so the cycles types seem to be a lot better (fewer cls per cycle). Great! Should we do the same for linux too? We're already running at -O1 on Linux, so there isn't much improvement left to be had, I suspect. It might be worth it, dunno. There is a lot of code cut out by being NDEBUG instead of DEBUG, that's where I think the mac is getting its speed up. Yesterdays mac valgrind runs on the main waterfall were actually -O0 while we waited for the v8 issue to be fixed and they saw that speed up. TVL --~--~-~--~~~---~--~~ 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: How to Generate Visual Studio .SLN file from gyp
sync again, it sounds like your src tree and gyp version are out of sync. TVL On Thu, Jul 16, 2009 at 6:39 AM, zys ziadsall...@gmail.com wrote: Hello You might think that this is a really a stupid question. I have downloaded chrome source code as well as the depot_tools and now I am trying to generate .SLN file for VS2005 However when running gclient runhooks --force I am getting the following error running 'D:\Programs\GoogleChrome\depot_tools\python_bin \python.exe src /tools/gyp/gyp_chromium' in 'D:\Programs\GoogleChrome\home\chrome-svn \tarball\ch romium' D:\Programs\GoogleChrome\depot_tools\python_bin\python.exe: can't open file 'src /tools/gyp/gyp_chromium': [Errno 2] No such file or directory failed to run command: D:\Programs\GoogleChrome\depot_tools\python_bin \python.ex e src/tools/gyp/gyp_chromium I would appreciate if you can guide me to an up-to-date docs on how to generate and build Chrome on VS Thx Ziad --~--~-~--~~~---~--~~ 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: How to Generate Visual Studio .SLN file from gyp
On Thu, Jul 16, 2009 at 8:44 PM, Bradley Nelson bradnel...@google.comwrote: I'm puzzled why src/tools/gyp/gyp_chromium is getting used, as src/tools/gyp/gyp_dogfood is what I would expect. What shows up at the bottom of src/DEPS? (in the run hook) The hook is src/tools/gyp/gyp_chromium, we sorta left the dogfood state a while ago :) and it's role has evolved to the point the work it does is specific to Chromium. So when tweaking something in it for the buildbots the other day, we went ahead and renamed it. TVL -BradN On Thu, Jul 16, 2009 at 10:53 AM, Thomas Van Lenten thoma...@chromium.org wrote: sync again, it sounds like your src tree and gyp version are out of sync. TVL On Thu, Jul 16, 2009 at 6:39 AM, zys ziadsall...@gmail.com wrote: Hello You might think that this is a really a stupid question. I have downloaded chrome source code as well as the depot_tools and now I am trying to generate .SLN file for VS2005 However when running gclient runhooks --force I am getting the following error running 'D:\Programs\GoogleChrome\depot_tools\python_bin \python.exe src /tools/gyp/gyp_chromium' in 'D:\Programs\GoogleChrome\home\chrome-svn \tarball\ch romium' D:\Programs\GoogleChrome\depot_tools\python_bin\python.exe: can't open file 'src /tools/gyp/gyp_chromium': [Errno 2] No such file or directory failed to run command: D:\Programs\GoogleChrome\depot_tools\python_bin \python.ex e src/tools/gyp/gyp_chromium I would appreciate if you can guide me to an up-to-date docs on how to generate and build Chrome on VS Thx Ziad --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New path service constants
If you are adding new path service constants as part of a new feature (ie-adding new directories to the install footprint or a new data dir for storing things in), please make sure you include someone for each platform in the review and call out what the path is for. We've had a few paths added over time that on the Mac that were trying to write directly into the apps install tree, which is not something we can do. TVL --~--~-~--~~~---~--~~ 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: A suggestion to Drastically improve build times,
On Wed, Jul 8, 2009 at 11:03 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I wonder if it would be possible to have a conditional flag, maybe in common.gypi, that you would flip to turn on incremental linking, with still non-incremental linking being the default. Something like this probably makes sense to be a generator flag. I just beefed up the support for these in GYP. A cl for that should be pretty simple. The general build layout changes would be within the GYP files and probably want a flag to enable. TVL On Wed, Jul 8, 2009 at 05:00, nakroyoav.zilberb...@gmail.com wrote: First off, i am not complaining, just suggesting as the build (especially link gets slower and slower) I contribed code before to chrome, and plan to do so in the future, however even changing one line of Code in say browser.vcproj leads to 10+ mins of linking (yes TEN) what i did was wrote scripts which allow me to re-enable incremental linking and i was happy with it since you lately moved to libs for chrome_dll and the like, the process became harder but i still manage to enable incremental linking (there is an option in VS2008 to use objs instead of static libraries which re-enables incremental linking) just to give you a taste of why i say this without incremental linking i get 10+ mins of build time for changing just one line of code with inc linking i am down to ~15 seconds for a simple change,, which is SUCH a great improvement i recall you removed inc linking since some projects (i know of ui_tests) needs more than 2GB for linking but you could just disable it for this one project i hope you will re-consider introducing inc linking on VS thanx (btw, there are issues with re-introducing inc linking as lib and obj rules are different, but they are kinda small) --~--~-~--~~~---~--~~ 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: running browser_tests on more bots
Looks like the tests don't run on the mac, I'll look into that. TVL On Wed, Jul 8, 2009 at 3:17 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Hmmm. They do run on try bots. Oh, indeed. But only on Windows. But I noticed you're working on this, so - seems good. They also do run in debug and release on both vista and xp too on the main watefall. Not sure where you would like to see them. (Except maybe linux and mac... and I need to work on that this week). Yes, it was mostly linux mac question. Thanks for the info. --~--~-~--~~~---~--~~ 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: running browser_tests on more bots
Looks like the tests don't run on the mac, I'll look into that. TVL On Wed, Jul 8, 2009 at 3:17 PM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Hmmm. They do run on try bots. Oh, indeed. But only on Windows. But I noticed you're working on this, so - seems good. They also do run in debug and release on both vista and xp too on the main watefall. Not sure where you would like to see them. (Except maybe linux and mac... and I need to work on that this week). Yes, it was mostly linux mac question. Thanks for the info. --~--~-~--~~~---~--~~ 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: what's difference between master.chromium and master.chromium.fyi?
master.chromium -- http://build.chromium.org/buildbot/waterfall/ master.chromium.fyi -- http://build.chromium.org/buildbot/waterfall.fyi/ From the main waterfall, the experimental link takes to you the fyi one. The fyi waterfall lists the bots that we run, but don't close the tree for. TVL 2009/7/6 Rosail Davis sitan2...@sina.com I saw those in http://dev.chromium.org/developers/testing/chromium-build-infrastructure/getting-the-buildbot-source , and that made me a little curious. --~--~-~--~~~---~--~~ 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: some questions about chrome's layout-test
2009/7/6 David Jones ds...@163.com I have worked on webkit ,though I didn't know much about wekkit's layout-test. I'm curious about chrome's layout-test. -do you take webkit's layout-test into chrome with any changes? I don't think so, so what're these changes? It depends a little on the platform in question. A lot of them run just fine (more so on the Mac), but as you look at other platforms, font metrics tends to make for differences. Also, so tests log javascript errors, and since we use V8, the messages are different. -why simutaneously run 2 test_shell ? for efficiency? The number run depends on the number of cpus your machines has. Yes, we run one test shell per core to finish the tests faster. -while I'm runing run_webkit_test.bat, my DOS always display ERROR as below: 090706 15:37:19 __init__.py:1032 ERROR LayoutTests/fast/backgrounds/svg-as-mask.html failed: Text diff mismatch Image mismatch 090706 15:37:20 __init__.py:1032 ERROR LayoutTests/fast/block/float/013.html failed: Text diff mismatch Image mismatch 090706 15:37:21 __init__.py:1032 ERROR LayoutTests/fast/block/float/nested-clearance.html failed: Text diff mismatch Image mismatch What does that mean? It means those two tests failed to produce the expected results. When done, the summary page should open with a list of any tests that didn't result in the expected way, with links to see the expected, actual and difference in values. Which __init__.py does it use? I find a lot of __init__.py under chromium The python scripts live (mostly) in src/webkit/tools/layout_tests (and the layout_package directory under there). TVL -- 200万种商品,最低价格,疯狂诱惑你http://count.mail.163.com/redirect/footer.htm?f=http://gouwu.youdao.com --~--~-~--~~~---~--~~ 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: some questions about chrome's layout-test
See the expectations file, it lists the ones that are known to fail on a given platform. This is how we easily track new failures. TVL 2009/7/6 David Jones ds...@163.com It means those two tests failed to produce the expected results. When done, the summary page should open with a list of any tests that didn't result in the expected way, with links to see the expected, actual and difference in values. really? While runing layout-test, I always get a lot of ERRORs. But at the end, I get a summary as : Expected to fail, but passed (5): LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html LayoutTests/fast/encoding/invalid-UTF-8.html Expected to timeout, but passed (1): LayoutTests/http/tests/security/credentials-in-referer.html Regressions: Unexpected failures (8): LayoutTests/fast/css/css2-system-fonts.html = FAIL LayoutTests/fast/dom/anchor-toString.html = FAIL LayoutTests/fast/dom/java-applet-calls.html = FAIL LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL LayoutTests/http/tests/security/ cross-frame-access-protocol-explicit-domain.ht ml = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL LayoutTests/plugins/embed-attributes-setting.html = FAIL Regressions: Unexpected timeouts (1): LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = TIMEOUT -- = Tests to be fixed for the current release (786): 88 test cases (11.2%) Passed 364 test cases (46.3%) Skipped 287 test cases (36.5%) Text diff mismatch 190 test cases (24.2%) Simplified text diff mismatch 160 test cases (20.4%) Image mismatch 10 test cases (1.3%) Test timed out 6 test cases (0.8%) Test shell crashed 2 test cases (0.3%) No expected image found = Tests we want to pass for the current release (8984): 8273 test cases (92.1%) Passed 364 test cases (4.1%) Skipped 299 test cases (3.3%) Text diff mismatch 200 test cases (2.2%) Simplified text diff mismatch 164 test cases (1.8%) Image mismatch 11 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found = Tests to be fixed for a future release (0): = All tests (10884): 8752 test cases (80.4%) Passed 2130 test cases (19.6%) Skipped 409 test cases (3.8%) Text diff mismatch 301 test cases (2.8%) Simplified text diff mismatch 183 test cases (1.7%) Image mismatch 12 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found 090706 15:44:24 __init__.py:1032 INFO Exit status: 9 090706 15:44:24 __init__.py:1032 INFO flushing stdout 090706 15:44:24 __init__.py:1032 INFO flushing stderr 090706 15:44:24 __init__.py:1032 INFO stopping http server 090706 15:44:24 __init__.py:1032 INFO Shutting down http server I think that means only 9 ERRORs should happen. Is that a contradiction? puzzled.. -- 200万种商品,最低价格,疯狂诱惑你http://count.mail.163.com/redirect/footer.htm?f=http://gouwu.youdao.com --~--~-~--~~~---~--~~ 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: Number of threads in Render Process on MacOSX
If you look at a lot of Mac executables, you find that the system can create threads in response to same API calls. On the copy of Chrome I'm currently running, I seeing one renderer with 5 threads and another with 6. At quick glance the extra are the OS doing some extra work in response to api calls. TVL On Sat, Jun 20, 2009 at 7:39 PM, n179911 n179...@gmail.com wrote: From this post http://blog.marcchung.com/2008/09/05/chromes-process-model-explained.html, it said Each Renderer process has two threads: one Render thread–which renders web pages, and one IPC thread–which transports data in a thread-safe, non- blocking manner between the Render thread and an IPC counterpart sitting in the Browser process. The Renderer process manages 1 IPC thread and 1 Render thread. But when i see that ActivityMoniter on MacOSX, it has 3 threads: 262 Chromium john 0.0 3 32.77 MB974.34 MB Intel 189 Chromium john 0.4 16 65.57 MB1.03 GB Intel 307 Chromium john 1.3 3 51.77 MB992.93 MB Intel 295 Chromium john 0.0 3 56.07 MB992.88 MB Intel Can you please tell me what is the 3rd thread? Thank you. --~--~-~--~~~---~--~~ 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: IO Request Handing in Chromium
See http://dev.chromium.org/developers/design-documents/plugin-architecturefor some more details. TVL On Fri, Jun 19, 2009 at 1:51 PM, Evan Martin e...@chromium.org wrote: On Thu, Jun 18, 2009 at 12:15 AM, n179911n179...@gmail.com wrote: In http://dev.chromium.org/developers/design-documents/multi-process-resource-loading , all I/O in Render Process (WebKit code) is sent to Browser Process and Browser process is download the resource from the source. But what about Plugins (flash) which runs inside RenderProcess? How can those I/O requests being forward to Browser Process via chromium IPC mechanism? Plugins run in their own separate plugin process. Flash plugins is closed source and it can make more than HTTP request. Flash can make RTMP request for video. How does IO in plugin being handled? Requests made through NPAPI get routed back through the browser's HTTP layer. Other requests go directly to the system, as plugin processes are not sandboxed. (In some sense, getting plugins out of the renderer process is a prerequisite for making renderer processes sandboxable.) --~--~-~--~~~---~--~~ 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: sandboxing external libraries (like Growl)
On Thu, Jun 18, 2009 at 4:58 PM, John Gregg john...@google.com wrote: Hi all, I'm working on a desktop notifications javascript API for web apps; on Mac these calls will go out to the Growl notification system if it's installed and user has granted permission to get notifications from that origin. I'm still trying to completely grasp the sandbox architecture, so the question I need some input on is how to design the integration with respect to sandboxing security. The Growl code that would be included in Chrome is just a stub that works by marshalling data over to a separate Growl process, so the surface area is small, but as a design question, is calling to a third-party library something that should happen in the sandboxed renderer process, or should it be kept in the browser process? One other factor is that the notification requires an icon to be downloaded, which should happen outside the sandbox. So there are two possible flows: A. renderer gets notification(iconURL, text) call = hop to browser to download icon = call Growl from browser B. renderer gets notification(iconURL, text) call = hop to browser to download icon = pass back icon data to renderer = call Growl from renderer My instinct is that B is safer for the remote possibility that Growl chokes on the input and causes a crash. What do people think? Is there an existing precedent for similar library calls? B won't (shouldn't) work because of the sandboxing, if the renderer can talk to the Growl helper app, there's a vector open for talking to any application. TVL Thanks, -John --~--~-~--~~~---~--~~ 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: Makefile build broken
On Thu, Jun 11, 2009 at 12:48 PM, Adam Langley a...@chromium.org wrote: On Thu, Jun 11, 2009 at 8:52 AM, Tony Changt...@chromium.org wrote: Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. I reverted in r18168. It sucks that there's no try or builders for the make build, but it's what everyone uses these days. If the times are really better, we can change the default in gyp, someone just needs to update the buildbot scripts accordingly. TVL AGL --~--~-~--~~~---~--~~ 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: Adding Mac OS X Spellchecker to Chromium
On Wed, Jun 10, 2009 at 2:38 PM, p_W paulwoolcoc...@gmail.com wrote: Forgive my (possibly) stupid concern here, but a few months ago there was some talk about this, and about how integrating with the OS's spellchecker was the preferred route as it allowed users to use their dictionary customizations over all their applications. Here is link to the discussion: http://groups.google.com/group/chromium-dev/browse_thread/thread/31832b99aeb953d7/d722d0f183a0b35f?hl=enlnk=gstq=OSX+spell#d722d0f183a0b35f Any thoughts about this? Uh, that's what this thread is about, his project is to switch to using the os one instead. And Jeremy was commenting that he doesn't need to support both, just switch to the native. Or am I reading this differently? TVL On Jun 9, 9:00 pm, Jeremy Moskovich jer...@chromium.org wrote: A couple more things: * I think ultimately we should support the grammar checker, but at first just getting spellchecking to work would be great! * +1 for supporting the Cocoa gui for spellchecking paragraphs, see the 2nd paragraph bellow for more thoughts on this. Matching Linux Windows functionality is a non-goal IMHO, to reiterate we want to behave like a native Cocoa application. WebKit/Safari already support these features so the issue is to get the plumbing working right in our multiprocess model (which may be non-trivial). IMHO the correct route here is to look at how this is done in WebKit and match the behavior there as much as possible, that's what I'm doing with the keyboard events at the moment and it's proving pretty fruitful. It's really exciting you're working on this!! Best regards, Jeremy On Tue, Jun 9, 2009 at 5:50 PM, Jeremy Moskovich jer...@chromium.org wrote: IMHO there is no need to maintain dual hunspell/OSX spellchecker backends. There are addon OSX spellcheckers for other languages e.g. http://www.mitzpettel.com/software/hspell.php . Writing additional spelling servers is pretty simple so I think the correct approach would be: 1. Getting OSX spelling/grammar checking support working well. 2. If the need arises, wrapping hunspell as an Apple Spelling service and provide it as a separate project users can install. Best regards, Jeremy On Tue, Jun 9, 2009 at 5:32 PM, Paul Wicks pwick...@gmail.com wrote: Crap, sorry to post an incomplete version of this post earlier. Accidentally hit send before I finished it. Argh... Anyway, I've been looking at implementing support for the OS X spellchecker on the Mac build as part of my SoC project and I thought I'd run some thoughts I had today by the list. For the basic design, both hunspell and the os x spellchecker need to be usable, since hunspell supports more languages than OS X does. The public interface of the Spellchecker class is fairly small (mainly 2 methods: SpellCheckWord, AddWord). It seems that mapping these onto the OS X spellchecker shouldn't be too hard. I originally thought to do something more elaborate and create seperate spellchecker classes for each platform, but then realized that I could do it more simply as follows: -leave the majority of spellchecker.cc as is. It works and I don't see any reason to mess with what works. -for SpellCheckWord, change the call to hunspell_-spell(...) to call a (new) private method in the SpellChecker class. In this method, add some code at the beginning that will check if we are on the mac and if the built-in spellchecker supports the current language and if so checks the word using it, other wise using hunspell as before. This way, we can leave the rest of the code alone and still use the SpellCheckWordIterator to grab individual words out of the string. As for getting the suggestions for a word, it might make sense to do things a little differently, since there is no need to create and manage the char** suggestions variable to pass to hunspell, as NSSpellChecker can give us an easy-to-iterate-through NSArray. Probably just an #if defined(OS_MACOSX) would suffice here, since the code here will be wholly different. -for AddWord, their probably isn't as much of a need to abstract the hunspell specific code (it's all hunspell code), so just an #if defined( OS_MACOSX)+language support check would suffice. -The other public methods all deal with language selection and querying, which should remain the same, since the OS X spellchecker only supports a subset of the languages supported by hunspell. (there may need to be a little bit of code to translate between the codes for supported languages so that the built-in spellchecker always gets used when it should, but this should be a relatively simple matter. -The private method IsValidContraction could call the same new private method as defined above. -This way, the public interface stays the
[chromium-dev] Re: confused with chrome's version control
From the very end of http://dev.chromium.org/developers/how-tos/get-the-code gclient sync --revision s...@ TVL On Tue, Jun 9, 2009 at 9:27 AM, Jickae Davis jick...@gmail.com wrote: And I also encountered a new question. How to update to certain revision of different kinds(snapshot/continuous/tarball). For example, I want chrome r17830 of snapshot/continuous/tarball. --~--~-~--~~~---~--~~ 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: Does anyone have objections to adding a GetSwitchValues() accessor to CommandLine?
On Wed, Jun 3, 2009 at 12:06 AM, Book'em Dano daniel.c...@gmail.com wrote: Does anyone have objections to including such a function? It would just return a copy of std::mapstd::string, StringType switches_; I'd like to add such a function so that I can iterate over the command line args (both switches and loose values) and validate that only expected values are present. How do you decide what is unexpected? The current system allows any part of the code to define and use switches. TVL -D --~--~-~--~~~---~--~~ 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 there any way to profile chromium on MacOS?
On Tue, Jun 2, 2009 at 12:25 PM, Lucius Fox lucius.fo...@gmail.com wrote: I can build and debug TestShell project. But can you please tell me how to attach appropriate renderer with Shark? What is an appropriate renderer? TestShell doesn't do the out of process model, all rendering is done inproc with TestShell. TVL On Mon, May 25, 2009 at 7:37 AM, Mike Pinkerton pinker...@chromium.org wrote: You can always attach to the appropriate renderer with Shark. Does that not fit the bill? On Sat, May 23, 2009 at 3:53 AM, lucius lucius.fo...@gmail.com wrote: Hi, Does chromium have build in profiling? e.g. can I find out the break down in html processing, css processing, js processing for each page load? or can i run chromium with some profiling tool on MacOS to understand the bottleneck? Thank you. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ 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: Which is the Xcode project for chromium on MacOS
On Tue, May 26, 2009 at 1:37 PM, Daniel Dreiberg daniel.dreiber...@gmail.com wrote: Hi, Can you please tell me where i can find Xcode project for chromium on MacOS? I tried $chromium_src_root/src/chrome/chrome.xcodeproj, but that does not seem to have html parser code, javascript engine code, css engine code. I would like to 'open an URL' and debug code in html parser code or javascript engine code or css engine code for that particular page. You'll notice other projects referenced by that project; specifically, V8, WebKit... TVL Thank you. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Process Names
Just a quick heads up, later today I'll be landing some initial fixes for code that cared about the application's name. If you find yourself needing this, look carefully at why and what you're using. The Mac version is going to need a little more work to get the final branding right in all places (on disk, dock, menu bar, etc.). But that's a little further out in my queue (and if/when we have to give the renderer a different bundle for info.plist it will get even more complex). TVL --~--~-~--~~~---~--~~ 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: chromium resources always rebuilding
The deps for all the files generated is a problem, Mark and I have talked
about it a few times, but haven't come up with something complete for it
yet, hopefully it will pop back up on our queues shortly so we can figure
out something more complete.
TVL
On Mon, Apr 27, 2009 at 6:14 PM, Evan Martin e...@chromium.org wrote:
PS: here's a hack I did in make.gyp to output a rule that manually
touches the output file to work around this. Perhaps you could do
something in your Xcode generator to work around it for now.
# Deep inside the rules conversions code path:
if name == 'resources_grit':
# HACK: This is ugly. Grit intentionally doesn't touch the
# timestamp of its output file when the file doesn't change,
# which is fine in hash-based dependency systems like scons
# and forge, but not kosher in the make world. After some
# discussion, hacking around it here seems like the least
# amount of pain.
fp.write('\...@touch --no-create $...@\n')
On Mon, Apr 27, 2009 at 3:12 PM, Evan Martin e...@chromium.org wrote:
The build system has a generation dependency path like this:
1) final output depends on
2) grit header and cc, which depends on
3) grit input .grd file, which depends on
4) theme resources
This means whenever you tweak theme resources, you cause a recompile,
even when the .cc and .h in (2) don't change. So Glen requested Tony
change grit to not touch the outputs if their contents don't change,
and that's what's causing the problem.
This works fine for scons (because it uses file content hashes to
compute whether dependencies need rebuilding), but breaks systems
(including make and Xcode) that rely on file timestamps. Why?
Because you end up with the timestamp of 3 being newer than the
timestamp of 2, so the dependency checker thinks you always need to
re-run grit to convert 3=2.
The symptom you get is that grit runs every time you build.
I think the correct fix is to make grit just modify the output files,
like every other program does. Sorry, Glen.
--~--~-~--~~~---~--~~
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: Changes to FilePath?
On Tue, Apr 28, 2009 at 4:39 PM, Greg Spencer gspen...@google.com wrote: Hi Chromium Developers, I'm working on Google's O3D (http://code.google.com/p/o3d), and we (naturally) share some of Chrome's base classes for our code, including the very useful class FilePath. However, in using FilePath in the last few months, I've seen that it needs some refinement. I'd like to augment the FilePath class with some things that would make it more generally useful -- it's very nicely set up, but it's missing a few things that make it harder to work with than it needs to be: 1) I'd like to add some explicit routines for converting to/from UTF8 and UTF16. While it's nice (and important) that FilePath uses the platform's native string, we've found that many third party libraries have made other assumptions, where they always expect UTF8 (char) or UTF16 (wchar_t) paths regardless of platform, and converting a FilePath to and from those forms is a platform-dependent exercise which should be centralized into the class (i.e. adding ToUTF8 and ToWide functions to the class, and explicit constructors that take each type). 2) I'd like to make it possible to instantiate a POSIX FilePath object on Windows and a Windows FilePath on POSIX platforms. This is because some libraries (e.g. the zip library, or tar files), use POSIX semantics for their paths even on Windows (I haven't seen a use case for Windows paths on POSIX yet, actually). This would make it possible to use the nice API that FilePath has to manipulate paths appropriately for these other libraries. This could be easily accomplished by having POSIX and Windows versions of FilePath, and then typedef'ing FilePath differently on different platforms to one of these versions. 3) It would be helpful to have real path normalization for each of the platforms (although I know what a testing nightmare that can be). I might try and tackle this if people think it would be beneficial. 4) Make sure we handle case sensitivity vs case preservation correctly. It's unclear to me that FilePath does this correctly on the Mac -- Mac file names are case preserving, but case insensitive, Unix filenames are both (and windows filenames are neither :-). FYI - it's a drive format time option on the Mac, so they can be case preserving and case sensitive. TVL So, is there any resistance to any of the above? Do you have other suggestions that I might take into account? Am I violating any design assumptions of FilePath? For #2, is speed/size enough of a concern to avoid a virtual base class (I wouldn't think so, but you never know..)? -Greg. --~--~-~--~~~---~--~~ 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: Crossplatform ProcessSingleton and ChromeBrowserProcessId()
On Fri, Apr 24, 2009 at 4:55 PM, Никита Офицеров himi...@gmail.com wrote: There are now different platform-dependent ways to ensure that only one instance of Chrome is running, and to get its pid. I think that there is a way of accomplishing both goals in a cross-platform way, reusing existing IPC system. I'll try to explain how IMO things are now, and why this might be not the best way: Now: 1. Windows Hidden top-level window is used for getting Chrome pid and IPC on startup. This is actually reinventing IPC over window messages with custom protocol. 2. Linux UNIX socket is used for IPC on startup, and fuser program is launched on it to get the pid - IMHO not the best way to do it. 3. Mac There is now ProcessSingleton on Mac, as it's not needed. Some hack on ps output is used to get the pid. So there are 3 different implementations, and not very optimal ones. Same effect could be acieved by this method: Don't try to get pid dynamically, but create on startup in datadir file 'ChromePid' or something like that with pid. Also, create an IPC channel with channel_id equal to pid with forced FIFO mode on POSIX. Current POSIX implementation should be modified to allow this and to store socket in datadir, not in /var/tmp. Then ProcessSingleton check would be simple and crossplatform: find pid file, read pid, connect to channel, send some message and wait for response. This eliminates all differences between platforms in process_singleton_* and chrome_process_util_*. What do you think? I think the first question is what do we need/usr singleton for? Rather than ensure it's the same/common/etc. on all platform, it seems like a case where stepping further back and seeing why it's used might be more important. For the cases where it's used to handle off shortcut urls to an always running instance, that's not needed on the Mac as Launch Services already does that. I don't know, but there might be better ways on Linux for dealing this this the the current Windows model. I believe the unittests use it to see if something is already running with a given profile, a slightly different need. Cleaning up the calling places to have specifically defined needs might not result is needing what we have right now, but some different apis instead. TVL Nikita Ofitserov --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
fyi -Some failures will happen on the Macs because test_shell sets/restores user settings on startup/shutdown, so having more then one running can cause things to fail as one exits changing state on another that's running. It's on my list to move into a helper app so it can be done around the whole setup instead, it just hasn't bubble up in the priority list yet. TVL On Thu, Apr 9, 2009 at 12:06 PM, Pam Greene p...@chromium.org wrote: On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ 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: release builders now run webkit tests in parallel
On Thu, Apr 9, 2009 at 12:37 PM, Ojan Vafai o...@google.com wrote: This would only affect pixel tests, which are still off by default on mac, right? It also includes prefs about font sizes, smoothing, etc, which has shown in the past to change the layout and hence the text dumps. TVL On Thu, Apr 9, 2009 at 9:11 AM, Thomas Van Lenten thoma...@chromium.orgwrote: fyi -Some failures will happen on the Macs because test_shell sets/restores user settings on startup/shutdown, so having more then one running can cause things to fail as one exits changing state on another that's running. It's on my list to move into a helper app so it can be done around the whole setup instead, it just hasn't bubble up in the priority list yet. TVL On Thu, Apr 9, 2009 at 12:06 PM, Pam Greene p...@chromium.org wrote: On Mon, Apr 6, 2009 at 6:57 PM, David Levin le...@google.com wrote: On Mon, Apr 6, 2009 at 6:24 PM, Ojan Vafai o...@google.com wrote: run_webkit_test.sh now runs cpus+1 test_shells for Release builds. Please keep an eye out over the next couple days for test flakyness that may have resulted from this. Nice job! Release tests on a dual core now take about half the time they used to. There's still a lot of room for improvement and I'm a bit burnt out on this stuff, so if anyone is willing to help that would be much appreciated. Here are the remaining obvious things we could do to make a significant performance improvement: 1. Test and turn on parallelizing for Debug builds 2. Get 4 or 8 core webkit buildbots 3. Shard LayoutTests/fast and LayoutTests/http. Right now, in order to reduce test flakiness, we bucket tests by directory and run all those tests in the same process (thanks to dlevin for this idea!). The problem is that we're left with two very large buckets that can be further broken down. The work of breaking them down further is trivial (just add the directory names to a list in run_webkit_tests.py), the bigger problem is that some flakiness starts to appear in the fast/http tests when we break them down further. So, we need people to figure out what the source of the flakiness is and deal with it appropriately. For #3, an alternative may be to sort http tests to be first and don't break it down further. (http is less than one quarter of the time on OSX at least, so you can still scale up to quad core.) Also, I think fast (and dom) can be broken down into the 1st sub dir level without increased flakiness. So this may be an easy gain without having to figure out lots of test depedencies (which can be a bit painful). On that note, though, it would be amazing if someone wanted to figure out the interdependencies. We have three run_webkit_tests otpions available to help: --randomize-order, which runs the tests in a random order;--run-singly, which launches a fresh test_shell for each test; and --num-test-shells, which sets how many test_shell threads to run at once. It'll be time-consuming (--run-singly is especially slow), and there will be some work involved in comparing the results to figure out which test(s) are causing problems, but it would be a valuable thing. And no programing knowledge required. - Pam If we did all of the above, I expect we would see at least another factor of two performance improvement. Let me know if you want to help out with any of this. Ojan --~--~-~--~~~---~--~~ 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: Fwd: variant definitions in the .gyp files
So we'd take the product of variants and configuration?
I don't think we can do official this way because we need to modify sources
lists, so official would stay controlled by a variable for the whole tree.
I think your link changes would actually have to be w/in a
tagert_conditional blocks so they only applied to executables and/or shared
libs.
Anyway, looks pretty good.
TVL
On Thu, Apr 2, 2009 at 12:56 PM, Steven Knight s...@chromium.org wrote:
[Forwarding to chromium-dev from the right @chromium.org address.]
-- Forwarded message --
From: Steven Knight s...@google.com
Date: Thu, Apr 2, 2009 at 9:54 AM
Subject: variant definitions in the .gyp files
To: Mark Mentovai mmento...@google.com, Bradley Nelson
bradnel...@google.com, Adam Langley a...@google.com
Cc: Darin Fisher da...@google.com, chromium-dev
chromium-dev@googlegroups.com
I've appended a draft section below of what I'd like to add to the .gyp
configuration to support the different build flavors (coverage, profile,
etc.) that can be applied to the build configurations (Debug, Release).
It would be good if all of the platforms used similar configuration and
terminology, even though the settings will obviously be different. For
SCons, I'll turn these into command-line COVERAGE=, PROFILE= variable
settings. Mark thinks he can make the concept work for XCode. Brad, Adam,
will this work for your generators as well?
--SK
'variants': {
'coverage': {
'cflags': ['-fprofile-arcs', '-ftest-coverage'],
'linkflags': ['-fprofile-arcs'],
},
'profile': {
'cflags': ['-pg', '-g'],
'linkflags': ['-pg'],
},
'official': {
'defines': ['OFFICIAL_BUILD'],
# Make sure units of code and data go in their own section,
# and then GC them in the linker to remove unreferenced data
# and code. Currently gold doesn't support --gc-sections,
# so you'll have to build with the original GNU ld.
'cflags': ['-ffunction-sections', '-fdata-sections'],
'linkflags': ['-Wl,--gc-sections'],
},
'symbols': {
'cflags': ['-g'],
},
},
--~--~-~--~~~---~--~~
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: porting chrome_process_filter
A bunch of process handle code is something we're gonna need to look very carefully at. The filtering via names may be valid on Windows, but on Linux, a user could have Chromium running twice (with different profiles/user data dirs) pointing at different displays, so we'll have to be very careful to make sure it's only acting on the processes in the current instance and not the other one. If I remember right when I looked at some of this, the Windows code uses the process filter as a hook to scan the windows to find a running Chromium and send it a message. So that whole functionality should be re-abstracted, if needed, instead of making it have to work by walking a process list. TVL On Tue, Mar 24, 2009 at 11:31 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: I'm thinking about porting chrome/common/chrome_process_filter, but I don't quite know how it works on Windows (there's some FindWindowEx there). Could someone briefly explain what it's supposed to do? And some more specific questions: - does it match only browser process, or everything (browser, renderer, etc)? - would ProcessSingleton be a good starting point for making the filter work on Linux? (like trying to see which process has the singleton socket open) --~--~-~--~~~---~--~~ 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: porting chrome_process_filter
On Tue, Mar 24, 2009 at 1:00 PM, Amanda Walker ama...@chromium.org wrote: 2009/3/24 John Abd-El-Malek j...@chromium.org: Right, this is used so that if the user starts Chrome a second time, it tells the currently running exe to open a new tab. This is the standard way of doing it on Windows, but I don't know how Mac/Linux apps enforce single-instance semantics. We should first figure out if this code is needed before porting it.. Mac OS X handles this via the UI--if you try to launch an already-running application through the Finder, Dock, etc., the already running instance is brought to the front. While nothing in the underlying OS enforces single-instance semantics, the only way to get multiple instances within a single user session is to open a command line and explicitly launch them (or do the equivalent from another program or script). Additional instances can of course be launched in other user sessions simply by switching to another session and launching the application normally. It's not at all clear to me that we need to explicitly filter out multiple instances on the Mac; if we do, we will need to scope such filtering to a single user session, which will require using Mac-specific APIs. I would suggest that we postpone this until and unless we find a demonstrated need for it. The point I was trying to make, is all of this logic, should not be handled at the process filter layer, the real thing needed here is a higher level abstraction that capture what we're after (find_running_chromium(), message_running_chromium(), etc.). The individual platform code can then implement it w/ process filter or whatever, but trying to wedge it into working on all platforms via process filter seems wrong. TVL --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] Chromium App Executables Disk Layout
The Windows product builds a small executable that then loads the main chromium dll, and hands off control to that. I believe this is done solely for updating reasons. All the difference processes start from that one shim. On the Mac, we are currently building as a single executable. But, this brings up some complications, we need to be able to launch the Renderers with different Cocoa initialization. This data comes out of the info.plist, so we really need different bundles on disk (the OS acts on the data before the process is even started). So what it's looking like is that we need to move to a world where we also have a small shim for Chromium that loads a main shared lib and hands off control. Then we'll have a second shim for Renderers (and maybe plugin hosts, etc.) that loads the main shared lib and hands off control. Each of these shims will have different info.plists to provide the different Cocoa configuration information. Linux currently builds as one executable also. But Adam proposed we create a second executable (via hardlink?) for AppArmor as a sandbox? Does it make sense to standardize/require a small shell and shared lib for all platforms? One advantage of this approach on all platforms is they can initialize breakpad/crash reporting to the started up in the shim, so a crash during the loading of the main shared lib would be captured. One place not standardizing this gets ugly is within the build system, where it could become very complex expressing what goes into apps vs. shared libs. Thoughts/suggestions/comments? TVL --~--~-~--~~~---~--~~ 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: Chromium App Executables Disk Layout
On Tue, Mar 24, 2009 at 4:07 PM, George Djabarov geor...@google.com wrote: One additional reason to use small executable that loads chrome main dll is to prevent firewalls warnings each time chrome is updated. On the Mac, we should be able to avoid these by having a signed executable. Once the user says to trust the binary, the signature allows that to stay across updates (if the sig is the same). TVL -George On Tue, Mar 24, 2009 at 11:45 AM, Thomas Van Lenten thoma...@chromium.org wrote: The Windows product builds a small executable that then loads the main chromium dll, and hands off control to that. I believe this is done solely for updating reasons. All the difference processes start from that one shim. On the Mac, we are currently building as a single executable. But, this brings up some complications, we need to be able to launch the Renderers with different Cocoa initialization. This data comes out of the info.plist, so we really need different bundles on disk (the OS acts on the data before the process is even started). So what it's looking like is that we need to move to a world where we also have a small shim for Chromium that loads a main shared lib and hands off control. Then we'll have a second shim for Renderers (and maybe plugin hosts, etc.) that loads the main shared lib and hands off control. Each of these shims will have different info.plists to provide the different Cocoa configuration information. Linux currently builds as one executable also. But Adam proposed we create a second executable (via hardlink?) for AppArmor as a sandbox? Does it make sense to standardize/require a small shell and shared lib for all platforms? One advantage of this approach on all platforms is they can initialize breakpad/crash reporting to the started up in the shim, so a crash during the loading of the main shared lib would be captured. One place not standardizing this gets ugly is within the build system, where it could become very complex expressing what goes into apps vs. shared libs. Thoughts/suggestions/comments? TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] transform-replaced-shadows.html layout test
Looks like transform-replaced-shadows.html has been failing since last night? A quick scan of the waterfall history seems to indicate it started w/ http://codereview.chromium.org/43058, which was reverting http://codereview.chromium.org/21192. But folks seemed to ignore it for a while, so I'm not sure if it's really something to close the tree for or not. TVL --~--~-~--~~~---~--~~ 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: Copy/Paste, Cocoa, and you
On Wed, Mar 11, 2009 at 10:40 AM, Amanda Walker awal...@google.com wrote: For the URL field, I think that (1) is the best solution until we replace it with a real omnibox, at which point things could get complicated (since it'll need attributes for color etc. at the very least). What happens when we want to paste into an html edit area? Do we need to core browser binary to not include *any* of the webkit symbols so the system one could load to support NSAttributedString? TVL --Amanda On Wed, Mar 11, 2009 at 10:29 AM, Avi Drissman a...@google.com wrote: Now that the Clipboard change is in, I was about to land a quick, small patch to turn on copy/paste, when I ran into an interesting problem. If you copy something from the webpage you're viewing, and try to paste it into the URL box, we die. In digging, I found out what's going on. When we copy, WebKit puts an HTML flavor onto the clipboard. That's what we want. When we paste into our URL box (which allows rich text), Cocoa sees the HTML flavor and decides that it wants to turn it into an attributed string. Cocoa has a really bad HTML reader called NSHTMLReader. But that was retrofitted a few system releases ago to call WebKit. System WebKit then starts fighting with our WebCore, and things asplode. #11 0x95e9904a in -[NSHTMLReader _loadUsingWebKit] () #12 0x95e98c95 in -[NSHTMLReader attributedString] () #13 0x95e97930 in _NSReadAttributedStringFromURLOrData () There are several options here. 1. Turn off rich text support in the URL field. That's the easiest fix, and if we want to enforce a rule throughout Chromium that we aren't allowed any rich text fields editable by the user, that might be enough. 2. Patch out the Cocoa impl in the right place (the definition of which is TBD). This would gain us the freedom of not having to worry about this problem, but cost us worry about that patch. 3. Not put HTML on the clipboard. I don't see that as viable. 4. Figure out why system WebKit doesn't get along with our WebCore. I'm not sure where to start. 1 is obviously the most expedient, but is it the right solution? I think it is, for now. Avi --~--~-~--~~~---~--~~ 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: Copy/Paste, Cocoa, and you
On Wed, Mar 11, 2009 at 10:45 AM, Thomas Van Lenten thoma...@chromium.orgwrote: On Wed, Mar 11, 2009 at 10:40 AM, Amanda Walker awal...@google.comwrote: For the URL field, I think that (1) is the best solution until we replace it with a real omnibox, at which point things could get complicated (since it'll need attributes for color etc. at the very least). What happens when we want to paste into an html edit area? Do we need to core browser binary to not include *any* of the webkit symbols so the system one could load to support NSAttributedString? [hit send to fast] Input managers can be written by third parties, and who know what they will use w/in our browser process. The host we use for plugins is likely to have similar problems, we can't keep plugins from using NSAttributed string. TVL TVL --Amanda On Wed, Mar 11, 2009 at 10:29 AM, Avi Drissman a...@google.com wrote: Now that the Clipboard change is in, I was about to land a quick, small patch to turn on copy/paste, when I ran into an interesting problem. If you copy something from the webpage you're viewing, and try to paste it into the URL box, we die. In digging, I found out what's going on. When we copy, WebKit puts an HTML flavor onto the clipboard. That's what we want. When we paste into our URL box (which allows rich text), Cocoa sees the HTML flavor and decides that it wants to turn it into an attributed string. Cocoa has a really bad HTML reader called NSHTMLReader. But that was retrofitted a few system releases ago to call WebKit. System WebKit then starts fighting with our WebCore, and things asplode. #11 0x95e9904a in -[NSHTMLReader _loadUsingWebKit] () #12 0x95e98c95 in -[NSHTMLReader attributedString] () #13 0x95e97930 in _NSReadAttributedStringFromURLOrData () There are several options here. 1. Turn off rich text support in the URL field. That's the easiest fix, and if we want to enforce a rule throughout Chromium that we aren't allowed any rich text fields editable by the user, that might be enough. 2. Patch out the Cocoa impl in the right place (the definition of which is TBD). This would gain us the freedom of not having to worry about this problem, but cost us worry about that patch. 3. Not put HTML on the clipboard. I don't see that as viable. 4. Figure out why system WebKit doesn't get along with our WebCore. I'm not sure where to start. 1 is obviously the most expedient, but is it the right solution? I think it is, for now. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] App Mode
Is there a design doc/notes/etc. for App Mode on Windows? I'm starting to look at it for the Mac because there could be some arch issues we'll have to deal w/, so I want to understand the Windows side first. TVL --~--~-~--~~~---~--~~ 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: Mac Dogfood Planning
Did you happen to audit what we're currently logging w/ NOTIMP() and/or DCHECKs? Seems like anything that shows up loading basic pages should also go on the list for close out (either do it, or remove the log and open a bug for follow up like the linux folks have done). TVL On Mon, Mar 2, 2009 at 2:27 PM, Mike Pinkerton pinker...@chromium.orgwrote: As we're making rapid progress, I wanted to start to organize a little more around the 5 minute browser goal for the end of the quarter and see if we can better define what we want for our dogfood milestone. Here's a very quick list of things that I see us as needing in order to get to something that we can call dogfood: - bookmark bar - class/nib infrastructure for tab dragging, even if we don't drag tabs - history - cut/copy/paste - breakpad - HTML SELECT popups - page-cycler tests running on a bot and collecting stats - plug-ins in-process (out-of-process will probably be more difficult) Some other nice to have's, but I wouldn't consider these blocking for dogfood (probably a followup milestone, listed only to show I thought of them but didn't deem them important enough for inclusion in the primary dogfood milestone), include: - keychain integration - preferences - fancy omnibox functionality - improved UI from Cole - tab dragging - IME - out-of-process-plugins - ...the list goes on (printing, etc etc) First off, does the first list sound like the right list of things to be focusing on? Are there obvious things I'm missing? I'm sure there are. If these are the right things, we should probably reflect this work somewhere. The linux folks are using the bug system for their tasks. Some people don't mind this, others dislike the everything is a bug mentality. How do we want to capture the work so it's trackable externally? Personally I'm happy with bugs, I just know there are others that can't stand it. I went through the buglist of label:mac this morning and there's not too much on there that's top priority. I suggest we have a meeting tomorrow, similar to what the linux folks did, and triage the bugs (P1 = blocking dogfood, P2 = important for later, P3 = we'll get to it one day). Let's hold off picking what we're working on until we've agreed this is the right list. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] mac builds
Mac builds will probably need to either clobber or nuke src/xcodebuild/chrome.build/*/generated. I landed support for the resource loader, but you need the grit based resources to rebuild, and xcode deps doesn't currently track as dependencies any changes to the scripts that build them. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] NSS and NSPR
Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Claiming Process ProcessHandle
Follow up from the other week - I'm still digging into ProcessUtil::LaunchApp and the fall out from there. The current code in unittests and w/in chromium depends on a few things that windows offers since it gets handlers for this, the Mac Linux world can't really map things like this, so we're going to end up needed a slightly beefer process object to provide some of what is needed (hopefully we'll be able to leave the unittests on the current api for now, the problems doesn't really cause the tests issues (or we've fixed them)). TVL --~--~-~--~~~---~--~~ 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: using string16
Trying to remember what came up along the discussion. UTF16 is what Mac/win use, so there we can avoid a batch of conversions on those two platforms. (Mac can take UTF8, but the system would still be doing conversions to get things into a form it prefers) Didn't someone say ICU needs things in 16bit also, so every time we call one of those apis, we'd be converting round tripping if we went w/ UTF8? TVL On Wed, Feb 4, 2009 at 12:35 PM, Dean McNamee de...@chromium.org wrote: On Wed, Feb 4, 2009 at 6:11 PM, Darin Fisher da...@chromium.org wrote: The proposal was to search-n-replace std::wstring to string16. We would have to invent a macro to replace L usage. Most usages of string literals are in unit tests, so it doesn't seem to matter if there is cost associated with the macro. My belief is that there isn't much fruit to be had by converting everything to UTF-8. I fear people passing non-UTF-8 strings around using std::string and the bugs that ensue from that. We've had those problems in areas that deal with UTF-8 and non-UTF-8 byte arrays. Whenever we have a string16 or a wstring, it means implicitly that we have unicode that can be displayed to the user. So, the compiler helps us not screw up. This seems to be the only argument you make, that by making string16 a new type, we know it's encoding. This can be solved by many other ways by keeping utf8. We can add a new utf8 string class if you really wanted, or we can just be diligent and make sure to DCHECK in methods that expect a specific encoding. Have we had a lot of these problems? Do you have some examples? It would help me figure out solutions for better checking for utf-8. If someone can make a compelling performance argument for changing Chrome's UI over to UTF-8 and also invent a solution that avoids the problem I described above, then converting to UTF-8 would seem OK to me. But, right now... it just looks like cost for not much benefit. -Darin On Wed, Feb 4, 2009 at 8:21 AM, Evan Martin e...@chromium.org wrote: On Wed, Feb 4, 2009 at 6:53 AM, Dean McNamee de...@chromium.org wrote: I apologize for missing this discussion, I'm sure that I'm not seeing the entire picture and the pros of this argument. I mentioned before that I'm in support of utf-8 everywhere we can get it. I lost this argument, so I will defer this response to someone else. :) --~--~-~--~~~---~--~~ 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: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote: On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote: [Reposting from wrong mailing list, sorry for dupe.] On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named pipes), with one end passed through the spawn to the child process. Right now the interfaces don't expose this dependency, so I'm thinking of refactoring things a bit to do so. Jeremy suggested that I talk to Carlos, and I know tvl is looking at this - anyone else want in? Basic notion would be to modify LaunchApp() (or whatever Tom is doing to it) to accept an IPC::Channel (versus the current vector of fds). LaunchApp is in base/, but IPC::Channel is in chrome/common/. You can't have base/ depend on chrome/common/, so if this dependency is the right answer, then we'd need to move IPC::Channel down to base/. Why is passing an IPC::Channel to LaunchApp the answer? Just for reference, I'm still sorting things out here, but on the Mac, we might want to actually bounce some of these launches through LaunchServices so the app think it was launched from the Dock/Finder/by the user and avoid it inherriting fds, mach info, etc. (I realize the renderers might need this, so we might end up w/ 1 launch api so we can get different style of launches, the current api seems to be mangled/extended w/ a collection of args to sorta cover different needs.) TVL -Darin The appropriate endpoint would not be marked close-on-exec, and would be passed down to the child via a new command-line parameter (versus the current static location). This could pretty easily be expanded to pass through multiple channels and make the new command-line parameter have multiple values, if we need to go there. Once we can pass fds over channels, that may be immaterial. From there, the Windows code could be adjusted to use the create-channel-spawn-process ordering to match, and the calling points would hopefully become less forked. Adam mentioned on the wrong-mailing-list version of this thread that it's accepted to wire file descriptors into fixed places. Either way, my goal is to make sure that launching Chrome-internal helper tasks is distinct from launching arbitrary tasks, because the Chrome-internal case most likely wants to make special provisions WRT the child, and right now that seems to be in the calling code. -scott --~--~-~--~~~---~--~~ 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: Thinking about refactoring the confluence of processes and ipc channels.
On Wed, Feb 4, 2009 at 5:12 PM, cpu c...@chromium.org wrote: We don't launch renderers using LaunchApp, we use broker_service- SpawnTarget(). I guess in other platforms that don't have a sandbox you can replace that for whatever you want. You can see BrowserRenderProcessHost::Init() for all the cruft that we need to launch a renderer, I don't see a good way to move many of these things down to \base. Doesn't the code call LaunchApp if the window build isn't in the sandbox? It looks like that else path has a OS_WIN check at the moment because it's using the single string launch call that is windows only at the moment, but the intent seems to be to have LaunchApp work (atleast to support no sandbox mode). TVL I think your best bet is to create an abstract method in RenderProcessHost or such. Is anybody working on the Mac Sandbox? On Feb 4, 12:47 pm, Darin Fisher da...@chromium.org wrote: We talked about moving IPC out of chrome/common, but we should really only do that if we have a consumer. Right now, it is only needed by Chrome, so it would seem to be a premature optimization to spend time moving it elsewhere. -Darin On Wed, Feb 4, 2009 at 12:35 PM, stoyan sto...@google.com wrote: +1 for Renderer/PluginLauncher() +1 for moving IPC out of /chrome/common, in very own library. Stoyan On Wed, Feb 4, 2009 at 11:30 AM, Scott Hess sh...@chromium.org wrote: On Wed, Feb 4, 2009 at 11:10 AM, Thomas Van Lenten thoma...@chromium.org wrote: On Wed, Feb 4, 2009 at 2:02 PM, Darin Fisher da...@chromium.org wrote: On Wed, Feb 4, 2009 at 10:54 AM, Scott Hess sh...@chromium.org wrote: [Reposting from wrong mailing list, sorry for dupe.] On Mac/Linux, IPC::Channel uses socketpairs (or in some cases named pipes), with one end passed through the spawn to the child process. Right now the interfaces don't expose this dependency, so I'm thinking of refactoring things a bit to do so. Jeremy suggested that I talk to Carlos, and I know tvl is looking at this - anyone else want in? Basic notion would be to modify LaunchApp() (or whatever Tom is doing to it) to accept an IPC::Channel (versus the current vector of fds). LaunchApp is in base/, but IPC::Channel is in chrome/common/. You can't have base/ depend on chrome/common/, so if this dependency is the right answer, then we'd need to move IPC::Channel down to base/. Why is passing an IPC::Channel to LaunchApp the answer? Just for reference, I'm still sorting things out here, but on the Mac, we might want to actually bounce some of these launches through LaunchServices so the app think it was launched from the Dock/Finder/by the user and avoid it inherriting fds, mach info, etc. (I realize the renderers might need this, so we might end up w/ 1 launch api so we can get different style of launches, the current api seems to be mangled/extended w/ a collection of args to sorta cover different needs.) It seems reasonable to me to distinguish launching an app to process a download from launching a renderer or plug-in process. We probably want to be pretty pedantic about the renderer process, and I'm very certain we don't want to rely on external services to deal with it (relying on Finder to launch renderer processes feels very uncomfortable to me). Due to the differences in process model between Unix and Windows, there may be bits which would be easier/cleaner/safer to setup in the parent process and inherited into the child versus passing parameters to the child and having it set things up (the bootstrap fd for IPC is one such thing). -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] net unittests on Mac
FYI - I pushed two fixes for the net unittests on Mac, they should no longer be flaky (ie-failing 70% of the time). If folks see results indicating otherwise, please let me know. TVL --~--~-~--~~~---~--~~ 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: Layout test expectations and fallbacks
On Thu, Jan 29, 2009 at 10:44 AM, Dean McNamee de...@chromium.org wrote: On Thu, Jan 29, 2009 at 4:43 PM, Mark Mentovai m...@chromium.org wrote: On the Mac, I think we want to match Apple WebKit baselines. I don't know if there are any baselines currently in chromium-win that we should share. All of the V8 differences, for example. We copy those into chromium-mac as needed. But the majority of the expected files come down to fonts and the windows files wouldn't be of any use there. In the pixel dumps, again, font and controls pretty much make using the windows ones pointless. TVL Mark Dean wrote: I talked to Mads a bit, basically: 1) I think the Mac expected result fallback is currently wrong, it doesn't seem to look in chromium-win correctly. This is probably causing a lot of failures. 2) We should move chromium-win to chromium (or chromium-common), and then chromium-win should not be a fallback. This might be more confusing to manage, but it's also less confusing to understand that everything should / can fallback to the Windows expectations. On Thu, Jan 29, 2009 at 2:49 PM, Mads Sig Ager a...@chromium.org wrote: It seems that when running layout tests on linux, if there are no special expected results for linux in chromium-linux, we fallback to the special expected results for windows in chromium-win. This is not the case on mac if there are no results in chromium-mac, we take the expectations that are next to the test even if there are other expectations in chromium-win. Is that on purpose? A related question: what is the intention with our custom expected resulsts? If we need to change the expectation for all three platforms, should we only add the new expectations in chromium-win? That sounds confusing to me. Maybe we should have a chromium-common? Cheers,-- Mads --~--~-~--~~~---~--~~ 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: Browser Bootstrapping Plan
I've hung off this page another page for Mac issues that will need followup ( http://sites.google.com/a/chromium.org/dev/developers/browser-bootstrapping/mac-followup). As you hit other issues, please note them there so they are all in one place. TVL On Tue, Jan 20, 2009 at 10:18 AM, Mike Pinkerton pinker...@chromium.orgwrote: We had a meeting last week to talk about how to get to a running multi-process browser by mid-Feb. I was asked to follow-up with a document where we could collaborate, and have done so: http://sites.google.com/a/chromium.org/dev/developers/browser-bootstrapping Let me know if you have any feedback. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[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 -~--~~~~--~~--~--~---
