[chromium-dev] Chromium arm native compile error on ubuntu.
I'm using chromeos build script build_chrome.sh. Error log: RULE webcore_bindings_sources_binding_39 out/Release/obj/gen/webcore/ bindings/ V8DocumentType.cpp Traceback (most recent call last): File "scripts/action_csspropertynames.py", line 166, in sys.exit(main(sys.argv)) File "scripts/action_csspropertynames.py", line 141, in main assert returnCode == 0 AssertionError Traceback (most recent call last): File "scripts/action_maketokenizer.py", line 101, in sys.exit(main(sys.argv)) File "scripts/action_maketokenizer.py", line 89, in main p1 = subprocess.Popen(['flex', '-t', flexInput], stdout=subprocess.PIPE) File "/usr/lib/python2.6/subprocess.py", line 595, in __init__ errread, errwrite) File "/usr/lib/python2.6/subprocess.py", line 1092, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory Thanks Richard -- 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] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
I filed bugs and made CL below. Dan, may I send this to you? http://codereview.chromium.org/466047 - oshima On Wed, Dec 2, 2009 at 7:38 AM, oshima wrote: > > > On Tue, Dec 1, 2009 at 3:11 PM, Dan Kegel wrote: > >> On Tue, Dec 1, 2009 at 2:30 PM, oshima wrote: >> > Looks like there are more tests that failing in valgrind test. >> > ... >> > This is not good. Is there any issue if we make a valgrind test fail >> when >> > the test itself fails? >> > If not, I'd suggest that we exclude them in ui_tetsts.gtext.txt for now >> > (I'll file bugs) >> > and change the test script so that a valgrind test fails when the test >> > itself tails. >> > Any opinion? >> >> It's a great idea. >> This (and getting more tests to pass under valgrind) >> has been on Stuart's post-beta to-do list for some time. >> If somebody else wants to beat him to it, I'm sure >> he wouldn't complain... >> > > Ok, I'll file bugs and make changes to ui_tests.gtext.txt. > I'm not falimiar with script side. Is it chrome_tests.py that I need to > look at? > Anyway, I'll work on this once I'm back from ChromeOS team Offsite. > > - oshima > > >> - Dan >> > > -- 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] Chromium arm native compile error on ubuntu.
Do you have flex installed? On Mon, Dec 7, 2009 at 5:59 AM, Richard Zhao wrote: > I'm using chromeos build script build_chrome.sh. Error log: > > RULE webcore_bindings_sources_binding_39 out/Release/obj/gen/webcore/ > bindings/ > V8DocumentType.cpp > Traceback (most recent call last): > File "scripts/action_csspropertynames.py", line 166, in > sys.exit(main(sys.argv)) > File "scripts/action_csspropertynames.py", line 141, in main > assert returnCode == 0 > AssertionError > Traceback (most recent call last): > File "scripts/action_maketokenizer.py", line 101, in > sys.exit(main(sys.argv)) > File "scripts/action_maketokenizer.py", line 89, in main > p1 = subprocess.Popen(['flex', '-t', flexInput], > stdout=subprocess.PIPE) > File "/usr/lib/python2.6/subprocess.py", line 595, in __init__ > errread, errwrite) > File "/usr/lib/python2.6/subprocess.py", line 1092, in > _execute_child > raise child_exception > OSError: [Errno 2] No such file or directory > > Thanks > Richard > > -- > 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
Re: [chromium-dev] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
On Mon, Dec 7, 2009 at 10:29 AM, oshima wrote: > I filed bugs and made CL below. Dan, may I send this to you? > http://codereview.chromium.org/466047 Sure, I'd be happy to review. Please replace abc with the real bug number ... oddly, there wasn't one, so I just filed 29598 for this. Are you going to stand by to disable all the tests that fail once this hits the bots?There are going to be a ton. - 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: Plugin Manager UI Proposal
This is much needed, thanks for working on it :) Some notes: -Putting it in a url, but not having a menu item, removes much of the benefit since only a tiny percentage would be able to use it. -Checking that each plugin is up to date should be automatic and enabled for all users, just like our plugin installer is automatic. I don't see the benefit of having that functionality be listed as a "plugin", especially since that can't be completely done inside an NPAPI plugin. Can you put this information in a mini design doc somewhere online? Also things like exactly how you propose to implement this, and the future features (i.e. disabling plugins that have big security holes, asking the user to update etc...) On Mon, Dec 7, 2009 at 11:08 AM, Panayiotis wrote: > Hello, we are a small group of Googlers who'd like to volunteer our 20% > time to work on plugin management, and eventually plugin update in Chromium. > At first we'd like to start working only on management. We'd appreciate if > you could review our proposal and provide feedback. > > Thanks, > Panayiotis, Noe, Nav. > > > *Plugin Manager UI Proposal * > > *Purpose*: UI for managing (enabling/disabling) plugins in Chromium. > > *Background*: There's a lot of reasons why this would be desirable, most > are reported in http://code.google.com/p/chromium/issues/detail?id=736, > major ones include security and performance > > *Suggested solution: * > > The User Interface could look a lot like chrome://extensions. We could use > for example *chrome://plugins*/ for its url. A user would have to type the > url to get to it, we would not link to it from any menu. Very similar to > chrome://extensions, it would be a table of all plugins, with ability to > enable/disable plugins. A mockup is attached. > > All plugins, plugin name, plugin description, plugin version (see below) > and full filename of the plugin on the filesystem would be listed. Disabled > plugins look like disabled extensions and have an "enable" link, enabled > plugins have a "disable" link. > > *Non-goals:* > >- We don't want to be able to enable/disable plugins per-site/ per-tab >at this point. >- There won't be any notification to the user that a plugin was >attempted to be used -- this can be hard to detect because many pages use > JS >to see if the plugin is installed and show different content if it's not. >It's not impossible, but we think we shouldn't aim for this in the first >iteration. > > *Alternative ideas we considered:* > >- Modify about:plugins for this purpose. That page is a simple >javascript page that iterates over navigator.plugins. Similar to other >about: pages it doesn't have access to chrome internals. We feel >chrome://plugins follows the model of chrome://extensions better, in that >this page cannot be inspected and allows the user to modify state of the >browser. >- Have a popup window similar to Firefox's Add-on manager. We feel >mimicing chrome://extensions is going to be more consistent, besides, > having >it be a url allows you to load it in a tab. >- Add the plugins to chrome://extensions -- we can do that too, we'll >let Chromium devs chime in on what's the preferred option here. > > *Implementation details:* > >- Modify mostly PluginService (chrome/browser/plugin_service.cc) >- Will store state in the sqlite database, per user. >- A plugin is identified by its path in the filesystem. Different paths >are considered different plugins. >- Once a plugin is disabled, all subsequent calls to create a plugin >instance will fail. Similarly for enabling. Pages that have the plugin >already loaded should still work. > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Profiles + SharedWorkers
Hi all, I'm trying to understand the current (and future) state of Profile support. Currently, SharedWorkers are shared by all windows in the system - any two windows under the same domain can do "new SharedWorker(url)" and get a reference to the same SharedWorker, and can use that worker to share data. I currently am special-casing incognito windows, so incognito windows don't share workers with non-incognito workers, but I don't do anything to deal with profiles in general (so if you were running with separate profiles, those profiles would see one another's workers). I'm trying to figure out the best way to address this (and whether this is something that needs to be addressed in the near term, given that we don't officially support profiles - it sounds like chromeos may make some use of them?). ResourceMessageFilter has a reference to a Profile object - are these Profile objects global (for example, in the typical situation of a single profile + incognito, are there only two Profile objects in the Browser process)? -atw -- 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] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
It's d...@chromium.org. On Dec 7, 2009 11:21 AM, "oshima" wrote: On Mon, Dec 7, 2009 at 10:52 AM, Dan Kegel wrote: > > On Mon, Dec 7, 2009 at 10:29 ... Thanks. Is it dke...@google.com, right? > > Please replace abc with the real bug number ... oddly, > there wasn't one, so I just filed 29... Oh, I sorry about that. I was going to update after I filed all bugs. Done. > > Are you going to stand by to disable all the tests that fail > once this hits the bots?The... I went trough logs on bots and disabled tests that are failing. I tried the cl on linux_valgrind, and it passed (linux_valgrind try-server does not run ui_tests tho). There may be other flaky ones, but I'm hoping that there shoudln't be many. Oh, by the way, i found that the same thing is happening on mac side as well, but I'm not familiar with mac. Can someone take care of mac side? - oshima > - Dan > -- 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] Re: WorkerTest in the linux/valgrind tests are silently failing due to mmap failure
On Mon, Dec 7, 2009 at 10:52 AM, Dan Kegel wrote: > On Mon, Dec 7, 2009 at 10:29 AM, oshima wrote: > > I filed bugs and made CL below. Dan, may I send this to you? > > http://codereview.chromium.org/466047 > > Sure, I'd be happy to review. > Thanks. Is it dke...@google.com, right? > Please replace abc with the real bug number ... oddly, > there wasn't one, so I just filed 29598 for this. > Oh, I sorry about that. I was going to update after I filed all bugs. Done. > Are you going to stand by to disable all the tests that fail > once this hits the bots?There are going to be a ton. > I went trough logs on bots and disabled tests that are failing. I tried the cl on linux_valgrind, and it passed (linux_valgrind try-server does not run ui_tests tho). There may be other flaky ones, but I'm hoping that there shoudln't be many. Oh, by the way, i found that the same thing is happening on mac side as well, but I'm not familiar with mac. Can someone take care of mac side? - oshima > - 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: Plugin Manager UI Proposal
I'm not sure if my email did reach chromium-dev, but John's reply contains it as quoted text. In any case, repeating here: Hello, we are a small group of Googlers who'd like to volunteer our 20% time to work on plugin management, and eventually plugin update in Chromium. At first we'd like to start working only on management. We'd appreciate if you could review our proposal and provide feedback. Chromium plugin update proposal http://docs.google.com/View?id=acphg8jwwrqk_133d2q9k5d3 Chromium Plugin Manager Proposal <-- We think we can start working on this first http://docs.google.com/View?id=acphg8jwwrqk_131fknzfnd7 Thanks, Panayiotis. On Dec 7, 11:28 am, John Abd-El-Malek wrote: > This is much needed, thanks for working on it :) > > Some notes: > -Putting it in a url, but not having a menu item, removes much of the > benefit since only a tiny percentage would be able to use it. > -Checking that each plugin is up to date should be automatic and enabled for > all users, just like our plugin installer is automatic. I don't see the > benefit of having that functionality be listed as a "plugin", especially > since that can't be completely done inside an NPAPI plugin. > > Can you put this information in a mini design doc somewhere online? Also > things like exactly how you propose to implement this, and the future > features (i.e. disabling plugins that have big security holes, asking the > user to update etc...) > > > > On Mon, Dec 7, 2009 at 11:08 AM, Panayiotis wrote: > > Hello, we are a small group of Googlers who'd like to volunteer our 20% > > time to work on plugin management, and eventually plugin update in Chromium. > > At first we'd like to start working only on management. We'd appreciate if > > you could review our proposal and provide feedback. > > > Thanks, > > Panayiotis, Noe, Nav. > > > *Plugin Manager UI Proposal * > > > *Purpose*: UI for managing (enabling/disabling) plugins in Chromium. > > > *Background*: There's a lot of reasons why this would be desirable, most > > are reported inhttp://code.google.com/p/chromium/issues/detail?id=736, > > major ones include security and performance > > > *Suggested solution: * > > > The User Interface could look a lot like chrome://extensions. We could use > > for example *chrome://plugins*/ for its url. A user would have to type the > > url to get to it, we would not link to it from any menu. Very similar to > > chrome://extensions, it would be a table of all plugins, with ability to > > enable/disable plugins. A mockup is attached. > > > All plugins, plugin name, plugin description, plugin version (see below) > > and full filename of the plugin on the filesystem would be listed. Disabled > > plugins look like disabled extensions and have an "enable" link, enabled > > plugins have a "disable" link. > > > *Non-goals:* > > > - We don't want to be able to enable/disable plugins per-site/ per-tab > > at this point. > > - There won't be any notification to the user that a plugin was > > attempted to be used -- this can be hard to detect because many pages > > use JS > > to see if the plugin is installed and show different content if it's not. > > It's not impossible, but we think we shouldn't aim for this in the first > > iteration. > > > *Alternative ideas we considered:* > > > - Modify about:plugins for this purpose. That page is a simple > > javascript page that iterates over navigator.plugins. Similar to other > > about: pages it doesn't have access to chrome internals. We feel > > chrome://plugins follows the model of chrome://extensions better, in that > > this page cannot be inspected and allows the user to modify state of the > > browser. > > - Have a popup window similar to Firefox's Add-on manager. We feel > > mimicing chrome://extensions is going to be more consistent, besides, > > having > > it be a url allows you to load it in a tab. > > - Add the plugins to chrome://extensions -- we can do that too, we'll > > let Chromium devs chime in on what's the preferred option here. > > > *Implementation details:* > > > - Modify mostly PluginService (chrome/browser/plugin_service.cc) > > - Will store state in the sqlite database, per user. > > - A plugin is identified by its path in the filesystem. Different paths > > are considered different plugins. > > - Once a plugin is disabled, all subsequent calls to create a plugin > > instance will fail. Similarly for enabling. Pages that have the plugin > > already loaded should still work. -- 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] Profiles + SharedWorkers
I was wondering if worker processes have a profile affinity too. Eric's bringing up Databases in workers right now and databases are definitely per-profile. I'd vote to assert that a worker process only runs workers on behalf one profile, just like renderers. >ResourceMessageFilter has a reference to a Profile object - are these Profile objects global > (for example, in the typical situation of a single profile + incognito, are there only two Profile > objects in the Browser process)? Yes. The fact that a worker process can host at most one worker certainly does simplify things for the time being ;) On Mon, Dec 7, 2009 at 11:37 AM, Drew Wilson wrote: > Hi all, > > I'm trying to understand the current (and future) state of Profile support. > > Currently, SharedWorkers are shared by all windows in the system - any two > windows under the same domain can do "new SharedWorker(url)" and get a > reference to the same SharedWorker, and can use that worker to share data. > > I currently am special-casing incognito windows, so incognito windows don't > share workers with non-incognito workers, but I don't do anything to deal > with profiles in general (so if you were running with separate profiles, > those profiles would see one another's workers). > > I'm trying to figure out the best way to address this (and whether this is > something that needs to be addressed in the near term, given that we don't > officially support profiles - it sounds like chromeos may make some use of > them?). ResourceMessageFilter has a reference to a Profile object - are > these Profile objects global (for example, in the typical situation of a > single profile + incognito, are there only two Profile objects in the > Browser process)? > > -atw > > -- > 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
Re: [chromium-dev] Profiles + SharedWorkers
On Mon, Dec 7, 2009 at 11:37 AM, Drew Wilson wrote: > I currently am special-casing incognito windows, so incognito windows don't > share workers with non-incognito workers, but I don't do anything to deal > with profiles in general (so if you were running with separate profiles, > those profiles would see one another's workers). > That's bad. You should not special-case Incognito. You should make these profile-scoped. I'm trying to figure out the best way to address this (and whether this is > something that needs to be addressed in the near term, given that we don't > officially support profiles - it sounds like chromeos may make some use of > them?). > We do officially support profiles: they're how Incognito works. And we go to great lengths elsewhere to make them work right in general. We don't have UI for widespread general use of lots of profiles, but the functionality works well. If you look at the implementation of profiles you will find that most things that act "global" are really hung off the profile. ResourceMessageFilter has a reference to a Profile object - are these > Profile objects global (for example, in the typical situation of a single > profile + incognito, are there only two Profile objects in the Browser > process)? > Yes. PK -- 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] Re: Plugin Manager UI Proposal
Sigh, resending now that I have re-added my address to Groups after it got auto-removed :( On Mon, Dec 7, 2009 at 12:25 PM, Peter Kasting wrote: > On Mon, Dec 7, 2009 at 11:45 AM, Panayiotis Mavrommatis < > panayio...@google.com> wrote: > >> I'm not sure if my email did reach chromium-dev, > > > It didn't, so I was confused at first :) > > > >- Modify about:plugins for this purpose. That page is a simple >> > > >javascript page that iterates over navigator.plugins. Similar to >> other >> > >about: pages it doesn't have access to chrome internals. We feel >> > >chrome://plugins follows the model of chrome://extensions better, >> in that >> > >this page cannot be inspected and allows the user to modify state >> of the >> > >browser. >> > > To users the distinction is meaningless. I suspect (but am not sure) that > we can write an internal handler that serves about:plugins in whatever way > we want (e.g. as a DOM UI page with two-way communication with the browser). > > > >- Add the plugins to chrome://extensions -- we can do that too, >> we'll >> > >let Chromium devs chime in on what's the preferred option here. >> > > We should definitely put the two together in whatever UI we end up with. > Users don't perceive these differently (just try explaining to a > non-developer how when they say "plugins" they really mean "extensions"), > and the information to see and actions to take are pretty much identical > with an extension versus a plugin. > > > >- Modify mostly PluginService (chrome/browser/plugin_service.cc) >> > >- Will store state in the sqlite database, per user. >> > > I'm not familiar with this code. Does it already use a sqlite database? > If not it might make sense to just shove this in the Preferences file. > This is where we list other similar data, and it avoids the overhead of > having another file to open and read on startup. > > > >- A plugin is identified by its path in the filesystem. Different >> paths >> > >are considered different plugins. >> > > Does this imply that different versions of a plugin are different plugins? > I ask because it would be annoying to find the Flash auto-reenabled itself > after it auto-updated. Perhaps "same name OR same path"? > > 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: Plugin Manager UI Proposal
I think it's important the possibility to users add/edit/remove plugin directories. So not only the default directories will be scanned. I requested this function, but it was marked as WontFix, see: http://code.google.com/p/chromium/issues/detail?id=29442 On 7 dez, 18:28, Peter Kasting wrote: > Sigh, resending now that I have re-added my address to Groups after it got > auto-removed :( > > > > On Mon, Dec 7, 2009 at 12:25 PM, Peter Kasting wrote: > > On Mon, Dec 7, 2009 at 11:45 AM, Panayiotis Mavrommatis < > > panayio...@google.com> wrote: > > >> I'm not sure if my email did reach chromium-dev, > > > It didn't, so I was confused at first :) > > > > > - Modify about:plugins for this purpose. That page is a simple > > > > > javascript page that iterates over navigator.plugins. Similar to > >> other > >> > > about: pages it doesn't have access to chrome internals. We feel > >> > > chrome://plugins follows the model of chrome://extensions better, > >> in that > >> > > this page cannot be inspected and allows the user to modify state > >> of the > >> > > browser. > > > To users the distinction is meaningless. I suspect (but am not sure) that > > we can write an internal handler that serves about:plugins in whatever way > > we want (e.g. as a DOM UI page with two-way communication with the browser). > > > > > - Add the plugins to chrome://extensions -- we can do that too, > >> we'll > >> > > let Chromium devs chime in on what's the preferred option here. > > > We should definitely put the two together in whatever UI we end up with. > > Users don't perceive these differently (just try explaining to a > > non-developer how when they say "plugins" they really mean "extensions"), > > and the information to see and actions to take are pretty much identical > > with an extension versus a plugin. > > > > > - Modify mostly PluginService (chrome/browser/plugin_service.cc) > >> > > - Will store state in the sqlite database, per user. > > > I'm not familiar with this code. Does it already use a sqlite database? > > If not it might make sense to just shove this in the Preferences file. > > This is where we list other similar data, and it avoids the overhead of > > having another file to open and read on startup. > > > > > - A plugin is identified by its path in the filesystem. Different > >> paths > >> > > are considered different plugins. > > > Does this imply that different versions of a plugin are different plugins? > > I ask because it would be annoying to find the Flash auto-reenabled itself > > after it auto-updated. Perhaps "same name OR same path"? > > > 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: Plugin Manager UI Proposal
-Putting it in a url, but not having a menu item, removes much of the benefit since only a tiny percentage would be able to use it. -> Extensions opens chrome://extensions so yes, we can do the same for plugins, or reuse chrome://extensions for listing the plugins as well, as Peter and I think other developers have suggested. -Checking that each plugin is up to date should be automatic and enabled for all users, just like our plugin installer is automatic. I don't see the benefit of having that functionality be listed as a "plugin", especially since that can't be completely done inside an NPAPI plugin. Yes we want to implement this in Chrome itself, but at a later stage. On Dec 7, 12:28 pm, Peter Kasting wrote: > Sigh, resending now that I have re-added my address to Groups after it got > auto-removed :( > > > > On Mon, Dec 7, 2009 at 12:25 PM, Peter Kasting wrote: > > On Mon, Dec 7, 2009 at 11:45 AM, Panayiotis Mavrommatis < > > panayio...@google.com> wrote: > > >> I'm not sure if my email did reach chromium-dev, > > > It didn't, so I was confused at first :) > > > > > - Modify about:plugins for this purpose. That page is a simple > > > > > javascript page that iterates over navigator.plugins. Similar to > >> other > >> > > about: pages it doesn't have access to chrome internals. We feel > >> > > chrome://plugins follows the model of chrome://extensions better, > >> in that > >> > > this page cannot be inspected and allows the user to modify state > >> of the > >> > > browser. > > > To users the distinction is meaningless. I suspect (but am not sure) that > > we can write an internal handler that serves about:plugins in whatever way > > we want (e.g. as a DOM UI page with two-way communication with the browser). > > > > > - Add the plugins to chrome://extensions -- we can do that too, > >> we'll > >> > > let Chromium devs chime in on what's the preferred option here. > > > We should definitely put the two together in whatever UI we end up with. > > Users don't perceive these differently (just try explaining to a > > non-developer how when they say "plugins" they really mean "extensions"), > > and the information to see and actions to take are pretty much identical > > with an extension versus a plugin. > Thanks for the insight. Taking these into consideration, I agree putting extensions and plugins together makes sense (another point of confusion is that extensions can be configured to use NPAPI, which blurs the line between the two even further. I'll update the design doc unless I hear otherwise in the next few days. > > > > - Modify mostly PluginService (chrome/browser/plugin_service.cc) > >> > > - Will store state in the sqlite database, per user. > > > I'm not familiar with this code. Does it already use a sqlite database? > > If not it might make sense to just shove this in the Preferences file. > > This is where we list other similar data, and it avoids the overhead of > > having another file to open and read on startup. Will definitely come back and ask you more about this as soon as the UI settles down > > > > > - A plugin is identified by its path in the filesystem. Different > >> paths > >> > > are considered different plugins. > > > Does this imply that different versions of a plugin are different plugins? > > I ask because it would be annoying to find the Flash auto-reenabled itself > > after it auto-updated. Perhaps "same name OR same path"? > It's a good question. On linux in particular I find myself with 2-3 versions of a plugin from time to time. One in /etc, another in ~/.mozilla ... Personally I found myself wanting to disable the /etc plugin but leave the one in ~/.mozilla So I know of at least 1 user who'd prefer per- path disabling/enabling. But I don't know what fraction of the user base I represent. The situation you suggest is a good point. We can investigate how often plugin paths change after auto-update and come back with a plan. Will definitely add to the design doc soon. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 33990
Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)" http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/1072 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29 --=> Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)" <=-- Revision: 33990 Blame list: grego...@google.com Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] UI Jank Task Force Status Update
* UI Jank Task Force Status Update The UI Jank Task Force is out to fix UI Jank and slowness in the browser. A list of open Jank bugs is here: http://code.google.com/ p/chromium/issues/list?q=label:Jank (feel free to take one!) Status John - Chasing down browser hang from Target's website (Flash fetching many URLs repeatedly) Carlos - Fighting with PGO build, several steps failing. - A NaCl linking step fails - NaCl team looking into it with VS2008. - Linker crashes. Will need to file a ticket upstream. - Will try to build with LKGR today. - Will give a build to John if he can get it building again. - Darin landed a change to improve how we paint small updates (fast scrolling rects). Chase - Infrastructure changes; changing how we gather perf test outputs. - Has a patch that will fix orange on DHTML page cyclers. Will send the CL to Carlos. Evan - Triaging Linux Jank bugs. Probably not many that are actionable right now, though. Tony - Profiling renderer startup. Faster renderers -> faster new tabs. * -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [GTTF] running the views and chromeos trybots for more kinds of CLs
I hit at least few cases when I broke the views and/or chromeos buildbot with a CL which doesn't touch the views code directly (which would trigger submitting it to the views trybot). Today another change in a gypi file triggered a compile failure on views bots, while all other trybots have been so green. How about triggering sending the CL to views trybots when it touches any gyp-related file, or any code in chrome? This should help making our tree even more green. -- 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] UI Jank Task Force Status Update
On Mon, Dec 7, 2009 at 22:34, Glenn Wilson wrote: > Evan > > Triaging Linux Jank bugs. Probably not many that are actionable right now, though. That's not exactly Jank issue, but on a lot of our bots we're getting leftover processes on Linux. It seems they don't respond properly to SIGTERM. This seems to have started after we added the handler for SIGTERM (previously chrome was using the default handler). So this causes quite a lot of flakiness, but is also kind-of janky. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Splitting off some pieces of chrome.gyp...
Hello All,
Last week I re-landed a change to split off parts of chrome.gyp into .gypi's
in the same directory.
I had done something similar a couple weeks back, but took it out because
concern was raised about merge conflicts in m4.
I put it back in because I got the all clear on m4.
The goal is to reduce contention on chrome.gyp which has gotten quite large
- 7000+ lines.
The current division is:
chrome_tests.gypi - 1793 (all tests)
chrome_browser.gyp - 2384 ('browser' target)
chrome.gyp - 2873 - (everything else)
The reason for using .gypi's rather than normal .gyp files is that the xcode
generator emits one xcodeproj per .gyp file.
Finer granularity would mean xcode users would get an overly myopic view of
the total project.
To avoid this, I've just pulled out larger targets into neighboring gypi's,
but they are still effectively a part of chrome.gyp. Targets behave the same
in an ancillary gypi file as they would if they were in the 'targets' list
in the main gyp file.
In a related theme, gregoryd is in the process of trying to produce 64-bit
builds of base, app, and a few other targets for use in nacl's 64-bit shim.
Without going into too much detail, in order to work correctly, even as a
part of a 32-bit build of chrome, a 64-bit shim which depends on base, app,
etc. needs to be built along side on windows. The best solution we've been
able to come up with is to use 'target_conditions' inside a gyp file to
allow a 'base' and 'base_nacl_win64' to share common files and settings. And
then use a facility in the msvs gyp generator to have some targets within a
32-bit sln configuration actually be 64-bit . This unfortunately somewhat
obscures which parts of the .gyp are relevant to which target. To make the
relationship more clear, we've come up with the idea of breaking out the
'magical' targets into separate .gypi files. You can see this in action in
the current state of base.gyp and base.gypi.
We've considered a number of alternatives: duplicate the contents of each
target for x64, enhance gyp to support target 'inheritance', wrap the whole
thing up in a python script to build things multiple different ways. The
advantage of the current approach is that nothing changes from the point of
view of someone building in the IDE.
Some concern has been raised as to the readability of the resulting gyp
files. We'd like to find something that meets everyones needs, so please let
me know if you've got ideas on how to do this more cleanly.
-BradN
--
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] Splitting off some pieces of chrome.gyp...
On Mon, Dec 7, 2009 at 1:43 PM, Bradley Nelson wrote:
> Hello All,
>
> Last week I re-landed a change to split off parts of chrome.gyp into
> .gypi's in the same directory.
> I had done something similar a couple weeks back, but took it out because
> concern was raised about merge conflicts in m4.
> I put it back in because I got the all clear on m4.
> The goal is to reduce contention on chrome.gyp which has gotten quite large
> - 7000+ lines.
>
> The current division is:
> chrome_tests.gypi - 1793 (all tests)
> chrome_browser.gyp - 2384 ('browser' target)
> chrome.gyp - 2873 - (everything else)
>
> The reason for using .gypi's rather than normal .gyp files is that the
> xcode generator emits one xcodeproj per .gyp file.
> Finer granularity would mean xcode users would get an overly myopic view of
> the total project.
> To avoid this, I've just pulled out larger targets into neighboring gypi's,
> but they are still effectively a part of chrome.gyp. Targets behave the same
> in an ancillary gypi file as they would if they were in the 'targets' list
> in the main gyp file.
>
> In a related theme, gregoryd is in the process of trying to produce 64-bit
> builds of base, app, and a few other targets for use in nacl's 64-bit shim.
> Without going into too much detail, in order to work correctly, even as a
> part of a 32-bit build of chrome, a 64-bit shim which depends on base, app,
> etc. needs to be built along side on windows. The best solution we've been
> able to come up with is to use 'target_conditions' inside a gyp file to
> allow a 'base' and 'base_nacl_win64' to share common files and settings. And
> then use a facility in the msvs gyp generator to have some targets within a
> 32-bit sln configuration actually be 64-bit . This unfortunately somewhat
> obscures which parts of the .gyp are relevant to which target. To make the
> relationship more clear, we've come up with the idea of breaking out the
> 'magical' targets into separate .gypi files. You can see this in action in
> the current state of base.gyp and base.gypi.
>
> We've considered a number of alternatives: duplicate the contents of each
> target for x64, enhance gyp to support target 'inheritance', wrap the whole
> thing up in a python script to build things multiple different ways. The
> advantage of the current approach is that nothing changes from the point of
> view of someone building in the IDE.
>
> Some concern has been raised as to the readability of the resulting gyp
> files. We'd like to find something that meets everyones needs, so please let
> me know if you've got ideas on how to do this more cleanly.
>
Have you looked at using some of the infrastructure used by the
cross-compile builds on linux (the toolset stuff) ? It's basically a way to
implicitly duplicate gyp targets and manage dependencies between them.
Beyond host vs target, I had in mind the ability to more generically use
different tools to build the same target, though never got around to
implement it really. E.g. PIC vs not PIC for linux x64 builds. It may be the
right abstraction for the win x64 stuff, though I don't know the details of
how that works on windows.
Antoine
>
> -BradN
>
> --
> 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
Re: [chromium-dev] UI Jank Task Force Status Update
On Mon, Dec 7, 2009 at 1:41 PM, Paweł Hajdan Jr. wrote: > On Mon, Dec 7, 2009 at 22:34, Glenn Wilson wrote: > > Evan > > > > Triaging Linux Jank bugs. Probably not many that are actionable right > now, though. > > That's not exactly Jank issue, but on a lot of our bots we're getting > leftover processes on Linux. It seems they don't respond properly to > SIGTERM. This seems to have started after we added the handler for SIGTERM > (previously chrome was using the default handler). So this causes quite a > lot of flakiness, but is also kind-of janky. > As you pointed out, this is not jank (i.e., sluggish user experience). Have you filed a bug and cc'ed agl + willchan + mark (who I believe have worked on the new handler)? > -- > 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: Building chromium for arm--erroring out
On Mon, Dec 7, 2009 at 2:50 PM, SOFIA TAHSEEN wrote:
> Hi Antoine/Joel,
>
> When I try to build using the following make command I get the error as
> below...Have you seen this earlier :
>
> make -r -j3 BUILDTYPE=Release chrome
> (I have a dual core so used -j3)
>
> CXX(target)
> out/Release/obj.target/common/chrome/common/histogram_synchronizer.o
> CXX(target)
> out/Release/obj.target/common/chrome/common/important_file_writer.o
> CXX(target)
> out/Release/obj.target/common/chrome/common/jstemplate_builder.o
> CXX(target) out/Release/obj.target/common/chrome/common/libxml_utils.o
> CXX(target) out/Release/obj.target/common/chrome/common/logging_chrome.o
> cc1plus: warnings being treated as errors
> chrome/common/libxml_utils.cc: In static member function 'static void
> XmlReader::GenericErrorCallback(void*, const char*, ...)':
> chrome/common/libxml_utils.cc:38: error: cannot pass objects of non-POD
> type 'struct va_list' through '...'; call will abort at runtime
> make: *** [out/Release/obj.target/common/chrome/common/libxml_utils.o]
> Error 1
> make: *** Waiting for unfinished jobs
>
>
+chromium-dev
Sofia, I haven't seen that error. Which compiler did you end up using ?
However the code does look suspicious, passing va_list through "...":
void XmlReader::GenericErrorCallback(void* context, const char* msg, ...) {
va_list args;
va_start(args, msg);
XmlReader* reader = static_cast(context);
reader->errors_.append(StringPrintf(msg, args));
}
Chromium C++ experts: Is that supposed to be legal, or even portable ? It
sounds like StringAppendV would be preferable here.
Antoine
--
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] UI Jank Task Force Status Update
Is this thought to be http://crbug.com/29240, or are there other problems with the signal handler? The change to fix that is out at http://codereview.chromium.org/460094. Mark Evan Stade wrote: > On Mon, Dec 7, 2009 at 1:41 PM, Paweł Hajdan Jr. > wrote: >> >> On Mon, Dec 7, 2009 at 22:34, Glenn Wilson wrote: >> > Evan >> > >> > Triaging Linux Jank bugs. Probably not many that are actionable right >> > now, though. >> That's not exactly Jank issue, but on a lot of our bots we're getting >> leftover processes on Linux. It seems they don't respond properly to >> SIGTERM. This seems to have started after we added the handler for SIGTERM >> (previously chrome was using the default handler). So this causes quite a >> lot of flakiness, but is also kind-of janky. > > As you pointed out, this is not jank (i.e., sluggish user experience). Have > you filed a bug and cc'ed agl + willchan + mark (who I believe have worked > on the new handler)? > >> >> -- >> 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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Building chromium for arm--erroring out
No, I believe the correct way is
va_list ap;
va_start(ap, msg);
std::string str;
StringAppendV(&result, format, ap);
va_end(ap);
XmlReader* reader = static_cast(context);
reader->errors_.append(str);
Weird that there's no StringPrintV() in string_util.
On Mon, Dec 7, 2009 at 3:13 PM, Antoine Labour wrote:
>
>
> On Mon, Dec 7, 2009 at 2:50 PM, SOFIA TAHSEEN wrote:
>>
>> Hi Antoine/Joel,
>> When I try to build using the following make command I get the error as
>> below...Have you seen this earlier :
>> make -r -j3 BUILDTYPE=Release chrome
>> (I have a dual core so used -j3)
>> CXX(target)
>> out/Release/obj.target/common/chrome/common/histogram_synchronizer.o
>> CXX(target)
>> out/Release/obj.target/common/chrome/common/important_file_writer.o
>> CXX(target)
>> out/Release/obj.target/common/chrome/common/jstemplate_builder.o
>> CXX(target) out/Release/obj.target/common/chrome/common/libxml_utils.o
>> CXX(target) out/Release/obj.target/common/chrome/common/logging_chrome.o
>> cc1plus: warnings being treated as errors
>> chrome/common/libxml_utils.cc: In static member function 'static void
>> XmlReader::GenericErrorCallback(void*, const char*, ...)':
>> chrome/common/libxml_utils.cc:38: error: cannot pass objects of non-POD
>> type 'struct va_list' through '...'; call will abort at runtime
>> make: *** [out/Release/obj.target/common/chrome/common/libxml_utils.o]
>> Error 1
>> make: *** Waiting for unfinished jobs
>
> +chromium-dev
> Sofia, I haven't seen that error. Which compiler did you end up using ?
> However the code does look suspicious, passing va_list through "...":
> void XmlReader::GenericErrorCallback(void* context, const char* msg, ...) {
> va_list args;
> va_start(args, msg);
> XmlReader* reader = static_cast(context);
> reader->errors_.append(StringPrintf(msg, args));
> }
> Chromium C++ experts: Is that supposed to be legal, or even portable ? It
> sounds like StringAppendV would be preferable here.
> Antoine
>
> --
> 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] buildbot failure in Chromium on XP Tests, revision 34009
Automatically closing tree for "unit_tests" on "XP Tests" http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/15391 http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests --=> Automatically closing tree for "unit_tests" on "XP Tests" <=-- Revision: 34008, 34009 Blame list: grego...@google.com,gwil...@google.com Buildbot waterfall: http://build.chromium.org/ -- 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 chromium for arm--erroring out
On Mon, Dec 7, 2009 at 4:00 PM, Sofia Tahseen wrote:
> Hi All,
>
> I am using the codesourcery toolchain to compile
> http://www.codesourcery.com/sgpp/lite/arm/portal/release644 ---
> arm-2008q3
>
> I will delete everything and do gclient sync again...
>
>
> The following are the steps I use to get the source code for chrome
> browser for ARM:
>
> gclient config http://src.chromium.org/svn/trunk/src
> export GYP_GENERATORS=make
> export GYP_DEFINES="target_arch=arm armv7=1 sysroot=/home/adas/x-tools/
> arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
> disable_nacl=1 use_system_ffmpeg=1"
> gclient sync
>
> Let me know if I am doing something wrong.
>
Try with a newer version of CodeSourcery. I haven't had this issue with
2009q1 or 2009q3.
I'm working on a fix anyway, see http://codereview.chromium.org/464064
Antoine
>
> Thanks,
> Sofia
>
> On Dec 7, 5:13 pm, Antoine Labour wrote:
> > On Mon, Dec 7, 2009 at 2:50 PM, SOFIA TAHSEEN
> wrote:
> > > Hi Antoine/Joel,
> >
> > > When I try to build using the following make command I get the error as
> > > below...Have you seen this earlier :
> >
> > > make -r -j3 BUILDTYPE=Release chrome
> > > (I have a dual core so used -j3)
> >
> > > CXX(target)
> > > out/Release/obj.target/common/chrome/common/histogram_synchronizer.o
> > > CXX(target)
> > > out/Release/obj.target/common/chrome/common/important_file_writer.o
> > > CXX(target)
> > > out/Release/obj.target/common/chrome/common/jstemplate_builder.o
> > > CXX(target)
> out/Release/obj.target/common/chrome/common/libxml_utils.o
> > > CXX(target)
> out/Release/obj.target/common/chrome/common/logging_chrome.o
> > > cc1plus: warnings being treated as errors
> > > chrome/common/libxml_utils.cc: In static member function 'static void
> > > XmlReader::GenericErrorCallback(void*, const char*, ...)':
> > > chrome/common/libxml_utils.cc:38: error: cannot pass objects of non-POD
> > > type 'struct va_list' through '...'; call will abort at runtime
> > > make: *** [out/Release/obj.target/common/chrome/common/libxml_utils.o]
> > > Error 1
> > > make: *** Waiting for unfinished jobs
> >
> > +chromium-dev
> >
> > Sofia, I haven't seen that error. Which compiler did you end up using ?
> > However the code does look suspicious, passing va_list through "...":
> >
> > void XmlReader::GenericErrorCallback(void* context, const char* msg, ...)
> {
> > va_list args;
> > va_start(args, msg);
> >
> > XmlReader* reader = static_cast(context);
> > reader->errors_.append(StringPrintf(msg, args));
> >
> > }
> >
> > Chromium C++ experts: Is that supposed to be legal, or even portable ? It
> > sounds like StringAppendV would be preferable here.
> >
> > Antoine
>
--
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] [GTTF] running the views and chromeos trybots for more kinds of CLs
On Mon, Dec 7, 2009 at 1:38 PM, Paweł Hajdan Jr. wrote: > I hit at least few cases when I broke the views and/or chromeos buildbot > with a CL which doesn't touch the views code directly (which would trigger > submitting it to the views trybot). Today another change in a gypi file > triggered a compile failure on views bots, while all other trybots have been > so green. > > How about triggering sending the CL to views trybots when it touches any > gyp-related file, or any code in chrome? This should help making our tree > even more green. > Agreed. Only question I have is if we have enough view/chromeos bots to handle all requests in reasonable time. May not be an issue tho. As somewhat related note, we're planning to make changes to view and chromeos build. Basically, chromeos build will become what view build does today, and chromeos dependency will be removed from view build. This should make our life a bit easier. - oshima > -- > 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] buildbot failure in Chromium on Chromium Mac, revision 34030
Automatically closing tree for "compile" on "Chromium Mac" http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Mac/builds/3567 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Mac --=> Automatically closing tree for "compile" on "Chromium Mac" <=-- Revision: 34029, 34030 Blame list: mar...@chromium.org,pi...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- 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 chromium for arm--erroring out
Hi All,
I am using the codesourcery toolchain to compile
http://www.codesourcery.com/sgpp/lite/arm/portal/release644 ---
arm-2008q3
I will delete everything and do gclient sync again...
The following are the steps I use to get the source code for chrome
browser for ARM:
gclient config http://src.chromium.org/svn/trunk/src
export GYP_GENERATORS=make
export GYP_DEFINES="target_arch=arm armv7=1 sysroot=/home/adas/x-tools/
arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
disable_nacl=1 use_system_ffmpeg=1"
gclient sync
Let me know if I am doing something wrong.
Thanks,
Sofia
On Dec 7, 5:13 pm, Antoine Labour wrote:
> On Mon, Dec 7, 2009 at 2:50 PM, SOFIA TAHSEEN wrote:
> > Hi Antoine/Joel,
>
> > When I try to build using the following make command I get the error as
> > below...Have you seen this earlier :
>
> > make -r -j3 BUILDTYPE=Release chrome
> > (I have a dual core so used -j3)
>
> > CXX(target)
> > out/Release/obj.target/common/chrome/common/histogram_synchronizer.o
> > CXX(target)
> > out/Release/obj.target/common/chrome/common/important_file_writer.o
> > CXX(target)
> > out/Release/obj.target/common/chrome/common/jstemplate_builder.o
> > CXX(target) out/Release/obj.target/common/chrome/common/libxml_utils.o
> > CXX(target) out/Release/obj.target/common/chrome/common/logging_chrome.o
> > cc1plus: warnings being treated as errors
> > chrome/common/libxml_utils.cc: In static member function 'static void
> > XmlReader::GenericErrorCallback(void*, const char*, ...)':
> > chrome/common/libxml_utils.cc:38: error: cannot pass objects of non-POD
> > type 'struct va_list' through '...'; call will abort at runtime
> > make: *** [out/Release/obj.target/common/chrome/common/libxml_utils.o]
> > Error 1
> > make: *** Waiting for unfinished jobs
>
> +chromium-dev
>
> Sofia, I haven't seen that error. Which compiler did you end up using ?
> However the code does look suspicious, passing va_list through "...":
>
> void XmlReader::GenericErrorCallback(void* context, const char* msg, ...) {
> va_list args;
> va_start(args, msg);
>
> XmlReader* reader = static_cast(context);
> reader->errors_.append(StringPrintf(msg, args));
>
> }
>
> Chromium C++ experts: Is that supposed to be legal, or even portable ? It
> sounds like StringAppendV would be preferable here.
>
> Antoine
--
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] Chromium arm native compile error on ubuntu.
Yes, I 've installed flex: ii flex 2.5.35-6ubuntu1 A fast lexical analyzer generator. Thanks Richard On Tue, Dec 8, 2009 at 2:41 AM, Dan Kegel wrote: > Do you have flex installed? > > On Mon, Dec 7, 2009 at 5:59 AM, Richard Zhao wrote: >> I'm using chromeos build script build_chrome.sh. Error log: >> >> RULE webcore_bindings_sources_binding_39 out/Release/obj/gen/webcore/ >> bindings/ >> V8DocumentType.cpp >> Traceback (most recent call last): >> File "scripts/action_csspropertynames.py", line 166, in >> sys.exit(main(sys.argv)) >> File "scripts/action_csspropertynames.py", line 141, in main >> assert returnCode == 0 >> AssertionError >> Traceback (most recent call last): >> File "scripts/action_maketokenizer.py", line 101, in >> sys.exit(main(sys.argv)) >> File "scripts/action_maketokenizer.py", line 89, in main >> p1 = subprocess.Popen(['flex', '-t', flexInput], >> stdout=subprocess.PIPE) >> File "/usr/lib/python2.6/subprocess.py", line 595, in __init__ >> errread, errwrite) >> File "/usr/lib/python2.6/subprocess.py", line 1092, in >> _execute_child >> raise child_exception >> OSError: [Errno 2] No such file or directory >> >> Thanks >> Richard >> >> -- >> 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] -m32 not recognized on arm ubuntu
I found many places using -m32 cflags. but my gcc can recognize it. How do you compile? Thanks Richard -- 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] -m32 not recognized on arm ubuntu
On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao wrote: > I found many places using -m32 cflags. but my gcc can recognize it. > How do you compile? > http://code.google.com/p/chromium/wiki/LinuxChromiumArm 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] Visualizing painting
Chrome now supports a handy command line flag that'll show you the regions of the page that are being re-painted. This can be helpful if you are tracking down repaint issues. $ chrome --show-paint-rects It's interesting to see what causes large re-paints ;-) -Darin -- 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] Chromium arm native compile error on ubuntu.
Thanks. I run gclient sync --deps="unix,chromeos" --force again. It's ok now. Richard On Tue, Dec 8, 2009 at 10:13 AM, Richard Zhao wrote: > Yes, I 've installed flex: > ii flex 2.5.35-6ubuntu1 > A fast lexical analyzer generator. > > Thanks > Richard > > On Tue, Dec 8, 2009 at 2:41 AM, Dan Kegel wrote: >> Do you have flex installed? >> >> On Mon, Dec 7, 2009 at 5:59 AM, Richard Zhao wrote: >>> I'm using chromeos build script build_chrome.sh. Error log: >>> >>> RULE webcore_bindings_sources_binding_39 out/Release/obj/gen/webcore/ >>> bindings/ >>> V8DocumentType.cpp >>> Traceback (most recent call last): >>> File "scripts/action_csspropertynames.py", line 166, in >>> sys.exit(main(sys.argv)) >>> File "scripts/action_csspropertynames.py", line 141, in main >>> assert returnCode == 0 >>> AssertionError >>> Traceback (most recent call last): >>> File "scripts/action_maketokenizer.py", line 101, in >>> sys.exit(main(sys.argv)) >>> File "scripts/action_maketokenizer.py", line 89, in main >>> p1 = subprocess.Popen(['flex', '-t', flexInput], >>> stdout=subprocess.PIPE) >>> File "/usr/lib/python2.6/subprocess.py", line 595, in __init__ >>> errread, errwrite) >>> File "/usr/lib/python2.6/subprocess.py", line 1092, in >>> _execute_child >>> raise child_exception >>> OSError: [Errno 2] No such file or directory >>> >>> Thanks >>> Richard >>> >>> -- >>> 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
Re: [chromium-dev] Visualizing painting
On Mon, Dec 7, 2009 at 8:15 PM, Darin Fisher wrote: > Chrome now supports a handy command line flag that'll show you the regions > of the > page that are being re-painted. This can be helpful if you are tracking > down repaint > issues. > > $ chrome --show-paint-rects > > It's interesting to see what causes large re-paints ;-) > I would love to see someone enable the window resize gripper on Windows (which has never been enabled due to repaint perf issues) and start using this flag to figure out what's up. Added incentive: maybe Darin's repaint coalescing work has eliminated the performance problems of this code and we can just turn it on. PK -- 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] -m32 not recognized on arm ubuntu
On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour wrote: > > > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao wrote: >> >> I found many places using -m32 cflags. but my gcc can recognize it. >> How do you compile? > > http://code.google.com/p/chromium/wiki/LinuxChromiumArm It's about cross-compile. I'm doing native compile. Does 'disable_nacl': 1, 'use_system_ffmpeg' : '1', help? chromiumos.git/src/scripts/build_chrome.sh don't have this two define. Thanks Richard -- 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] Visualizing painting
On Mon, Dec 7, 2009 at 8:31 PM, Peter Kasting wrote: > On Mon, Dec 7, 2009 at 8:15 PM, Darin Fisher wrote: > >> Chrome now supports a handy command line flag that'll show you the regions >> of the >> page that are being re-painted. This can be helpful if you are tracking >> down repaint >> issues. >> >> $ chrome --show-paint-rects >> >> It's interesting to see what causes large re-paints ;-) >> > > I would love to see someone enable the window resize gripper on Windows > (which has never been enabled due to repaint perf issues) and start using > this flag to figure out what's up. > > Added incentive: maybe Darin's repaint coalescing work has eliminated the > performance problems of this code and we can just turn it on. > > PK > Yeah, I suspect that we should be able to re-enable the window resize gripper now. -Darin -- 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] -m32 not recognized on arm ubuntu
On Mon, Dec 7, 2009 at 8:35 PM, Richard Zhao wrote: > On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour > wrote: > > > > > > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao wrote: > >> > >> I found many places using -m32 cflags. but my gcc can recognize it. > >> How do you compile? > > > > http://code.google.com/p/chromium/wiki/LinuxChromiumArm > It's about cross-compile. I'm doing native compile. > Good luck with that. Chrome takes several gigabytes of RAM to link, and >15 minutes to link on a PC. It will take hours on any existing ARM machine. > Does >'disable_nacl': 1, >'use_system_ffmpeg' : '1', > help? > They will be needed, as well as target_arch=arm. > chromiumos.git/src/scripts/build_chrome.sh don't have this two define. > Chromium OS doesn't yet build for ARM. Antoine -- 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] -m32 not recognized on arm ubuntu
On Tue, Dec 8, 2009 at 12:41 PM, Antoine Labour wrote: > > > On Mon, Dec 7, 2009 at 8:35 PM, Richard Zhao wrote: >> >> On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour >> wrote: >> > >> > >> > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao wrote: >> >> >> >> I found many places using -m32 cflags. but my gcc can recognize it. >> >> How do you compile? >> > >> > http://code.google.com/p/chromium/wiki/LinuxChromiumArm >> It's about cross-compile. I'm doing native compile. > > Good luck with that. > Chrome takes several gigabytes of RAM to link, and >15 minutes to link on a > PC. It will take hours on any existing ARM machine. > >> >> Does >> 'disable_nacl': 1, >> 'use_system_ffmpeg' : '1', >> help? > > They will be needed, as well as target_arch=arm. > >> >> chromiumos.git/src/scripts/build_chrome.sh don't have this two define. > > Chromium OS doesn't yet build for ARM. I'm building chromiumos on arm ubuntu manually. Most things got from ubuntu arm repo. It seems chromiumos don't has ffmpeg package installed, so I don't need to add "'use_system_ffmpeg' : '1'"? What about disable_nacl? I've substituted all -m32 with " ". Thanks Richard -- 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] -m32 not recognized on arm ubuntu
On Mon, Dec 7, 2009 at 8:58 PM, Richard Zhao wrote: > On Tue, Dec 8, 2009 at 12:41 PM, Antoine Labour > wrote: > > > > > > On Mon, Dec 7, 2009 at 8:35 PM, Richard Zhao wrote: > >> > >> On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour > >> wrote: > >> > > >> > > >> > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao > wrote: > >> >> > >> >> I found many places using -m32 cflags. but my gcc can recognize it. > >> >> How do you compile? > >> > > >> > http://code.google.com/p/chromium/wiki/LinuxChromiumArm > >> It's about cross-compile. I'm doing native compile. > > > > Good luck with that. > > Chrome takes several gigabytes of RAM to link, and >15 minutes to link on > a > > PC. It will take hours on any existing ARM machine. > > > >> > >> Does > >>'disable_nacl': 1, > >>'use_system_ffmpeg' : '1', > >> help? > > > > They will be needed, as well as target_arch=arm. > > > >> > >> chromiumos.git/src/scripts/build_chrome.sh don't have this two define. > > > > Chromium OS doesn't yet build for ARM. > > I'm building chromiumos on arm ubuntu manually. Most things got from > ubuntu arm repo. > It seems chromiumos don't has ffmpeg package installed, so I don't > need to add "'use_system_ffmpeg' : '1'"? > If you don't set use_system_ffmpeg=1, the build system will try to build x86 assembly with and x86 assembler and it won't work. > What about disable_nacl? > You need it as well. > > I've substituted all -m32 with " ". > Really, set target_arch=arm That will fix your -m32 issues, as well as many others (like trying to compile sse code). Antoine -- 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] Profiles + SharedWorkers
On Mon, Dec 7, 2009 at 11:37 AM, Drew Wilson wrote: > Hi all, > > I'm trying to understand the current (and future) state of Profile support. > > Currently, SharedWorkers are shared by all windows in the system - any two > windows under the same domain can do "new SharedWorker(url)" and get a > reference to the same SharedWorker, and can use that worker to share data. > > I currently am special-casing incognito windows, so incognito windows don't > share workers with non-incognito workers, but I don't do anything to deal > with profiles in general (so if you were running with separate profiles, > those profiles would see one another's workers). > That's definitely a bug if we ever really make use of profiles. In general, we have tried to honor the profile divide even if we don't surface profiles in the UI. > > I'm trying to figure out the best way to address this (and whether this is > something that needs to be addressed in the near term, given that we don't > officially support profiles - it sounds like chromeos may make some use of > them?). ResourceMessageFilter has a reference to a Profile object - are > these Profile objects global (for example, in the typical situation of a > single profile + incognito, are there only two Profile objects in the > Browser process)? > A renderer process is merely assigned a Profile. That way a renderer is limited to only seeing the data of a single Profile. -Darin > > -atw > > -- > 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
Re: [chromium-dev] -m32 not recognized on arm ubuntu
On Tue, Dec 8, 2009 at 1:03 PM, Antoine Labour wrote: > > > On Mon, Dec 7, 2009 at 8:58 PM, Richard Zhao wrote: >> >> On Tue, Dec 8, 2009 at 12:41 PM, Antoine Labour >> wrote: >> > >> > >> > On Mon, Dec 7, 2009 at 8:35 PM, Richard Zhao wrote: >> >> >> >> On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour >> >> wrote: >> >> > >> >> > >> >> > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao >> >> > wrote: >> >> >> >> >> >> I found many places using -m32 cflags. but my gcc can recognize it. >> >> >> How do you compile? >> >> > >> >> > http://code.google.com/p/chromium/wiki/LinuxChromiumArm >> >> It's about cross-compile. I'm doing native compile. >> > >> > Good luck with that. >> > Chrome takes several gigabytes of RAM to link, and >15 minutes to link >> > on a >> > PC. It will take hours on any existing ARM machine. >> > >> >> >> >> Does >> >> 'disable_nacl': 1, >> >> 'use_system_ffmpeg' : '1', >> >> help? >> > >> > They will be needed, as well as target_arch=arm. >> > >> >> >> >> chromiumos.git/src/scripts/build_chrome.sh don't have this two define. >> > >> > Chromium OS doesn't yet build for ARM. >> >> I'm building chromiumos on arm ubuntu manually. Most things got from >> ubuntu arm repo. >> It seems chromiumos don't has ffmpeg package installed, so I don't >> need to add "'use_system_ffmpeg' : '1'"? > > If you don't set use_system_ffmpeg=1, the build system will try to build x86 > assembly with and x86 assembler and it won't work. > >> >> What about disable_nacl? > > You need it as well. > >> >> I've substituted all -m32 with " ". > > Really, set target_arch=arm > That will fix your -m32 issues, as well as many others (like trying to > compile sse code). > Antoine export GYP_DEFINES="chromeos=1 target_arch=arm disable_nacl=1 use_system_ffmpeg=1" It won't fix the -m32 issues. Thanks Richard -- 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] -m32 not recognized on arm ubuntu
On Tue, Dec 8, 2009 at 1:54 PM, Richard Zhao wrote: > On Tue, Dec 8, 2009 at 1:03 PM, Antoine Labour wrote: >> >> >> On Mon, Dec 7, 2009 at 8:58 PM, Richard Zhao wrote: >>> >>> On Tue, Dec 8, 2009 at 12:41 PM, Antoine Labour >>> wrote: >>> > >>> > >>> > On Mon, Dec 7, 2009 at 8:35 PM, Richard Zhao wrote: >>> >> >>> >> On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour >>> >> wrote: >>> >> > >>> >> > >>> >> > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao >>> >> > wrote: >>> >> >> >>> >> >> I found many places using -m32 cflags. but my gcc can recognize it. >>> >> >> How do you compile? >>> >> > >>> >> > http://code.google.com/p/chromium/wiki/LinuxChromiumArm >>> >> It's about cross-compile. I'm doing native compile. >>> > >>> > Good luck with that. >>> > Chrome takes several gigabytes of RAM to link, and >15 minutes to link >>> > on a >>> > PC. It will take hours on any existing ARM machine. >>> > >>> >> >>> >> Does >>> >> 'disable_nacl': 1, >>> >> 'use_system_ffmpeg' : '1', >>> >> help? >>> > >>> > They will be needed, as well as target_arch=arm. >>> > >>> >> >>> >> chromiumos.git/src/scripts/build_chrome.sh don't have this two define. >>> > >>> > Chromium OS doesn't yet build for ARM. >>> >>> I'm building chromiumos on arm ubuntu manually. Most things got from >>> ubuntu arm repo. >>> It seems chromiumos don't has ffmpeg package installed, so I don't >>> need to add "'use_system_ffmpeg' : '1'"? >> >> If you don't set use_system_ffmpeg=1, the build system will try to build x86 >> assembly with and x86 assembler and it won't work. >> >>> >>> What about disable_nacl? >> >> You need it as well. >> >>> >>> I've substituted all -m32 with " ". >> >> Really, set target_arch=arm >> That will fix your -m32 issues, as well as many others (like trying to >> compile sse code). >> Antoine > export GYP_DEFINES="chromeos=1 target_arch=arm disable_nacl=1 > use_system_ffmpeg=1" > It won't fix the -m32 issues. Log: TOUCH out/Release/obj.target/third_party/WebKit/WebCore/WebCore.gyp/webcore_bindings_sources.stamp ACTION js2c_js2c out/Release/obj/gen/libraries.cc TOUCH out/Release/obj.host/v8/tools/gyp/js2c.stamp CXX(host) out/Release/obj.host/v8_nosnapshot/gen/libraries.o cc1plus: error: unrecognized command line option "-m32" make: *** [out/Release/obj.host/v8_nosnapshot/gen/libraries.o] Error 1 -- 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] -m32 not recognized on arm ubuntu
On Mon, Dec 7, 2009 at 9:58 PM, Richard Zhao wrote: > On Tue, Dec 8, 2009 at 1:54 PM, Richard Zhao wrote: > > On Tue, Dec 8, 2009 at 1:03 PM, Antoine Labour > wrote: > >> > >> > >> On Mon, Dec 7, 2009 at 8:58 PM, Richard Zhao > wrote: > >>> > >>> On Tue, Dec 8, 2009 at 12:41 PM, Antoine Labour > >>> wrote: > >>> > > >>> > > >>> > On Mon, Dec 7, 2009 at 8:35 PM, Richard Zhao > wrote: > >>> >> > >>> >> On Tue, Dec 8, 2009 at 11:41 AM, Antoine Labour > > >>> >> wrote: > >>> >> > > >>> >> > > >>> >> > On Mon, Dec 7, 2009 at 7:30 PM, Richard Zhao > >>> >> > wrote: > >>> >> >> > >>> >> >> I found many places using -m32 cflags. but my gcc can recognize > it. > >>> >> >> How do you compile? > >>> >> > > >>> >> > http://code.google.com/p/chromium/wiki/LinuxChromiumArm > >>> >> It's about cross-compile. I'm doing native compile. > >>> > > >>> > Good luck with that. > >>> > Chrome takes several gigabytes of RAM to link, and >15 minutes to > link > >>> > on a > >>> > PC. It will take hours on any existing ARM machine. > >>> > > >>> >> > >>> >> Does > >>> >>'disable_nacl': 1, > >>> >>'use_system_ffmpeg' : '1', > >>> >> help? > >>> > > >>> > They will be needed, as well as target_arch=arm. > >>> > > >>> >> > >>> >> chromiumos.git/src/scripts/build_chrome.sh don't have this two > define. > >>> > > >>> > Chromium OS doesn't yet build for ARM. > >>> > >>> I'm building chromiumos on arm ubuntu manually. Most things got from > >>> ubuntu arm repo. > >>> It seems chromiumos don't has ffmpeg package installed, so I don't > >>> need to add "'use_system_ffmpeg' : '1'"? > >> > >> If you don't set use_system_ffmpeg=1, the build system will try to build > x86 > >> assembly with and x86 assembler and it won't work. > >> > >>> > >>> What about disable_nacl? > >> > >> You need it as well. > >> > >>> > >>> I've substituted all -m32 with " ". > >> > >> Really, set target_arch=arm > >> That will fix your -m32 issues, as well as many others (like trying to > >> compile sse code). > >> Antoine > > export GYP_DEFINES="chromeos=1 target_arch=arm disable_nacl=1 > > use_system_ffmpeg=1" > > It won't fix the -m32 issues. > Log: > TOUCH > out/Release/obj.target/third_party/WebKit/WebCore/WebCore.gyp/webcore_bindings_sources.stamp > ACTION js2c_js2c out/Release/obj/gen/libraries.cc > TOUCH out/Release/obj.host/v8/tools/gyp/js2c.stamp > CXX(host) out/Release/obj.host/v8_nosnapshot/gen/libraries.o > cc1plus: error: unrecognized command line option "-m32" > make: *** [out/Release/obj.host/v8_nosnapshot/gen/libraries.o] Error 1 > I see. The host-side tools force -m32 in v8. It'd be great to not need it but right now that's needed for 64-bit hosts. Your best bet is to remove the -m32 lines in v8/tools/gyp/v8.gyp (see associated TODO). Antoine -- 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] Profiles + SharedWorkers
> > >> > We do officially support profiles: they're how Incognito works. And we go > to great lengths elsewhere to make them work right in general. We don't > have UI for widespread general use of lots of profiles, but the > functionality works well. > Indeed -- we have some tests (e.g. sync integration tests) that currently rely on running multiple profiles in one browser process, and it works as expected*. * aside from some memory leaks on multi-profile teardown I haven't tracked down, though :( > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
