Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
Yeah, so my question was, does that mean test_shell would have a separate mechanism (the current one?) for file:/// listings? On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher da...@chromium.org wrote: DOM UI implies chrome://, which is implemented by the ChromeURLDataManager (in browser/dom_ui/). TestShell wouldn't be able to use that. -Darin On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee de...@chromium.org wrote: I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
I am pretty out of things these days, but will a DOM UI file:// listing work for test_shell? On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher da...@chromium.org wrote: Right, that's the tricky part. You'd need to do something creative. -Darin On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: Okay. Yes we could use data URI, but where do we retrieve the icon resources from at that level? 2010/1/6 Darin Fisher da...@chromium.org We can also use data: URLs to inject the icons into the HTML file used to render the directory listings. We can do that at the time when the HTML file is generated. -Darin On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin e...@chromium.org wrote: I talked with Arv in person and I think I sufficiently convinced him that getting DOMUI security right is tricky. (Consider: XSSes in the FTP display code, and that ftp sites containing HTML pages must not have privs when displaying the HTML.) That may still mean that DOMUI is ok, but I would prefer to consider any other option available. One idea is to say we don't care if any old page can img src='chrome://os-style-icon/foobar.psd' to get a Photoshop icon. Not sure. On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson a...@chromium.org wrote: I think it should be OK to move these to DOMUI. NTP can also link to local HTML files and we already mark the chrome protocol in such a way that it cannot be accessed by any other scheme. erik On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette pierre.lafaye...@gmail.com wrote: That's why I wanted to check before starting any work. So the question is now whether it we'd rather use a DOM UI page or create a similar API that would be used solely by file:// and ftp://. What is needed for http://crbug.com/24421 is simply access to the favicon data for file types. I'm not sure if these are available through WebCore or not. The drag and drop functionality required by http://crbug.com/27772 seems like it would be a lot of work without using a DOM UI page. Any opinions on this part of my original post?: Is there any reason why ChromiumOS' chrome://filebrowse DOM ui page couldn't be generalized to be used for these other directory listing pages? It just seems to me that it would be rather redundant handle 3 separate instances of a file browse HTML page (ftp://, file:// and chrome://filebrowse) in 3 separate ways. Thanks. 2010/1/5 Evan Martin e...@chromium.org On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy g...@chromium.org wrote: I don't think anyone has any objection to DOMUIifying those pages, and I don't think it would be a large amount of work. The only reason they're not is that there hasn't been a reason to do so. DOM UI (at least when I last looked) just means that that renderer (the page) gets extra privileges necessary for doing special browser calls, such as access to your browsing history for the History implementation. We went to some effort to keep these sorts of pages distinct from network content with the hope of reducing the security surface. I worry changing this for FTP would be going in the wrong direction. It might make more sense to do something *like* DOM UI but with a different API just to keep things distinct. But then we reencounter the same sorts of problems we have with DOM UI, like for example if you click a link from an FTP site to an HTML file, how to prevent the FTP privileges from bleeding into the HTML file. I feel like Darin is the person who would best know how to address this. :) -- Pierre. -- 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 -- Pierre. -- 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] Thread naming
Traceline is a good way to see how this happens. We generally name all of the Chrome threads (base::Thread), but the system is allowed to create threads of its own. Loads of APIs create threads, along with the windows worker pool (which we make good use of to help reuse threads). For example, wininet can create it's own thread pools, etc. I did some work on cutting down the number of threads and thread creation times. In specific thread creation can contend the main UI thread because of holding the loader lock for DLLMain initialization, etc. Here is an older example of traceline output: http://deanm.github.com/misc/traceline/traceline.xml#startup-release.json You can easily see which threads are created, when, and the call stacks for what created them by hovering on the lines. -- dean On Thu, Dec 31, 2009 at 7:09 PM, Jim Roskind j...@chromium.org wrote: I'm pretty sure we name all the threads we can (or at least used to), I *think* the problem is worker threads in a thread pool, which are started up and shut down automatically, and aren't named (and don't have message loops). When I was doing the work to generate the internal page about:tasks, it was critical to have names on all the threads (that I could), as the data also shows what threads sent and received tasks. Jim On Thu, Dec 31, 2009 at 1:11 AM, Berend-Jan Wever skyli...@chromium.org wrote: If you do not care about the way threads are run inside a process in Chromium, you can stop reading now. Some of our threads are named, while others are not. See below cdb.exe output for a renderer process: 2:020:x86 ~ 1 Id: d98.1588 Suspend: 1 Teb: 7efd8000 Unfrozen Chrome_ChildIOThread . 20 Id: d98.1440 Suspend: 1 Teb: 7efdb000 Unfrozen Main Thread 21 Id: d98.10d4 Suspend: 1 Teb: 7ef4d000 Unfrozen 22 Id: d98.171c Suspend: 1 Teb: 7efd5000 Unfrozen 2:020:x86 ~21 s ntdll32!ZwWaitForMultipleObjects+0x15: 76fa99fd c21400 ret 14h 2:021:x86 kp ChildEBP RetAddr 0399fcd4 7702787d ntdll32!ZwWaitForMultipleObjects+0x15 0399fe68 750feccb ntdll32!TppWaiterpThread+0x328 0399fe74 76fdd24d kernel32!BaseThreadInitThunk+0xe 0399feb4 76fdd45f ntdll32!__RtlUserThreadStart+0x23 0399fecc ntdll32!_RtlUserThreadStart+0x1b 2:021:x86 ~22 s ntdll32!NtWaitForWorkViaWorkerFactory+0x12: 76fab5ee c20800 ret 8 2:022:x86 kp ChildEBP RetAddr 0357f6ec 76f9b927 ntdll32!NtWaitForWorkViaWorkerFactory+0x12 0357f81c 750feccb ntdll32!TppWorkerThread+0x1f6 0357f828 76fdd24d kernel32!BaseThreadInitThunk+0xe 0357f868 76fdd45f ntdll32!__RtlUserThreadStart+0x23 0357f880 ntdll32!_RtlUserThreadStart+0x1b What are these threads and why are they nameless? Did we create these threads at all? (They could have been created by plugins/detours/etc. that we have no control over.) It would be nice if we could name all threads, so you know what you're looking at. Thanks! BJ Berend-Jan SkyLined Wever skyli...@google.com -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing 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: linux startup regression
I will investigate this today. On Thu, Sep 3, 2009 at 4:29 AM, James Hawkinsjhawk...@chromium.org wrote: No, and it's only invoked during tab dragging. On Wed, Sep 2, 2009 at 7:20 PM, Michael Nordmanmicha...@google.com wrote: There's is nothing platform specific about r25099, since other platforms don't show a hit... probably not it. r25112 - use x11_util::GetXWindowStack Does that load additional libraries? On Wed, Sep 2, 2009 at 6:41 PM, James Hawkins jhawk...@chromium.org wrote: Maybe r25099? I don't know how long it takes between commit time and when the results show up in the graph, so this is a rough guess. r25099 -- Plumb request interception into the appcache library for both chrome and test_shell. ... Chrome: * Each UserProfile instantiates a ChromeAppCacheService, which is derived from an appcache library class. On Wed, Sep 2, 2009 at 6:21 PM, Evan Martine...@chromium.org wrote: http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150 We seem to have lost about 50% around r25132, but the commits around there aren't at all suspicious. :( Any guesses? Maybe Brett's change? --~--~-~--~~~---~--~~ 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 startup regression
Ug, I can't reproduce this on my desktop. If I had to take a guess, I would guess Brett's gfx::Font change. TOT: *RESULT warm: t= [134.82,133.98,135.04,134.37,134.95,135.01,134.78,134.69,134.55,134.21,134.27,137.12,134.31,134.20,134.56,135.37,135.02,134.68,134.22,134.58,] ms r25120: *RESULT warm: t= [135.35,134.35,133.96,134.84,134.52,133.69,134.14,134.07,134.42,134.18,133.86,134.13,133.99,134.50,134.10,134.62,134.21,134.55,134.27,133.60,] ms On Thu, Sep 3, 2009 at 10:20 AM, Dean McNameede...@chromium.org wrote: I will investigate this today. On Thu, Sep 3, 2009 at 4:29 AM, James Hawkinsjhawk...@chromium.org wrote: No, and it's only invoked during tab dragging. On Wed, Sep 2, 2009 at 7:20 PM, Michael Nordmanmicha...@google.com wrote: There's is nothing platform specific about r25099, since other platforms don't show a hit... probably not it. r25112 - use x11_util::GetXWindowStack Does that load additional libraries? On Wed, Sep 2, 2009 at 6:41 PM, James Hawkins jhawk...@chromium.org wrote: Maybe r25099? I don't know how long it takes between commit time and when the results show up in the graph, so this is a rough guess. r25099 -- Plumb request interception into the appcache library for both chrome and test_shell. ... Chrome: * Each UserProfile instantiates a ChromeAppCacheService, which is derived from an appcache library class. On Wed, Sep 2, 2009 at 6:21 PM, Evan Martine...@chromium.org wrote: http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150 We seem to have lost about 50% around r25132, but the commits around there aren't at all suspicious. :( Any guesses? Maybe Brett's change? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Major tab cold regression on mac around r24415
Looking at the graphs this would seem to make sense. All of the tests except the one using 'typical_history' have regressed. That's because Brett checked in the upgraded database for typical_history, but not for the other themes. We should just upgrade those and check them in. On Wed, Aug 26, 2009 at 9:46 AM, Thomas Van Lenten thoma...@chromium.org wrote: On Wed, Aug 26, 2009 at 12:32 PM, Thomas Van Lenten thoma...@chromium.org wrote: On Wed, Aug 26, 2009 at 12:28 PM, Evan Martin e...@chromium.org wrote: PS Every time I want to call it the EPIC CHANGE. On Wed, Aug 26, 2009 at 9:27 AM, Evan Martine...@chromium.org wrote: Here's a guess: the history file is restored each time the test runs, and Brett's epoch change means that we need to re-migrate the history file every time we start. (I don't recall how this test works, but it seems logical to test NTP performance you'd want some data that the NTP would make use of...) Wouldn't linux show this data also? or the non theme test also show it? I spoke too soon: http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150 looks like linux also sees it. TVL TVL On Wed, Aug 26, 2009 at 9:23 AM, Mike Pinkertonpinker...@chromium.org wrote: If you look at http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150 You'll see a pretty big spike in new tab performance between r24415 and r24419 http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?url=/trunk/srcmode=htmlrange=24415:24419 Anyone know what's going on? This is a very serious regression and there were no Mac-specific changes anywhere in the vicinity that I could see. I filed http://code.google.com/p/chromium/issues/detail?id=20312 to cover the regression. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Creating a SkBitmap filled with one color
To answer the technical (non-political) part of this question. Create a SkBitmap which backs to some pixels. Create a SkCanvas on top of it. Call drawPaint or more directly drawColor. On Wed, Aug 26, 2009 at 4:17 PM, Nico Weber tha...@chromium.org wrote: When I talked with Aaron, he said porting the shelf to OS X isn't something I should tackle unless I'm _really_ running out of things to do, since they're not even sure they're going to keep it. Has this changed, or is the situation different on linux for some reason? Nico On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: How do I create a SkBitmap of arbitrary size, filled with color of my choice (on Linux)? I'd need that for Linux extension shelf, and the Windows code for that seems not easily portable to Linux. --~--~-~--~~~---~--~~ 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: Creating a SkBitmap filled with one color
On Wed, Aug 26, 2009 at 4:14 PM, Elliot Glaysher (Chromium) e...@chromium.org wrote: See what I do in GtkThemeProvider::LoadThemeBitmap: SkBitmap* bitmap = new SkBitmap; bitmap-setConfig(SkBitmap::kARGB__Config, kToolbarImageWidth, kToolbarImageHeight); bitmap-allocPixels(); bitmap-eraseRGB(color-red 8, color-green 8, color-blue 8); This code is incorrect, you should divide by 257, not 256. See the GDK_COLOR_RGB macro. return bitmap; -- Elliot On Wed, Aug 26, 2009 at 4:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: How do I create a SkBitmap of arbitrary size, filled with color of my choice (on Linux)? I'd need that for Linux extension shelf, and the Windows code for that seems not easily portable to Linux. --~--~-~--~~~---~--~~ 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: Creating a SkBitmap filled with one color
Yes, this can be reformulated easier as i * 257 = i * 256 + i and i / 256 will always be zero for i 256. Anyway, I suppose it doesn't matter. The question is what to do for mapping 16-bit back to 8-bit, when it wasn't necessarily originally produced from 8-bit. I suppose that dividing by 256 is the right thing to do, sorry about that. It just seemed strange to not do the inverse, but yeah, you're right... On Wed, Aug 26, 2009 at 5:21 PM, Nico Weber tha...@chromium.org wrote: This code is incorrect, you should divide by 257, not 256. See the GDK_COLOR_RGB macro. That's not true. GDK_COLOR_RGB multiplies by 257 (= 0x10001) to distribute the bits evenly ( http://www.mindcontrol.org/~hplus/graphics/expand-bits.html ). To get back, you can just shift (or, formulated differently, i == (i*257)/256 for all i 256). --~--~-~--~~~---~--~~ 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: Cross-compiling on ARM
That still requires you to link locally, and I don't think we have any ARM machines with enough memory to do that. On Mon, Aug 24, 2009 at 1:53 PM, Scott Hess sh...@chromium.org wrote: Would it be possible/reasonable to use distcc plus a farm of cross-compiler machines to let you do faster self-hosted builds? It's not the right solution, but in the past I've found it to sometimes be an easier path to take in the short term while you're working on fixing all the little problems. -scott On Fri, Aug 21, 2009 at 12:54 PM, Antoine Labourpi...@chromium.org wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox highlighting and PRIMARY selection concerns
A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there has been so much discussion. I am not going to try to repeat all of that here. You can also read bug 13561, which was a previous round of something similar. Basically you have to stop thinking of the Omnibox as an already existing GTK widget, and think of it as a new widget designed specifically for optimizing input of URLs. That means there is no conventions for this new type of widget. GtkEntry / etc were optimized for clicking a text box and editing / inserting text. The Omnibox widget is optimized for clicking and replacing text. We believe this behavior makes sense for how people input URLs. On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote: This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. Doesn't the fact that this debate has happened 15 times already raise a red flag for everyone? I mean, to me, that smells like - as they say on the internets - you're doing it wrong. I hate that we're distracting you guys once again on an issue that you all thought was settled, but I can also guarantee that you'll see it another 115 times, until it starts to conform with conventions. And I'd really hate for us boneheaded non-windows users to keep wasting your attention and deflecting your energy when you could be using it instead to take care of all those other things that I'm sure are on your plates. We're on your side, we really are! I don't want to go back to Firefox. Please reconsider. --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. Chromium of course is open source, which is a very hidden form of configuration. Good luck, -- dean On Fri, Aug 21, 2009 at 8:57 AM, JT Olds jto...@xnet5.com wrote: Can we please make it configurable? I hate the click once select all thing. It really drives me nuts. Chromium is so nice otherwise. I don't care how hidden of a configuration parameter it is, just so long as I can change it. On Fri, Aug 21, 2009 at 9:12 AM, Dean McNameede...@chromium.org wrote: A bug tracker is the right place to have this discussion, and I see you've filed 19508 which was closed WontFix. I appreciate your opinion and dedication to Linux. We have plenty of Linux users who have gotten adjusted to this behavior and prefer it. There is no clear answer, which is why there has been so much discussion. I am not going to try to repeat all of that here. You can also read bug 13561, which was a previous round of something similar. Basically you have to stop thinking of the Omnibox as an already existing GTK widget, and think of it as a new widget designed specifically for optimizing input of URLs. That means there is no conventions for this new type of widget. GtkEntry / etc were optimized for clicking a text box and editing / inserting text. The Omnibox widget is optimized for clicking and replacing text. We believe this behavior makes sense for how people input URLs. On Thu, Aug 20, 2009 at 11:38 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 20, 5:40 pm, Dean McNamee de...@chromium.org wrote: This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. Doesn't the fact that this debate has happened 15 times already raise a red flag for everyone? I mean, to me, that smells like - as they say on the internets - you're doing it wrong. I hate that we're distracting you guys once again on an issue that you all thought was settled, but I can also guarantee that you'll see it another 115 times, until it starts to conform with conventions. And I'd really hate for us boneheaded non-windows users to keep wasting your attention and deflecting your energy when you could be using it instead to take care of all those other things that I'm sure are on your plates. We're on your side, we really are! I don't want to go back to Firefox. Please reconsider. --~--~-~--~~~---~--~~ 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: Lock the Render process in chromium
Joel had some ideas about doing something like thing for power saving. On Thu, Aug 20, 2009 at 12:51 PM, Adam Langley a...@chromium.org wrote: On Thu, Aug 20, 2009 at 9:38 AM, n179911n179...@gmail.com wrote: I don't want the renderer process to die. I just want it 'locked' so that i can dump out information of the page (DOM, CSS) of the page. And I want the page unchange during the information dumping. SIGSTOP doesn't kill the process, it just, well, stops it. (SIGCONT to start it again.) 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: Cross-compiling on ARM
On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour pi...@google.com wrote: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. If you decide you do want snapshotting on arm (it has some down sides), I think there is a pretty easy way to go about this. Basically making the mksnapshot target pause and wait for you to hit enter. Then you can run your script or do whatever to run mksnapshot on the right machine, and bring the output back. I would not try to make GYP any more intelligent than this (besides maybe running an arbitrary script), since how you're going to run mksnapshot and move the data around is going to vary greatly depending on your setup. We could easily just add a gyp variable like v8_mksnaphot_command, and then you could replace that with whatever script you want. - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. I also don't think we should modify our GYP build for this. You can set PKG_CONFIG_PATH, etc, to have pkg-config use a different set of pc files. You can just create these files for whatever target you are building, and point pkg-config to use them instead. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
On Fri, Aug 21, 2009 at 2:58 PM, Antoine Labour pi...@google.com wrote: On Fri, Aug 21, 2009 at 2:45 PM, Erik Corryerik.co...@gmail.com wrote: 2009/8/21 Antoine Labour pi...@google.com: There's growing interest from several parties in getting Chrome to cross-compile onto linux/ARM. Let's make sure everyone is on the same page so that we don't duplicate efforts. I understand that Joel Stanley, Dean McNamee and Lei Zhang have already been doing a lot of work towards that. There's a wiki page there: http://code.google.com/p/chromium/wiki/LinuxChromiumArm I've identified a few missing pieces to get a full version of chrome - there may be others. They are mostly build infrastructure issues: - v8 snapshotting needs to be disabled currently, we'd like to enable it. That means executing mksnapshot as a target executable, either through qemu or directly on device, i.e. the infrastructure to run a target program. Actually the armulator (ARM simulator in V8) can be used to create ARM snapshots without running anything on the target platform. The C++ work is done for this, but the build file work isn't. What is needed is to build mksnapshot.cc with the armulator. This is done with simulator=arm in the scons build. I don't know how it's done with gyp. When the snapshot.cc file has been generated by mksnapshot you need to rebuild V8 from scratch, this time with the cross compiler. With the scons build that would be (after saving snapshot.cc and blowing away the other generated files) with snapshot=nobuild arch=arm wordsize=32. You need to make sure the CXX, AR, RANLIB and CC environment variables point to your cross toolchain. As I say, the build file work for this is not done yet. I am sure that it would be worth doing. The snapshot support makes startup of the VM faster at the cost of a moderate increase in size (moderate for a system capable of running Chromium). Since Chromium starts the VM on every new tab that is worth doing. On the other hand the browser is perfectly usable without this optimization so it is no show-stopper for the ARM version. That is very cool to know - I was afraid to ask :). It sounds like with some work on gyp, we could entirely cross-compile chrome, full featured. This sounds extremely difficult to do with gyp. Another thought, what about using qemu user emulation to run mksnapshot? Antoine - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. - The chrome os build relies on the protobuf compiler. The current build system builds it as a target executable, so we either need to run in qemu / on device it as above, or change the build system to understand target vs host executables. I wanted to double check if anyone was working on any of that, or if anyone has good ideas about how to achieve each of them. Please speak up ! Antoine -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. On Fri, Aug 21, 2009 at 2:52 PM, Dean McNamee de...@chromium.org wrote: On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 21, 10:17 am, Dean McNamee de...@chromium.org wrote: The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. ...but, wait a sec, Chromium on OSX seems to do exactly the right thing (for both Mac and Linux). Wouldn't unifying the logic behind these conventions for both of these platforms maybe simplify existing complexity? These are completely separate implementations, so no, there wouldn't be any simplification. The Omnibox work on OSX is not nearly as complete as Linux or Windows. I am not sure they've yet had the discussion about how this should 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] Re: Cross-compiling on ARM
On Fri, Aug 21, 2009 at 2:34 PM, Lei Zhang thes...@chromium.org wrote: On Fri, Aug 21, 2009 at 2:25 PM, Dean McNameede...@chromium.org wrote: On Fri, Aug 21, 2009 at 1:43 PM, Antoine Labour pi...@google.com wrote: - Gyp uses pkg-config to find includes/lib dependencies, i.e. it's going to look at the host for them. If your target distribution matches your host maybe you're fine, but it may not work at all, so it'd would be good to extract that and get a way to specify the dependencies explicitly. I also don't think we should modify our GYP build for this. You can set PKG_CONFIG_PATH, etc, to have pkg-config use a different set of pc files. You can just create these files for whatever target you are building, and point pkg-config to use them instead. I don't remember having to fight pkg-config. Maybe my host/target (Ubuntu Hardy x86/Debian Lenny ARM) matched closely enough that it didn't matter. Thanks for writing the wiki page. I should've done that a long time ago. I dumped the bits I remember on the wiki page. (Joel wrote the wiki page, thanks Joel!) --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 12:18 PM, alenpeacock alenlpeac...@gmail.com wrote: On Aug 21, 10:17 am, Dean McNamee de...@chromium.org wrote: The Omnibox widget code is already very involved, and I don't think it is a good idea to add any more complexity or additional modes. ...but, wait a sec, Chromium on OSX seems to do exactly the right thing (for both Mac and Linux). Wouldn't unifying the logic behind these conventions for both of these platforms maybe simplify existing complexity? These are completely separate implementations, so no, there wouldn't be any simplification. The Omnibox work on OSX is not nearly as complete as Linux or Windows. I am not sure they've yet had the discussion about how this should 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] Re: Omnibox highlighting and PRIMARY selection concerns
On Fri, Aug 21, 2009 at 4:01 PM, Stuart Morgan stuartmor...@chromium.org wrote: On Fri, Aug 21, 2009 at 3:36 PM, Dean McNameede...@chromium.org wrote: Note: Firefox on OSX selects all on single click. So there isn't a clear answer on OSX either. Firefox has historically tended to favor do what Firefox does on other platforms over follow the platform standard. In other cases, it does the wrong thing on the Mac simply because the behavior was written on Windows as cross-platform code and nobody has gotten around to fixing it for the Mac yet--text editing in particular has many examples of this. Firefox does it differently should never be an argument that something isn't an established standard on the Mac. My argument was just that I know of only 2 frequently used URL bars in browser. Safari, and Firefox. They differ in their behavior. I don't know how you have an established standard when you only have a few reference points, and one of the major ones doesn't follow it. How/where is it standardized? -Stuart --~--~-~--~~~---~--~~ 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 Linux 64-bit
The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ 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 Linux 64-bit
That is just a utility program, no? On Thu, Aug 20, 2009 at 12:06 PM, Michael Moss mm...@chromium.org wrote: Anybody working on 64-bit breakpad yet? src/breakpad/linux/minidump-2-core.cc:303:2: error: #error This code has not been ported to your platform yet I guess worst case, I can turn this off for official 64-bit builds right now. Michael On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ 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: Omnibox highlighting and PRIMARY selection concerns
This thread is massive. Having been the one who wrote the majority of the Omnibox code on Linux, I can promise you that this debate has already happened about 15 times previously. I'm not sure there is any more information here, we've already decided how we want things to work. On Thu, Aug 20, 2009 at 4:11 PM, Amanda Walker ama...@chromium.org wrote: Oops, didn't see how long the thread was :-). On Thu, Aug 20, 2009 at 7:10 PM, Amanda Walkerama...@chromium.org wrote: Safari does not. Single click sets the text caret where you click. On Thu, Aug 20, 2009 at 4:56 PM, Peter Kastingpkast...@chromium.org wrote: On Thu, Aug 20, 2009 at 1:36 PM, Adam Barth aba...@chromium.org wrote: On Thu, Aug 20, 2009 at 12:07 PM, JT Oldsjto...@xnet5.com wrote: 1) on a single click to the omnibox, the cursor should be placed. The contents of the omnibox should not be selected. We violate this convention on Windows too. Yep, and so does every other browser in the universe. There's a convention that a single click in a browser's address bar selects all, so to speak. PK -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) -- Portability is generally the result of advance planning rather than trench warfare involving #ifdef -- Henry Spencer (1992) --~--~-~--~~~---~--~~ 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: FreeBSD port and ifdefs
we could go with like _nix or something, and consider OSX to not be unix (which is kinda isn't). Really, in theory, we should have more granular ifdefs ./configure style, but that is also really a pain in my opinion. On Wed, Aug 19, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Wed, Aug 19, 2009 at 11:43 AM, Ben Laurieb...@chromium.org wrote: #if defined(OS_LINUX) || defined(OS_FREEBSD) and this is ugly. It doesn't deeply worry me, except when NetBSD, OpenBSD come along. Could you use OS_BSD instead? I know that some may assume that OS X would be included, but I don't have a better name. 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: FreeBSD port and ifdefs
I kinda feel like this is one of those things you can try hard to premeditate, but in the end you'll just have to deal with it being ugly for a while and hope it eventually converges to something better. Sort of a non-answer, but I'd be happy to see this running on a BSD first, and then we can argue about the patch. I just went through some work trying to build it on OpenBSD (promised a friend I'd try). There are a lot of little things we need to do before we even have this debated. Pretty much everything in third_party (icu, libevent), gmock, etc. Some of these will probably require changes upstream. On Wed, Aug 19, 2009 at 1:53 PM, Amanda Walker ama...@chromium.org wrote: On Wed, Aug 19, 2009 at 4:14 PM, Evan Martine...@chromium.org wrote: It seems the configurations we'll see most frequently in code are: 1) POSIX (basically, non-Windows -- we have this already) 2) POSIX minus Mac (since Mac has the most extensions, especially at the GUI layer) 3) POSIX minus Linux (aka everything BSD-derived, more or less) Dean proposes a define for #2, agl proposes a define for #3. I think it'd be nice to keep the defines down if possible. I strongly dislike a #define for #2. I think that having defines for particular combinations of platforms is the wrong way to denote the absence or presence of a particular API or feature. Rather, I would prefer to leave the platform flags as general as possible, and then have features for particular differences within a major platform (this also parallels how webkit's feature controls work, how we're denoting usage of GTK, etc.). So, for example, MacOS X might be OS_POSIX and USES_MACH_THREADS or something. OS_POSIX_BUT_NOT_MAC seems like the wrong direction. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Halting JS execution in V8?
Mads is working on something for this. On Wed, Aug 12, 2009 at 12:58 PM, Drew Wilsonatwil...@chromium.org wrote: Hi all, It appears from looking at the worker code that if worker script enters into an infinite loop, the associated worker thread/process will never exit. The JavaScriptCore implementation uses the JSC timeoutChecker mechanism to halt script execution. Is there an analog we can use for V8? I didn't see anything that looked particularly likely from a quick browse through the v8 headers, and I also didn't see anything similar for page script in V8Proxy.cpp, so I'm obviously missing something since page script handles infinite loops gracefully. -atw --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Allocator Choice
Do we have numbers on how the 4 allocates compare on those tests (page cycler, etc)? On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: In an effort to make it easier to test debugging heaps and allocators, I just landed a changelist which makes our allocators switchable at runtime. Unlike Obama's plan for healthcare, this CL is about giving you more choice. From an environment variable, you can now switch between 4 different allocators. set CHROME_ALLOCATOR=tcmalloc // default - use TC Malloc set CHROME_ALLOCATOR=jemalloc // use JEMalloc, the allocator also used in firefox set CHROME_ALLOCATOR=winheap // use the built in windows heap set CHROME_ALLOCATOR=winlfh // use the low-fragmentation windows heap This change also contains a fix to tcmalloc to more aggressively return pages (in other words, actually return them sometimes). Without this fix, Chrome grows but doesn't shrink. As a result, this change *DOES* have a negative performance impact on chrome (we're now returning pages fairly aggressively) Good news: - Our memory test shows a 4% drop (not terribly significant) http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150graph=commit_charge Neutral news: - The Moz page cycler shows no change: http://build.chromium.org/buildbot/perf/vista-release-dual-core/moz/report.html?history=150 Bad news - The JS page cycler shows a 3% drop. http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 I'm working on this. Let me know if you have problems or feedback. Also, if you do play around with the allocator choices, let me know your experience. Mike --~--~-~--~~~---~--~~ 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: new hunspell has tons of valgrind warnings... revert?
I've never seen valgrind have problems with memory mapped files. On Mon, Aug 3, 2009 at 1:14 AM, Brett Wilsonbre...@chromium.org wrote: On Sat, Aug 1, 2009 at 4:34 PM, Dan Kegeld...@kegel.com wrote: I suppose you could try running the hunspell test suite itself under valgrind. Their README tells how to do it, but when I tried, I couldn't get it to work. (Wonder if that means they haven't run it, either?) Hi Dan, Purify has some problems with tracking memory that the OS memory maps, and it ends up giving uninitialized memory reads for any 0xCCs that the OS memory maps (since it doesn't see the write). Does Valgrind have a similar problem? Most of the data is memory mapped. It seems unlikely to me given we didn't have this problem before, but it's worth checking. My main concern is: who is working on this? It's OK like this for a couple of days I guess, but this seems like a potentially serious problem we don't want to file a bug and get to it later. It also seems like Mohammed will need help, and I'll be out part of next week (still figuring out the days). If we can't fond somebody to look at this soon, we should probably back out until there is somebody. Brett --~--~-~--~~~---~--~~ 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: FYI: Upcoming O3D integration changes.
Any idea on how much this increase the size of chrome.dll? On Wed, Jul 22, 2009 at 9:51 PM, Nicolas Sylvainnsylv...@chromium.org wrote: On Wed, Jul 22, 2009 at 11:47 AM, Greg Spencer gspen...@google.com wrote: On Wed, Jul 22, 2009 at 11:27 AM, Nicolas Sylvain nsylv...@chromium.org wrote: src/third_party/nixysa/files: why in a subdir called files? A leftover from converting from p4/scons -- I'll remove it. # NACL has to be in this weird directory because it looks for # googleclient two levels above it. src/third_party/native_client/googleclient/native_client: Looks like they should change their code to make it work without assuming all these directories. and this code is already fetched in src/native_client, we don't want it twice. Yes, that just happened recently -- I'll try to switch to using their new GYP build. For those who are curious : $ du -h --max-depth=1 . 4.1M ./gflags 34M ./native_client 1.3M ./nixysa 251K ./npapi 2.1M ./ply-3.1 24M ./vectormath 64M . And the additional native_client will disappear, so more like 30M. (and these numbers include all the .svn dirs, so the real code is half that). The docs in the vectormath library are 17M, so we could probably delete those from the repo if size is an issue, and make it 13M total. That would be great! Thanks Nicolas -Greg. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Proposal for adding ChangeLog files to Chromium
-100 million to changelogs. On Wed, Jul 22, 2009 at 8:28 AM, Anthony LaForgelafo...@google.com wrote: It also strikes me that we'd have have trouble filtering out reverts using the RELEASE_NOTE tag. Since the original change with the RELEASE_NOTE tag and the reverted change would be in different revisions I'm not sure a simple grep would suffice. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge lafo...@google.com wrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForgelafo...@google.com wrote: In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ 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: Mozilla design challenge
I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in the Browser challenge have been announced. Collapsible Tab Groups includes among others some things I've proposed, including grouping and collapsing groups. Favitabs reminds me of some old brainstorming ideas from pamg about converting certain tabs into favicon buttons. Folks considering the future of tabs (e.g. Ben, Glen, Scott) might do well to take a look at some of these. 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: FYI canvas is hosed
If anyone out there from Mozilla is reading, or someone knows where to redirect this bug, that would be really helpful: https://bugzilla.mozilla.org/show_bug.cgi?id=504301 Thanks On Tue, Jul 14, 2009 at 8:23 PM, Dean McNameede...@chromium.org wrote: My point was the behavior before the patch was wrong. What they did now is closer, but still wrong. On Tue, Jul 14, 2009 at 8:22 PM, Peter Kastingpkast...@chromium.org wrote: On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote: We weren't spec compliant: http://dev.w3.org/html5/spec/Overview.html The lineTo(x, y) method must do nothing if the context has no subpaths. Isn't that what I just said? That the current behavior doesn't match the spec? I still don't understand what's going on or what chromium-dev should do about it. 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] FYI canvas is hosed
https://bugs.webkit.org/show_bug.cgi?id=27187 -- dean --~--~-~--~~~---~--~~ 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: FYI canvas is hosed
We weren't spec compliant: http://dev.w3.org/html5/spec/Overview.html The lineTo(x, y) method must do nothing if the context has no subpaths. On Tue, Jul 14, 2009 at 8:13 PM, Peter Kastingpkast...@chromium.org wrote: On Tue, Jul 14, 2009 at 3:11 AM, Dean McNamee de...@chromium.org wrote: https://bugs.webkit.org/show_bug.cgi?id=27187 Maybe the spec needs to change? It seems like the patch moved away from spec-compliant behavior to match Gecko. I'm not sure what chromium-dev can do for you on this issue. Is there some way we can help? 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: FYI canvas is hosed
My point was the behavior before the patch was wrong. What they did now is closer, but still wrong. On Tue, Jul 14, 2009 at 8:22 PM, Peter Kastingpkast...@chromium.org wrote: On Tue, Jul 14, 2009 at 11:15 AM, Dean McNamee de...@chromium.org wrote: We weren't spec compliant: http://dev.w3.org/html5/spec/Overview.html The lineTo(x, y) method must do nothing if the context has no subpaths. Isn't that what I just said? That the current behavior doesn't match the spec? I still don't understand what's going on or what chromium-dev should do about it. 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: Reviewers
I got it. Thanks On Wed, Jul 8, 2009 at 12:49 AM, Thiago Farinathiago.far...@gmail.com wrote: Lei can you review this patch for me? http://codereview.chromium.org/155078 On Jul 6, 11:56 pm, Lei Zhang thes...@chromium.org wrote: You didn't give enough context. It'll be more helpful if you put links to the patches you want reviewed. On Mon, Jul 6, 2009 at 7:47 PM, Thiago Farinathiago.far...@gmail.com wrote: When I don't know who can review some patch for me what I have to do? Currently I have 3 patchs waiting for review, but I haven't received any feedback or contact until now. What I have to do in this cases? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Who wants to fix a build warning?
CXX /.../out/Debug/obj/webkit/glue/temporary_glue.o In file included from ./base/timer.h:49, from ./webkit/glue/resource_fetcher.h:19, from ./webkit/glue/image_resource_fetcher.h:9, from ./webkit/glue/webview_impl.h:16, from webkit/glue/temporary_glue.cc:8: ./base/logging.h:226:1: warning: LOG redefined In file included from third_party/WebKit/JavaScriptCore/wtf/RefCounted.h:24, from third_party/WebKit/WebCore/history/BackForwardList.h:31, from ./webkit/glue/back_forward_list_client_impl.h:8, from ./webkit/glue/webview_impl.h:15, from webkit/glue/temporary_glue.cc:8: third_party/WebKit/JavaScriptCore/wtf/Assertions.h:230:1: warning: this is the location of the previous definition Thanks -- dean --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: what's difference between master.chromium and master.chromium.fyi?
2009/7/6 Rosail Davis sitan2...@sina.com: From the main waterfall, the experimental link takes to you the fyi one. The fyi waterfall lists the bots that we run, but don't close the tree for. The bots on main waterfall are critical bots, the bots on fyi waterfall are not so importan, right? Well, how do you judge whether a bot should be included in main or fyi? Can you give me an example? For example, when we were just starting the Linux port, we wanted to know what the status was, but it was often in a state of being broken, not building, crashing tests, etc. We wanted to know this, but we didn't want normal developers to worry about it, or to close the tree over it. Most of things in FYI eventually make it to the main dashboard after they become stable enough, etc. Some things that are less critical for every change list, like code coverage, will probably never make the main waterfall. --~--~-~--~~~---~--~~ 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: memory leak in the jpeg_codec.cc
I didn't either at first, and then Lei pointed out it's using
set/longjmp. Gnarly.
On Mon, Jul 6, 2009 at 4:26 PM, Evan Martine...@chromium.org wrote:
I don't understand this bug report. Where is the code path that
allocates memory but doesn't free it? You just wrote if error
happens in libjpeg but that is not clear.
On Mon, Jul 6, 2009 at 1:50 AM, runtimerun_t...@tut.by wrote:
I sent a bug report
http://code.google.com/p/chromium/issues/detail?id=15990
I don't know I did it correct or not.
Lei Zhang wrote:
It probably needs to be converted into a scoped_array like in
JPEGCodec::Decode. Can you file a bug for this on http://crbug.com/ ?
On Thu, Jul 2, 2009 at 5:59 AM, runtimerun_t...@tut.by wrote:
Hi
There is memory leak in the module jpeg_codec.cc, member function
bool JPEGCodec::Encode(const unsigned char* input, ColorFormat format,
int w, int h, int row_byte_width,
int quality, std::vectorunsigned char*
output);
code
// output row after converting
unsigned char* row = new unsigned char[w * 3];
while (cinfo.next_scanline cinfo.image_height) {
converter(input[cinfo.next_scanline * row_byte_width], w, row);
jpeg_write_scanlines(cinfo, row, 1);
}
delete[] row;
The allocated in row pointer memory will not be released if error
happens in libjpeg.
--~--~-~--~~~---~--~~
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: Help with logging in Linux.
If it detaches from the terminal this probably means you have another instance of Chromium already running. We check the profile lock on startup, and if there is already a running process holding that lock, we message it to create a new window. This might not be it, but it kinda sounds like it. Otherwise I would debug / strace / etc to figure out what's going on. On Mon, Jul 6, 2009 at 6:43 AM, Anandakmis...@gmail.com wrote: Hi all, I'm working on one of the bugs in chrome and the thing that's halted my progress is that I can't get logging to work on Linux. I build chrome in Debug mode, but when I launch it (with --log-level=0), it spits out a few log message and then detaches from the terminal. I get no further logging despite littering my code with LOG(INFO) messages. I'm not building with any special flags, just 'hammer chrome' and I'm just running with ' --log-level=0' and nothing else. Help! --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
Hey Bradley, Thanks, I can build again from the command line. My CPU utilization is still annoying low. I made sure and NUM_CPUS is 4. Compare this to the Linux make build, which keeps my 4 cores at 100% cpu all the way through. Thanks -- dean On Sun, Jun 28, 2009 at 2:06 AM, Bradley Nelsonbradnel...@google.com wrote: Hi Dean, So I've dropped in a change that switches directories to have name like: (base) (test_shell) This will allow you to run things at the command line again. I don't find this choice particularly ascetic myself. But the options where limited, because the following characters cannot appear in solution folder names: / ? : \ *| # % Let me know if you run into any more problems with this. Also definitely let me know if someone thinks of something less ugly. -BradN On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote: This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd
[chromium-dev] Re: Font handling in chromium
On Tue, Jun 30, 2009 at 10:29 PM, n179911n179...@gmail.com wrote: On Tue, Jun 30, 2009 at 12:31 PM, Adam Langleya...@chromium.org wrote: On Tue, Jun 30, 2009 at 12:29 PM, n179911n179...@gmail.com wrote: How does Chromium handling font loading? Which platform? MacOS X and Linux. I don't know about OSX, for Linux the code is in webkit at: WebKit/WebCore/platform/graphics/chromium/ See the files with font and linux in the name. Thank you. 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: Frustrating problem with Linux Make build
Patches are welcome. It looks like maybe in chrome.gyp, the debugger target should also debug on chrome_strings ? On Wed, Jul 1, 2009 at 12:50 PM, Ben Laurieb...@google.com wrote: On Wed, Jul 1, 2009 at 11:11 AM, Ben Laurieb...@google.com wrote: On Wed, Jul 1, 2009 at 8:22 AM, Ben Goodger (Google)b...@chromium.org wrote: Sounds like a dependency issue. Can you explicitly build the chrome_strings target and then try building the target you were trying to build again? $ make chrome_strings make: *** No rule to make target `chrome_strings'. Stop. BTW, if I try to build the missing file... $ make out/Debug/obj/gen/chrome/grit/generated_resources.h make: *** No rule to make target `out/Debug/obj/gen/chrome/grit/generated_resources.h'. Stop. However: $ make out/Debug/obj/gen/chrome/grit/renderer_resources.h make: Nothing to be done for `out/Debug/obj/gen/chrome/grit/renderer_resources.h'. OK, so this seems like a dependencies issue - and given the logic of the makefiles, AUIU (i.e. hazily), I don't see how this is supposed to work. If I add the line: $(obj)/chrome/browser/debugger/devtools_window.o: $(obj)/gen/chrome/grit/generated_resources.h to chrome/debugger.mk then it all builds fine. According to my reading of the makefiles, there's nothing to ensure this happens on a clean build because: a) There are not yet any dependency files, and b) Dependency files are not read for targets that will be built anyway (according to the comments) What I now don't understand is why it works for anyone? Also, it seems to me that b) is a bad idea because files like generated_resources.h, even if they do get rebuilt, might get rebuilt at the wrong moment (i.e. too late for their dependencies). Or perhaps I totally don't understand what's going on? Oh, actually, I think I just nailed it. If I do: $ make chrome it fails. If I do: $ make -j30 chrome it works. So, I think my conclusion about dependencies is correct. With -j30 it just happens that the dependency gets built in time, without, it doesn't. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Frustrating problem with Linux Make build
On Wed, Jul 1, 2009 at 2:21 PM, Dean McNameede...@chromium.org wrote: Patches are welcome. It looks like maybe in chrome.gyp, the debugger target should also debug on chrome_strings ? Er, it should also _depend_ on. Anyway, the Makefiles are generated from the gyp files. There could be a bug in the makefile generator, but it is more likely the problem is the dependency isn't correct in the gyp file. I don't know enough about the debugger to tell you what it should depend on. From the sound of the original message chrome_strings might need to be added. The difference between chrome_resources and chrome_strings is not super clear to me, but I imagine the first is images, etc, and the second is localized strings. -- dean On Wed, Jul 1, 2009 at 12:50 PM, Ben Laurieb...@google.com wrote: On Wed, Jul 1, 2009 at 11:11 AM, Ben Laurieb...@google.com wrote: On Wed, Jul 1, 2009 at 8:22 AM, Ben Goodger (Google)b...@chromium.org wrote: Sounds like a dependency issue. Can you explicitly build the chrome_strings target and then try building the target you were trying to build again? $ make chrome_strings make: *** No rule to make target `chrome_strings'. Stop. BTW, if I try to build the missing file... $ make out/Debug/obj/gen/chrome/grit/generated_resources.h make: *** No rule to make target `out/Debug/obj/gen/chrome/grit/generated_resources.h'. Stop. However: $ make out/Debug/obj/gen/chrome/grit/renderer_resources.h make: Nothing to be done for `out/Debug/obj/gen/chrome/grit/renderer_resources.h'. OK, so this seems like a dependencies issue - and given the logic of the makefiles, AUIU (i.e. hazily), I don't see how this is supposed to work. If I add the line: $(obj)/chrome/browser/debugger/devtools_window.o: $(obj)/gen/chrome/grit/generated_resources.h to chrome/debugger.mk then it all builds fine. According to my reading of the makefiles, there's nothing to ensure this happens on a clean build because: a) There are not yet any dependency files, and b) Dependency files are not read for targets that will be built anyway (according to the comments) What I now don't understand is why it works for anyone? Also, it seems to me that b) is a bad idea because files like generated_resources.h, even if they do get rebuilt, might get rebuilt at the wrong moment (i.e. too late for their dependencies). Or perhaps I totally don't understand what's going on? Oh, actually, I think I just nailed it. If I do: $ make chrome it fails. If I do: $ make -j30 chrome it works. So, I think my conclusion about dependencies is correct. With -j30 it just happens that the dependency gets built in time, without, it doesn't. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: VectorCanvas usage
I believe it's used for printing on Windows. The idea is to capture the API call so the vector info can be turned into a WMF or GDI-style command buffer or whatever for printing on Windows. If you need the details Marc-Antoine would know. On Wed, Jul 1, 2009 at 1:34 PM, mailandroidmailandr...@gmail.com wrote: Hi, The VectorCanvas is inherited from PlatformCanvasWin and overrides many functions. Could anyone explain me what is VectorCanvas and why it is used in Chrome? regards --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How do I deploy an NPAPI plugin over the internet from HTML ?
On Fri, Jun 26, 2009 at 11:24 AM, Non-Stickkevin.ra...@ntlworld.com wrote: OK. Thanks for the information. Before I proceed to build an independent installer, please can you advise whether or not there are any plans for Chrome to provide such a mechanism for automatic NPAPI Plugin downloads at some point in the future ? No, I don't think so. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: question about helpwanted items (how it works)
Yeah, this is great, thanks. On Fri, Jun 26, 2009 at 5:28 PM, Evan Martine...@chromium.org wrote: Thanks for writing this! I would personally use this feature frequently. The code looks good too. On Fri, Jun 26, 2009 at 4:35 AM, nakroyoav.zilberb...@gmail.com wrote: http://codereview.chromium.org/147202 (i didn't know how to use gcl properly, so i re-submitted and deleted the prev issue, prev was only up for a very short while) --~--~-~--~~~---~--~~ 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 buildbots, which locale?
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio I just committed a change that converted our sys_string_conversion_linux from using ICU UTF-8 (assuming that the system locale was always UTF-8) to calling the system APIs that will vary depending on the locale. I believe this is technically what we want, we want these APIs to do the conversion to whatever locale your system is set to. On my machine these all pass fine. I don't know what locale we have set on the buildbots, but it all seems to fail. It is also kind of curious that some of our net/file tests depend on locale, but I suppose that makes sense. For now I'll pull out my changes until we can get the buildbots on a utf-8 locale (like en_US.UTF-8). -- dean --~--~-~--~~~---~--~~ 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 buildbots, which locale?
I just took a look at what was happening on one of the Linux buildbots. It looks like we completely clear the env and just explicitly set a few things. We need to add LANG=en_US.UTF-8 to that list of things. Any takers? Thanks On Thu, Jun 25, 2009 at 2:12 PM, Dean McNameede...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio I just committed a change that converted our sys_string_conversion_linux from using ICU UTF-8 (assuming that the system locale was always UTF-8) to calling the system APIs that will vary depending on the locale. I believe this is technically what we want, we want these APIs to do the conversion to whatever locale your system is set to. On my machine these all pass fine. I don't know what locale we have set on the buildbots, but it all seems to fail. It is also kind of curious that some of our net/file tests depend on locale, but I suppose that makes sense. For now I'll pull out my changes until we can get the buildbots on a utf-8 locale (like en_US.UTF-8). -- dean --~--~-~--~~~---~--~~ 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: Memory usage in chrome
Have you tried running with --memory-model=high ? 2009/6/23 PhistucK phist...@gmail.com: This explanation actually shows me the source of this serious jank (I hope I am using the term in the right context) I am having all of the time. I am getting back to Chrome after a few minutes of dealing with some other application and I have to wait, sometimes even for twenty seconds or more, until I get the control back on the tab contents. Sometimes I am not using a tab for a few minutes (or more) and when I switch back to it, it takes it twenty seconds or more until I get the control back of the tab contents. :( ☆PhistucK On Mon, Jun 22, 2009 at 19:57, Mike Belshe mbel...@google.com wrote: On Mon, Jun 22, 2009 at 9:29 AM, Mike Beltzner beltz...@mozilla.com wrote: On 21-Jun-09, at 10:22 AM, Mike Belshe wrote: Second, the author is basically right. Since he's running on Vista, its a bit hard to tell whether his stats included shared memory or not; using the default memory statistic (Memory (Private Working Set)) is actually a pretty good measure to just sum. But he doesn't say which measurement he used. Doesn't Private Bytes accurately represent the private memory for a given process? I thought the whole point of that was that it didn't measure any shared memory pools. Yes, that accurately represents the private memory for a process, but it doesn't reflect the user's experience. Windows generally tracks working set. Why? Because the working set is the amount of memory *not available to other apps*. If other apps can have the memory, then using the bytes is inconsequential. For most applications, there isn't much difference between private bytes and working set private bytes. However, because of Chrome's multi-proc architecture, there is a big difference. The reason is because Chrome intentionally gives memory back to the OS. For instance, on my current instance of Chrome, I'm using 16 tabs. The sum of the private bytes is 514408. The sum of the private working set bytes is 275040, nearly half of the private bytes number. This is on a machine with 8GB of RAM, so there is plenty of memory to go around. But if some other app wants the memory, Chrome gave it back to the OS and will suffer the page faults to get it back. Since Chrome has given it back to the OS (and has volunteered to take the performance consequences of getting it back), I don't think it should be counted as Chrome usage. Others may disagree. But Windows uses working set as the primary metric for all applications the OS folks agree that working set is the right way to account for memory usage. Single process browsers have a hard time giving memory back, because they can't differentiate which pages are accounted to unused, background tabs and which pages are accounted to the active, in-use tabs. Finally, the common metric which definitely doesn't work well is Windows XP's default metric: working set (private + shared). Because of shared memory between processes, simply summing the working set will far overstate the actual RAM used. Part of the motivation with Vista changing the default metric from working set to private working set was precisely to deal with the issue of better accounting of shared memory. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Pixel layout tests and checksums
Last week I updated our DEPS to pull in a newer version of Skia. I was stumped at a few cases where the checked in PNG looked completely wrong, but yet it was passing on the buildbots. There was no way that image could have been the output. It just dawned on me today, but I haven't verified it. I can dig up my commit to verify it, but I'd say 99% sure this was the case. If the checksum is valid, we don't even go to the PNG. Therefor I believe we have a bunch of layout tests where the checked in PNG is completely wrong, but the checksum is right. I don't have the time right now, but it would be great if someone could write a script and clean this up. Thanks -- dean --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the dependencies are built anymore. For instance, theme_dll isn't built (not listed in the proj deps), is this expected? On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote: Okay, it looks like this change is sticking, at least until someone discovers Yet Another Unintended Side Effect. So heed the warnings in the previous message, quoted below. Git users on Linux: this requires an update to gyp to work properly, so make sure you gclient sync after you git pull, or whatever the right combination of commands is. If you see Python stack traces from gyp accompanied by complaints about looking up a Dir as a File, make sure the tools/gyp subdirectory is at r521. --SK On Wed, Jun 17, 2009 at 9:25 PM, Steven Knight s...@chromium.org
[chromium-dev] Re: changing chrome_exe to chrome, converting chrome.exe to gyp
Additionally it seems like I'm getting no parallelism. I checked my visual studio settings and everything seems fine. Attached is a screenshot of how my CPU usage has looked for the entire processing of building test_shell (from chrome.sln). -- dean On Fri, Jun 19, 2009 at 12:10 PM, Dean McNameede...@chromium.org wrote: This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote: Yeah it happened to me before as well, I just figured I'd complain now.. Note another missing dependency is on crash_service.exe , npapi_layout_test_plugin, and npapi_test_plugin btw just to be clear, these are missing dependencies on ui_tests. On Thu, Jun 18, 2009 at 3:00 PM, Jeremy Orlow jor...@google.com wrote: I actually had this problem _before_ this change. Guess I should have brought it up, but I figured it was just something funny on my system. On Thu, Jun 18, 2009 at 2:21 PM, John Abd-El-Malek j...@chromium.org wrote: +1 this is affecting a lot of people. On Thu, Jun 18, 2009 at 12:43 PM, Daniel Cowx daniel.c...@gmail.com wrote: I notice that when I load chrome.sln and do a build, not all the dependencies are built anymore. For instance, theme_dll isn't built (not listed in the proj deps), is this expected? On Jun 18, 12:38 am, Steven Knight s...@chromium.org wrote: Okay, it looks like this change is sticking, at least until someone discovers Yet Another Unintended Side Effect. So heed the warnings in the previous message, quoted below. Git users on Linux: this requires an update to gyp to work properly, so make sure
[chromium-dev] Re: skia backend support
Skia is already enabled in Chrome. We are not using the GL backend (it's not really finished). Thanks -- dean On Wed, Jun 17, 2009 at 1:43 PM, mailandroid wrote: I was looking at the support of skia backend for rendering (OpenGL/ OpenVG). How and where can we enable these backend in skia for chrome? Please provide me the details. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: some trival details
You could answer a lot of these questions yourself, with a little bit of digging or a Google search. I'll try to give you a boost though. 2009/6/15 sitan2...@sina.com: I began to read chromium's source codes, and got caught in these trival questions: 1. what's gfx? I always see that. gfx:: is a namespace where lots of our graphics related code lives. See base/gfx and app/gfx. 2. what's the usage of .gyp files? Something like cmake, a meta-language to declare our build configuration, and then generate Visual Studio, Scons, Makefiles, XCode projects. This happens transparently by gclient, or manually by gclient runhooks --force. http://code.google.com/p/gyp/ 3.Is gmock used to help automation test? What else does chrome use for automation test? I'm curious about that. gmock was just recently introduced. I'm not sure if or where we are using it. 4.gcapi confused me, what is it? 5.mini_installer.exe and setup.exe? I can't execute them. What're they used for? Search the lists for discussions on this. I don't know much about how our installer works, but these are part of it. 6.what is courgette? and used for? Helping to make the downloads of incremental updates smaller. http://neugierig.org/software/chromium/notes/2009/05/courgette.html --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Makefile build broken
At least for me, I'm hitting an error with generate_stubs.py. Will
try to figure out the proper fix, in the mean time I fixed up the
paths manually and ran the following from my source root. I was able
to successfully build. This is for a debug build, replace Debug w/
Release for a release build.
python third_party/ffmpeg/generate_stubs.py -i out/Debug/obj/gen -o
out/Debug/obj/gen/ffmpeg/third_party/ffmpeg -t posix_stubs -e
third_party/ffmpeg/ffmpeg_stub_headers.fragment -s ffmpeg_stubs -p
third_party/ffmpeg
third_party/ffmpeg/{avcodec-52.sigs,avformat-52.sigs,avutil-50.sigs}
-- dean
--~--~-~--~~~---~--~~
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: Naming things _views
Does this mean we can do something similar for GTK? It feels a bit unfair that we have to name everything browser/gtk/blah_gtk.cc and BrowserToolbarGtk, etc, while views gets the short name. For example views: views/info_bubble.cc and class name InfoBubble gtk: gtk/info_bubble_gtk.cc and class name InfoBubbleGtk On Thu, Jun 11, 2009 at 7:45 AM, Ben Goodger (Google)b...@chromium.org wrote: If you're porting a file in the browser/ directory and going to be renaming a file foo _views.cc/h, consider just moving the file into browser/views and not renaming it. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: No symbols for Google Chrome 2.0.172.30
Hey Nicolas,
Did these symbols ever get uploaded?
Thanks
On Sun, Jun 7, 2009 at 2:55 AM, yuhongyuhongbao_...@hotmail.com wrote:
SYMSRV:
http://build.chromium.org/buildbot/symsrv/chrome_exe.pdb/0C57BF1B1D3D48
49B3037D4FE9424CCC2/chrome_exe.pdb not found
DBGHELP: chrome - no symbols loaded
[SYMCHK] MODULE64 Info --
[SYMCHK] Struct size: 1672 bytes
[SYMCHK] Base: 0x0040
[SYMCHK] Image size: 782336 bytes
[SYMCHK] Date: 0x4a128615
[SYMCHK] Checksum: 0x000c0d3d
[SYMCHK] NumSyms: 0
[SYMCHK] SymType: SymNone
[SYMCHK] ModName: chrome
[SYMCHK] ImageName: C:\Users\bob\AppData\Local\Google\Chrome
\Application\chrome.
exe
[SYMCHK] LoadedImage: C:\Users\bob\AppData\Local\Google\Chrome
\Application\chrom
e.exe
[SYMCHK] PDB:
[SYMCHK] CV: RSDS
[SYMCHK] CV DWORD: 0x53445352
[SYMCHK] CV Data: C:\b\slave\chrome-official-2\build\src\chrome
\Release\chrome_
exe.pdb
[SYMCHK] PDB Sig: 0
[SYMCHK] PDB7 Sig: {----}
[SYMCHK] Age: 0
[SYMCHK] PDB Matched: TRUE
[SYMCHK] DBG Matched: TRUE
[SYMCHK] Line nubmers: FALSE
[SYMCHK] Global syms: FALSE
[SYMCHK] Type Info:FALSE
[SYMCHK]
SymbolCheckVersion 0x0002
Result 0x00010001
DbgFilename chrome.dbg
DbgTimeDateStamp0x
DbgSizeOfImage 0x
DbgChecksum 0x
PdbFilename C:\b\slave\chrome-official-2\build\src\chrome
\Release\chrome
_exe.pdb
PdbSignature{0C57BF1B-1D3D-4849-B303-7D4FE9424CCC}
PdbDbiAge 0x0002
--~--~-~--~~~---~--~~
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: Zygote mode on by default in Linux now. Here's how to disable it...
Yeah, I just took a poke at this, it seems that zygote \ browser \ renderer \ renderer ... Is there a design document or anything somewhere? Also, did we get an measurements on tab startup performance, memory sharing, etc? On Tue, Jun 9, 2009 at 10:57 AM, Lei Zhangthes...@chromium.org wrote: Does this mean the zygote manager process is the parent process for the browser process and all renderer processes? Whereas before the browser process was the parent to all renderer processes. On Mon, Jun 8, 2009 at 5:39 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: http://src.chromium.org/viewvc/chrome?view=revrevision=17909 enabled zygote mode on Linux by default. This changes how processes work on Linux; the initial process becomes a fork server, and holds open file descriptors for the .pak files. This lets us continue running even if the app is updated or uninstalled while we're running. The next time you restart, the new files will take effect. If for some reason (say, you don't like the fact that the main process is now this funky fork server) you want to go back to how things were before temporarily, you can disable zygote mode by doing export DISABLE_ZYGOTE_MANAGER=x before running. The valgrind ui_test bots are currently greener than they should be, possibly because zygote mode is interfering with how I set ui_test mode up under valgrind. I'll have a look at that tomorrow. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Zygotes [was Re: [chromium-dev] Re: Avoiding crash after autoupdate on Linux]
On Tue, May 26, 2009 at 10:54 PM, Evan Martine...@chromium.org wrote: On Tue, May 26, 2009 at 1:06 PM, Adam Langley a...@chromium.org wrote: But we've gone over this before? Zygotes disable ASLR, make debugging harder etc. They might have some performance benefits, but I don't believe that they're the correct solution for the auto update issue. I suggested Dan bring this up on chromium-dev so we could hash it out publicly. :) (For context for the rest of the list: the question is whether we re-fork a preforked zygote renderer subprocess or do a new fork/exec of our binary when we want a new renderer process.) Here's a list of the issues I've heard about. ASLR: you say it disables ASLR, but it seems you get whatever randomized address space the initial zygote got. Net effect is that within a given browser instance each renderer will have the same layout. How bad is that? (Honest question, not suggesting it isn't bad.) There are two things that seemed medium bad to me about zygotes and ASLR. - The renderers always have the same layout, meaning if you could find some bug that allowed you to spawn a new tab/process, attack it, and let it crash, you could brute force addresses until you hit it. Although, I suppose the probability is similar either way. - The browser and renderers share the same layout. If you can find a pointer leak / bug in the renderer, you then know the address layout to try and attack the browser process. Debugging: you say it's harder, but I'm not sure why. Because of the renderer-cmd-prefix stuff? But gdb is just as capable of attaching to a pid -- rather than --renderer-cmd-prefix='xterm -e gdb' we could just as well do --renderer-cmd-pid-prefix='xterm -e gdb -p'. On the pro-zygote side, issues we have: Updates clobbering our files. If we open everything before we fork we're good. (I'm not confident that we can open everything we want before we fork -- the inspector is a collection of random files scattered in /usr/share. But the inspector problem applies to any solution I've yet seen and we ought to be able to pack it into one mmappable file if we want.) Sharing: with zygotes, each instance of webkit shares memory pages, even the ones we tweak after renderer startup but before we fork. Performance: may be faster to start renderers if we've preforked. Sharing/performance of course don't count as benefits until we have numbers to support them. Dan did preliminary measurements and found no perf win, but I don't know if we have tests that measure the performance of starting many tabs. However, we could easily make a hardlink with a specific version in the name. That could go wrong if packaging systems write the same inode when updating rather than creating a new one, but I suspect that they don't. A patch to use the zygote hammer for the auto-updating issue would first have to show that there's no easier alternatives! I don't have a strong opinion on what we should do here beyond right now we're broken and we should fix that. We can imagine many solutions but each time there's a bit of hand-waving. Perhaps you could make a concrete counterproposal? (Again, I don't mean that to sound as hostile as it might seem -- I honestly think it'd be good to be able to weigh pros/cons of approaches.) --~--~-~--~~~---~--~~ 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] nested messageloop patch landed
I'm really curious of why that would be. I realize the old code was a bit buggy, but I wonder exactly where the startup improvement came in. I think it would be pretty important to understand... Any takers? On Thu, Jun 4, 2009 at 1:34 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Wed, Jun 3, 2009 at 3:25 PM, Lei Zhang thes...@chromium.org wrote: Aren't the bots in virtual machines? Since we're in the middle of some hardware upgrades, perhaps the new host machine isn't as loaded. Would that affect the performance numbers? The first time the blue line dropped it was a real improvement. The second drop, where both the yellow and the blue line dropped, was because we moved to the new (and better) machine. Nicolas I still remember the numbers from my box from the last time I made the numbers go the other way. It was in the 300-350 ms range. I ran the test again just now and it's down to ~200 ms. On Wed, Jun 3, 2009 at 3:25 PM, Lei Zhang thes...@google.com wrote: Aren't the bots in virtual machines? Since we're in the middle of some hardware upgrades, perhaps the new host machine isn't as loaded. Would that affect the performance numbers? I still remember the numbers from my box from the last time I made the numbers go the other way. It was in the 300-350 ms range. I ran the test again just now and it's down to ~200 ms. On Wed, Jun 3, 2009 at 2:56 PM, Evan Martin e...@chromium.org wrote: This patch, aside from fixing Antoine's problem and those other two bugs, seems to have significantly improved our startup time: http://build.chromium.org/buildbot/perf/linux-release/startup/report.html?history=150 (The second drop is due to running on new hardware.) I kinda suspect we're measuring something wrong, because we're down to 65ms (!). On Mon, Jun 1, 2009 at 3:04 PM, Evan Martin e...@chromium.org wrote: Antoine wrote a patch to make nested message loops work on Linux. http://codereview.chromium.org/115812 It's always a bit scary touching the message loop code, but this will fix two real issues we know about: - file save dialogs crash on some subset of platforms - copy and paste crashers My plan: I am going to land this patch, see if it does anything horrible in the next few days or two. So if you suddenly start getting new crashers, let me know. We can always back it out. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: Chromium code coverage dashboard is up
Seems there are some bugs relating to which files count. For example: http://build.chromium.org/buildbot/coverage/linux-debug/17471/CHROMIUM/base/index.html It counts files like wmi_util, which is Windows specific and not compiled on Linux. On Wed, Jun 3, 2009 at 9:12 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Looks cool! I wonder... what does instrumented, but not executed (yellow) mean? On Wed, Jun 3, 2009 at 18:31, Randall Spangler rspang...@google.com wrote: The Chromium code coverage dashboard is now live! View it here: http://build.chromium.org/buildbot/coverage/ ...or click on the 'coverage' link at the top of the main http://build.chromium.org waterfall, right next to the 'perf' link. This dashboard reports code coverage statistics on Chromium on each platform - that is, which lines of code are executed by unit tests. It's one measure of how comprehensive the tests are, and helps identify tests which aren't running and source code which has excaped testing. The top-level dashboard reports the following: Percent coverage for source code (excluding tests) - that is, what we want to test. Percent coverage for the tests themselves. The low numbers here indicate that not all the tests are currently running under coverage. This should approach 100%. If you click through on a graph, you get a full-page view of the graph where you can click on an individual data point to get more details on that build. CL = details on the changelists for that build (you're seen this before on other perf graphs..) Coverage = detailed coverage data on all subdirectories and files, down to line-by-line coverage (this is new!) Coverage runs nightly on linux and mac platforms and currently covers only the base/net/media/printing submodules. The builds are on the right side of the experimental dashboard (http://build.chromium.org/buildbot/waterfall.fyi) Coming soon: windows platform, test_shell, more submodules, etc. (Thanks to jrg for getting unit tests running under coverage, and nsylvain for helping me with buildbot.) - Randall rspang...@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: Where is the integration point betwee chromium and V8
My spidey sense would guess that you set the breakpoint in the Browser
process, when V8 and WebKit run in the Renderer process.
Good luck
-- dean
2009/5/29 Lucius Fox lucius.fo...@gmail.com:
Thank you.
I tried your suggestion on XCode on MacOS. But it still does not break for me.
I set a break point at:
LocalScript Script::Compile(v8::HandleString source,
v8::ScriptOrigin* origin,
v8::ScriptData* script_data) {
ON_BAILOUT(v8::Script::Compile(), return LocalScript());
LOG_API(Script::Compile);
ENTER_V8;
i::Handlei::String str = Utils::OpenHandle(*source);
i::Handlei::Object name_obj;
int line_offset = 0;
int column_offset = 0;
/* Set my break point in the line below */
if (origin != NULL) {
Here is how I set my breakpoint:
1. I open the build/all.xcodeproj
2. click open the test_shell.xcodeproj
3. click open the v8.xcodeproject
4. open api.cc
5. set breakpoint in the location I mentioned above
6. go to test_shell.xcodeproj and click 'Build and Go(Debug)'
7. load an url, (e.g. www.yahoo.com)
The site gets loaded, but the break point never breaks.
I appreciate if anyone can help me with this.
Thank you.
2009/5/27 Søren Gjesse sgje...@chromium.org:
Hi,
There must be something wrong with your setting of break points. There is
only on way of getting JavaScript code into V8 from a client application,
and that is through the static method v8::Script::Compile in the public API.
This method is defined in api.cc where it in turn calls
v8::internal:Compiler::Complie defined in compiler.cc. All the adding of
code to V8 from Chromium is handled in v8_proxy.cpp.
Code added from within JavaScript through the use of eval will be handled by
v8::internal:Compiler::ComplieEval.
Note that if you are using Chromium for this you need to take the
multiprocess architecture into account either by using the --single-process
switch to turn it off or by attaching to the process you will actually like
to debug.
Regards,
Søren
On Thu, May 28, 2009 at 07:52, Lucius Fox lucius.fo...@gmail.com wrote:
Hi,
i am trying to understand how chromium passes JS script node/JS file
to v8 engine for execution.
So i setup breakpoints in Xcode with test)shell xcode project opened:
Compiler::Compile
Compiler::CompileEval
Compiler::CompileLazy
And then I 'build and go (debug)' to get a TestShell. It did start up
the TestShell, and it did break in the initial breakpoint I setup in
test_shell_main.cc. But when I load a page with Javascript for sure,
e.g. www.cnn.con, it never breaks in the Compiler functions that I
mentioned above.
Can you please tell me how does chromium passes JS script node/JS file
to v8 engine for execution
--~--~-~--~~~---~--~~
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: Where is the integration point betwee chromium and V8
I just re-read your post and realized you were using test_shell, which
is single process. In that case, I am not sure what the problem is,
and have no experience with xcode.
Sorry, good luck
On Fri, May 29, 2009 at 11:06 AM, Dean McNameede...@chromium.org wrote:
My spidey sense would guess that you set the breakpoint in the Browser
process, when V8 and WebKit run in the Renderer process.
Good luck
-- dean
2009/5/29 Lucius Fox lucius.fo...@gmail.com:
Thank you.
I tried your suggestion on XCode on MacOS. But it still does not break for
me.
I set a break point at:
LocalScript Script::Compile(v8::HandleString source,
v8::ScriptOrigin* origin,
v8::ScriptData* script_data) {
ON_BAILOUT(v8::Script::Compile(), return LocalScript());
LOG_API(Script::Compile);
ENTER_V8;
i::Handlei::String str = Utils::OpenHandle(*source);
i::Handlei::Object name_obj;
int line_offset = 0;
int column_offset = 0;
/* Set my break point in the line below */
if (origin != NULL) {
Here is how I set my breakpoint:
1. I open the build/all.xcodeproj
2. click open the test_shell.xcodeproj
3. click open the v8.xcodeproject
4. open api.cc
5. set breakpoint in the location I mentioned above
6. go to test_shell.xcodeproj and click 'Build and Go(Debug)'
7. load an url, (e.g. www.yahoo.com)
The site gets loaded, but the break point never breaks.
I appreciate if anyone can help me with this.
Thank you.
2009/5/27 Søren Gjesse sgje...@chromium.org:
Hi,
There must be something wrong with your setting of break points. There is
only on way of getting JavaScript code into V8 from a client application,
and that is through the static method v8::Script::Compile in the public API.
This method is defined in api.cc where it in turn calls
v8::internal:Compiler::Complie defined in compiler.cc. All the adding of
code to V8 from Chromium is handled in v8_proxy.cpp.
Code added from within JavaScript through the use of eval will be handled by
v8::internal:Compiler::ComplieEval.
Note that if you are using Chromium for this you need to take the
multiprocess architecture into account either by using the --single-process
switch to turn it off or by attaching to the process you will actually like
to debug.
Regards,
Søren
On Thu, May 28, 2009 at 07:52, Lucius Fox lucius.fo...@gmail.com wrote:
Hi,
i am trying to understand how chromium passes JS script node/JS file
to v8 engine for execution.
So i setup breakpoints in Xcode with test)shell xcode project opened:
Compiler::Compile
Compiler::CompileEval
Compiler::CompileLazy
And then I 'build and go (debug)' to get a TestShell. It did start up
the TestShell, and it did break in the initial breakpoint I setup in
test_shell_main.cc. But when I load a page with Javascript for sure,
e.g. www.cnn.con, it never breaks in the Compiler functions that I
mentioned above.
Can you please tell me how does chromium passes JS script node/JS file
to v8 engine for execution
--~--~-~--~~~---~--~~
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: Should the header file sentries contain double underscores?
Yes, this is legacy. You'll see that new code uses (at least should use) a single trailing underscore: cpu.h:#ifndef BASE_CPU_H_ cpu.h:#define BASE_CPU_H_ cpu.h:#endif // BASE_CPU_H_ It should be an easy mass replace, but it's not really more than an ideological concern. We've just been slowly updating guards as we touch the files. Thanks -- dean On Tue, May 12, 2009 at 1:37 PM, Glider ramosian.gli...@gmail.com wrote: Hi chromium-dev, The Chromium header files begin with a sentry section that looks like: #ifndef PATH_FILENAME__ #define PATH_FILENAME__ However, the names containing __ are reserved according to the C++ standard and cannot be used. Is that a legacy in the codebase, or should it be fixed? WBR, Alexander Potapenko --~--~-~--~~~---~--~~ 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 painting and deadlock
On Mon, May 4, 2009 at 12:15 AM, Darin Fisher da...@chromium.org wrote: Painting is not the only issue. On Windows there are several ways in which the thread responsible for a HWND can block waiting for the thread responsible for a child HWND to respond. Are you sure there are no X calls that block in a similar fashion? Are there no cases where you can query something about a child X window that would require asking the client associated with that X window to provide some data? One nice thing about X and the client/server model, is that there is a clear interface and description of what can happen. I don't think X ever asks an application for information, instead the application always tells X things, and X maintains the state. Therefore I can't imagine anything happening in X like this: App1 - request - X - request App2 That is because X does not have a mechanism to ask things from the client, only to notify it about events. That said, we're using Xembed for plugins, and I don't know exactly what it involves. I would still be surprised to see this situation arise however. To quote some X tutorial: http://www.visi.com/~grante/Xtut/ As stated earlier, the X protocol defines what passes back and forth between the client and the server. The information that travels between client and server is broken up into ``packets'' at the X protocol level (which is different than Ethernet or TCP/IP packets or frames). There are four types of packets: - Request A request packet is sent by the client to the server to ask that the server perform some action or return some information. - Reply A reply packet is sent by the server to the client in response to a request from the server. Not all requests generate replies. - Event An event packet is sent by the server to the client to inform it of user input or some other happening about which it might want to do something (for example a window was re-sized or a previously obscured window was uncovered). - Error An error packet is sent by the server to the client to inform it that a request was not valid. Since requests are queued, the error might not be discovered until after several more requests have been queued by the client. -Darin On Sun, May 3, 2009 at 1:36 PM, Evan Martin e...@chromium.org wrote: Two statements of fact first, and then a proposal afterwards. Please correct my facts if I'm wrong. 1) On Windows, when you have a windowed plugin and paint the main window, it synchronously (?) paints the child windows including plugins. (This is the major point I'm unsure about; I don't understand Windows very well. See webkit/glue/plugins/test/plugin_create_instance_in_paint.cc [1] for a test that indicates that this is the problem.) Because of this, we can end up with a deadlock when the plugin WM_PAINT handler calls into renderer javascript which calls back into the browser process (for example, to query something like the screen size). We work around this by handling those synchronous queries on the IO thread, not the UI thread, in the browser process. 2) On Linux, queries about the screen (and clipboard handling) go via X and GTK wraps X. GTK/X aren't implicitly threadsafe so we can't directly handle the above queries on the IO thread; if we add locks we recreate the deadlock problem. The alternative Adam hacked up is an *additional* thread with its own connection to X, and then we must be careful to not touch any GTK functions there. (This is especially annoying because the point of using toolkits like GTK is that it provides a nice interface to these functions.) Ok, those were the facts as I understand them. Here's the thought: maybe we don't have this synchronous painting problem on X. (It seems strange to me it exists on Windows, maybe because I misunderstand the problem.) I created a test app (code attached) that stuffs a child process with a button in the host process, where clicking the button makes the child process hang for five seconds. While the child is hung, the button obviously doesn't repaint, but you can continue to resize and observe the main window repainting. Conclusion, if the above is all correct: we don't need to go through convolutions to avoid this deadlock problem. - With little code change, we can proxy those renderer-browser calls back to the UI thread on Linux only. r15028 [2] did just that. - To be cleaner, we could just terminate those calls on the UI thread (again, only on Linux) using the existing messaging infrastructure. (PS: I'm not sure if windowless plugins play into this at all. I recall there's a potential for a synchronous paint in some circumstances, but I believe that's synchronous between the renderer and the plugin, right?) [1] http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/test/plugin_create_instance_in_paint.cc [2] http://src.chromium.org/viewvc/chrome?view=revrevision=15028
[chromium-dev] Re: Plugin painting and deadlock
On Mon, May 4, 2009 at 5:48 PM, Darin Fisher da...@chromium.org wrote: On Mon, May 4, 2009 at 1:08 AM, Dean McNamee de...@chromium.org wrote: On Mon, May 4, 2009 at 12:15 AM, Darin Fisher da...@chromium.org wrote: Painting is not the only issue. On Windows there are several ways in which the thread responsible for a HWND can block waiting for the thread responsible for a child HWND to respond. Are you sure there are no X calls that block in a similar fashion? Are there no cases where you can query something about a child X window that would require asking the client associated with that X window to provide some data? One nice thing about X and the client/server model, is that there is a clear interface and description of what can happen. I don't think X ever asks an application for information, instead the application always tells X things, and X maintains the state. Therefore I can't imagine anything happening in X like this: App1 - request - X - request App2 That is because X does not have a mechanism to ask things from the client, only to notify it about events. That said, we're using Xembed for plugins, and I don't know exactly what it involves. I would still be surprised to see this situation arise however. To quote some X tutorial: http://www.visi.com/~grante/Xtut/ As stated earlier, the X protocol defines what passes back and forth between the client and the server. The information that travels between client and server is broken up into ``packets'' at the X protocol level (which is different than Ethernet or TCP/IP packets or frames). There are four types of packets: - Request A request packet is sent by the client to the server to ask that the server perform some action or return some information. - Reply A reply packet is sent by the server to the client in response to a request from the server. Not all requests generate replies. - Event An event packet is sent by the server to the client to inform it of user input or some other happening about which it might want to do something (for example a window was re-sized or a previously obscured window was uncovered). - Error An error packet is sent by the server to the client to inform it that a request was not valid. Since requests are queued, the error might not be discovered until after several more requests have been queued by the client. Good to know. However, this morning it occurred to me that it almost doesn't matter. Consider the case of scrolling a page with plugins: To scroll the page so that it looks like everything is scrolling as one piece, we have to blit the backingstore to the screen for the render view, and then we need to re-position and possibly re-paint any exposed plugin windows. We need to make all of this happen together, which on Windows is accomplished by synchronizing the browser UI thread with the plugin UI thread. Sorry, I am not too familiar with this code, so I'm probably a bit lost. Are you talking about windowed or windowless plugins? You said reposition, so I am assuming you are talking about windowed plugins. In that case I completely don't understand what you just said :) Thanks So, I don't believe that we can avoid the need to block the browser UI thread on the plugin UI thread. -Darin --~--~-~--~~~---~--~~ 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: Extracting Views, creating app/
If people need things moved to base, you can file a bug against me. During this refactor, it would be nice to also have the opposite, a clean dependencies on what uses views. For Linux we would like to build without views. Right now there are dependencies from outside of views/ to views/. There is a bug filed to try to untangle it, but I suppose it makes sense to wait until you pull views/ out completely. On Tue, Apr 28, 2009 at 1:00 AM, Scott Violet s...@chromium.org wrote: chrome/common/scoped_vector.h This file really wants to be in base. Same thing for chrome/common/stl_util-inl.h . -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp shared library builds on Linux
Looks like it's missing -ldl, but I haven't looked closely.
On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote:
hi there,
thanks for working on getting the shared lib of libraries! I was
pointed to this work by Evan Martin as well and he pointed me to this
(http://codereview.chromium.org/88058). However I am having some
difficulty getting it to build and it errors out while building
libxml.
==
...
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os
Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so
Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/xmlcatalog
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os
Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose'
collect2: ld returned 1 exit status
scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
src/sconsbuild/Debug/xmlcatalog] Error 1
scons: building terminated because of errors.
===
Here are the steps that I tried:
a) first I tried to download each patch from patch set 4 and patched
the corresponding files manually. Removed sconsbuild directory and
rebuilt. it had the same errors.
I read your instructions in Description section but I did not
understand where exactly I need to make changes to exclude and include
those files. I looked at all_main.scons and common.gypi. it would be
really helpful if you can elaborate on those instructions.
b) I did a get latest with revision 14166 by using following command:
CHROMIUM_ROOT$ gclient sync --revision s...@14166
(chromium root = directory that has src directory in it).
Let me know what steps I might be missing. Another point I want to add
is that I have followed the instructions in 'Staying Green more of the
time' section of getting code on chrome wiki for linux developers, if
that matters any.
Thanks,
On Apr 21, 8:21 pm, Steven Knight s...@chromium.org wrote:
The gyp build can generate shared libraries on Linux (as of r14166).
You can set up to use shared libraries by setting the GYP_DEFINES variable
as follows:
$ export GYP_DEFINES='library=shared_library'
$ gclient runhooks --force
If it's not set when you run gclient, it will silently generate .scons
files that build with static libraries, of course, so put it in your
.profile or .bashrc or whatever suits.
As an alternative to an environment variable, put the following text in the
~/.gyp/include.gypi startup file in your home directory:
{
'variables': {
'library': 'shared_library',
},
}
Note that you *can* build shared and static in the same tree by switching
back and forth (the shared object files will have a different suffix), but
the .a and .so files get built in the same sconsbuild/{Debug,Release}/lib
directory. This can throw you for a loop if the linker decides to use an
old .so in preference to the new .a you just built, so it's safer to clean
things out (at least the lib/ subdirectory, anyway).
--SK
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp shared library builds on Linux
The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de...@chromium.org wrote: Looks like it's missing -ldl, but I haven't looked closely. On Fri, Apr 24, 2009 at 12:57 PM, nshah nidhi.kejri...@gmail.com wrote: hi there, thanks for working on getting the shared lib of libraries! I was pointed to this work by Evan Martin as well and he pointed me to this (http://codereview.chromium.org/88058). However I am having some difficulty getting it to build and it errors out while building libxml. == ... Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/xmlcatalog Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 scons: building terminated because of errors. === Here are the steps that I tried: a) first I tried to download each patch from patch set 4 and patched
[chromium-dev] Re: gyp shared library builds on Linux
Just to follow up explicitly to what Craig said, you should do something like the following, and make sure there are no errors: # Clobber rm -rf sconsbuild # Make sure everything is up to date gclient sync --force # Make sure the scons files were regenerated from the gyp files gclient runhooks --force On Fri, Apr 24, 2009 at 4:50 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Actually all the targets work ... Steven fixed them all and I just hadn't realised that so the hammer app thing and my earlier rambling is ignorable. I see from your other mail that you are using the tarball though so I'd recommend trying to sync up with the current svn trunk. It should all work there. Also you must do the gclient runhooks --force thing ... I might be on #chromium later ... Drop by if you're still having trouble. That's easier than trying to solve it here... --Craig On 24 Apr 2009, at 15:55, nshah nidhi.kejri...@gmail.com wrote: actully I saw it there but then I was not sure if it needs another condition block for shared_library but before asking you again I wanted to try to build chrome (hammer app) and see if that works as you suggested. Thanks! Nidhi On Apr 24, 9:16 am, Craig Schlenter craig.schlen...@gmail.com wrote: Hmmm ... actually it seems as if -ldl is present in third_party/libxml/libxml.gyp ... so take a look if it's there for you and run gclient sync if it isn't. Try running gclient runhooks -- force if none of the other things work. Perhaps your scons files have not been updated properly. --Craig On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter craig.schlen...@gmail.com wrote: Hi At some point I had used -ldl in the xml gyp file but then I dropped that when I purely targeted chrome and not any of the other targets ... in fact I haven't even tried building the other targets for a while so it's quite possible that they won't build as shared targets. Try hammer app and see if that works or add '-ldl' after '-lm' in libxml.gyp near the xmlcatalog stuff. Thanks! --Craig On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee de...@chromium.org wrote: The obvious fix would be to add -ldl, but I don't see why libxml should be using it... From a quick peek at the code, I saw xmlmodules.c using dlerror / etc for dynamic module support. Since libxml is running sandboxed, do we really want dynamic module support? In specific, it seems like we have LIBXML_MODULES_ENABLED defined in our xmlversion.h... On Fri, Apr 24, 2009 at 2:18 PM, nshah nidhi.kejri...@gmail.com wrote: This group is very impressive, always so quick in reply! Thanks for quick reply! I did hammer --verbose and here is the command if that helps: cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/base ../chrome/tools/build/linux/version.sh file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ global_intermediate/base/file_version_info_linux.h flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ src/ sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/ home/ chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/ home/ dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/ Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/ tarball/ chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ ProgramFiles/ v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/ third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 - Wl,--end- group /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen' /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose' collect2: ld returned 1 exit status scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/ src/sconsbuild/Debug/xmlcatalog] Error 1 gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/ sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz- tibetan.os -c - m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/ usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD - DTOOLKIT_GTK=1 - D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/ src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/ ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/ harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/ chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c scons: building terminated because of errors. On Apr 24, 7:41 am, Dean McNamee de
[chromium-dev] Re: [Linux] Heads-up: New build dependency
Not to make more things complicated, but shouldn't it be possible to only use gconf if it's available, otherwise don't get the proxy settings? I am just worried that we are slowing sucking in the whole world into our dependency list. I guess we obviously need the headers for building, but at runtime it would be nice to just fallback instead of requiring a dependency. Dunno... On Fri, Apr 17, 2009 at 5:29 PM, Stephane Doyon sdo...@chromium.org wrote: If you don't build on Linux, then you can stop reading now. I will be checking in this CL (http://codereview.chromium.org/60009) that will require gconf as a build dependency for Linux. You need to do: sudo apt-get install libgconf2-dev (or equivalent for your distro) and if you are on a 64bits system: sudo ln -s libgconf-2.so.4 /usr/lib32/libgconf-2.so maruel@ has been kind enough to update the build slaves. I have also updated the wiki, and the build/install-build-deps.sh script will be updated by the same CL. I'll wait until Monday so people have a chance to see this. Thanks --~--~-~--~~~---~--~~ 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] Heads-up: New build dependency
On Fri, Apr 17, 2009 at 8:25 PM, Stephane Doyon sdo...@chromium.org wrote: On Fri, 17 Apr 2009, Dean McNamee wrote: Not to make more things complicated, but shouldn't it be possible to only use gconf if it's available, otherwise don't get the proxy settings? I am just worried that we are slowing sucking in the whole world into our dependency list. I guess we obviously need the headers for building, but at runtime it would be nice to just fallback instead of requiring a dependency. Dunno... AFAICT the whole GNOME world depends on gconf so that in practice libgconf2-4 is always installed, so as a run-time dependency it shouldn't be a problem. Ok, makes sense. I sort of misread that this was just an announcement about installing the dev package (headers, etc). Thanks (It's vaguely amusing to see what apt-get wants to throw away if you ask it to uninstall the run-time lib libgconf2-4.) On Fri, Apr 17, 2009 at 5:29 PM, Stephane Doyon sdo...@chromium.org wrote: If you don't build on Linux, then you can stop reading now. I will be checking in this CL (http://codereview.chromium.org/60009) that will require gconf as a build dependency for Linux. You need to do: sudo apt-get install libgconf2-dev (or equivalent for your distro) and if you are on a 64bits system: sudo ln -s libgconf-2.so.4 /usr/lib32/libgconf-2.so maruel@ has been kind enough to update the build slaves. I have also updated the wiki, and the build/install-build-deps.sh script will be updated by the same CL. I'll wait until Monday so people have a chance to see this. Thanks --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
Word on the street is that the ccflags are all wrong, and that release
builds aren't being built release properly.
On Thu, Apr 2, 2009 at 7:23 AM, Mark Mentovai m...@chromium.org wrote:
Awesome. This is seriously good news. Thanks!
Mark
Steven Knight wrote:
Linux builds have been converted to gyp-generated SCons files.
I'm in the process of updating the wiki pages to reflect the change. Here's
the executive summary of the most important points (or the ones I can
remember):
- The gclient hook will have gyp generate the .scons files for you
after next update
- Output is now generated in src/sconsbuild/{Debug,Release}
- Consequently, it's going to rebuild your (Linux) world after
your first update
- The main build entry point is now the src/build directory;
see below for a little more detail.
- Start using --mode=Release (not --mode=opt) to build the
release version
- LOAD= does not work at the moment, but will shortly (there's a
CL teed up)
- Sorry SHARED=1 people, that's broken again
Build instructions:
$ cd $CHROMIUM_ROOT/src/build
$ hammer [targets]
Default is all. You can specify any of the targets from the .gyp files to
build just the specified targets. So:
$ cd $CHROMIUM_ROOT/src/build
$ hammer app
$ ../sconsbuild/Debug/chrome
If you prefer to do everything from the src/ directory, use -C (like make):
$ cd $CHROMIUM_ROOT/src
$ hammer -C build app
$ sconsbuild/Debug/chrome
If you have questions or notice problems, you know who to find...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
I can't actually get it to build (trying Release for now), I am
getting linker errors for X calls, we are probably not linking
correctly. I will debug it :\
On Thu, Apr 2, 2009 at 12:11 PM, Dean McNamee de...@chromium.org wrote:
Word on the street is that the ccflags are all wrong, and that release
builds aren't being built release properly.
On Thu, Apr 2, 2009 at 7:23 AM, Mark Mentovai m...@chromium.org wrote:
Awesome. This is seriously good news. Thanks!
Mark
Steven Knight wrote:
Linux builds have been converted to gyp-generated SCons files.
I'm in the process of updating the wiki pages to reflect the change. Here's
the executive summary of the most important points (or the ones I can
remember):
- The gclient hook will have gyp generate the .scons files for you
after next update
- Output is now generated in src/sconsbuild/{Debug,Release}
- Consequently, it's going to rebuild your (Linux) world after
your first update
- The main build entry point is now the src/build directory;
see below for a little more detail.
- Start using --mode=Release (not --mode=opt) to build the
release version
- LOAD= does not work at the moment, but will shortly (there's a
CL teed up)
- Sorry SHARED=1 people, that's broken again
Build instructions:
$ cd $CHROMIUM_ROOT/src/build
$ hammer [targets]
Default is all. You can specify any of the targets from the .gyp files to
build just the specified targets. So:
$ cd $CHROMIUM_ROOT/src/build
$ hammer app
$ ../sconsbuild/Debug/chrome
If you prefer to do everything from the src/ directory, use -C (like make):
$ cd $CHROMIUM_ROOT/src
$ hammer -C build app
$ sconsbuild/Debug/chrome
If you have questions or notice problems, you know who to find...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
Notice the lack of -O2, etc. This also broke SYMBOLS= PROFILE=, COVERAGE=, etc.
I am tempted to revert it all.
de...@trex:build$ hammer -j6 --mode=Release SYMBOLS=1 --verbose v8_shell
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o
/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src/snapshot-empty.o
-c -m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse
-DCHROMIUM_BUILD -DNDEBUG
-I/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src
-I/usr/local/google/home/deanm/chrome/git/new/src/v8/src
/usr/local/google/home/deanm/chrome/git/new/src/v8/src/snapshot-empty.cc
g++ -o
/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src/accessors.o
-c -m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse
-DCHROMIUM_BUILD -DNDEBUG
-I/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src
-I/usr/local/google/home/deanm/chrome/git/new/src/v8/src
/usr/local/google/home/deanm/chrome/git/new/src/v8/src/accessors.cc
g++ -o
/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src/allocation.o
-c -m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse
-DCHROMIUM_BUILD -DNDEBUG
-I/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src
-I/usr/local/google/home/deanm/chrome/git/new/src/v8/src
/usr/local/google/home/deanm/chrome/git/new/src/v8/src/allocation.cc
On Thu, Apr 2, 2009 at 12:43 PM, Dean McNamee de...@chromium.org wrote:
-lX11 -lXrender -lXext (at least) was dropped in the switch to gyp. I
tried to understand how gyp worked or where these were coming from,
but no luck.
On Thu, Apr 2, 2009 at 12:35 PM, Dean McNamee de...@chromium.org wrote:
I can't actually get it to build (trying Release for now), I am
getting linker errors for X calls, we are probably not linking
correctly. I will debug it :\
On Thu, Apr 2, 2009 at 12:11 PM, Dean McNamee de...@chromium.org wrote:
Word on the street is that the ccflags are all wrong, and that release
builds aren't being built release properly.
On Thu, Apr 2, 2009 at 7:23 AM, Mark Mentovai m...@chromium.org wrote:
Awesome. This is seriously good news. Thanks!
Mark
Steven Knight wrote:
Linux builds have been converted to gyp-generated SCons files.
I'm in the process of updating the wiki pages to reflect the change.
Here's
the executive summary of the most important points (or the ones I can
remember):
- The gclient hook will have gyp generate the .scons files for you
after next update
- Output is now generated in src/sconsbuild/{Debug,Release}
- Consequently, it's going to rebuild your (Linux) world after
your first update
- The main build entry point is now the src/build directory;
see below for a little more detail.
- Start using --mode=Release (not --mode=opt) to build the
release version
- LOAD= does not work at the moment, but will shortly (there's a
CL teed up)
- Sorry SHARED=1 people, that's broken again
Build instructions:
$ cd $CHROMIUM_ROOT/src/build
$ hammer [targets]
Default is all. You can specify any of the targets from the .gyp files
to
build just the specified targets. So:
$ cd $CHROMIUM_ROOT/src/build
$ hammer app
$ ../sconsbuild/Debug/chrome
If you prefer to do everything from the src/ directory, use -C (like
make):
$ cd $CHROMIUM_ROOT/src
$ hammer -C build app
$ sconsbuild/Debug/chrome
If you have questions or notice problems, you know who to find...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
-lX11 -lXrender -lXext (at least) was dropped in the switch to gyp. I
tried to understand how gyp worked or where these were coming from,
but no luck.
On Thu, Apr 2, 2009 at 12:35 PM, Dean McNamee de...@chromium.org wrote:
I can't actually get it to build (trying Release for now), I am
getting linker errors for X calls, we are probably not linking
correctly. I will debug it :\
On Thu, Apr 2, 2009 at 12:11 PM, Dean McNamee de...@chromium.org wrote:
Word on the street is that the ccflags are all wrong, and that release
builds aren't being built release properly.
On Thu, Apr 2, 2009 at 7:23 AM, Mark Mentovai m...@chromium.org wrote:
Awesome. This is seriously good news. Thanks!
Mark
Steven Knight wrote:
Linux builds have been converted to gyp-generated SCons files.
I'm in the process of updating the wiki pages to reflect the change.
Here's
the executive summary of the most important points (or the ones I can
remember):
- The gclient hook will have gyp generate the .scons files for you
after next update
- Output is now generated in src/sconsbuild/{Debug,Release}
- Consequently, it's going to rebuild your (Linux) world after
your first update
- The main build entry point is now the src/build directory;
see below for a little more detail.
- Start using --mode=Release (not --mode=opt) to build the
release version
- LOAD= does not work at the moment, but will shortly (there's a
CL teed up)
- Sorry SHARED=1 people, that's broken again
Build instructions:
$ cd $CHROMIUM_ROOT/src/build
$ hammer [targets]
Default is all. You can specify any of the targets from the .gyp files
to
build just the specified targets. So:
$ cd $CHROMIUM_ROOT/src/build
$ hammer app
$ ../sconsbuild/Debug/chrome
If you prefer to do everything from the src/ directory, use -C (like make):
$ cd $CHROMIUM_ROOT/src
$ hammer -C build app
$ sconsbuild/Debug/chrome
If you have questions or notice problems, you know who to find...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
(this isn't just V8, all of chromium is built without optimization in
release). There are lots of other issues all over the place.
On Thu, Apr 2, 2009 at 1:14 PM, Dean McNamee de...@chromium.org wrote:
Notice the lack of -O2, etc. This also broke SYMBOLS= PROFILE=, COVERAGE=,
etc.
I am tempted to revert it all.
de...@trex:build$ hammer -j6 --mode=Release SYMBOLS=1 --verbose v8_shell
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o
/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src/snapshot-empty.o
-c -m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse
-DCHROMIUM_BUILD -DNDEBUG
-I/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src
-I/usr/local/google/home/deanm/chrome/git/new/src/v8/src
/usr/local/google/home/deanm/chrome/git/new/src/v8/src/snapshot-empty.cc
g++ -o
/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src/accessors.o
-c -m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse
-DCHROMIUM_BUILD -DNDEBUG
-I/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src
-I/usr/local/google/home/deanm/chrome/git/new/src/v8/src
/usr/local/google/home/deanm/chrome/git/new/src/v8/src/accessors.cc
g++ -o
/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src/allocation.o
-c -m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse
-DCHROMIUM_BUILD -DNDEBUG
-I/usr/local/google/home/deanm/chrome/git/new/src/sconsbuild/Release/obj/v8/src
-I/usr/local/google/home/deanm/chrome/git/new/src/v8/src
/usr/local/google/home/deanm/chrome/git/new/src/v8/src/allocation.cc
On Thu, Apr 2, 2009 at 12:43 PM, Dean McNamee de...@chromium.org wrote:
-lX11 -lXrender -lXext (at least) was dropped in the switch to gyp. I
tried to understand how gyp worked or where these were coming from,
but no luck.
On Thu, Apr 2, 2009 at 12:35 PM, Dean McNamee de...@chromium.org wrote:
I can't actually get it to build (trying Release for now), I am
getting linker errors for X calls, we are probably not linking
correctly. I will debug it :\
On Thu, Apr 2, 2009 at 12:11 PM, Dean McNamee de...@chromium.org wrote:
Word on the street is that the ccflags are all wrong, and that release
builds aren't being built release properly.
On Thu, Apr 2, 2009 at 7:23 AM, Mark Mentovai m...@chromium.org wrote:
Awesome. This is seriously good news. Thanks!
Mark
Steven Knight wrote:
Linux builds have been converted to gyp-generated SCons files.
I'm in the process of updating the wiki pages to reflect the change.
Here's
the executive summary of the most important points (or the ones I can
remember):
- The gclient hook will have gyp generate the .scons files for you
after next update
- Output is now generated in src/sconsbuild/{Debug,Release}
- Consequently, it's going to rebuild your (Linux) world after
your first update
- The main build entry point is now the src/build directory;
see below for a little more detail.
- Start using --mode=Release (not --mode=opt) to build the
release version
- LOAD= does not work at the moment, but will shortly (there's a
CL teed up)
- Sorry SHARED=1 people, that's broken again
Build instructions:
$ cd $CHROMIUM_ROOT/src/build
$ hammer [targets]
Default is all. You can specify any of the targets from the .gyp
files to
build just the specified targets. So:
$ cd $CHROMIUM_ROOT/src/build
$ hammer app
$ ../sconsbuild/Debug/chrome
If you prefer to do everything from the src/ directory, use -C (like
make):
$ cd $CHROMIUM_ROOT/src
$ hammer -C build app
$ sconsbuild/Debug/chrome
If you have questions or notice problems, you know who to find...
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: gyp build on Linux
I confirmed the debug build line has no -g. Also, all of the buildbots are red because of ICU issues: http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/6601/steps/test_shell_tests/logs/MimeTypeTests On Thu, Apr 2, 2009 at 3:46 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: And it seems to be built without debugging flags in debug mode. At least, I can't single-step through code on Linux. On Thu, Apr 2, 2009 at 4:18 AM, Dean McNamee de...@chromium.org wrote: (this isn't just V8, all of chromium is built without optimization in release). There are lots of other issues all over the place. On Thu, Apr 2, 2009 at 1:14 PM, Dean McNamee de...@chromium.org wrote: Notice the lack of -O2, etc. This also broke SYMBOLS= PROFILE=, COVERAGE=, etc. I am tempted to revert it all. --~--~-~--~~~---~--~~ 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: variant definitions in the .gyp files
On Thu, Apr 2, 2009 at 7:48 PM, Mark Mentovai m...@chromium.org wrote:
Steven Knight wrote:
'official': {
'defines': ['OFFICIAL_BUILD'],
# Make sure units of code and data go in their own section,
# and then GC them in the linker to remove unreferenced data
# and code. Currently gold doesn't support --gc-sections,
# so you'll have to build with the original GNU ld.
'cflags': ['-ffunction-sections', '-fdata-sections'],
'linkflags': ['-Wl,--gc-sections'],
},
I agree with what Tom said regarding 'official' as a variant.
variants will need to have the same restrictions that configurations
do, meaning that they won't be able to influence 'sources' or
'actions' or 'rules' or anything else in input.py's
non_configuration_keys list. For 'official', we do need the ability
to make changes to some non_configuration_keys, so this won't fly.
'official' will need to remain a GYP generation-time tunable.
'symbols': {
'cflags': ['-g'],
},
For Chrome's purposes, I don't see why we would ever want to build
without symbols. Either you're a developer and symbols are handy in a
direct way, or you're building an official release build and symbols
are handy for crash reporting. In what cases would -g0 be useful?
We did this for speed, not generating debug symbols in all of your
objects, and linking together a massive binary, can cut down the build
time significantly. Basically for a lot of people release is
something they can build and use, and debug is something they will use
for development. The stack traces / debugging / etc in a optimized
build isn't that great anyway, so basically what you generally want is
something like:
debug - symbols
release - no symbols
official - symbols
but it is nice to be able to build a release w/ symbols if you want, a
good example is for running valgrind, etc.
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 App Executables Disk Layout
Something important would be to understand the overhead for a shared library (fpic, relocation, etc). On Tue, Mar 24, 2009 at 7:45 PM, Thomas Van Lenten thoma...@chromium.org wrote: The Windows product builds a small executable that then loads the main chromium dll, and hands off control to that. I believe this is done solely for updating reasons. All the difference processes start from that one shim. On the Mac, we are currently building as a single executable. But, this brings up some complications, we need to be able to launch the Renderers with different Cocoa initialization. This data comes out of the info.plist, so we really need different bundles on disk (the OS acts on the data before the process is even started). So what it's looking like is that we need to move to a world where we also have a small shim for Chromium that loads a main shared lib and hands off control. Then we'll have a second shim for Renderers (and maybe plugin hosts, etc.) that loads the main shared lib and hands off control. Each of these shims will have different info.plists to provide the different Cocoa configuration information. Linux currently builds as one executable also. But Adam proposed we create a second executable (via hardlink?) for AppArmor as a sandbox? Does it make sense to standardize/require a small shell and shared lib for all platforms? One advantage of this approach on all platforms is they can initialize breakpad/crash reporting to the started up in the shim, so a crash during the loading of the main shared lib would be captured. One place not standardizing this gets ugly is within the build system, where it could become very complex expressing what goes into apps vs. shared libs. Thoughts/suggestions/comments? TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: sheriffs: please keep the purify bots green
It looks similar to: http://build.chromium.org/buildbot/waterfall/builders/XP%20Unit%20(purify)/builds/2466/steps/purify%20test:%20unit/logs/stdio Which is what caused hclam's patch to reverted previously. On Wed, Mar 18, 2009 at 7:55 PM, Adam Langley a...@chromium.org wrote: On Wed, Mar 18, 2009 at 11:48 AM, Marc-Antoine Ruel mar...@chromium.org wrote: It could be anywhere from 11801 to 11818. ben, jam, agl, dkegel, hclam, levin, tc, pkasting checked in during that time frame. ager, sgk did non-code changes so I don't think it's them. We'll soon make the tree automatically close on failure on some tests. One of the issue here is latency. Erik, if you can track it down, that'd be really appreciated. Possibly hclam: UMR in chrome/common/render_messages.h:1257 IPC::ParamTraits::Write(Message::IPC *,ViewHostMsg_Resource_Request const) 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] When creating new files
Usually when I create a new file, I just copy some old one, but then I get the copyright date wrong, or forget to update the include guards. I just fixed a lot of incorrect include guards in our code, which were clearly mistakes from manually typing out the names. It could be much easier, so here is my script. You run it something like genc chrome/common/my_new_file.h my_new_file.h I also use it for .cc files and just remove the guards. #!/bin/sh if [ $# -ne 1 ]; then echo usage: genc base/pants.h exit 1 fi GUARD=`echo $1_ | tr '[:lower:]./-' '[:upper:]___'` cat EOF // Copyright (c) 2009 The Chromium Authors. All rights reserved. // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. #ifndef $GUARD #define $GUARD #endif // $GUARD EOF --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
I had a discussion about Views with Scott. I think I am on the side of the fence that porting views it not a good idea. One of the things that came up is remote X, would it be possible to ever have good remote X performance with the Views panting model? I wouldn't want to paint ourselves into a corner (dum dum dum). On Sat, Mar 14, 2009 at 4:43 AM, t...@chromium.org wrote: I started a page describing some of the high level tradeoffs between the two. Please add items or elaborate. http://code.google.com/p/chromium/wiki/GtkVsViewsGtk On Fri, 13 Mar 2009, Ben Goodger (Google) wrote: Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met briefly earlier today to discuss Linux UI and Gtk. What we agreed is that next week Elliot and I will spend some time researching what it would take to use views with Gtk, including the Widget/Window types and NativeControl. The plan is to use native Gtk widgets for the outer container and for all locations where a NativeControl is used on Windows, so the applicable system integration for things like IME in text fields should just work. In this capacity, views is used as a layout engine and an event receiver/propagation system for views that aren't GtkWidgets, as it is on Windows for widgets that aren't HWNDs/Common Controls. As usual, Skia is providing the rendering. Since we're just researching right now, don't let this delay any UI work that's already under way. We'll report back to this group at the end of next week with our findings. -Ben --~--~-~--~~~---~--~~ 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: Doing some research with views and GTK.
On Sat, Mar 14, 2009 at 12:59 AM, Ben Goodger (Google) b...@chromium.org wrote: Scott Violet, Elliot, Evan Martin, Adam Langley, Tony, Linus and I met briefly earlier today to discuss Linux UI and Gtk. What we agreed is that next week Elliot and I will spend some time researching what it would take to use views with Gtk, including the Widget/Window types and NativeControl. The plan is to use native Gtk widgets for the outer container and for all locations where a NativeControl is used on Windows, so the applicable system integration for things like IME in text fields should just work. In this capacity, views is used as a layout engine and an event receiver/propagation system for views that aren't GtkWidgets, as it is on Windows for widgets that aren't HWNDs/Common Controls. As usual, Skia is providing the rendering. I think it's important to point our here that Skia (well ChromeCanvas) is not equal on Linux and Windows. Specifically Windows draws text using GDI, which current is much more powerful than drawing text using Skia. Until Skia has a text layout engine, panting text with Skia is basically a no go. We would still need to draw the text with Pango / Cairo, but we could incorporate that into ChromeCanvas... Since we're just researching right now, don't let this delay any UI work that's already under way. We'll report back to this group at the end of next week with our findings. -Ben --~--~-~--~~~---~--~~ 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: Status Bubble GTK?
In case you wanted to boring technical details on the topic:
From the ICCCM:
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.10
If the window will be visible for a very short time and should not be
decorated at all, the client can set override-redirect on the window.
In general, this should be done only if the pointer is grabbed while
the window is mapped. The window manager will never interfere with
these windows, which should be used with caution. An example of an
appropriate use is a pop-up menu.
From GTK, when creating a popup, it sets the GDK type to:
GDK_WINDOW_TEMP
From GDK, when handling this window type:
if (private-window_type == GDK_WINDOW_TEMP)
{
xattributes.save_under = True;
xattributes.override_redirect = True;
xattributes.cursor = None;
xattributes_mask |= CWSaveUnder | CWOverrideRedirect;
My understanding is that the window manager will never see these
windows, as it ignores the window managers SubstructureRedirectMask.
This is the reason popups actually work correctly and are put exactly
where you ask them to be put, the window manager doesn't even get a
chance to see them.
The other solution it sounded like you were saying is to try to create
a normal window, but asking the window manager to position it exactly
how you want and without decorations. I don't believe this works in
practice with a lot of window managers (tiling, etc). These are
hints, and I believe they very often go ignored.
It seems the only real solution would be to use a popup, but to
manually go to X and manage the stacking order, if this is even
possible. I think the best thing to do is to make it a child window
of the WebContents, and we can position it within the contents exactly
where we want it. It will never extend outside of our top level
window, but I think that's ok.
I wonder if the situation is at all similar on Mac.
On Fri, Mar 13, 2009 at 1:02 PM, Dean McNamee de...@chromium.org wrote:
Hey Darin,
I'm a bit familiar with this problem. From what I understand, the
window manager doesn't get a chance to handle popup windows. The
problem we have with the status bubble now, is if chrome is not on top
(it's behind some other window), and you mouse over a link, our status
bubble popup comes up over the window in front, since a popup wants to
be topmost.
We would probably have to try to manage the stacking order ourselves,
since the window manager can't help with this situation. I personally
think what Evan is proposing is simpler and good enough, additionally
Linux users aren't going to expect this behavior of things moving
outside the main window. It's nice on Windows, but I don't really
think it's worth the work on Linux.
On Thu, Mar 12, 2009 at 10:40 PM, Evan Martin e...@chromium.org wrote:
On Thu, Mar 12, 2009 at 2:34 PM, Darin Fisher da...@chromium.org wrote:
I see... there has to be a way with window manager hints to make this work
:-)
I hope so, too. I played around with it for a while in a test app,
and then decided that doing it Right was going to be a lot of effort
and I'd be better off fixing gaping holes than polishing this. I made
it extra-ugly just so nobody would take it too seriously.
We might be getting a 20% who's written a window manager before; I was
trying to interest him in this problem as a starter project.
--~--~-~--~~~---~--~~
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: focusRingColor() listening to system settings changes on Windows?
I would have to guess that if there was, it would be some window message (WM_THEMECHANGED ?) sent to our top level window, and the plumbing would be annoying for it. On Mon, Mar 9, 2009 at 10:21 AM, Jeremy Moskovich jer...@chromium.org wrote: (mailed to random people who I thought might know the answer). In platform/graphics/chromium/ColorChromium.cpp we currently hardcode the value of focusRingColor on OS X Windows. On OS X Safari listens on a notification to see if the user has changed the system focus color. Is there a similar notification mechanism on Windows we should be using? Best regards, Jeremy --~--~-~--~~~---~--~~ 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-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching the tree go red after it.
Appreciation from another time zone,
-- dean
On Thu, Mar 5, 2009 at 7:38 AM, hc...@chromium.org wrote:
Author: hc...@chromium.org
Date: Wed Mar 4 22:38:52 2009
New Revision: 10972
Log:
Highlights of changes:
1. Added entry to ResourceResponseHead so that it contains
either a base::PlatformFile (OS_WIN) or
base::FileDescriptor (OS_POSIX) for passing the file
handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
is added so that the peer is notified of the download
progress in the renderer process.
3. Load flag to kick start the resource loading for media
files. LOAD_MEDIA_RESOURCE is added so that
ResourceDispatcherHost knows how to use a different
ResourceHandler for handling media resource request.
Review URL: http://codereview.chromium.org/27168
Modified:
trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
trunk/src/chrome/browser/renderer_host/resource_handler.h
trunk/src/chrome/common/render_messages.h
trunk/src/chrome/common/render_messages_internal.h
trunk/src/chrome/common/resource_dispatcher.cc
trunk/src/chrome/common/resource_dispatcher.h
trunk/src/net/base/load_flags.h
trunk/src/net/http/http_cache.cc
trunk/src/net/http/http_cache_unittest.cc
trunk/src/net/url_request/url_request.h
trunk/src/webkit/glue/resource_loader_bridge.h
Modified: trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
==
--- trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
(original)
+++ trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc Wed
Mar 4 22:38:52 2009
@@ -815,6 +815,15 @@
response-response_head.content_length = request-GetExpectedContentSize();
request-GetMimeType(response-response_head.mime_type);
+ // Structure of ResourceResponseHead depends on the platform, so we do it
+ // differently.
+#if defined(OS_POSIX)
+ response-response_head.response_data_file.fd =
request-response_data_file();
+ response-response_head.response_data_file.auto_close = false;
+#elif defined(OS_WIN)
+ response-response_head.response_data_file = request-response_data_file();
+#endif
+
if (request-ssl_info().cert) {
int cert_id =
CertStore::GetSharedInstance()-StoreCert(
Modified: trunk/src/chrome/browser/renderer_host/resource_handler.h
==
--- trunk/src/chrome/browser/renderer_host/resource_handler.h (original)
+++ trunk/src/chrome/browser/renderer_host/resource_handler.h Wed Mar 4
22:38:52 2009
@@ -12,6 +12,11 @@
#ifndef CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
#define CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
+#include build/build_config.h
+#if defined(OS_POSIX)
+#include base/file_descriptor_posix.h
+#endif
+#include base/platform_file.h
#include chrome/common/filter_policy.h
#include net/url_request/url_request_status.h
#include webkit/glue/resource_loader_bridge.h
@@ -29,6 +34,20 @@
// Specifies if the resource should be filtered before being displayed
// (insecure resources can be filtered to keep the page secure).
FilterPolicy::Type filter_policy;
+
+ // A platform specific handle for a file that carries response data. This
+ // entry is used if the resource request is of type ResourceType::MEDIA and
+ // the underlying cache layer keeps the response data in a standalone file.
+#if defined(OS_POSIX)
+ // If the response data file is available, the file handle is stored in
+ // response_data_file.fd, its value is base::kInvalidPlatformFileValue
+ // otherwise.
+ base::FileDescriptor response_data_file;
+#elif defined(OS_WIN)
+ // An asynchronous file handle to the response data file, its value is
+ // base::kInvalidPlatformFileValue if the file is not available.
+ base::PlatformFile response_data_file;
+#endif
};
// Parameters for a synchronous resource response.
Modified: trunk/src/chrome/common/render_messages.h
==
--- trunk/src/chrome/common/render_messages.h (original)
+++ trunk/src/chrome/common/render_messages.h Wed Mar 4 22:38:52 2009
@@ -377,6 +377,9 @@
case ResourceType::OBJECT:
type = LOBJECT;
break;
+ case ResourceType::MEDIA:
+ type = LMEDIA;
+ break;
default:
type = LUNKNOWN;
break;
@@ -1334,12 +1337,14 @@
ParamTraitswebkit_glue::ResourceLoaderBridge::ResponseInfo::Write(m, p);
WriteParam(m,
[chromium-dev] Re: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
I didn't mean that to be such a personal flame, we need to have some
better guards to prevent this from happening. It's just frustrating
when the tree is broken for hours at a time. It's happened a lot
lately, the tree has been closed and/or hosed for the majority of my
workday week. The sheriff wakes up, reverts everything closes the
tree, nurses it back to heath, and then it happens again the next
morning. It's not really a good strategy.
Maybe we need to limit the hours people are commit, if a sheriff isn't
around to fix things? I don't really think that's a good strategy
either. I don't know.
On Thu, Mar 5, 2009 at 5:34 PM, Dean McNamee de...@chromium.org wrote:
I just verified that this patch completely broke everything. You
committed late at night when no sheriff or anyone was around, and then
you went to bed.
Thanks for not testing your code, and not watching the tree go red after it.
Appreciation from another time zone,
-- dean
On Thu, Mar 5, 2009 at 7:38 AM, hc...@chromium.org wrote:
Author: hc...@chromium.org
Date: Wed Mar 4 22:38:52 2009
New Revision: 10972
Log:
Highlights of changes:
1. Added entry to ResourceResponseHead so that it contains
either a base::PlatformFile (OS_WIN) or
base::FileDescriptor (OS_POSIX) for passing the file
handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
is added so that the peer is notified of the download
progress in the renderer process.
3. Load flag to kick start the resource loading for media
files. LOAD_MEDIA_RESOURCE is added so that
ResourceDispatcherHost knows how to use a different
ResourceHandler for handling media resource request.
Review URL: http://codereview.chromium.org/27168
Modified:
trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
trunk/src/chrome/browser/renderer_host/resource_handler.h
trunk/src/chrome/common/render_messages.h
trunk/src/chrome/common/render_messages_internal.h
trunk/src/chrome/common/resource_dispatcher.cc
trunk/src/chrome/common/resource_dispatcher.h
trunk/src/net/base/load_flags.h
trunk/src/net/http/http_cache.cc
trunk/src/net/http/http_cache_unittest.cc
trunk/src/net/url_request/url_request.h
trunk/src/webkit/glue/resource_loader_bridge.h
Modified: trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
==
--- trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc
(original)
+++ trunk/src/chrome/browser/renderer_host/resource_dispatcher_host.cc Wed
Mar 4 22:38:52 2009
@@ -815,6 +815,15 @@
response-response_head.content_length = request-GetExpectedContentSize();
request-GetMimeType(response-response_head.mime_type);
+ // Structure of ResourceResponseHead depends on the platform, so we do it
+ // differently.
+#if defined(OS_POSIX)
+ response-response_head.response_data_file.fd =
request-response_data_file();
+ response-response_head.response_data_file.auto_close = false;
+#elif defined(OS_WIN)
+ response-response_head.response_data_file =
request-response_data_file();
+#endif
+
if (request-ssl_info().cert) {
int cert_id =
CertStore::GetSharedInstance()-StoreCert(
Modified: trunk/src/chrome/browser/renderer_host/resource_handler.h
==
--- trunk/src/chrome/browser/renderer_host/resource_handler.h (original)
+++ trunk/src/chrome/browser/renderer_host/resource_handler.h Wed Mar 4
22:38:52 2009
@@ -12,6 +12,11 @@
#ifndef CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
#define CHROME_BROWSER_RENDERER_HOST_RESOURCE_HANDLER_H_
+#include build/build_config.h
+#if defined(OS_POSIX)
+#include base/file_descriptor_posix.h
+#endif
+#include base/platform_file.h
#include chrome/common/filter_policy.h
#include net/url_request/url_request_status.h
#include webkit/glue/resource_loader_bridge.h
@@ -29,6 +34,20 @@
// Specifies if the resource should be filtered before being displayed
// (insecure resources can be filtered to keep the page secure).
FilterPolicy::Type filter_policy;
+
+ // A platform specific handle for a file that carries response data. This
+ // entry is used if the resource request is of type ResourceType::MEDIA
and
+ // the underlying cache layer keeps the response data in a standalone
file.
+#if defined(OS_POSIX)
+ // If the response data file is available, the file handle is stored in
+ // response_data_file.fd, its value is base::kInvalidPlatformFileValue
+ // otherwise.
+ base::FileDescriptor response_data_file;
+#elif defined(OS_WIN)
+ // An asynchronous file handle to the response data file, its value is
+ // base::kInvalidPlatformFileValue if the file is not available.
+ base::PlatformFile
[chromium-dev] Re: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
On Thu, Mar 5, 2009 at 6:01 PM, Nicolas Sylvain nsylv...@chromium.org wrote: There is one thing though, I don't think hclam checkin turned any Linux tests red. The linux build was unusable, but the unit tests and layout tests were passing. It seems like there is a lack of tests here. Yeah, we aren't running UI tests yet, and that would have caught this (or page cycler or anything else). I think we're getting close, but there is a bunch of things involved to get everything working. We definitely need better testing, but I think we're all test burnt out from working on layout tests, and just want to get some of our UI going. When I woke up I reverted his change because it broke Purify on windows and another unit test on windows, on only 1 bot. There is a possibility that he did wait, but did not judge that the tree was red enough to worry about it. (the unit test did look like a flakyness, and Purify is often slow to give results). I learned just after the revert that it did fix the problem with linux. So, my recommendations: 1. hclam: don't resubmit until you are sure it does not break linux. I'm sure any linux people here can help you with this. 2. linux people: We need more tests. 3. Everyone: If the tree is broken, and no sheriff is around, please, try to find what broke it, and revert the change. I pretty much wasted my day doing 3). It was my fault for not starting at the top and just going down, reverting, rebuild, etc. That would have found it pretty quickly. Mostly because it takes so long to build, I instead tried to debug it, hoping I would find the answer quickly. In the end I chased a bunch of wrong ideas and wasted a ton of time on it. If the tree is broken because of a problem with the buildbots, and no one is around to fix it, you can also page me. (I'll add the email alias to my who page). It's not so fair to wake you up in the middle of the night. I'd rather just take the day off :) I'm sure I was far too hard on hclam, I'm not super angry or anything. I am just trying to point out a problem that we continually seem to have, and we obviously need to improve here and have clear steps about how we're doing it. More tests on Mac and Linux definitely need to happen. If SVN wasn't so slow, I would have just sync'd back a few revisions. We should make our build and source control faster, the build I know we're working on. I think also some improvement to the waterfall is going to be really helpful. We have so many builds and builders and tests now, it's really hard to take all the information in. When there is a problem, we should have like a top 10 recent shady commits page, which tries to attribute new failures across all our builders and tests to a change list. It's often hard to tell from a single builder if a patch was bad, but if it caused a purify problem here, another problem here, etc, then at least that would give people a good starting point of where to look when they think the tree has gone sour. We also obviously need to improve our test flakiness. I've committed more than my share of shady patches, and I think so has the rest of the team. Again, I didn't meant to try to blame things so personally. And you're right, even when you do commit and watch the tree, it's often hard to tell the outcome, when it goes from kinda red to still kinda red, that isn't a great gauge. It just seems with all of the new platforms / code / complexity, we need some better ways of managing when it happens, because it's going to keep on happening. I think the outcome goal should be to not have sheriffs, and to have a system that can handle itself. Nicolas On Thu, Mar 5, 2009 at 8:47 AM, Amanda Walker ama...@chromium.org wrote: On Thu, Mar 5, 2009 at 11:41 AM, Dean McNamee de...@chromium.org wrote: Maybe we need to limit the hours people are commit, if a sheriff isn't around to fix things? I don't really think that's a good strategy either. I don't know. Well, it's not the sheriff's responsibility to fix every checkin, they're just there as a safety net. All of us should be making sure we don't break the build, every time we commit something. I don't think limiting commit hours is a workable strategy, given how many people are working across so many time zones. However, last night was a good reminder that no one should ever commit and then leave without watching the build to make sure it landed cleanly. It just leaves a mess for other people, which is unfriendly. --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-checkins] r10972 - in trunk/src: chrome/browser/renderer_host chrome/common net/base net/http net/url_request webkit/glue
On Thu, Mar 5, 2009 at 7:03 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: 2009/3/5 Amanda Walker ama...@chromium.org On Thu, Mar 5, 2009 at 12:38 PM, Alpha (Hin-Chung) Lam hc...@google.com wrote: everytime I do a checkin I do a sync and send it to the try server, which really takes me a lot of time, but still try server is showing me green light to check in, am I suppose to not trust the try server and rely on human intelligence? In this case watching the build wouldn't have helped, since the buildbots stayed green (I had misinterpreted Dean's original message, the tone of which he has since apologized for). However, to answer the general question, you should not completely trust the try server. If the try server breaks, it's a very good indication that an actual commit would break, but the reverse is not true. If the try server succeeds, it doesn't mean that a commit will succeed, since the try server runs fewer tests (and there may be commits to the tree in between doing a try and doing a commit). So even if the try succeeds, it's still important to watch the buildbots to make sure the actual commit also succeeds. That wasn't the problem in this instance (you wouldn't have seen this failure), but I wanted to make sure people don't rely too much on the try server. It's a good preflight check, but it won't catch everything. Thanks Amanda and Nicolas for the clarifactions. Sorry Dean for wasting your time to debug, I should have comminucated better as the patch really is posix specific. Sorry all chromium commiters if I have caused trouble to you. Hey, it's no big deal. I just want to make sure we took the instance as an example of how we can improve our build setup, and how we can keep the tree more stable. Alpha --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] What's the deal temp_scaffolding_subs ?
I am working on Linux omnibox, and chasing a stupid crash into temp_scaffolding_stubs.cc (TabContents). Every method I looked at was just a copy and paste from tab_contents.cc, without any modifications. Why? Why are we not just using the code in tab_contents.cc ? There is just a massive ifdef around it, with no comment as to what doesn't work, why it copied verbatim into stubs, etc. Totally confused. Thanks -- dean --~--~-~--~~~---~--~~ 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 modules debug red
It's been red for a while: [--] 15 tests from GKURL [ RUN ] GKURL.SameGetters [ OK ] GKURL.SameGetters (82 ms) [ RUN ] GKURL.DifferentGetters ASSERTION FAILED: isMainThread() (/b/slave/linux/build/src/third_party/WebKit/WebCore/platform/text/TextEncodingRegistry.cpp:172 buildBaseTextCodecMaps) program finished with exit code 245 --~--~-~--~~~---~--~~ 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: NSS and NSPR
I realize our checkouts are big, but there is a ton of other stuff besides NSS. I don't really see the point in trying to do this just now, it's seems likely to break a bunch of other platforms and be a bit of a mess. If you feel that it's that important, ok, don't break anything :) On Thu, Feb 26, 2009 at 8:36 AM, Darin Fisher da...@chromium.org wrote: Hmm... I'm OK with having the small duplication of NSS/NSPR code for the foreseeable future. I think it is nice that base doesn't require all of NSS+NSPR. So, I guess that's a +1 in favor of moving it to deps_os as planned. -Darin On Wed, Feb 25, 2009 at 9:08 PM, Michael Moss mm...@chromium.org wrote: Does that imply that it shouldn't move to deps? We can restrict it to Linux with deps_os now, and then make it apply to all platforms later, right? Or is it better to just leave it in trunk since it's already there? I'm fine with it either way, though it's less hassle for me to leave it where it is, and it means it's in my git tree instead of gclient/svn, but that's only a minor benefit since I don't expect to be changing it a lot once all these initial commits are in. Michael On Wed, Feb 25, 2009 at 8:08 PM, Darin Fisher da...@chromium.org wrote: If we do that cleanup, then we will need NSS and NSPR on all platforms. -Darin On Wed, Feb 25, 2009 at 7:31 PM, Michael Moss mm...@chromium.org wrote: There are actually both nss and nspr under base, but only a handful of files, not the whole trees. I plan to clean those up as appropriate, once this is all in and working. Michael On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang thes...@chromium.org wrote: BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten thoma...@chromium.org wrote: Sorry for arriving late w/ this question... I'm guessing NSS NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: NSS and NSPR
I don't understand why we need to import all of this code just so we can build an .so. Why don't we just take the .so's from the 32-bit package we're already using, and stick them into our .deb? We can check them into svn if don't want developers to have to have it, but that problem is already solved by the install script. Tracking third_party source (security updates, etc) is a huge pain, and has caused a lot of problems in the past. Also, having to build it seems pointless. On Thu, Feb 26, 2009 at 6:42 PM, Adam Langley a...@chromium.org wrote: On Thu, Feb 26, 2009 at 9:26 AM, Michael Moss mm...@chromium.org wrote: include nss and nspr directly in our build, thus bypassing any issues with missing system libs. Also note that, for the people using git, it's all in the history now anyway so it doesn't matter to us if it ever gets removed. 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: Merge 41017:41057 also needs a clobber for Windows folks
When we spot cases like this, can't we fix the makefiles / build files so that the dependencies are properly described? On Thu, Feb 19, 2009 at 12:31 AM, Dimitri Glazkov dglaz...@google.com wrote: As it turns out, the clobber applies to Mac and possibly Linux builds. Basically, clobber all. :DG On Wed, Feb 18, 2009 at 3:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Hi All, Because the latest merge introduces a change to third_party/WebKit/WebCore/css/html4.css, which is only picked up by DerivedSources.make, making that change actually appear in your build requires a clobber. :DG --~--~-~--~~~---~--~~ 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 Omnibox
I've started working on a GTK omnibox widget. I'll let you know when I have some more progress. --~--~-~--~~~---~--~~ 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 info caching
I was just reminded of this thread. I'm not sure if it was premeditated, but having the mime-types be a function (NP_GetMIMEDescription) is actually important for a specific Linux use-case. nspluginwrapper is a single plugin that proxies access to other plugins (for example, 64bit - 32bit). It doesn't know at build time which plugins it will be proxying for. At runtime, it's initialization will walk the directories specific in the npw configuration, and look for suitable plugins to proxy. You should be careful with caching metadata here also, since nspluginwrapper's library.so could be the same, but it could now be proxying more / different plugins. On Wed, Jan 28, 2009 at 8:50 AM, Darin Fisher da...@chromium.org wrote: Hmm, yeah... if it is easy to do so without a lot of code, that'd be great. -Darin On Tue, Jan 27, 2009 at 11:36 PM, John Abd-El-Malek j...@chromium.org wrote: One of my goals with the out of process worker code is it to make it easier to have many different types of child processes. Perhaps it makes sense to have the linux port do this stuff in a child process once that code is ready. On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher da...@chromium.org wrote: Wow. It sucks that we'll need to load plugins in the main browser process. That gives plugins a nice opportunity to hose the browser. Oh well :-( If we really wanted to, I suppose we could have a plugin scanner process, but that seems unfortunately heavyweight. -Darin On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin e...@chromium.org wrote: I'd been sending this sort of stuff to Dean and John but maybe other people will find it interesting. Plugin loading works in two phases: - at startup, we scan the plugin directories for metadata, like plugin names and which mime-types they apply to; - at runtime, when we're asked for a specific plugin by mime type, we open the appropriate library and have at it. On Windows and Mac, the startup step queries file metadata (version info on Windows, plists on Mac). On Linux, that step must dlopen() the plugin and poke a function in it. This means if a plugin ends up getting used we open it twice, which is especially brutal because Flash can take multiple seconds to open for me (complicated story, Adobe is working on it). It appears that Mozilla (maybe for similar reasons) caches this info across browser runs and relies on the file mtime to see when its cache has expired, much to some users' dismay: https://bugzilla.mozilla.org/show_bug.cgi?id=125469 Or at least they did in 2002. ;) For now (for test_shell) I think I'll just pay the double-load cost. The alternative is leaving plugins open, which I think wastes memory and hurts load time. At some point we'll have to look at performance and decide about the cache thing. PS: Do we scan for plugins on a background thread in the normal browser startup? If so, how do we prevent races between that scan and someone's home page requesting a plugin? --~--~-~--~~~---~--~~ 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: checkdeps failure when a unit test relies on v8.h
I thought the js debugger was out of process (or trying to be)? On Mon, Feb 16, 2009 at 1:29 PM, Marc-Antoine Ruel mar...@chromium.org wrote: the js debugger On Mon, Feb 16, 2009 at 5:53 AM, Dean McNamee de...@chromium.org wrote: What for? On Mon, Feb 16, 2009 at 12:18 AM, Erik Kay erik...@chromium.org wrote: v8 is already in the browser process. Erik On Sun, Feb 15, 2009 at 1:46 PM, Evan Martin e...@chromium.org wrote: Does this mean we'll have v8 in the browser process? We had idly chatted about running a 64-bit browser process to fix the library hell on Linux. It shouldn't block you either way -- I'm just curious. On Sun, Feb 15, 2009 at 1:42 AM, Aaron Boodman a...@chromium.org wrote: I'm trying to commit a change (http://codereview.chromium.org/19737/diff/1440/1448 ) which adds a base class for unit tests that exercise JavaScript. It uses v8.h, which is disallowed by DEPS. What is the right way to do this? - a --~--~-~--~~~---~--~~ 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 layout tests need rebaselining
I just spot checked one of these (size15) and the new image looks better than the old. I can rebaseline these quick and I will TBR you. On Sun, Feb 15, 2009 at 10:27 AM, Mark Larson (Google) m...@chromium.org wrote: I broke the following layout tests on Linux: Regressions: Unexpected failures (5): LayoutTests/fast/backgrounds/size/backgroundSize15.html = FAIL LayoutTests/fast/backgrounds/size/backgroundSize18.html = FAIL LayoutTests/fast/backgrounds/size/zero.html = FAIL LayoutTests/fast/canvas/canvas-bg.html = FAIL LayoutTests/tables/mozilla_expected_failures/marvin/backgr_position-table-column.html = FAIL I have no way to fix them. I have a linux box, but it's Ubuntu 6. The change I made puts back a change to Skia that was dropped in the merge in December. (See http://crbug.com/5564, http://src.chromium.org/viewvc/chrome?view=revrevision=9839, and the original merge at http://src.chromium.org/viewvc/chrome?view=revrevision=6925). I think these tests can just be re-baselined (since they were probably already baselined to the version of Skia on trunk). If someone with a working Linux test_shell could take care of that, it'd be great. Meanwhile, the webkit linux builder is red. 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: Passing around NativeViews between processes.
Hey Darin, The long story is pretty long, but I can explain it if you're interested in all of the details. The medium sized version: Gtk implements a non-trivial amount of code for handling the X event forwarding and management of the xembed protocol, which is how modern plugin embedding on Linux works. In order to take advantage of this code, we need a GtkWidget (in this case a GtkSocket) in the Gtk hierarchy. If we were to do things like move the backing X window directly (without asking Gtk to move it), Gtk is just going to move it back on the next layout, since Gtk is managing its position. Evan had originally implemented a custom container widget that prevent Gtk from laying out the plugin windows. However, it turned out layout is an important step, as the GtkSocket uses these events to send an expose message to the plugin. There is a balance here, the more we start trying to sidestep how Gtk wants things to be done, the more we're skipping over important code thats required and expected by the embedded plugins. I have a strategy that I think will work for plugins. It will mean that the window can be create and managed from only the same process. If the renderer needs to tell the browser to move a window, we need to move the GtkWidget, and not the X window. We can't work in X window IDs here, we need the GtkWidget* so we can move it within its parent container. We could put the X id in a map, and pull out the GtkWidget*, but then the id is arbitrary. We could also iterate over all of the plugin windows, asking for their X window id until it matches, that's an O(n) search which would probably be ok, but it's not very elegant. I believe the situation is similar on the Mac. I'm not sure the current design of passing HWNDs between processes conceptually extends beyond win32. My impression so far from a handful of conversions is there isn't a big willingness to change here. If that's the case, we will just have to come up with some hacks that allows the win32 design work on the other platforms. Thanks -- dean On Fri, Feb 13, 2009 at 4:08 AM, Darin Fisher da...@chromium.org wrote: I had assumed that NativeWindowID should just be the X window ID in our Linux build. That is what NPAPI uses (see NPWindow), and so it is what we will need to pass around. I think you can initialize a GdkWindow from a X window ID. I don't think we should worry about the case where GDK is not running on top of X :-) It would probably take some considerable work to stop passing HWNDs / X window IDs through the renderer on behalf of plugins. -Darin On Wed, Feb 11, 2009 at 6:51 AM, Dean McNamee de...@chromium.org wrote: On Windows, pretty much everything deals in HWNDs, which is an integer index into a kernel handle table. This means HWNDs, which are just integer window ids, are good across processes. The fact that all of the Windows APIs work in HWNDs, means that it is the primitive for NativeWindow and NativeView on Windows. On Linux, we have a similar concept, the X window id. However, our NativeWindow is currently a GtkWindow, and NativeView is a GtkWidget. Both a GtkWindow (this is the top level application window) and a GtkWidget can be backed by a GdkWindow, which encapsulates the X window id. Gtk is a cross-platform toolkit, which is one of the reasons you don't deal w/ the window ids directly. A recent example of this I've encountered is DidMove(WebPluginGeometry), which has a NativeView handle. This is not going to be IPC-able, as this would be a pointer to a GtkWidget instance, which obviously won't be good across processes. In order to have something that would be, we would need to do GtkWidget - GdkWindow - x window id. Then on the other side we'd have to create a new GdkWindow around the x window id. It seems we might need some new abstractions, since on Linux both NativeView and NativeWindow are pointers, not integers that are valid between processes. It seems like we need some NativeWindowId abstraction. Hey, I just looked at the code, I noticed someone added a NativeViewId type and conversion methods, so we already have the abstraction. We just need to start using them. I'm not sure this is enough security-wise though. It is scary to allow the to renderer send messages to the browser, telling it to do operations on arbitrary windows. I think this is where Adam mentioned something like HMAC, or we could do some sort of handle type thing to implement security. This might be a bit tricky, depending where the window is created an used (we have 3 processes involved, plugin, browser, and renderer). It would be nice if we could also enforce IDs per-renderer process, and not just HMAC'd to any renderer. In some of these cases, we are probably just using the HWND out of convenience so we don't have to keep state. It seems like it's probably a mess to try to duplicate the state in the browser process, but that's also one possible solution
