[chromium-dev] How to run chrom automation test
Hi, In src/chrome/test/automation, it has a automation_proxy_uitest.cc, How can I run the automation test on MacOSX? I see that is a directory xcodebuild/chrome.build/Debug/automated_ui_tests.build, but there is no *.app under there. Thank you for any tip. --~--~-~--~~~---~--~~ 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 run chrom automation test
Most (all?) of the uitests are compiled into an executable called uitests. Use xcodebuild/Debug/ui_tests --gtest_print_time to list all test names, then do xcodebuild/Debug/ui_tests --gtest_filter=SavePageTest.SaveHTMLOnly to execute the test you want. ps: First hit when searching for running chromium ui tests: http://code.google.com/p/chromium/wiki/RunningChromeUITests On Thu, Aug 27, 2009 at 7:56 PM, hap 497hap...@gmail.com wrote: Hi, In src/chrome/test/automation, it has a automation_proxy_uitest.cc, How can I run the automation test on MacOSX? I see that is a directory xcodebuild/chrome.build/Debug/automated_ui_tests.build, but there is no *.app under there. Thank you for any tip. --~--~-~--~~~---~--~~ 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 run chrom automation test
I don't know. But I'm sure a search engine of your choice can help you here :-) The steps should be somewhere along the lines of open chrome.xcodeproj, select 'run ui_tests' in the overview dropdown, edit project settings to add a command-line param, hit debug. I'm sure you'll figure it out. On Fri, Aug 28, 2009 at 9:03 AM, hap 497hap...@gmail.com wrote: Thank you. I ran the Automation UI test by ./ui_tests --gtest_filter=Automation* Can you please tell me how can I run it in XCode so that I can debug/step thru each Test Case? On Fri, Aug 28, 2009 at 7:20 AM, Nico Weber tha...@chromium.org wrote: Most (all?) of the uitests are compiled into an executable called uitests. Use xcodebuild/Debug/ui_tests --gtest_print_time to list all test names, then do xcodebuild/Debug/ui_tests --gtest_filter=SavePageTest.SaveHTMLOnly to execute the test you want. ps: First hit when searching for running chromium ui tests: http://code.google.com/p/chromium/wiki/RunningChromeUITests On Thu, Aug 27, 2009 at 7:56 PM, hap 497hap...@gmail.com wrote: Hi, In src/chrome/test/automation, it has a automation_proxy_uitest.cc, How can I run the automation test on MacOSX? I see that is a directory xcodebuild/chrome.build/Debug/automated_ui_tests.build, but there is no *.app under there. Thank you for any tip. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [linux] plugin paths
Right now our plugin loading code matches Firefox in the search path order. 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 3 path_to_chrome_binary/plugins - analogous to Firefox 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses On systems that have nspluginwrapper installed, they have an nspluginwrapper instance in the 4th directory and a copy of Flash (etc.) hidden off to the side. That means Chrome will also use nspluginwrapper, which is suboptimal: Chrome spawns a plugin process which loads nspluginwrapper which itself spawns another plugin process. It would be nice to not use nspluginwrapper, but we cannot just request people install plugins into the normal plugins directories, as you want other browsers (Firefox, etc.) to continue using nspluginwrapper. I propose the solution to this is to put Chrome-specific plugin directories at the front of the search path. Something like 1 ~/.config/google-chrome/plugins (not sure on this one... a bit weird to stick plugins in a config dir) 2 path_to_chrome_binary/plugins and then the Mozilla paths as before 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses Then people can install (symlink) the real plugins into the chrome-specific dirs if they want. Does that seem reasonable? --~--~-~--~~~---~--~~ 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: [linux] plugin paths
Can't we blacklist nspluginwrapper, and use the same logic that it uses to find the real plugins? On Fri, Aug 28, 2009 at 11:01 AM, Evan Martin e...@chromium.org wrote: Right now our plugin loading code matches Firefox in the search path order. 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 3 path_to_chrome_binary/plugins - analogous to Firefox 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses On systems that have nspluginwrapper installed, they have an nspluginwrapper instance in the 4th directory and a copy of Flash (etc.) hidden off to the side. That means Chrome will also use nspluginwrapper, which is suboptimal: Chrome spawns a plugin process which loads nspluginwrapper which itself spawns another plugin process. It would be nice to not use nspluginwrapper, but we cannot just request people install plugins into the normal plugins directories, as you want other browsers (Firefox, etc.) to continue using nspluginwrapper. I propose the solution to this is to put Chrome-specific plugin directories at the front of the search path. Something like 1 ~/.config/google-chrome/plugins (not sure on this one... a bit weird to stick plugins in a config dir) 2 path_to_chrome_binary/plugins and then the Mozilla paths as before 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses Then people can install (symlink) the real plugins into the chrome-specific dirs if they want. Does that seem reasonable? --~--~-~--~~~---~--~~ 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: [linux] plugin paths
On Fri, Aug 28, 2009 at 11:03 AM, John Abd-El-Malekj...@chromium.org wrote: Can't we blacklist nspluginwrapper, and use the same logic that it uses to find the real plugins? I have been thinking about this. The tricky part is that for *some* plugins, nspluginwrapper is the best we currently can do, because it's used to bridge 64-bit browsers to 32-bit plugins. But I think if we scan all plugins, we can pick and choose between them and we should prioritize native plugins over nspluginwrapper'd ones when they are available. --~--~-~--~~~---~--~~ 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 run chrom automation test
Thank you. I ran the Automation UI test by ./ui_tests --gtest_filter=Automation* Can you please tell me how can I run it in XCode so that I can debug/step thru each Test Case? On Fri, Aug 28, 2009 at 7:20 AM, Nico Weber tha...@chromium.org wrote: Most (all?) of the uitests are compiled into an executable called uitests. Use xcodebuild/Debug/ui_tests --gtest_print_time to list all test names, then do xcodebuild/Debug/ui_tests --gtest_filter=SavePageTest.SaveHTMLOnly to execute the test you want. ps: First hit when searching for running chromium ui tests: http://code.google.com/p/chromium/wiki/RunningChromeUITests On Thu, Aug 27, 2009 at 7:56 PM, hap 497hap...@gmail.com wrote: Hi, In src/chrome/test/automation, it has a automation_proxy_uitest.cc, How can I run the automation test on MacOSX? I see that is a directory xcodebuild/chrome.build/Debug/automated_ui_tests.build, but there is no *.app under there. Thank you for any tip. --~--~-~--~~~---~--~~ 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: [linux] plugin paths
On Fri, Aug 28, 2009 at 7:01 PM, Evan Martine...@chromium.org wrote: Right now our plugin loading code matches Firefox in the search path order. 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 3 path_to_chrome_binary/plugins - analogous to Firefox 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses On systems that have nspluginwrapper installed, they have an nspluginwrapper instance in the 4th directory and a copy of Flash (etc.) hidden off to the side. That means Chrome will also use nspluginwrapper, which is suboptimal: Chrome spawns a plugin process which loads nspluginwrapper which itself spawns another plugin process. It would be nice to not use nspluginwrapper, but we cannot just request people install plugins into the normal plugins directories, as you want other browsers (Firefox, etc.) to continue using nspluginwrapper. I propose the solution to this is to put Chrome-specific plugin directories at the front of the search path. Something like 1 ~/.config/google-chrome/plugins (not sure on this one... a bit weird to stick plugins in a config dir) 2 path_to_chrome_binary/plugins and then the Mozilla paths as before 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses Then people can install (symlink) the real plugins into the chrome-specific dirs if they want. Does that seem reasonable? It seems to make a lot of sense to be able to override chrome-specific plugins for chrome - is there actually a reason we use Mozilla ones first, or was it fairly arbitrary? --~--~-~--~~~---~--~~ 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: [linux] plugin paths
On Fri, Aug 28, 2009 at 11:03 AM, John Abd-El-Malek j...@chromium.orgwrote: Can't we blacklist nspluginwrapper, and use the same logic that it uses to find the real plugins? Last time I looked, the way nspw works: for each wrapped plugin it installs a version of the nspw plugin into the 'normal' plugins directory, except each one of these is tagged with the hard-coded path to the original plugin. So it'd be nice to detect nspw plugins, and extract from there the path to the original plugins and try to load those. However 2 issues I can forsee: - nspw plugins try to look like regular plugins - I'm not sure the ABI nspw uses to embed the hard-coded path is stable. See http://svn.beauchesne.info/gwenole/projects/nspluginwrapper/trunk/src/npw-config.c?revision=881view=markupfor the tool that generates it. Maybe my concerns are not founded, see the is_wrapper_plugin_handle function, it itself can read various versions. However if we're chrome 32 trying to use the 64-bit nspw plugins to find the original 32 bit ones, we'll need to manually read the elf, since dlopen will fail. Antoine On Fri, Aug 28, 2009 at 11:01 AM, Evan Martin e...@chromium.org wrote: Right now our plugin loading code matches Firefox in the search path order. 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 3 path_to_chrome_binary/plugins - analogous to Firefox 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses On systems that have nspluginwrapper installed, they have an nspluginwrapper instance in the 4th directory and a copy of Flash (etc.) hidden off to the side. That means Chrome will also use nspluginwrapper, which is suboptimal: Chrome spawns a plugin process which loads nspluginwrapper which itself spawns another plugin process. It would be nice to not use nspluginwrapper, but we cannot just request people install plugins into the normal plugins directories, as you want other browsers (Firefox, etc.) to continue using nspluginwrapper. I propose the solution to this is to put Chrome-specific plugin directories at the front of the search path. Something like 1 ~/.config/google-chrome/plugins (not sure on this one... a bit weird to stick plugins in a config dir) 2 path_to_chrome_binary/plugins and then the Mozilla paths as before 1 $MOZ_PLUGIN_PATH 2 ~/.mozilla/plugins 4 /usr/lib/mozilla/plugins and related directories - what Firefox uses Then people can install (symlink) the real plugins into the chrome-specific dirs if they want. Does that seem reasonable? --~--~-~--~~~---~--~~ 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 IPC layer in 64-bit MacOS
Hi all, Has anyone tried to build the Chromium IPC/shared memory code on 64-bit Mac OS? We have a need for IPC and shared memory between 64-bit and 32-bit processes, and what Chrome has seems to be a good fit for our needs. From my first glance through the code, it looks like standard POSIX without any obvious bit-width dependencies but I haven't tried it out yet, and it seems 64-bit Linux is already running on a basic level. Is anyone aware of any obvious issues in the 64-bit Mac world? Thanks! 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: Chromium IPC layer in 64-bit MacOS
On Fri, Aug 28, 2009 at 3:44 PM, Mark Wangm...@cooliris.com wrote: Has anyone tried to build the Chromium IPC/shared memory code on 64-bit Mac OS? We have a need for IPC and shared memory between 64-bit and 32-bit processes, and what Chrome has seems to be a good fit for our needs. From my first glance through the code, it looks like standard POSIX without any obvious bit-width dependencies but I haven't tried it out yet, and it seems 64-bit Linux is already running on a basic level. There is almost no OS X specific code in /ipc and it works on 64-bit Linux. There is a very high probability that it'll work just fine on 64-bit OS X. 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: Chromium IPC layer in 64-bit MacOS
Hi Mark, We haven't specifically tested the ipc layer as a method to communicate between 64 32-bit processes on OS X. At it's core the IPC layer just consists of a pipe to which we read write binary data, therefore if the binary representation of the data types that you want to push over the ipc channel are compatible between both processes, you *should* be fine. I don't know what your use case is, but one concern I would have is passing file descriptors back and forth, while this should work it's untested. Best regards, Jeremy On Fri, Aug 28, 2009 at 3:44 PM, Mark Wang m...@cooliris.com wrote: Hi all, Has anyone tried to build the Chromium IPC/shared memory code on 64-bit Mac OS? We have a need for IPC and shared memory between 64-bit and 32-bit processes, and what Chrome has seems to be a good fit for our needs. From my first glance through the code, it looks like standard POSIX without any obvious bit-width dependencies but I haven't tried it out yet, and it seems 64-bit Linux is already running on a basic level. Is anyone aware of any obvious issues in the 64-bit Mac world? Thanks! 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: Chromium IPC layer in 64-bit MacOS
The message serialization code, as I recall, had problems in making the 64-bit port where two types that were previously separate ended up typedef'ing to the same underlying type. I think Dean removed all of those to make the 64-bit port work now, but that may have the consequence that code that writes, say, a size_t from 64-bit and reads a size_t on 32-bit may disagree about how many bytes to read. But maybe you don't need all of that code. On Fri, Aug 28, 2009 at 3:44 PM, Mark Wangm...@cooliris.com wrote: Hi all, Has anyone tried to build the Chromium IPC/shared memory code on 64-bit Mac OS? We have a need for IPC and shared memory between 64-bit and 32-bit processes, and what Chrome has seems to be a good fit for our needs. From my first glance through the code, it looks like standard POSIX without any obvious bit-width dependencies but I haven't tried it out yet, and it seems 64-bit Linux is already running on a basic level. Is anyone aware of any obvious issues in the 64-bit Mac world? Thanks! 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: Git woes
On Thu, Aug 27, 2009 at 23:07, Nico Webertha...@chromium.org wrote: I accidentally fixed the problem by running something like rm -rf .git/svn/ git svn fetch; This one is most likely, the next one being the git pull. ... git merge trunk git merge refs/remotes/origin/trunk git checkout -f HEAD This command should do nothing, unless you removed the files outside .git directory (also called working tree). It is the same as git reset --hard (HEAD will be assumed): get tree from the revision pointed by HEAD and write them in the file system. git pull This may have cured you of the problem too, by fetching some data from the parent repository. It may have been enough to never access the problematic pack at its problematic place anymore. . Not sure what fixed it, but pulling works again. Yay, I guess, but of course I fixed it about 2 minutes before someone asked me to send a dtrace to the git mailing list :-/ There is also git fsck --full, which can tell more about about where problems located, so you can try to look at backups or parent/sibling repositories for corrupted data. It is generally enough to just copy the objects (files from .git/objects/?? and .git/objects/pack/*, even blindly all of them) into the problematic repository. You can repack (either git gc or git repack -ad) later to get rid of the data not referenced by your particular set of references. But in all cases, if you have something which looks like a repository corruption, developers at g...@vger.kernel.org would like to know about it. Thank you. P.S. Oh, great. Now I'm discovered :) --~--~-~--~~~---~--~~ 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: The webkit canary bots, now with performance tests!
Thanks a lot, Nicolas! yours, anton. On Fri, Aug 28, 2009 at 8:45 AM, Darin Fisherda...@chromium.org wrote: Thank you!!! On Thu, Aug 27, 2009 at 4:03 PM, Nicolas Sylvain nsylv...@chromium.org wrote: And now it is also running test_shell_tests in purify and valgrind: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Webkit+(purify+webkit.org)builder=Webkit+Linux+(valgrind+webkit.org) Nicolas On Wed, Aug 26, 2009 at 11:53 PM, Adam Barth aba...@chromium.org wrote: Yay! This is fantastic! Adam On Wed, Aug 26, 2009 at 11:47 PM, Darin Fisherda...@chromium.org wrote: Thanks to bevc and nsylvain, we now have performance bots testing chromium with the very latest webkit code: http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=XP+Perf+(webkit.org)builder=Linux+Perf+(webkit.org)reload=none (no mac bot yet) The dashboard is here: http://build.chromium.org/buildbot/perf/dashboard/overview-canary.html Now, we can see with much finer granularity the impact of webkit changes on the chromium performance tests! No more guessing as to what will happen to performance when we roll deps ;-) Marvelous! -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
