Re: [chromium-dev] Embedding chrome.pak in the chrome binary for Linux?
On Mon, Dec 14, 2009 at 12:02 PM, Tony Chang wrote: I have considered the possibility of moving the resources on Windows out of chrome.dll. I made a change a few weeks back that moved theme resources into chrome.dll and there was no noticeable change on the bots. I imagine moving them back out (along with chrome resources) would not slow down startup on the bots either. The benefit to doing this would be that small changes to the resources file wouldn't cause a relink, which is exceptionally painful on Windows. On Sat, Dec 12, 2009 at 9:33 PM, Satoru Takabayashi sato...@chromium.orgwrote: Evan, Thank you for the detailed feedback. It looks there won't be a much difference so I'll just forget about the idea. Thanks, Satoru On Sun, Dec 13, 2009 at 12:36 PM, Evan Martin e...@chromium.org wrote: On Sat, Dec 12, 2009 at 4:52 AM, Satoru Takabayashi sato...@chromium.org wrote: The chrome binary for Linux seems to load resource bundles from a file named chrome.pak, while the resource booundles are embedded in the chrome DLL in other platforms (correct me if I'm wrong). This makes me wonder if it's a good idea to embed chrome.pak in the chrome binary for Linux. This would save open+mmap cost (probably negligible though), and would make the package a bit simpler. I guess it can be done with objcopy, without too much work. Any thoughts? I thought about this for a while and I'm not sure there is enough of a difference either way to make it matter. It seems that having it within the executable should be nearly identical in terms of startup cost and memory usage. I guess the code might be slightly less complicated, but we already pay complexity anyway for locating the locale data, which remains separate. If I have any preference, I would prefer it either all one way (all static data embedded within the executable) or the other (all static data external to the executable). Right now we're somewhere in the middle (since ICU data is in the executable) and your proposed change also leaves us in the middle (since it would leave locale data out of the executable). There's maybe one other benefit to consider: the simpler the executable, the faster the iterative compile/link cycle will be. But again I wonder if the difference would be enough to measure, since the resources data is only 1.4mb. (The ICU data is something like 8mb, so that ought to cost more.) -- 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] Height of Personal Stuff tab in Options window
http://code.google.com/p/chromium/issues/detail?id=18949 On Tue, Dec 8, 2009 at 3:18 PM, Evan Stade est...@chromium.org wrote: With the addition of bookmark sync and form autofill, this tab is getting rather tall (see attachment, ignore the blank space above synchronize bookmarks, which is a separate bug). Do we need to move some stuff to Under the Hood, or add a scroll bar? -- Evan Stade -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev http://code.google.com/p/chromium/issues/detail?id=18949 -- 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] Height of Personal Stuff tab in Options window
I agree that this dialog should be shorter, but I think we still need an overflow solution. I can always make the display smaller or make the fonts larger. Alternately, we should pick a target minimum font size+display height and say we don't support user configurations less than that (kind of like how we set the minimum browser window size). On Tue, Dec 8, 2009 at 4:25 PM, Evan Stade est...@chromium.org wrote: On Tue, Dec 8, 2009 at 4:18 PM, Peter Kasting pkast...@google.com wrote: On Tue, Dec 8, 2009 at 4:11 PM, Evan Stade est...@chromium.org wrote: proposals on which of these options (again, see original attachment) to rip out are welcome and within the scope of this thread. Off the top of my head: * We have crazy word wrapping. The bookmark sync text could fit on one line. Why does it wrap? etc. elsewhere yes, we can save two lines in bookmark sync by removing the blank line and disallowing line wrap on the first label (although I'd guess that might force the dialog to be too wide in some locales). * What is with the blank line below that text? read original post * Show Saved Passwords button should be vertically level with offer to save passwords radio button, horizontally on right side of dialog (a la Firefox) this suggestion conflicts with the gnome hig * Save passwords/save form values could perhaps be combined into one section heading sgtm * Does the explanatory text under browsing data add much? Maybe rip it out and make the button text longer if we need clarity (Import data from another browser...) sgtm * Appearance section is a mess. Why are there buttons for GTK/Classic theme when it looks like what's desired is a radio button pair? to match windows Why are there these other options? We should decide, based on what the user's windowmanager best supports, which combo of settings will work best and just do it. We don't give Windows Aero users a button called use classic theme or Mac users a button to use the system-style (down-hanging, square-edged) tabs. not plausible. Windows and Mac have the advantage of only a single window manager, or very few WMs if you count different editions of the same WM. Linux has tons of WM and each provides a different set of functionality to the user, mostly through the window frame. We can either force all users to give up all their WM functionality (no go) or give up on the custom frame for linux altogether (no go). PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Height of Personal Stuff tab in Options window
I think the real long term goal here is to make the GTK+ theme fast and make it the default theme. Users can still add the blue classic theme via the themes page. On Tue, Dec 8, 2009 at 4:55 PM, Ben Goodger (Google) b...@chromium.orgwrote: BTW I think the Use Gtk Theme button should be replaced by a special theme that triggers this mode, much like the default theme we have in the theme gallery. This would make the selection of this mode vs. others feel more natural wrt the others. -Ben -- 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] Height of Personal Stuff tab in Options window
On Tue, Dec 8, 2009 at 5:20 PM, Elliot Glaysher e...@google.com wrote: On Tue, Dec 8, 2009 at 5:00 PM, Tony Chang t...@chromium.org wrote: I think the real long term goal here is to make the GTK+ theme fast and make it the default theme. Users can still add the blue classic theme via the themes page. I was under the impression that the long term goal was to make the GTK+ theme default *in GNOME and XFCE* once the upstream issues get fixed, with the windows theme being the default under desktop environments that weren't explicitly whitelisted (KDE, that Tcl/Tk monstrosity, etc.). Yes, you were right. Sorry, I was summarizing. In either case, the option would disappear once this happened, although I guess we still would need a GTK+ theme entry in the gallery. -- 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] new_tab_ui_warm_test is flaky
I have a change out that might make this less flaky. Hopefully. http://codereview.chromium.org/427005 On Fri, Nov 20, 2009 at 6:12 PM, Tim Steele t...@chromium.org wrote: This happened several times (at least 6) throughout the day, alternating with successful passes. It seems bad (as in an actual error, rather than a FLAKY_ test) if it actually takes more than 5 seconds for a new tab, warm or otherwise. I filed http://crbug.com/28448 as a perf regression -- not exactly sure what the protocol is as sheriff for this case. [ RUN ] NewTabUIStartupTest.PerfWarm C:\b\slave\chromium-dbg-builder\build\src\chrome\test\startup\feature_startup_test.cc(91): error: Value of: window-WaitForTabCountToBecome(3, 5000) Actual: false Expected: true [ FAILED ] NewTabUIStartupTest.PerfWarm (28016 ms) -- 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] Heads up: safely ignored regression on Linux Startup perf test
For reasons unknown to me, this line jumped back up. It seems it's because of Matt's revert: http://src.chromium.org/viewvc/chrome?view=revrevision=32524 This is a startup test, so it basically times how long it takes for LaunchApp to return. Maybe the methodology here is a bit off? On Wed, Nov 18, 2009 at 6:02 PM, Chase Phillips c...@google.com wrote: t_ref shouldn't move, though, since it was isolated from your change. Tony, I don't think there's a problem with the graph pulling the wrong numbers. I see the same difference between extension_toolstrip50 and extension_toolstrip1 when comparing the linux release hardy's graph values, the .dat file the graph code uses, and the output of the startup test itself. I thought maybe extension_toolstrip50 could be using the reference build on accident, so I verified startup_test.cc runs extension_toolstrip50 on the current build instead of the reference build (it does). Things look fine on Windows (the perf graph is what I'd expect, and running the test locally results in toolstrip50 results greater than toolstrip1). These tests don't run on Mac. We should run the tests on Linux to verify things look sane locally, too. No explanation for the odd results yet. Chase On Wed, Nov 18, 2009 at 3:08 PM, John Abd-El-Malek j...@chromium.orgwrote: I don't have an answer to that. The t_ref line didn't move either. On Wed, Nov 18, 2009 at 11:42 AM, Tony Chang t...@google.com wrote: Why didn't the black line on the linux warm perf bot change? It says that that is the extension_toolstrip50 test, which I would expect to run slower than the extension_toolstrip1 test. Maybe the graph is pulling the wrong numbers? http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150graph=warm On Wed, Nov 18, 2009 at 9:53 AM, John Abd-El-Malek j...@chromium.orgwrote: Yep, that was my plan. I'm planning on doing the same thing for the rest of the child processes, and if I see any significant changes on the perf test (which I don't expect), I'll update the reference builds again. On Wed, Nov 18, 2009 at 6:46 AM, Brett Wilson bre...@google.comwrote: On Tue, Nov 17, 2009 at 10:57 PM, Darin Fisher da...@chromium.org wrote: This sounds like goodness. Updating the reference builds is usually a good thing to do in cases like this so that new changes are easier to notice. We'll be doing this soon anyway. Al has a patch for the IPC message types running out which will break the reference build. Brett -- 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] [linux] page action extensions crashy on 4.0.237.0
If you don't run Chrome on Linux or you don't have any extensions installed, you can ignore this email. If you have any browser action extensions (like the buildbot extension or the gmail extension) installed on Linux Chrome, you may be experiencing frequent crashes when closing browser windows. A potential fix has been checked in, but until the next dev channel build is released, you can work around the crash by disabling the extension. This applies to any extension that puts a button in your browser toolbar. If you're curious: http://code.google.com/p/chromium/issues/detail?id=26751 tony --~--~-~--~~~---~--~~ 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: history.back always fires onload in chromium - is it expected?
It sounds like the test depends on the page cache being enabled so we won't be able to pass it until we support the page cache ( http://code.google.com/p/chromium/issues/detail?id=2879 ). There are a couple options: 1) Try to implement the page cache-- abarth probably has some thoughts on this. 2) Skip the test for now and mention in the bug that it depends on the page cache. 3) Try to fix the test so it at least doesn't timeout if we don't support the page cache (I guess layoutTestController.overridePreference should return an error?). We would still fail the test, but it wouldn't slow down the layout tests. I would probably just do 2 for now. On Wed, Nov 4, 2009 at 3:26 AM, Kinuko Yasuda kin...@google.com wrote: Hi chromium developers, I've been looking into a layout-test bug 20341 (http://code.google.com/p/chromium/issues/detail?id=20341) and found that in chromium history.back always fires onload() even if WebKit's page cache is enabled (== WebKitUsePageCachePreferenceKey is set true). This makes running this test (LayoutTests/loader/go-back-to-different-window-size.html) cause an infinite loop both in test_shell and chromium. In a quick glance FrameLoaderClientImpl::canCachePage() and ApplicationCacheHost::canCacheInPageCache() are hard-coded to return false (with a comment saying that we manage the cache so reporting the page as non-cacheable), making FrameLoader always go through all the page-loading steps. Seems like this behavior (calls onload on history.back or not) differs across browsers: FireFox 3: NO Safari: NO IE8: YES Is it an expected behavior or do we need some fix for it? --~--~-~--~~~---~--~~ 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: Reference build has been changed?
From the svn log: r30141 | ch...@chromium.org | 2009-10-26 18:00:16 -0700 (Mon, 26 Oct 2009) | 6 lines Update Windows reference build to r30072. BUG=25200 TEST=ref build runs locally, buildbot tests continue to work Review URL: http://codereview.chromium.org/339015 On Wed, Oct 28, 2009 at 8:14 AM, Anton Muhin ant...@chromium.org wrote: Dear chromerers, Looks like reference build (for buildbots) has been changed recently. Does anybody know exact build which is a reference now? yours, anton. --~--~-~--~~~---~--~~ 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: Why is Linux Chrome so fast?
On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth aba...@chromium.org wrote: Linux draw order: 1) Fill entire window with blue (This looks bad, can we use a different color? White?). http://code.google.com/p/chromium/issues/detail?id=20059 Looking at it again, I imagine one of the widgets has no background (TabContentsContainer?) and we just need to give it a white background. --~--~-~--~~~---~--~~ 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: new tab cold slowdown
In r28924, I made a change to the new tab tests so it the data in the history database would be recent. Because of this, the test now shows 8 most recently visited thumbnails when it was previously showing the 2 stock thumbnails. This causes a slight regression in the new tab cold times, but it's actually a new baseline. It gives us something more realistic to try to optimize. A long time ago, this is how the test was originally designed, it is a regression that we stopped showing the thumbnails in the test. tony --~--~-~--~~~---~--~~ 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: UI across multiple platforms
Also, it would be great if you found someone willing to implement the modification on other platforms if you're not going to do it yourself. This helps to get feedback early from other platforms (where the modification might not make sense) and it makes sure the bug doesn't sit there without an owner. On Wed, Oct 7, 2009 at 10:04 AM, Aaron Boodman a...@chromium.org wrote: FWIW, on extensions, what we have been finding works is to file separate bugs for each platform's UI implementation. It is just too much code to track with one bug. You end up with these mega bugs that never close. We label each bug OS-whatever the case may be - a On Wed, Oct 7, 2009 at 10:01 AM, Ben Goodger (Google) b...@chromium.org wrote: Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -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: Local State / Preferences distinction
Actually, the original distinction was stuff that could be shared across computers and stuff that couldn't be shared (i.e., local state). I think originally this was for the difference between stuff that a mounted home directory would sync and stuff that wouldn't sync. In practice, I think it's used for both, which is all the more reason to merge them. On Wed, Oct 7, 2009 at 12:46 PM, Evan Stade est...@chromium.org wrote: I was looking at http://crbug.com/19061, which is a bug Tony filed to merge the Local State and Preferences files. Both files hold user preferences, but the idea is that Local State holds prefs that are common to all user profiles, and Preferences is unique to each user (thus it is in the Default/ user profile directory). We don't actually support using multiple user profiles though, it seems. The win for combining them is to remove another file read on startup. Also, the distinction is confusing and some stuff is arguably in the wrong place (e.g. browser window dimensions are in Local State). However, the loss is that we will lose the ability to have multiple user profiles in one user data directory (don't know what our plans are for this, if any). This patch is pretty large so I'd like some feedback before starting it. -- Evan Stade --~--~-~--~~~---~--~~ 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: Local State / Preferences distinction
The quasi-defunct profile system that uses the enable-udd-profiles still has a separate Local State file and safe browsing databases because it used different user data directory (udd). This change seems orthogonal to the profile system as it is currently implemented. We can resplit the Preferences file in the future if needed (and once the actual split is clear or needed). On Wed, Oct 7, 2009 at 1:16 PM, Brett Wilson bre...@chromium.org wrote: On Wed, Oct 7, 2009 at 12:52 PM, Tony Chang t...@chromium.org wrote: Actually, the original distinction was stuff that could be shared across computers and stuff that couldn't be shared (i.e., local state). I think originally this was for the difference between stuff that a mounted home directory would sync and stuff that wouldn't sync. In practice, I think it's used for both, which is all the more reason to merge them. This comes up with the quasi-defunct profile system. Local State is supposed to be cross-profile, while the stuff in Default is your profile data. The safe browsing data in Local State should always stay with the safe browsing files, which currently stay in user-data-dir. I suspect the metrics stuff should also be cross profile. Do we need this profile support? The interface has been hidden behind a command line flag enable-udd-profiles. Is it time to rip all of this profile stuff out? 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: Changed WebKit build flags, may require clobber after sync
If you're getting linker errors about missing symbols for WebNotifications, then you're probably running gyp_chromium manually (which I think is most people using the make build or building 64 bit). To fix, add -Isrc/build/features_override.gypi to gyp_chromium (see src/DEPS where it's added to the gclient invocation of gyp_chromium). On Mon, Oct 5, 2009 at 9:11 AM, John Gregg john...@google.com wrote: Hi all, I checked in a change yesterday which sets ENABLE_NOTIFICATIONS=1 for the Chromium build of WebKit (in features_override.gypi). If you sync up and are seeing linking errors regarding notifications, this should be fixed by rebuilding WebCore. Some of the build bots seem to be fine, but others have hit this error. Thanks, -John --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: flaky resource failures
Which build was this? I checked in a change that changes how grit generates IDs. This type of change requires a clobber since I don't think we depend on all the grit .py files. I think these changes are rare enough that we can just clobber as needed. On Thu, Sep 24, 2009 at 12:03 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: We still have problems with resources, examples: [FATAL:tab_renderer.cc(132)] Check failed: waiting_animation_frames-width() % waiting_animation_frames-height() == 0. [FATAL:image_operations.cc(373)] Check failed: rgb.width() == alpha.width(). [FATAL:resource_bundle_win.cc(155)] Check failed: false. unable to find resource: 1495 [FATAL:resource_bundle_win.cc(152)] Check failed: false. unable to find resource: 1500 And of course these are intermittent. :( Can we rebuild the resources always, on Windows? I know it's going to increase the compile time. How much? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: debugging the browser started by UI tests
On Linux and mac, if you set the BROWSER_WRAPPER environment variable, it'll run that as a prefix of chrome. E.g., BROWSER_WRAPPER=xterm -e gdb --args should open a new xterm with gdb for each browser window. On Tue, Sep 22, 2009 at 3:00 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: What's the best way to attach the debugger to a browser started by a UI test? How about doing that only in case of a crash? I'm looking for solution both for Windows and Linux, so if you have good techniques, it'd be really nice. I can even document them on the wiki, but currently I'm using LOG statements when debugging the browser (I know it's not the optimal and kind of sucks, but I couldn't find a good way to attach the debugger). --~--~-~--~~~---~--~~ 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: Copying of profiles across systems
FWIW, I think this distinction is confusing without good use cases backed by tests to enforce the two separate files. I think we should just merge them for now (which would simplify the code and be one less file to read on startup) and re-split once we know what the use cases are. You could also imagine just having one file and having a json subtree provide the distinction. On Wed, Aug 26, 2009 at 1:11 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW we have two separate prefs files, Preferences and Local State to support this sort of thing in the pref system at least. Whether or not people put the right settings in the right data stores is another question. -Ben On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissmana...@google.com wrote: I've heard people proclaim the principle of being able to copy a profile across systems as being a deciding factor for certain changes (e.g. the history epoch change). However, it doesn't seem to be universally held or obeyed, and I'm not sure to the extent to which it can be obeyed. So some questions: - Is profile platform independence a guiding principle? - To what extent do we work to make it reality? - In the cases where it can't be kept (e.g. download folder path) should we keep a copy for each platform? - Is it worth rewriting today's code that doesn't conform (e.g. extensions and themes which use full paths and platform path separators)? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Creating a SkBitmap filled with one color
There's an example of how to do this with skia in src/app/resource_bundle.cc around line 146. That said, you should use cairo to paint in GTK. On Wed, Aug 26, 2009 at 4:27 PM, Dean McNamee de...@chromium.org wrote: 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: [Linux] switching from hammer to make as the default build tool
That particular bug is fixed (http://code.google.com/p/gyp/source/detail?r=559) but there are other bugs still (e.g., changes that touch grd files require running make twice to generate the right pak files). It would be good to fix these before switching to the make build on the builders. Reduced test cases and bugs on http://code.google.com/p/gyp/issues/list is the way to move this along. On Mon, Aug 17, 2009 at 3:19 PM, Lei Zhangthes...@chromium.org wrote: On Mon, Aug 17, 2009 at 3:00 PM, Antoine Labourpi...@google.com wrote: On Mon, Aug 17, 2009 at 2:07 PM, Lei Zhangthes...@chromium.org wrote: Hi, On Linux, building with make is a lot faster than build with hammer. Ever since I switched to the make build on Linux, I've never looked back. I imagine many other Linux developers are also using make, and we have been using the make build without any major problems for a few months now. So I wonder, is it time to switch our build bots to make and update the Linux build instructions? - Lei I'm all for it since that would reduce the make build breaks, but I think the dependency bug where you have to delete all your .a should be fixed first if you don't want to spend time babysitting buildbot. Antoine Is there a bug files for that? --~--~-~--~~~---~--~~ 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: Multiple outputs and errors: fail in make build
On Tue, Aug 4, 2009 at 9:25 AM, Ben Laurieb...@google.com wrote: Of course, you are also correct, in that there's a pile of dependencies make doesn't see - as I think I've said before, I'm a fan of automatic dependency extraction, which it seems grit could easily be persuaded to spit out (just as gcc can). In fact, the scons build currently does this (see tools/grit/grit/scons.py). It would probably be pretty easy to have grit also generate a .d file that lists the input dependencies when run. Then make could depend on the .d files like it does for .cc files. I think this might involve some special casing in the gyp make generator for handling gyp files. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy URL as plain text instead of HTML
Can you elaborate on how you're copying a URL from Chrome? Are you using Ctrl+C, the page menu item, or the context menu? When I use the context menu, I only get the plain text of the URL. In the other two cases, doesn't every browser paste as HTML? On Fri, Jul 31, 2009 at 10:28 AM, ptr727pieter.vilj...@gmail.com wrote: Hi This is my first post in this group, so if there is more appropriate place to post a requests like this, please let me know. I often copy and past the browser URL or link URL's in documents or emails. IE copies the URL as plain text, and when pasting the URL in a document, the pasted text has not formatting, and correctly inherits the formatting of the document. When doing the same with Chrome, it pastes the the URL as formatted HTML, messing up the font and formatting of the document. To work around this, every time I paste in Outlook or Word, I have to select the paste special menu, and select paste as text. I can think of no particular reason why the URL or a link needs to be formatted in anything other than plain text. Can the URL and link copy code please be changed to not format the text? Thank you P. --~--~-~--~~~---~--~~ 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: my patch fails compile on try servers because png file isn't updated?
The patch file doesn't include binary content. If it's just pngs, I normally just check in the new files in a separate change before doing the code change. On Fri, Jul 31, 2009 at 5:41 PM, Bradley Nelsonbradnel...@google.com wrote: I believe the tryserver doesn't take binaries. -BradN On Fri, Jul 31, 2009 at 5:40 PM, Tim Steele t...@chromium.org wrote: My patch keeps failing to compile on the try servers because the update step refuses to patch-in some .png files from the patch. I looked around and saw similar things happening to other folks on earlier reviews with .png files... Is this expected? Is there a way around it? Am I doing something wrong? Thanks Tim --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copy URL as plain text instead of HTML
I already filed a bug for this: http://code.google.com/p/chromium/issues/detail?id=18194 On Fri, Jul 31, 2009 at 7:06 PM, Evan Stadeest...@chromium.org wrote: Ah, I am eating my words. So you don't like the targets/flavors/formats we write to when copying from the omnibox, correct? If you plan to create a patch to change this, here would be the place to discuss the technical details. If you are simply requesting a change, you might be better served filing a bug at crbug.com. Personally I agree that it seems wrong to write the data as html when copying out of the omnibox, but I don't know the various formats that Windows programs expect well enough to say for sure. On Linux I think the right targets would be plain text and maybe uri list. --~--~-~--~~~---~--~~ 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-baseline producing baselines for wrong platform
This is a text only test (uses layoutTestController.dumpAsText()) so the Linux results should match windows exactly so we don't generate a Linux specific result. The test runner will fallback to the Windows result from Linux as well. You just need to verify that the results are correct on Windows and Mac (you can get these from the waterfall). On Wed, Jul 29, 2009 at 3:03 PM, Evan Martine...@chromium.org wrote: Starting with a clean tree, then running ./webkit/tools/layout_tests/run_webkit_tests.sh --debug --new-baseline LayoutTests/plugins/mouse-events.html on Linux, it seems to overwrite the Mac/Win expectations. % git ls-files --modified webkit/data/layout_tests/platform/chromium-mac/LayoutTests/plugins/mouse-events-expected.txt webkit/data/layout_tests/platform/chromium-win/LayoutTests/plugins/mouse-events-expected.txt Why? This seems very wrong. PS: It prints the following while running: 090729 15:01:01 run_webkit_tests.py:1035 INFO Placing new baselines in /work/chrome/src/webkit/data/layout_tests/platform/chromium-linux which is where I'd expect the output to go. --~--~-~--~~~---~--~~ 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-baseline producing baselines for wrong platform
Because mac doesn't have a fallback path to the windows results. So we could have put the same result file in win/linux/mac directories, but we do a small optimization and don't write the linux results because it falls back to windows results. On Wed, Jul 29, 2009 at 3:52 PM, Evan Martine...@chromium.org wrote: That sorta makes sense. But then why does it generate a mac baseline too? On Wed, Jul 29, 2009 at 3:18 PM, Tony Changt...@chromium.org wrote: This is a text only test (uses layoutTestController.dumpAsText()) so the Linux results should match windows exactly so we don't generate a Linux specific result. The test runner will fallback to the Windows result from Linux as well. You just need to verify that the results are correct on Windows and Mac (you can get these from the waterfall). On Wed, Jul 29, 2009 at 3:03 PM, Evan Martine...@chromium.org wrote: Starting with a clean tree, then running ./webkit/tools/layout_tests/run_webkit_tests.sh --debug --new-baseline LayoutTests/plugins/mouse-events.html on Linux, it seems to overwrite the Mac/Win expectations. % git ls-files --modified webkit/data/layout_tests/platform/chromium-mac/LayoutTests/plugins/mouse-events-expected.txt webkit/data/layout_tests/platform/chromium-win/LayoutTests/plugins/mouse-events-expected.txt Why? This seems very wrong. PS: It prints the following while running: 090729 15:01:01 run_webkit_tests.py:1035 INFO Placing new baselines in /work/chrome/src/webkit/data/layout_tests/platform/chromium-linux which is where I'd expect the output to go. --~--~-~--~~~---~--~~ 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: fighting the flakiness - resource bundle issues?
To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get 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: fighting the flakiness - resource bundle issues?
Look at how the current gyp hook works. It looks for changes to .gyp files and only runs if a .gyp (and maybe gypi?) file has changed. You can find what header it generates by opening the grd file and parsing the XML (the XML lists the output files). You'll need to build the base directory (e.g., Debug/obj/global_intermediate/ and the Release version), I would just check for the Windows versions since we don't seem to have this problem with the mac or linux buildbots. On Thu, Jul 23, 2009 at 5:36 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: I think that this workaround may be worth it. I'm not familiar with the IncrediBuild, but I can help making the hook (and we can run it only on Windows). How do I make a hook know which grd files changed? And also know which headers it generates? Alternatively, maybe this Windows-only hook would just delete all generated headers (with a hardcoded list)? Generation seems to be cheap, and such hook seems trivial to write. So, yes, this hook is kludgey. But we are aware of its limitations, and it would eliminate one kind of build mysteries. What do you think? On Thu, Jul 23, 2009 at 17:30, Tony Chang t...@chromium.org wrote: Here's a crappy work around: Add a gclient hook that checks for grd file changes. When a grd file changes, force delete the header it would generate. I'm pretty sure this would prevent bad builds from IncrediBuild. Alternately, maybe we can make a reduced test case and file a bug against IncrediBuild. On Thu, Jul 23, 2009 at 4:44 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Is it possible to force it to rebuild some files, or... I don't know, do you see some real way to fix this problem? On Thu, Jul 23, 2009 at 16:41, Tony Chang t...@chromium.org wrote: To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get 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: fighting the flakiness - resource bundle issues?
Here's a crappy work around: Add a gclient hook that checks for grd file changes. When a grd file changes, force delete the header it would generate. I'm pretty sure this would prevent bad builds from IncrediBuild. Alternately, maybe we can make a reduced test case and file a bug against IncrediBuild. On Thu, Jul 23, 2009 at 4:44 PM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: Is it possible to force it to rebuild some files, or... I don't know, do you see some real way to fix this problem? On Thu, Jul 23, 2009 at 16:41, Tony Chang t...@chromium.org wrote: To elaborate on Peter's comment. IncrediBuild (which the buildbots use) get confused by changes to our grd files. Our grd files generate headers, which should then cause lots of cc files to get rebuilt. Visual Studio seems to always get this right, but IncrediBuild gets this wrong and cc files don't get rebuilt. I imagine IncrediBuild is checking the timestamp of the file before the headers are re-generated and doesn't realize it needs to rebuild. On Thu, Jul 23, 2009 at 4:38 PM, Peter Kastingpkast...@google.com wrote: On Thu, Jul 23, 2009 at 4:31 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Some of the flaky failures are caused by resource bundle issues. If you are familiar with the build process, or the resource bundle, please take a look. It looks like something needed a manual clobber and didn't get 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: running layout_tests on vista and windows 7
(This time using a reply-all) We used to do this for things like faking font metrics. It resulted in lots of if (webkit_glue::IsLayoutTestMode()) code. We moved away from it because it made it made the code more complicated and meant we weren't shipping the code we were testing. I've heard it proposed before that instead of adding code to check for layout test mode, that maybe we can intercept the system calls and return controlled values (maybe the XP theme?) when in layout test mode. I'm not sure how feasible this is on Windows. On Mon, Jul 13, 2009 at 12:50 PM, Dirk Prankedpra...@google.com wrote: Hi all, (If you don't ever care to run the webkit layout tests, you can skip this note). As most of you are no doubt aware, we currently can only run the webkit layout_tests on windows XP. For some of us who primarily develop on 64-bit Vista, this is inconvenient at best, and this is only going to get worse over time as more of migrate to 64-bit machines and (eventually) Windows 7. So, I'm working on porting the layout tests to Vista. This note is a writeup of the approach I'm thinking of taking, and I'm looking for feedback and suggestions, especially since most of you have been on this code base a lot longer than me. My basic approach is to try and get something up as quickly as possible as a proof of concept, and then work to try and reduce the maintenance over time. So, I've started by cloning the chromium-win port over to vista, and modifying the test scripts to be aware of the new set of test expectations. I will then tweak the tests to get roughly the same list of tests passing on Vista as on Windows. The main differences will have to do with how the theming renders scroll bars and a few other native controls. I have most of this now, and should have the rest of this in a day or two, but this is not a maintainable solution without a lot of manual overhead. Next, we'll get a buildbot setup to run on Vista. While we're doing this, I'll start working on reducing the test set duplication between XP and Vista. The best way to do this (we currently think) will be to modify test_shell to *not* draw the native controls, but rather stub them out in a platform-independent way for test purposes (e.g., just painting a grey box instead of a real scroll bar). Then we can write a few platform-specific unit tests to ensure that the widgets do work correctly, but the bulk of the tests will become (more) platform-independent. My hope is that we'll have something that I can demonstrate here in a week or two, and that it will extend trivially to Win 7. A stretch hope is that we can even get the rendering to be platform-independent enough that we may even be able to leverage them across the linux and mac ports. I don't know if this is realistic or not, as many of the tests may differ just due to font rendering and other minor differences. An alternative strategy is to start looking at more and more of the tests and making sure they are written to be as platform-independent as possible. First we'd this by making sure that we don't rely on pixel-based tests where text-based tests would do. Another option would be to switch to writing two tests just to ensure that page A renders the same way as page B (where A and B use two different sets of layout but should produce the same output). Both of these options are significantly more work up front, but will payoff in much less maintenance down the line. Also, all of this work will also overlap with the webkit test suites, so it'll need to be coordinated with our upstream buddies. Comments? Thoughts? -- Dirk --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Rewrite of DOMUI l10n strings
What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik --~--~-~--~~~---~--~~ 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: Rewrite of DOMUI l10n strings
No objections from me-- a faster new tab page sounds great! A couple side goals to consider: - Maybe move this new js code into a pseudo protocol rather than appending the js blob into every html file. I think e.g., the devtools does this already. - It would be nice if this would some day completely replace jstemplate, but maybe that's not really worth the effort. On Wed, Jul 8, 2009 at 11:28 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:13, Tony Changt...@chromium.org wrote: What are the more advanced things that we use JST for? Off the top of my head, all I can think of is bulleted lists. jsselect - which allows iteration. This is used for bulleted lists and the like eval/switch - this is used to allowed arbitrary JS expressions but it is only used inside jsselect at the moments. I think we went with a JS solution because it seemed easier and safer at the time. I'm ok with doing string injection in the front end (i.e., a C++ HTML templating library), I'm just concerned about XSS. Is there a good existing library that would integrate well into chromium? I'm not sure. I think a small js solution is something I can do in a day or two and it will buy us about 30ms on every DOMUI page. Any objections to me going ahead with my initial plan? On Wed, Jul 8, 2009 at 11:09 AM, Erik Arvidssona...@chromium.org wrote: On Wed, Jul 8, 2009 at 11:05, Glen Murphyg...@chromium.org wrote: This time from a Chromium account: It would be nice if we didn't have to use JS and could just embed the strings live so that they could be cached, etc. Our CSS (and maybe even JS) files could use something like this, (currently we're just doing $0-$9 replacement). I'm not sure what you mean be embed the strings live so that they could be cached? This may be separate to what you're looking for. It was different from what I had in mind but maybe we should do the string injection on the front end instead of JS? What was the reason for doing it in JS in the first place? On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidssona...@chromium.org wrote: Currently we use JsTemplate (http://code.google.com/p/google-jstemplate/) to do our l10n of the DOMUI. JST has been working well but it is a bit of an overkill to do l10n of our UI. It has a couple of features that makes it slow down the UI: 1. It uses eval for every single RHS 2. It uses two nested with statements 3. It traverses the whole DOM using JavaScript It also has some advanced features like jsselect, which allows iteration, that we are using for non l10n things. My plan is to create a simpler solution, with almost exactly the same syntax that solves the 3 bullet points above. It will not allow arbitrary expressions on the RHS and it will only support jsvalues and jscontent. Instead of traversing the entire tree it ill use document.querySelector which does the tree traversal in C++ and uses CSS selectors as the matching which is a lot faster than doing the tree traversal in JS. Since there are still cases where we use JST to do more advanced templating it will still be available but it will require opt in. Any thoughts? -- erik -- erik -- erik --~--~-~--~~~---~--~~ 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: AutomationProvider for gtk?
A bunch of automation provider is compiled and works on linux/mac (it's what UI tests use). A bunch still needs to be ported (behind #ifs and some test files are not compiled). File a bug and have at it! On Tue, Jun 16, 2009 at 1:20 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: AutomationProvider::GetActiveWindow() comes from browser/automation/automation_provider.cc on windows, but common/temp_scaffolding_stubs.cc on mac and linux. Is anyone working on a real AutomationProvider implementation for 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: Makefile build broken
The make file generator has a bug. I started to work on fixing the build last night but it's not finished and I'm not sure how long it will take me this morning. I think it's a little unfair to revert even though all the buildbots are green (since there's no make buildbot and we can use the scons build instead). Alternately, if this file is not going to change often, maybe we can just check the generated file into the tree? Albert, what do you think? I estimate that about 5-7 people on the linux team use the make build these days. On Thu, Jun 11, 2009 at 8:29 AM, Adam Langleya...@chromium.org wrote: On Thu, Jun 11, 2009 at 2:39 AM, Dean McNameede...@chromium.org wrote: 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. Tony and awong were talking about this last night, but I don't know what the resolution was (I suspect none). If this is still busted: it's time to revert. Better inconvenience one person than screw up the morning for many. 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: Resurrecting the JSC build.
Kind of tangential, but having a JSC build today would mean that on linux we could build a 64bit version of chromium so we can test IMEs sooner on our 64bit workstations. On Thu, Jun 11, 2009 at 4:06 PM, Dimitri Glazkovdglaz...@google.com wrote: Team, Now that we're unforked, we want to concentrate on eliminating layout test failures. Through the magic of the WebKit merge, we've accumulated quite a few. Today, we expect around 400 failures, which is not a good number by any stretch. As one of the ways to help determine the source of the failures, I propose that we resurrect the JSC build (and builder), so that we can say with a fair degree of certainty if the cause is in the V8 bindings. Those of you who were involved in maintaining a JSC build of Chromium before may experience painful flashbacks and shortness of breath. My hope is that this time around we should have easier time, since we're unforked and the Script* abstractions are pretty well-defined to keep most of the nasties at bay. Additionally, having gyp is certainly a super-great help. Based on the IM/hallway conversation, Dave Levin, Dmitry Titov, myself and possibly a few others might be interested in helping out with the project. We don't want this to be more than a 10% effort on our parts. Since we hope to have a JSC build bot and ideally a canary bot, we may need some help from the infrastructure gods. So, do you think that resurrecting the JSC build is a: a) terrible idea b) great idea c) whatcha talking bout, Willis? :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] Re: Zygote mode on by default in Linux now. Here's how to disable it...
On Tue, Jun 9, 2009 at 7:33 AM, Dan Kegeldaniel.r.ke...@gmail.com wrote: My measurements on tab startup showed no clear effect. But http://build.chromium.org/buildbot/perf/linux-release/startup/report.html?history=150 shows that the 'startup' measurement increased by about 5ms and got quite a bit more variable. (My measurements were all with the old parentage arrangement, with the zygote as the first child, perhaps that change made a difference.) The orange line (reference build that is not affected by this change) also got slower and started bouncing around. I'm not convinced we have enough data to tell how this change impacted startup. The browser RSS seems to have gone down? http://build.chromium.org/buildbot/perf/linux-release/moz/report.html?history=150graph=vm_rss_final_b And the bytes of IO in the renderer seem to have gone down as well: http://build.chromium.org/buildbot/perf/linux-release/moz/report.html?history=150graph=total_byte_r --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: custom_deps [src/webkit/data/layout_tests/LayoutTests: None] has no effort
Be aware that it's not possible to just pick any directory and have it not synced. It only works on directories that are pulled from a different repository like src/webkit/data/layout_tests/LayoutTests. Our main repository in src/ has a lot of layout test result files in src/webkit/data/layout_tests/platform that will always get synced. On Tue, May 5, 2009 at 3:59 PM, Evan Martin e...@chromium.org wrote: On Mon, May 4, 2009 at 1:45 AM, chrome chromeorfire...@gmail.com wrote: Hi all, I trid to get the chrome source code via the gclient tools. Due to low-bandwidth, i did not want to sync the layout_tests code and added the filter line src/webkit/data/layout_tests: None, into the .gclient file. http://dev.chromium.org/developers/how-tos/get-the-code has a different path in its instructions. Is it incorrect? --~--~-~--~~~---~--~~ 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: Why are pref keys wchar_t's?
The history is that the Value type, which is the underlying data type used by PrefService used to only have wstring types. This bled into PrefService which caused PrefService to only understand wstring as keys. I'd be happy to see a patch that changed PrefService keys to std::string or char* which we DCHECK as ASCII. I'm worried that we may use user input or URLs as keys in some places and we need to encode more than ASCII in the key, but maybe we should just squash that use case (e.g., I think 'remove from NTP' uses hashes of URLs, which would work fine). tony 2009/5/1 Mike Pinkerton pinker...@chromium.org: Well, in this case they're not user-visible, so there's no reason for them to not be char*s. Unless I'm missing something obvious. On Fri, May 1, 2009 at 3:02 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: Is there a place that actually describes when it's appropriate to use which string type, and how to know if we should be fixing code we run across? Is everything just supposed to be string16? -Albert On Fri, May 1, 2009 at 11:59 AM, Evan Martin e...@chromium.org wrote: We have a bunch of places where wchar_ts still exist, and none of them are correct. I think this isn't particular instance isn't likely to b *that* much waste but it definitely would be nice to fix. I fixed command line switch names to be ASCII on the train into work once just 'cause it was bothering me. On Fri, May 1, 2009 at 11:42 AM, Mike Pinkerton pinker...@chromium.org wrote: Why are our internal pref keys all wchar_t strings? That's pretty wasteful for something the user never sees and doesn't need to be localized. It's really wasteful on Mac and Linux (32bit wchar_t). Is this on anyone's radar to fix? Should I file a bug? -- Mike Pinkerton Mac Weenie pinker...@google.com -- 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: chromium resources always rebuilding
I'm not sure this is related to the mac try servers being slow. This only causes GRIT to re-run (maybe 10s to run on all files?), but prevents .cc files from being recompiled. Mike is right that it causes null builds to be slower. I'm happy to rollback, it doesn't matter either way for me, but if we're trying to speed up the mac try slaves, this probably isn't going to help (this change has been in for almost a month). tony On Tue, Apr 28, 2009 at 8:46 AM, Mike Pinkerton pinker...@chromium.org wrote: Yes, this is certainly a direct cause of making a null build on mac take far, far longer than it should. Can we just back out Tony's change that was made in the rules to go back to the way things were in the short term? On Tue, Apr 28, 2009 at 11:31 AM, Marc-Antoine Ruel mar...@chromium.org wrote: You really should take a look ASAP because yesterday, the mac try slaves were like 35+ jobs being. That makes mac testing inexistent and will just cause more mac breakage. I assume today, tomorrow, etc will be as bad. -- 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: URLRequestMockHTTPJob?
It tries to get it from PathService::Get(chrome::DIR_TEST_DATA). Is that variable set for mac? (see chrome/browser/automation/automation_provider.cc:2117) On Tue, Apr 21, 2009 at 2:49 PM, Mike Pinkerton pinker...@chromium.orgwrote: Anyone familiar with how URLRequestMockHTTPJob is supposed to locate files? The UI tests just pass it a filename (no path, no nothing) and expect it to be found. On Mac, at least, this just ends up passing straight through so the FilePath looks like /filename.html which is clearly isn't going to find the Debug directory. It's looking for things in chrome/test/data. How does this extra mapping get done? Am I missing something obvious? -- 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: Building Chromium and running on Fedora 10
Also, can you verify that you have msttcorefonts installed in /usr/share/fonts/truetype/msttcorefonts? It's likely that the renderers are crashing because they can't find the required fonts. On Thu, Apr 16, 2009 at 12:04 PM, Adam Langley a...@chromium.org wrote: On Thu, Apr 16, 2009 at 11:34 AM, rrwinterton rrwinter...@gmail.com wrote: I have build and ran the latest (10 Apr 09) source on Ubuntu. I then tried to build and run it on Fedora 10. I was successful in building it but when I ran the binary the browser came up but the chromium splash did not show up and I was unable to browse to different sites. I believe it is a rendering problem due to incorrect links. Does anyone have any suggestions on how to get a correct build with the correct libraries on Fedora? We have a working build on Fedora. Tony might be able to give you more details. It sounds like the renderer is crashing. If you build a debug version you can run: chrome --renderer-cmd-prefix=xterm -e gdb --args to start the renderer in GDB and catch the crash. 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: Splitting an existing resource
If you no longer reference the string in code, you can just remove the string from the .grd file. On Tue, Apr 7, 2009 at 10:34 AM, Avi Drissman a...@chromium.org wrote: OK. If I don't change the contents, do I then mark the old string as DEPRECATED or something in the comments? a On Tue, Apr 7, 2009 at 1:30 PM, Tony Chang t...@chromium.org wrote: Right, but it's safe to just change it in generated_resources.grd and in code because all the other locales will just fall back to the English translation in generated_resources.grd. The magic ids won't match anymore since you changed the English string so everything will just default to the English text. On Tue, Apr 7, 2009 at 10:27 AM, Avi Drissman a...@chromium.org wrote: I don't need it immediately. I can tear apart the string at the null characters in code for now. It'd be nice to roll the strings, but that'd need to be done in coordination with code. Avi On Tue, Apr 7, 2009 at 1:23 PM, Tony Chang t...@chromium.org wrote: You can't split or change a string without going through the whole translation cycle. The canonical source of translations is in the translation console, so even if you were to change all the .xtb files by hand, your change would get clobbered the next time we pulled translations from the translation console. Do you need the translation immediately or is it ok to change the .grd file and just wait for the translations? On Tue, Apr 7, 2009 at 8:48 AM, Avi Drissman a...@chromium.org wrote: http://dev.chromium.org/developers/design-documents/ui-localizationdescribes the process of adding a resource. It goes something like this: 1. Add the key to a .grd file 2. ??? 3. Translations show up in .xtb files I need to split an existing key, though (one that is actually two strings in the first place), and that's not helpful. I need to split IDS_SAVE_PAGE_FILTER into two strings. I can change the .grd file, but all the .xtbs have some magic id number that I can't find the origin of. Now, once they're put into the generated_resources file they're matched up with the tag that the grd file had, but that's too late. What's going on here? How do I split an existing string into two without going through a whole translation cycle? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium App Executables Disk Layout
On Sat, Mar 28, 2009 at 5:35 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: On Sat, Mar 28, 2009 at 4:59 PM, Erik Kay erik...@chromium.org wrote: ...When you update in place, resources can be changed, removed, etc. So let's say that some dll hasn't been loaded yet, but then an autoupdate happens. Now you trigger loading the dll, and you crash, because this kind of forwards compatibility is never tested (nor should it be). This can happen with simple data files as well (although we don't have many of those at the moment). This is why all of the loaded code and resources are in a versioned directory (minus dictionaries, but that's a separate issue). How will in-place updating work on the Mac and Linux? For Linux, I was imagining that we'd open handles at startup to any file we'd need, and then never open any more handles after that. That way, the window during which an update could screw you would be brief (i.e. only if you started the app halfway through installation of an update could it misbehave). We looked into this more at one point and noticed that mmap doesn't make any promises when the file on disk changes. We'll probably have to use versioned directories as well to avoid problems when updating while running. --~--~-~--~~~---~--~~ 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: clobber rebuild needed
In r9193, I made a change that will require you to force rebuild your test_shell.pak file. You can either clobber your whole tree or just delete all .pak files in your Hammer dir (find Hammer -name *.pak | xargs rm) and rebuild. I will try to fix the SCons dependencies so this doesn't happen in the future. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
