Re: [chromium-dev] How to rebuild after modifying extension_api.json?
On Fri, Jan 15, 2010 at 9:57 AM, Thomas Van Lenten wrote: > Actually, it think it's sorta captured -- > chrome.gyp has chrome_resources_inputs, which is created by running a script > to figure out the input from the grd files. Looking at my xcode project, > there is a dependency on common/extensions/api/extension_api.json for the > grd files listed in chrome_resources_grds. I stand corrected! In the makefile it ends up with a layer of indirection due to grit having two outputs, so it works like this: - gen/chrome/grit/browser_resources.h depends on the .json - gen/chrome/browser_resources.pak depends on gen/chrome/grit/browser_resources.h - and then the eventual browser .pak files depend on those I would try: build once, touch, the .json file, then build again and see which piece is failing to rebuild. (Also try the same but try running the build twice in a row; there are probably still some bugs there.) -- 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] How to rebuild after modifying extension_api.json?
On Fri, Jan 15, 2010 at 9:19 AM, Dominic Mazzoni wrote: > I've observed that after modifying extension_api.json and rebuilding > on Linux (using "make" via distcc), often the entire extension api > stops working, with no error message. A clean build always solves the > problem. Is there some file I need to touch after modifying > extension_api.json in order for the correct dependencies to rebuild? $ git grep extension_api.json -- '*.gyp*' | wc -l 0 That is, this file is not ever mentioned to the build system. The problem is that a .grd file uses the .json file when building but that isn't explicitly told to gyp. In C++ we rely on the per-platform build system to figure out they do the same thing (an #include); for gyp we should just require people to keep the gyp file in sync. The place to look at fixing this is the .gyp* files where common_resources.grd is built; it should list this .json file as an input and it doesn't. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] [linux] printing webcore strings in gdb
We had a section of our wiki page with a GDB trick for printing webcore types. I just cleaned up and checked in that code. The wiki now just has the recipe on how to source this file into your GDB. It's easy, and now my GDB can display WebCore::AtomicString, UChar*, etc. as nice Unicode strings! http://code.google.com/p/chromium/wiki/LinuxDebugging#Printing_Chromium_types (You can still use commands x/10hc to inspect the UTF-16 memory values, of course.) If you have any other GDB extensions useful for Chrome, please add them to that file/directory and send them my way for review. I'm considering adding printers for e.g. Harfbuzz strings. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Setting global preferences/settings in code
On Thu, Jan 14, 2010 at 1:33 PM, Brian G. Merrell wrote: > Okay, I started looking into this. After a bit of work, I'm to the > point where I need to process the master_preferences json file. > That is, I am currently writing a ProcessMasterPreferences function > in first_run_gtk.cc. It looks like for Windows much of the work for > processing the file is done using install_util, which doesn't appear > to even be included in the build for Linux. So, I have a couple of > questions... > > What would be the preferred approach to processing the > master_preferences file in Linux? At a glance, it looks like > chrome/installer/util/master_preferences.cc might have everything > needed if it was built it for Linux, but should the parsing be done > somewhere more general and/or more portable? Documentation says > that chrome/installer has "source files and projects for making the > installer (MSI package)." I don't remember this code too well, but it sounds like perhaps processing the master preferences belongs in a shared location. Or maybe it's already in the appropriate shared location and we can build a minimal Linux installer_util library that just includes the master preferences code you want. See installer_util.gypi and chrome.gyp's mention of intaller.gyp to see where you'd need to tweak this. I'd take a look at the code that *uses* the master preferences to judge what makes sense to do here. > My other question is about the location of the master_preferences > file. In Windows, the file is required to be located in the same > directory as the chrome EXE (DIR_EXE). For Linux, I'm not sure that > this would fit. Any thoughts? It doesn't seem too terrible to me. We currently don't put any files outside of /opt for the Google Chrome packages; I guess at some point it would be nice to put data /usr/share, etc. at which point maybe it'd make sense to extend PathService to provide additional directories. But that's probably outside the scope of the change you're trying to make. > I will attach what I've come up with so far, in case someone is > interested. There are probably things I've done already that are > completely wrong :) It is tons easier to look at patches if you upload them to our review site. It's pretty easy to do; see http://www.chromium.org/developers/contributing-code if you're using svn. You can set me as the reviewer and write in your message "just looking for feedback, not ready to commit yet" and I can look there. One thing I'd consider is how this might work on the Mac. I don't think you should worry about implementing it, but I find considering how code *could* be shared helps me think of the appropriate abstraction layers and locations to implement these pieces. -- 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] seeking c++ expertise for a tiny tricky bit of code
On Wed, Jan 13, 2010 at 11:00 AM, Peter Kasting wrote: > On Wed, Jan 13, 2010 at 10:53 AM, Craig Schlenter > wrote: >> >> I'm one try-server run away from possibly turning -fno-strict-aliasing on >> for >> all linux/bsd gcc: http://codereview.chromium.org/519034 >> >> From a "process" standpoint, given that there is some disagreement here >> is someone going to come find me with a clue bat if I commit this? > > I don't think anyone will be rabid :) > That said, my comment in my prior email stands: if we're basically capable > of throwing -fstrict-aliasing for first-party code now, what do we gain by > instead throwing -fno-strict-aliasing? I would be sad to see us do this > unless it really buys us something. I believe it's just making the default setting explicit. PS: I'd be willing to flip the flag just after we do the next beta channel push and see how many more problems we get because of it. But in general, if it doesn't buy us any performance and it does cause hard-to-track-down crashes, I don't see why we should use it. The "correctness" gain doesn't buy us anything on other platforms anyway. -- 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] seeking c++ expertise for a tiny tricky bit of code
On Wed, Jan 13, 2010 at 9:22 AM, Mark Mentovai wrote: > Dan Kegel wrote: >> On Wed, Jan 13, 2010 at 9:12 AM, Stephen White >> wrote: >>> 2) Most of the supposed performance advantage of strict aliasing rules is >>> probably taken care of by memory disambiguation in modern (ie., Core2 and >>> later) CPUs. >> >> I kind of doubt that. Disallowing aliasing lets the compiler do >> a number of high-level optimizations that the chip could never do on its own. >> See e.g. >> http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html >> >> I'm for -fstrict-aliasing except for third_party. > > Me too. > > I support -fstrict-aliasing or not specifying anything explicitly (as > we presently do), and only using -fno-strict-aliasing for specific > third_party libraries that are known to need it. One argument for Stephen's side: much of our performance-critical code is in WebKit, which relies on no-strict-aliasing. At the code level I think it's not too hard for us to be aliasing correct (people like Craig have already fixed all of the places where we were wrong, and we have tools like bit_cast<> in basictypes.h to make it not too painful), so I'm not too opposed to it. But on a practical note, the default only matters on Linux with gcc 4.4, which is not a build configuration we (Google) yet use extensively, which means that we break solely but frequently for third-party builds: http://code.google.com/p/chromium/issues/list?can=1&q=strict+aliasing (note how much of those mention "fedora" or "ubuntu") With that in mind I think we should explicitly use -fno-strict-aliasing until someone is willing to take the time to run buildbots, track down regressions, etc. for the other configuration. (Consider https://bugs.webkit.org/show_bug.cgi?id=30827 as the sort of bug we've run into.) Albert has expressed some interest in getting us to use gcc 4.4 as our baseline compiler so maybe that will 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
Re: [chromium-dev] Interesting performance characteristics of http://a.qoid.us/google.html
On Tue, Jan 12, 2010 at 10:17 AM, Brett Wilson wrote: > I imagine the problems on Linux are the same as they were on Windows, > where the underlying graphics layer wants to place glyphs aligned on > pixel boundaries. This gives rounding problems and the letters jump > around. I spent several weeks making the rotations and transparency on > Windows text and form controls look good. Can you elaborate a bit on what you did? (I write this as maybe the person who will need to fight with this at some point, but practically I wonder if it'll eventually fall on 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] seeking c++ expertise for a tiny tricky bit of code
In this bug http://code.google.com/p/chromium/issues/detail?id=28749 It seems we're running afoul of a more finicky compiler not liking some tricks we're playing with objects and memory in LazyInstance. (You can skip down to comment #30 or so to get to the meat of it -- above that point we were still trying to figure out what was causing the crash.) I know enough to say that it sounds like the solution to the problem should involve placement new, but that is the extent of my C++ skill. If you are a wizard, could you take a look at the patch Craig posted on the bug (http://codereview.chromium.org/519045/show) and comment there? -- 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] Interesting performance characteristics of http://a.qoid.us/google.html
On Mon, Jan 11, 2010 at 9:04 PM, Chris Evans wrote: > The other browsers do not support the CSS used / required for this demo. > There was a similar version, but using SVG animation to do something very > similar. (It's currently offline). Firefox and Opera were able to attempt > the rotation of this one but both performed much worse that Safari and > Chrome. > Anyone know why Chrome, and to a certain extent Safari, are so much better > on this non-JS test? Is the Skia library underpinning Chrome superior? I'm not certain, but it sounds like you're comparing CSS rotations in the Chrome/Safari case and SVG rotations in the other, so I'm not sure it's a fair comparison. (Unless you mean to say Chrome/Safari were more performant for the SVG demo as well.) Two anecdotal comments: - In my experience (on Linux) Firefox had really poor SVG performance, and that (for example) canvas performs a lot better. I think none of the engines have done much work on SVG, in part because basically nobody uses it on the web except for demos like this. - Also in my experience Chrome+Skia tends to be faster but sometimes less smooth than Safari's CG. See also all of Dean's Pre3d demos. > There's also a difference between Chrome Windows and Chrome Linux. Whilst > Chrome Linux performs smoothly, the text is clearly jiggling around and even > getting more / less bold throughout the rotation cycle. Doesn't do that on > Windows. Any ideas? I don't know much about how this rotation business works, but if I had to guess from looking at it I'd say hinting is getting involved. -- 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] Where does documentation intended for non-developers go?
On Thu, Jan 7, 2010 at 7:44 PM, Nico Weber wrote:
> On Thu, Jan 7, 2010 at 5:31 PM, Evan Martin wrote:
>> On Thu, Jan 7, 2010 at 2:31 PM, Nico Weber wrote:
>>> I wrote up a document that's relevant not only for people working on
>>> chromium, but for (small parts of) the world in general ("under which
>>> circumstances does google chrome display idn urls as punycode?" I
>>> mean, who's not dying to know?).
>>>
>>> Where do documents like these go?
>>
>> We used to have a technical FAQ
>
> Where was it at?
http://dev.chromium.org/developers/faq
--
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] Where does documentation intended for non-developers go?
On Thu, Jan 7, 2010 at 2:31 PM, Nico Weber wrote:
> I wrote up a document that's relevant not only for people working on
> chromium, but for (small parts of) the world in general ("under which
> circumstances does google chrome display idn urls as punycode?" I
> mean, who's not dying to know?).
>
> Where do documents like these go?
We used to have a technical FAQ but I deleted it because it was
embarrassingly out of date ("When's the Mac port coming out?"). I
think we could profitably use one again. For example, "Why does
Chrome give a warning about .exe downloads on Linux?" is definitely a
FAQ I get.
--
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 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 " to get a Photoshop icon.
Not sure.
On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson 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
> 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
>>>
>>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy 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
Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?
On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy 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. :)
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] chromium crash when load flash plugin
On Mon, Jan 4, 2010 at 3:38 PM, Peter Kasting wrote: > On Mon, Jan 4, 2010 at 3:35 PM, if-ifone wrote: >> >> Hi: >> I build a Release chromium from latest trunk code.my Chromium always >> crash when page >> contain flash elements. >> on ubuntu 9.10 >> intel 32 >> build command >> make BUILDTYPE=Release >> and make chrome BUILDTYPE=Release > > Please file bugs on crbug.com. > In addition, if you build a binary yourself, it's pretty much your > responsibility to first debug the issue to determine it's something that > other people should care about/help with before reporting such bugs. Peter is exactly right, but it's probably http://code.google.com/p/chromium/issues/detail?id=28749 -- 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] Shockwave and Flash high CPU usage
On Sun, Jan 3, 2010 at 8:47 AM, ptr727 wrote: > Hi, don't know if this is the right group, please redirect if not. I think the best forum is the bug tracker. In general, for Flash performance, if you have (1) something that performs significantly differently in Chrome than in other browsers, and (2) reproduction steps, that is a useful bug report. In general, if the bug only happens in Chrome it's a Chrome bug, otherwise: > Does Chrome have any mechanism to help debug and report this bad > behavior to Adobe? Adobe has a bug tracker: http://bugs.adobe.com/flashplayer/ If your problem reproduces in multiple browsers that's a good place to bring it up. If it only occurs on one site, I'd bring it up with the site owner. -- 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] Any reason why we can't use Google's codesearch in chromium code base?
On Fri, Jan 1, 2010 at 10:05 AM, Mohamed Mansour wrote: > Or even something that was deleted from our current state that still exists > there: > http://www.google.com/codesearch?q=package:"http://src.chromium.org/svn/trunk/src"+kEnableWebSockets > That happens to everything. It seems it stopped indexing our source couple > of months ago (~6 or so) Ah, I see. From looking at the DEPS file (search for [webkit_trunk]) it looks like it was last updated in early October. I wonder how frequently they intend to update it... -- 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] Any reason why we can't use Google's codesearch in chromium code base?
On Fri, Jan 1, 2010 at 1:23 AM, Mohamed Mansour wrote: > Hi everyone, first I want to say Happy New Years! > For the last year, it was very easy and super fast searching the code base > of Chromium via http://www.google.com/codesearch, everything was there. > Codesearch gave us nice set of code searching tools we can use. It was > faster than grep, ack-grep, etc... If I wanted to search for a variable, all > I do "package:src.chromium.org kSomePrefVariable" and instantaneously, it > gives me the results. > For the past month or so, I rarely get any results anymore. Try searching > for something that was committed last week, even couple of month ago, you > simply can't. Does anyone internal know whats wrong? Did we block some > crawling (similar thing to what WebKit did to their repository)? > It would be nice if we can re-enable whatever we disabled. It was a nice, > well presented feature to explore Chromium's massive source code I clicked around a bit and found that package:"http://src.chromium.org/svn/trunk/src"; seems to be our source tree. I'm not sure if that counts as working or not. Maybe you can include a query that is failing that you think ought to work? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] [linux] new shm drawing code, watch for glitches
On Wed, Dec 30, 2009 at 3:21 PM, Evan Martin wrote: > On Wed, Dec 30, 2009 at 3:02 PM, Chris Evans wrote: >> I'm interested in a breakdown here. Is it dependent on X server version? >> (e.g. can you say Ubuntu version 9.10+ has it)? Or is it more subtle, >> involving exact gfx chipset and proprietary vs. X.org drivers? > > The latter, I believe. > > Build the attached program with g++ -o shm shm.cc -lXext and it will Rather: g++ -o shm shm.cc -lX11 -lXext > dump what you have. > My computer (karmic, nvidia 185.18.36, Quadro FX 380) says: > XSHM 1.1 (pixmaps: no). > -- 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] [linux] new shm drawing code, watch for glitches
On Wed, Dec 30, 2009 at 3:02 PM, Chris Evans wrote:
> I'm interested in a breakdown here. Is it dependent on X server version?
> (e.g. can you say Ubuntu version 9.10+ has it)? Or is it more subtle,
> involving exact gfx chipset and proprietary vs. X.org drivers?
The latter, I believe.
Build the attached program with g++ -o shm shm.cc -lXext and it will
dump what you have.
My computer (karmic, nvidia 185.18.36, Quadro FX 380) says:
XSHM 1.1 (pixmaps: no).
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev#include
#include
#include
int main(int argc, char* argv[]) {
Display* dpy = XOpenDisplay(NULL);
int major, minor;
Bool pixmaps;
Bool shm = XShmQueryVersion(dpy, &major, &minor, &pixmaps);
if (shm) {
printf("XSHM %d.%d (pixmaps: %s).\n", major, minor, pixmaps ? "yes" : "no");
} else {
printf("No SHM support.\n");
}
return 0;
}
[chromium-dev] [linux] new shm drawing code, watch for glitches
tl;dr I just landed a change that may improve drawing performance. Because the code path depends on the machine, it is difficult to test that I didn't break anything. Please let me know if you notice a drawing speed difference in Chrome builds after r35390/35392 (latter was a build fix for the former). Details: Previously we had two paths for drawing: 1) via shared memory pixmaps: image data -> shared memory -> copied to backing store by X server 2) slow fallback case: image data -> XImage -> serialized to X server pixmap -> copied to backing store by X server It turns out the first one has relatively weak support on existing machines. I just added one in the middle, for when the first one isn't supported: 1.5) shared memory putimage: image data -> XImage -> shared memory -> copied to pixmap by X server -> copied to backing store by X server It seems this is likely the code path that will run on most machines, and it saves a couple of serialization/copy steps, so hopefully it'll be faster. If you were to notice it you would notice it on drawing-heavy pages, like a canvas demo or some instances of Flash. -- 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] Command Line switches persisted in Preferences
On Thu, Dec 24, 2009 at 12:29 PM, Peter Kasting wrote:
> Yes: It allows/encourages people to use more command-line switches. The
> switches we have are generally for exceptional cases. If people need to use
> them regularly, we need to know about it, not simply enable even more usage.
You must use switches for a pretty common pattern ("separate profile
that goes through my work proxy") and I believe that's been wontfixed
in the past, so I'm not entirely unsympathetic to Mohamed's
suggestion, but I think Peter is right in principle.
--
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] Link error with chromium on ubuntu 9.10
On Sun, Dec 20, 2009 at 2:57 AM, Evan Martin wrote:
> On Sat, Dec 19, 2009 at 5:39 PM, Jacob Mandelson wrote:
>> Probably the OOM killer. Chrome takes a very large amount of memory to link.
>> You can add some swap, or trade a lot of link-time memory for a little
>> startup
>> delay by building shared. You can do that by putting this in your
>> ~/.gyp/include.gypi:
>> {'variables': {
>> 'library': 'shared_library',
>> }}
>
> Does this build still work? Last time I tried it it was broken again
> (something in v8...).
Two people informed me off-list that it works for them, so I guess
it's just something wrong locally. I again recommend using the shared
build if you're developing on a low-power computer. Linking is super
fast unless you're working on WebCore. :)
--
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] Recovering from browser crashes
On Tue, Dec 22, 2009 at 9:05 AM, Jim Roskind wrote: > I think it was a GIANT step forward when Chromium survived renderer crashes. > I'm not all that clear that another level of process-division would > increase robustness, and more importantly, increase customer satisfaction. I think renderer process separation was important in part because the web is very complicated: the space of allowable web pages is infinite and all of the parts are interlocking. The rest of the application is much more controllable in terms of complexity, and I think because of that the browser-side crashes we see are of a different flavor that can be pinned on bad test coverage and overly complex code. So one way to approach this is more separation of concerns at "compile time": that is, better factoring of separate modules (and fewer singletons!) that would allow more relatively independent tests. For example close to my heart: my last stab at refactoring the way we query plugins ended up running into subtle issues with how the metrics service shuts down relative to the UI and IO loops. These pieces need to talk to one another but our current system of needing to carefully puzzle through relative lifetimes, races, and refcounts doesn't seem scalable. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Setting global preferences/settings in code
On Sat, Dec 19, 2009 at 9:32 PM, cpu wrote: > Yes, the MasterPreferences is what we use so far. It is just a json > file in a particular path. I am not sure if we have enabled this for > the linux build. It hasn't. See browser_main.cc around line 540, the part that mentions ProcessMasterPreferences: http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob;f=chrome/browser/browser_main.cc;h=ff1d17d7277b5df9a9e1d901adaf326ee6c2c6ff;hb=HEAD#l539 You could probably follow the Windows implementation of ProcessMasterPreferences (see first_run_win) to make a Linux one, but it will of course be rather different. -- 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] Link error with chromium on ubuntu 9.10
On Sat, Dec 19, 2009 at 5:39 PM, Jacob Mandelson wrote:
> Probably the OOM killer. Chrome takes a very large amount of memory to link.
> You can add some swap, or trade a lot of link-time memory for a little startup
> delay by building shared. You can do that by putting this in your
> ~/.gyp/include.gypi:
> {'variables': {
> 'library': 'shared_library',
> }}
Does this build still work? Last time I tried it it was broken again
(something in v8...).
I think you need somewhere around 2gb of RAM + some swap to build.
I note the WebKitGtk hackers (who are on relatively weak laptops) will
actually close down most of the software they're using when it comes
time to link, to make more memory available. :~(
--
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] Linux 32-bit build instructions
On Sat, Dec 19, 2009 at 7:06 AM, Evan Martin wrote: > On Sat, Dec 19, 2009 at 6:59 AM, Kevin Millikin > wrote: >> I'm trying to build Linux 32-bit on 64-bit Ubuntu 8.04. >> The closest think I've found >> is http://code.google.com/p/chromium/wiki/LinuxBuild32On64 , but unless I'm >> just missing it, that doesn't seem to have actual build instructions. > > Yuck, it looks like the docs skewed. > > From the main build docs: > On a 64-bit system, set GYP_DEFINES=target_arch=x64 and regenerate the > Makefiles by doing gclient runhooks --force. > > Try setting that to ia32 instead (?) and see if that works. (Check if > gyp generates chrome/chrome.target.mk with an "-m32" flag.) If so, > can you update those docs? BTW, I expect at this point we've probably removed any hacks we used to have to make this works completely. So if some bits don't work, don't worry too much (I recall the file picker and IME) -- I assume you're probably just touching something related to v8... -- 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] Linux 32-bit build instructions
On Sat, Dec 19, 2009 at 6:59 AM, Kevin Millikin wrote: > I'm trying to build Linux 32-bit on 64-bit Ubuntu 8.04. > The closest think I've found > is http://code.google.com/p/chromium/wiki/LinuxBuild32On64 , but unless I'm > just missing it, that doesn't seem to have actual build instructions. Yuck, it looks like the docs skewed. >From the main build docs: On a 64-bit system, set GYP_DEFINES=target_arch=x64 and regenerate the Makefiles by doing gclient runhooks --force. Try setting that to ia32 instead (?) and see if that works. (Check if gyp generates chrome/chrome.target.mk with an "-m32" flag.) If so, can you update those docs? -- 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] Implementing the Chromium Webkit API
On Fri, Dec 18, 2009 at 10:32 AM, Balaji Rao wrote:
> I'm new to this list and I've joined after my discovery of the new Chromium
> WebKit API. Great work, it's awesome.
It's very new, so don't expect it to all quite work yet.
> I tried to compile a really stupid implementation (on Linux) with
> libWebKit.a, and it failed with a few thousand unresolved symbols. Using
> data from objdump, I figured out that functions annotated with WEBKIT_API
> were those in the list, which I figured out were due to '-fvisibility=false'
> being used for the static library case. Now I thought #defining WEBKIT_API
> to __attribute__ ((visibility("default"))) would help, but it didn't. I
> guess the encapsulating class needs to be annotated WEBKIT_API as well ? Can
> anyone please help me solve this ?
Something's confused here.
1) .a files are just archives of .o files, while visibility=hidden
only affects visibility beyond module boundaries.
2) -fvisibility=false doesn't exist, I assume you mean hidden (?)
> Also, I read somewhere in the webkit repo that gyp didn't support
> "shared_library" targets yet. Is it still true ? If yes, when can it be
> expected ?
gyp does support shared_library targets. Where did you read that?
> Obviously, the thing that would help me most is a sample implementation -
> which I think could exist because that there must have been an
> implementation that was grown parallel to the API itself. Is it the
> DumpRender tree ? Or the test-shell ? Can anyone please tell me where can I
> find one ?
test_shell:
http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=tree;f=webkit/tools/test_shell;h=d8c06ce190f8b2facf92162a690a647984e80c10;hb=HEAD
--
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] Running multiple Google Chrome channels side-by-side (for testing)
It's not quite the same thing, but run both Google Chrome (for the beta channel) and the Ubuntu Chromium (for testing nightly builds). You might be able to do a similar thing with one of the variants on Windows (like, say, run Google Chrome beta channel and then a more recent version of Iron). On Fri, Dec 18, 2009 at 2:36 AM, PhistucK wrote: > No (as far as I know), this was requested several times already. Would you > mind to try and give it some attention and let your friends know and help? > :) > ☆PhistucK > > > On Fri, Dec 18, 2009 at 08:27, Aaron Boodman wrote: >> >> On Windows, is there a way to hack the registry to allow multiple >> channels of Chrome to be installed simultaneously and let them update? >> It would be really useful for testing. >> >> - a >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Proposal: Accessibility extension api
(Disclaimer: I know very little about a11y.) On Wed, Dec 16, 2009 at 10:20 PM, Erik Kay wrote: > On Wed, Dec 16, 2009 at 1:15 PM, Dominic Mazzoni >> This experimental API exposes information about focused controls in the >> native ui, like dialog boxes and the location bar. Specifically, it allows >> an extension to determine the current focused control and listen to events >> such as changing focus, selecting controls, and text editing. It optionally >> allows for generating keyboard events, too. >> Existing screenreaders on Mac, Windows, and Linux do a good job of >> exposing simple dialog boxes, but a poor job of exposing complicated web >> pages. Javascript-based screenreaders can often provide much better support >> for browsing the web, but are poor at exposing the user interface of the >> browser. This solution empowers javascript-based screenreaders. >> Use cases >> 1. Build a complete screenreader as a Chrome extension, similar to the >> "FireVox" screenreader for Firefox (see http://www.firevox.clcworld.net/). >> This would enable developers to create custom accessibility solutions for >> people with all sorts of special needs, using JavaScript, that will run on >> Chrome on any platform. It's not clear to me who the intended target of this. It would seem users that already have accessibility needs will already be using the native accessibility framework, and Chrome will need to fit into that. However, clearly someone saw the need for Fire Vox so I must be missing something. >> 2. Enable pure-javascript testing of browser user-interface elements, like >> interacting with controls in a dialog box. This could potentially simplify >> some ui tests. Another way to approach this is to provide a simplified JS interface to the native accessibility libraries. That would doubly service to allow us to test our accessibility code. There's a proposal from Adobe for using the native accessibility framework for plugins (Flash), so if this goes through any API that intends to cover plugins as well will eventually need to go through the native API. (Note that this I believe this is still in the draft stage.) https://wiki.mozilla.org/Plugins:NativeAccessibility -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Tue, Dec 15, 2009 at 4:45 PM, Evan Stade wrote: > a) We don't have good support for untabbed browsing; if we really wanted to > support that we should have a --no-tabs mode which removes the tab strip and > forces NEW_TAB to NEW_WINDOW, but I don't think we want to support it. If anyone ever writes a patch for this, please send it my way. I don't think we'd commit such a patch but I'd use it locally. -- 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] [extensions] bug gardening, stable version
On Mon, Dec 14, 2009 at 6:13 PM, Aaron Boodman wrote: > I've gone through and gardened the bugs per our goals for stable: > > Win, linux: http://bit.ly/5s4lrp > Mac: http://bit.ly/8hHpdO > > Surely I'm missing some, but this should be a start. I know you had to decide to boot some stuff to make a reasonable goal set, but if you weren't aware of it, this one is needed for the "translate" extension to work, which is sorta one of the flagship extensions. http://code.google.com/p/chromium/issues/detail?id=29896 As they comment on the bug, it might not be too hard to fix, just needs someone to poke at it. BTW, if anyone takes a look at it, the language detector could use some legal love as well: http://code.google.com/p/chromium/issues/detail?id=29342 I think sidchat moved on, so there's no real owner for this stuff. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Embedding chrome.pak in the chrome binary for Linux?
On Sat, Dec 12, 2009 at 4:52 AM, Satoru Takabayashi 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
Re: [chromium-dev] Re: [chromium-reviews] Add the cmdline "-open-in-new-window" switch
On Sat, Dec 12, 2009 at 1:01 AM, Peter Kasting wrote:
> On Sat, Dec 12, 2009 at 12:54 AM, Clemens Fruhwirth
> wrote:
>>
>> http://codereview.chromium.org/464060 adds the small one-line feature
>> to open an URL in a new window from commandline
I wonder if you could hack it without a code change by converting URLs
into something like "javascript:window.open('http://myurl')" or
however that function works.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
On Fri, Dec 11, 2009 at 9:56 AM, Darin Fisher wrote: > The goal is to annoy you so you will try to stop passing these arguments. > Don't we already have other infobars possibly showing at startup (e.g., > restore tabs)? Yes. It looks a little silly -- you get two of them stacked -- but part of the point of this is that most users don't encounter it, it's only the ones doing things that we're trying to discourage. Since code speaks louder than words: http://codereview.chromium.org/490019 Screenshot: http://i.imgur.com/1mPST.png -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [WebGL] Recommending --no-sandbox
I also like the "infobar on start", especially if there's no way to say "stop bugging me" on it, so every time you start it will annoy you. I would like to bring back --single-process as well in that case. On Linux users are much more comfortable sending in stack traces etc. but trying to walk someone through getting a renderer subprocess crash into gdb is a pain; if I could say "run 'gdb --args chrome --single-process" it would save me a lot of time. On Fri, Dec 11, 2009 at 8:06 AM, Darin Fisher wrote: > I don't understand the argument for a periodic indicator. We don't have a > periodic indicator telling the user when to restart their browser to pick up > auto-updates. The only time it makes sense for the user to re-consider > the command line options is when restarting because they might have > been upgraded to a version that makes the --no-sandbox option unnecessary > for their usage. > -Darin > > On Fri, Dec 11, 2009 at 3:02 AM, PhistucK wrote: >> >> Yes, a periodic inforbar would be swell and fairly effective. in my >> opinion. >> ☆PhistucK >> >> >> On Fri, Dec 11, 2009 at 11:57, Jeremy Orlow wrote: >>> >>> On Fri, Dec 11, 2009 at 1:10 AM, Kenneth Russell >>> wrote: (Resending from chromium.org) On Thu, Dec 10, 2009 at 8:22 PM, Darin Fisher wrote: > After reading the WebGL blog post today, and following the link to the > wiki, > it struck me as fairly *bad* that we are telling people to disable the > sandbox. A good number of folks are going to disable the sandbox and > forget > that they had ever done so. I don't follow. The --no-sandbox command line argument only takes effect for the current invocation of the browser. Most people launch Chrome or Chromium from its icon, which will not have that argument associated with it. >>> >>> On Windows, the most common way for people to launch with arguments is to >>> add them to a short cut. The risk is that they'd do this to their main >>> shortcut and then forget about it. >>> > Once we can support WebGL in the sandbox, what will we do? It would > be nice > if we could somehow restore the sandbox automatically. But renaming > --no-sandbox doesn't seem like a great choice, and it isn't a scalable > solution for other things like this that come up in the future. We will just remove the --no-sandbox option from that wiki page, and people testing WebGL will eventually stop specifying it. >>> >>> _New_ users will stop specifying it, but I doubt people will be regularly >>> checking the wiki page. >>> > Perhaps --enable-webgl should instead implicitly disable the sandbox > today > so that "tomorrow," when WebGL just works, folks won't have to change > any > command line options to restore sandbox functionality. I can see a > counter > argument that people should have to explicitly opt-in to disabling the > sandbox, but I'm not sure that out-weighs the cost of having a good > number > of dev channel users running *permanently* without the sandbox. > Was this idea considered? Any other ideas? I considered this but rejected it because it might lull people into a false sense of security -- thinking that they had "just" enabled WebGL but were actually browsing without the sandbox. The best solution is to get the GPU process in place on all platforms, at which point WebGL can be run inside the sandbox; this is a high priority for me and others. >>> >>> We definitely know this is true, and I think it's even safe to assume >>> this will be true for other features in the future that only work with the >>> sandbox off initially. The problem is the time before this is true. >>> >>> As for the info bar/modal dialog: I've been thinking for a bit, and I'm >>> not sure this is enough. We have plenty of data that shows users often >>> leave browsers open for a very long time. The main risk is that someone >>> sets the flag, starts their browser, trys out the new cool feature, and then >>> leaves the browser window open...for a long time. The next time they start >>> it they'll see the warning again, but the period of time in between (that >>> they're more vulnerable) could be non-trivial. >>> The solution to this is either the annoying/scary UI can't be >>> disabled/clicked-through/etc (like a red and white striped theme that can't >>> be overridden) or to pop up a modal dialog or info bar periodically (it >>> could even be once an hour or even day) in addition to popping it up >>> initially. >>> >>> In http://code.google.com/p/chromium/issues/detail?id=24411, Finnur said >>> >>> Also, when thinking about options 1 and 2 above >>> (changing the appearance of Chrome) I can't help but think of someone >>> pitching WebGL >>> (which currently doesn't work in the sandbox) to their development team >>> and the >>> audience asking 'why is you
Re: [chromium-dev] Extensions and the Mac
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman wrote:
> If we had something like:
>
> "plugins": {
> "mac": ...
> "win": ...
> "linux": ...
> }
FWIW, one reason to avoid this sort of thing is that there is really
no single thing called "linux" to target. For example, because our
builds of Chrome off the buildbot are built against the Debian-derived
libnss so they will run on Debian and derivatives (Ubuntu, Mint) but
not any others (Fedora/SUSE/Gentoo/Arch/etc.) without hacks. (I guess
you could have the manifest say you target LSB 3.2 or something.)
Distributing binaries on Linux = sadness, as the Flash guys will tell
you.
I imagine there are similar (though smaller scale) incompatibilities
between major revs of OS X and Windows. Like say a plugin depends on
DirectX 17 which is only available on Windows 7.
In summary, all I offer you is more problems and the plea that we
should really really deter people from doing this kind of thing. I
imagine a dystopian future where we have a per-extension appsupport
matrix on the install page ("Works on x86-based ChromeOS but not
arm-based ChromeOS" or whatever).
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Splitting off some pieces of chrome.gyp...
On Thu, Dec 10, 2009 at 1:02 PM, oshima wrote: > I have similar concern about our build, in a way we handle different > configurations. > There are several ways to specify a set of files for different > configurations, such as suffic (_gtk/_mac), > "source!", "exclude"/"include", concat file lists, and I'm worrying that > it's getting out of control. I made some changes here recently to help more cleanup. The suffix rules are now all in build/common.gypi, so the per-project lists only need tweaking when the suffix rules are wrong. (In particular when ChromeOS uses / doesn't use a _gtk file is never clear to me, but that seems to be just because it's a work in progress.) -- 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't build r34152
Try pasting a subphrase of that into a search engine. :) On Wed, Dec 9, 2009 at 6:55 AM, Gary Thomas wrote: > Fedora Linux host: > > make: *** No rule to make target `third_party/yasm/source/patched-yasm/ > modules/arch/x86/gen_x86_insn.py', needed by `out/Debug/obj/gen/ > third_party/yasm/x86insns.c'. Stop. > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Is there any good tool on Linux to browser and cross reference chromium source code?
I got through my mail backlog far enough to at least file a bug on this http://code.google.com/p/chromium/issues/detail?id=29230 so you can star that for updates. On Thu, Sep 17, 2009 at 9:42 AM, <--v1c1ous--> wrote: > > I use a Search engine too: > > http://www.google.com/codesearch?hl=en&lr=&q=package:chromium.org+%s > > Or just search in site: chromium trunk in Google.com. > > -v1c1ous > > On Sep 16, 1:19 am, James Su wrote: >> Hi, >> I'm currently using cscope + vim, but it's so slow and hard to use. Is >> there any better choice? >> >> Regards >> James Su > > --~--~-~--~~~---~--~~ > 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] Modifying .gyp files
On Tue, Dec 8, 2009 at 12:23 PM, Igor Gatis wrote: > When I change a .gyp, do I need to call gyp or the build process does that > for me? If it does, how does it detect the .gyp file has been modified? On Linux, when you run "make" it will rerun gyp on your behalf if any gyp files changed. See the rule in the root Makefile that starts with "Makefile: ". -- 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] Tryconsole
On Tue, Dec 8, 2009 at 11:21 AM, Bradley Nelson wrote: > I've got a prototype summary view of the trybots up > at http://tryconsole.appspot.com/ > This will let you monitor/find your try jobs without digging through the > waterfall. > The text prompt lets you search (username / builder / change name). > The two summary graphs show load for the day, load for the hour. > I'd love suggestions on how to make this more useful. Not sure if it's exactly in this space, but it'd be nice to have the try script dump the URLs of the try servers involved. I would use this when trying a patch from someone else, so I could paste the try server URls into the code review. -- 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] Plugin Manager UI Proposal
On Mon, Dec 7, 2009 at 11:11 AM, Panayiotis wrote: > A plugin is identified by its path in the filesystem. Different paths are > considered different plugins. Can you discuss symlinks? We have to do some weird hacks in this area -- see webkit/glue/plugins/plugin_list_linux.cc and the call to AbsolutePath() there. > Once a plugin is disabled, all subsequent calls to create a plugin instance > will fail. Similarly for enabling. Pages that have the plugin already loaded > should still work. How about if multiple plugins provide the same mime type? Does disabling one cause the other to surface? For example, we currently prioritize "real" Flash over nspluginwrapper-wrapped Flash, which means that disabling just the Flash plugin will cause pages that use Flash to still use Flash but with additional bugs. -- 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] event.target is a copy of the element and doesn't validate with an equality test Options
Generally, the decision tree for this sort of thing is:
1) Does it also happen in Firefox and IE?
If yes: not a bug.
2) Does it happen in one of Firefox or IE?
If yes: probably not a bug, might wanna bring it up if the behavior
seems really broken.
3) Does it happen in Safari but not Firefox/IE?
If yes: WebKit bug. See their bug reporting guidelines:
http://webkit.org/quality/reporting.html
4) Does it happen in only Chrome, but not any of the above browsers?
If yes: file a Chrome bug.
I should put this up on the dev site somewhere. The short answer to
your question is that no, this isn't the right forum, but I can't
blame you for not knowing that. :)
On Sat, Dec 5, 2009 at 9:32 AM, nachumk wrote:
> Hi,
>
> I hope this is the right forum for this question...
> I am using Chrome Dev 4.0.249.25.
>
> I am creating a small floating menu and I want to detect when someone
> clicks outside of it. The way I detect if someone clicks out of the
> menu is by registering a window click event (window.addEvent...
> ('click')) and I test if event.target is equal to the original menu
> object (or a child of it). This worked on the Chrome beta version
> that
> I previously installed, but now with the dev version I see that the
> event is not the original event element but some type of copy that no
> longer validates with a (event.target == paramElement).
>
> sample code:
> //creating menu:
> var menu = document.createElement('div');
> myAddChildren(menu);
> window.addEventListener('click', function(event) { removeMenu(event,
> menu); }, false);
> document.body.appendChild(menu);
>
> //removing menu:
> function removeMenu(event, menu) {
> //event.target is never equal to menu even when it should be!!!
> if((event.target == menu) || (myIsChild(menu, event.target)))
> return //don't remove if click is on menu itself or a child of menu
> window.removeEventListener('click', arguments.callee.caller, false);
> document.body.removeChild(menu);
>
> I also noticed that if I add a custom variable to the menu object it
> doesn't show up under event.target when clicked. I have also verified
> that the element clicked is the actual menu as opposed to a child. I
> can verify this via the className which is set to the menu class type.
> The test that previously passed and *** should *** pass is
> (event.target == menu).
>
> The effect is that I want the menu to stay open so long as I've not
> clicked out of it. A click inside of it should keep it open. I know
> this sounds strange and it's not the way it will be in the end, but
> it's important for now.
>
> Thanx,
> nachum
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
>
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Something smells weird on the buildbot
On Thu, Dec 3, 2009 at 1:09 PM, Tei wrote: > Chromium is kind of awesome, but on my Ubuntu crash a bit too much. I > am looking forward for a stable version. Dudes!, speed the thing. Will > be this thing in the hoven for much longer? I grown impatient. This is the wrong place to bring this up. Note that non-Google builds of Chromium do not send crash reports and that we can't fix bugs we don't hear about. Please file bugs here: http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux -- 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] Information about revisions
It works for me.
Anton, are you perhaps using Linux Chrome in a locale where decimals
are written like "1,23"?
WebKit has a number of bugs in that area -- it'd be helpful to reduce
the problem you're encountering to a test case.
See e.g. https://bugs.webkit.org/show_bug.cgi?id=30342 and others.
On Wed, Dec 2, 2009 at 9:30 AM, Pam Greene wrote:
> Is anybody else seeing this problem?
> - Pam
>
> On Wed, Dec 2, 2009 at 5:53 AM, Anton Muhin wrote:
>>
>> On Tue, Dec 1, 2009 at 11:33 PM, Pam Greene wrote:
>> > Hi, Anton,
>> > Thanks for the additional information. I tried several points on that
>> > graph.
>> > They didn't show any revision information at first, but a few seconds
>> > later
>> > the frame loaded. Now I can look at other data points without any delay.
>> > Since it works sometimes, I suspect that the problem is in the network
>> > (a
>> > timeout, partial result sent, proxy error, or something of that sort),
>> > rather than an actual bug in the data file or parsing.
>> > What happens if you click the "Show Changelog" button, either with or
>> > without changing the revision range? It should (re)load the svn log for
>> > the
>> > range shown.
>>
>> Alas, nothing.
>>
>> Ok, thanks a lot for your help, Pam.
>>
>> yours,
>> anton.
>>
>> > On Tue, Dec 1, 2009 at 12:19 PM, Anton Muhin
>> > wrote:
>> >>
>> >> Good day, Pam.
>> >>
>> >> On Tue, Dec 1, 2009 at 11:13 PM, Pam Greene wrote:
>> >> > Can you be more specific? I gather you mean the revision information
>> >> > at
>> >> > the
>> >> > bottom of the performance graphs, when you select a data point on the
>> >> > graph.
>> >>
>> >> Precisely, one with SVN path, revision range, etc.
>> >>
>> >> > I just tried one at random (Page Cycle Intl1 - XP Perf) and it seems
>> >> > to
>> >> > be
>> >> > working correctly. What exactly causes this error?
>> >>
>> >> I tried
>> >>
>> >> http://build.chromium.org/buildbot/perf/xp-release-dual-core/intl1/report.html?history=150
>> >> and for several random points (in Chrome, Safari and FF) it shows no
>> >> info for revisions (inside the big test field), it shows revision
>> >> range and pages info (if I click pages on the right). For this URL I
>> >> see no errors in the log.
>> >>
>> >> yours,
>> >> anton.
>> >>
>> >> > On Tue, Dec 1, 2009 at 6:29 AM, Anton Muhin
>> >> > wrote:>>
>> >> >> Dear chromiumers,
>> >> >>
>> >> >> Relatively recently I stopped seeing information about revisions for
>> >> >> build bot graphs. If I open our debugger it reports something like:
>> >> >>
>> >> >> Uncaught TypeError: Cannot call method 'slice' of undefined.
>> >> >>
>> >> >> Line number it gives is incorrect. Most probably it should be
>> >> >> actually
>> >> >> line 50:
>> >> >>
>> >> >> function received_data(data) {
>> >> >> var tbody = document.getElementById("tbody");
>> >> >> data.replace('\r', '');
>> >> >>
>> >> >> var col_sums = [];
>> >> >> var rows = data.split('\n');
>> >> >>
>> >> >> for (var i = 0; i < rows.length; ++i) {
>> >> >> var tr = document.createElement("TR");
>> >> >>
>> >> >> var cols = rows[i].split(' ');
>> >> >>
>> >> >> // cols[0] = page name
>> >> >> // cols[1] = (mean+/-standard deviation):
>> >> >> // cols[2...] = individual runs
>> >> >>
>> >> >> // Require at least the page name and statistics.
>> >> >> if (cols.length < 2)
>> >> >> continue;
>> >> >>
>> >> >> var page = cols[0];
>> >> >> var values = cols[1].split('+/-');
>> >> >> append_column(tr, page, col_sums, -1);
>> >> >> append_column(tr, values[0].slice(1), col_sums, 0); // HERE
>> >> >> WE'RE
>> >> >> FAILING
>> >> >> append_column(tr, values[1].slice(0,-2), col_sums, 1);
>> >> >>
>> >> >> for (var j = 2; j < cols.length; ++j)
>> >> >> append_column(tr, cols[j], col_sums, j);
>> >> >>
>> >> >> tbody.appendChild(tr);
>> >> >> }
>> >> >>
>> >> >> It looks like data are returned in a wrong format. Chances are it
>> >> >> is
>> >> >> a problem with DOM or Dromaeo benchmarks, but I cannot see rev info
>> >> >> for other build bots either (e.g. Page Cycler Moz), there is no
>> >> >> exception however.
>> >> >>
>> >> >> Any ideas what goes on?
>> >> >>
>> >> >> 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 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] Design doc: Geolocation
On Tue, Dec 1, 2009 at 4:13 PM, Glen Murphy wrote: >> 1) Why green? The other infobars in the product are yellow. >> Historically, green in browsers has signaled extended validation. > > We had intended to use a few differently-colored infobars for a while, > but a more recent discussion (which got out of sync with the geo team; > my fault) has trimmed it to two - a neutral color (chrome blue) and > yellow. The latter being used for errors and warnings, the former for > more functional messages like this. What about users who are using themes? (On Mac and Linux, the neutral color is typically gray, not blue.) -- 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] Symbolized backtrace on Linux chromium?
On Mon, Nov 30, 2009 at 11:16 AM, Michael Moss wrote: >> We have a test covering this: >> ./out/Debug/base_unittests --gtest_filter=StackTrace* >> Running it locally reveals that it is broken -- but the bots still work? > > It looks like there isn't a debug builder that runs base_unittests. > It's the release build that passes. Since I (probably) broke this, I will fix it. -- 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] Use of external libICU
On Mon, Nov 30, 2009 at 9:50 AM, Mark Mentovai wrote: > nikuli...@gmail.com wrote: >> LibICU is almost ubiquitous in non microsoft OS distributions, usually >> more upstream and ahead of upstream with bugs subsequent to every ICU >> release. Also it takes a lot of time to compile. >> >> Is there any point of having it bundled? > > Our version of ICU is patched relative to the upstream version. > "Distribution" versions of ICU don't contain our patches. > > See http://crbug.com/28294 for the details. And in general, see http://code.google.com/p/chromium/wiki/LinuxPackaging for a description of which libraries we can't use from the system (ICU is on that list for the above reason). (Warning: info might be out of date, but at least I'm tryin'.) -- 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] Symbolized backtrace on Linux chromium?
On Mon, Nov 30, 2009 at 9:37 AM, Chris Bentzel wrote: > When DCHECK's trigger on my debug chromium build, I get an unsymbolized > stacktrace like > [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: > !request_. > [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: > !request_. > Backtrace: > out/Debug/chrome [0x8d7d9bc] > out/Debug/chrome [0x8d99838] > out/Debug/chrome [0x8fba726] [...] > Is there a reason I'm not getting symbols to display here? We have a test covering this: ./out/Debug/base_unittests --gtest_filter=StackTrace* Running it locally reveals that it is broken -- but the bots still work? I am confused. It was likely r32254. Maybe you can experiment with putting that flag into the Release-only section of the build/common.gypi? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: NameError: name 'ffmpeg_asm_lib' is not defined
2009/11/27 Maciej Bliziński : > The next problem: there's the /usr/bin/gcc path hardcoded somewhere: > [snip] > > sh: /usr/bin/gcc: not found > Failed to read names from file: /home/maciej/src/opencsw/pkg/chromium/ > trunk/work/build-isa-sparcv8/chromium/src/third_party/WebKit/WebCore/ > html/HTMLTagNames.in at /home/maciej/src/opencsw/pkg/chromium/trunk/ > work/build-isa-sparcv8/chromium/src/third_party/WebKit/WebCore/dom/ > make_names.pl line 213. It's printed right there. $ grep gcc third_party/WebKit/WebCore/dom/make_names.pl my $preprocessor = "/usr/bin/gcc -E -P -x c++"; It appears that make_names.pl takes a command-line argument to override that, so you might be able to hack the caller of it (try grepping the .gyp* files in third_party/WebKit). Or, if you'd like to fix it properly, open a bug with WebKit: http://bugs.webkit.org. -- 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] Warning message when running chrome in gdb
I have never encountered this. Have you tried searching for the error message? On Fri, Nov 27, 2009 at 4:31 PM, n179911 wrote: > Hi, > I am trying to run chrome under ubuntu. But I see a lot of 'internal error > in the warning message'. Can you please tell me what does those means and > how can I fix those? > Thank you. > $ gdb out/Debug/chrome > > warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in > symtab.) > warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in > symtab.) > warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in > symtab.) > warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in > symtab.) > warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in > symtab.) > warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in > symtab.) > > -- > 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] adding packages
I think you've accidentally used the wrong mailing list. Please see http://www.chromium.org/chromium-os/discussion-groups On Tue, Nov 24, 2009 at 3:45 PM, b23prodtm wrote: > HI! > I'm adding packages to my local repo. Since I've read the doc > tutorial : > http://sites.google.com/a/chromium.org/dev/chromium-os/how-tos-and-troubleshooting/add-a-new-package/package-management > I'd like to suggest a modification (no WIKI ?) to the paragraph > "Modify the package list for the chroot dev environment" > by diff'ing the package repo it could be added : >>>quote : > src/scripts/list_installed_packages.sh > /tmp/newpacks > diff -u ~/trunk/src/package_repo/repo_list_dev.txt /tmp/newpacks > > repo_list_dev.diff > make a backup : > cp src/package_repo/repo_list_dev.txt src/package_repo/ > repo_list_dev.old > patch the repo list : > patch -p0 src/package_repo/repo_list_dev.txt < repo_list_dev.diff > << > as made to patch the repo lists. > > thank you ! > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] NameError: name 'ffmpeg_asm_lib' is not defined
We currently won't build on Solaris; ffmpeg is the least of your
worries. Someone contributed patches to build on FreeBSD that might
get you closer, but the patch is enormous (~100kb, I think?) so I've
been refactoring bits of it into reviewable chunks (very slowly in my
free time).
2009/11/24 Maciej Bliziński :
> Hello chromium-dev,
>
> I've started to work on building Chromium on Solaris. I've recently
> finished completing the prerequisites (NSPR and NSS), and I'm moving
> forward with the Linux build descriptions. I'm using a tarball
> distribution. I don't run gclient sync, but gclient runhooks --
> force. The instructions say that I'm going to miss on platform-
> specific dependencies, but I guess I'm going miss on them anyway.
>
> My current problem looks as follows:
>
> mac...@netra ~/src/opencsw/pkg/chromium/trunk $ gmake build
> gmake[1]: Entering directory `/home/maciej/src/opencsw/pkg/chromium/
> trunk'
> [= NOW BUILDING: chromium-0.32797 MODULATION isa-sparcv8:
> ISA=sparcv8 =]
> [extract-modulated] complete for chromium.
> [patch-modulated] complete for chromium.
> (cd work/build-isa-sparcv8/home/chrome-svn/tarball/chromium \
> && \
> PATH=$PATH:/home/maciej/src/opencsw/pkg/chromium/trunk/
> work/build-isa-sparcv8/depot_tools:/opt/csw/gcc4/bin \
> GYP_GENERATORS=make \
> gclient runhooks --force)
>
> running '/opt/csw/bin/python src/build/gyp_chromium' in '/
> home/maciej/src/opencsw/pkg/chromium/trunk/work/build-isa-sparcv8/home/
> chrome-svn/tarball/chromium'
> Updating projects from gyp files...
> Traceback (most recent call last):
> File "src/build/gyp_chromium", line 79, in
> sys.exit(gyp.main(args))
> File "src/tools/gyp/pylib/gyp/__init__.py", line 423, in main
> params, options.check)
> File "src/tools/gyp/pylib/gyp/__init__.py", line 83, in Load
> depth, generator_input_info, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 2004, in Load
> depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 392, in
> LoadTargetBuildFile
> includes, depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 392, in
> LoadTargetBuildFile
> includes, depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 392, in
> LoadTargetBuildFile
> includes, depth, check)
> File "src/tools/gyp/pylib/gyp/input.py", line 350, in
> LoadTargetBuildFile
> build_file_path)
> File "src/tools/gyp/pylib/gyp/input.py", line 860, in
> ProcessVariablesAndConditionsInDict
> ProcessConditionsInDict(the_dict, is_late, variables, build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 737, in
> ProcessConditionsInDict
> variables, build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 886, in
> ProcessVariablesAndConditionsInDict
> build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 901, in
> ProcessVariablesAndConditionsInList
> ProcessVariablesAndConditionsInDict(item, is_late, variables,
> build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 860, in
> ProcessVariablesAndConditionsInDict
> ProcessConditionsInDict(the_dict, is_late, variables, build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 737, in
> ProcessConditionsInDict
> variables, build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 879, in
> ProcessVariablesAndConditionsInDict
> build_file, key)
> File "src/tools/gyp/pylib/gyp/input.py", line 860, in
> ProcessVariablesAndConditionsInDict
> ProcessConditionsInDict(the_dict, is_late, variables, build_file)
> File "src/tools/gyp/pylib/gyp/input.py", line 718, in
> ProcessConditionsInDict
> if eval(ast_code, {'__builtins__': None}, variables):
> File "", line 1, in
> NameError: name 'ffmpeg_asm_lib' is not defined while evaluating
> condition 'ffmpeg_asm_lib==1' in src/third_party/ffmpeg/ffmpeg.gyp
> while loading dependencies of src/media/media.gyp while loading
> dependencies of src/chrome/chrome.gyp while loading dependencies of
> src/build/all.gyp while trying to load src/build/all.gyp
> failed to run command: /opt/csw/bin/python src/build/gyp_chromium
> gmake[1]: *** [gclient-runhooks] Error 2
> gmake[1]: Leaving directory `/home/maciej/src/opencsw/pkg/chromium/
> trunk'
> gmake: *** [build-isa-sparcv8] Error 2
>
> My guess is that I need to build chromium-specific ffmpeg on Solaris
> as a prerequisite, by following src/third_party/ffmpeg/
> README.chromium. Is that correct?
>
> Maciej
>
> --
> 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] SQLite compression in history database.
Due to bugs we've seen users with 10gb history files, which may contribute to complaints. http://code.google.com/p/chromium/issues/detail?id=24947 Even if compression ends up being pretty slow, you could imagine using it for our archived history (history more than a month old). On Tue, Nov 24, 2009 at 10:21 AM, Elliot Glaysher (Chromium) wrote: > I'm all for it. I vaguely remember people complaining about the size > of our history files, and most of my history files are over 50M. > > -- Elliot > > On Tue, Nov 24, 2009 at 10:13 AM, Scott Hess wrote: >> Long ago when developing fts1, I experimented with using zlib >> compression as part of the implementation. It fell by the wayside >> because it really didn't provide enough performance improvement (I >> needed an order of magnitude, it didn't provide it), and because of >> licensing issues (fts1/2/3 are part of core SQLite, which does not >> include zlib). >> >> Chromium already has zlib, and I don't think there's any particular >> reason not to hack our version of fts to support it. Looking at my >> October history file, I get the following (numbers are in megabytes): >> >> ls -lh History\ Index\ 2009-10 >> # -rw-r--r--@ 1 shess eng 66M Nov 24 09:38 History Index 2009-10 >> .../sqlite3 History\ Index\ 2009-10 >> select >> round(sum(length(c0url)+length(c1title)+length(c2body))/1024.0/1024.0,2) >> from pages_content; >> # 34.9 >> select >> round(sum(length(compress(c0url))+length(compress(c1title))+length(compress(c2body)))/1024.0/1024.0,2) >> from pages_content; >> # 12.29 >> select round(sum(length(block))/1024.0/1024.0,2) from pages_segments; >> # 24.6 >> select round(sum(length(compress(block)))/1024.0/1024.0,2) from >> pages_segments; >> # 14.3 >> >> pages_segments is the fts index. Since it is consulted very >> frequently, I'd be slightly nervous about compressing it. >> pages_content is the document data, which is hit after the index (or >> when doing a lookup by document id), so compressing it shouldn't have >> much performance impact. >> >> Does this seem like a win worth pursuing? >> >> -scott >> >> -- >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How can I remove .o objects in linux
On Sun, Nov 22, 2009 at 1:43 PM, Antoine Labour wrote: > On Sun, Nov 22, 2009 at 1:35 PM, Adam Langley wrote: >> >> On Sun, Nov 22, 2009 at 1:23 PM, hap 497 wrote: >> > Can you please tell me how can I remove all .o after the build? >> > I tried 'make clean', but it said there is no 'clean' target'. >> >> % find out -type f -name "*.o" | xargs rm > > Note that all .o go into the build directory, 'out', that you can simply > wipe. I would LGTM a gyp patch that aliases "make clean" to "rm -rf out". -- 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] whitlisting compilers for -Werror
On Sat, Nov 21, 2009 at 11:59 AM, Peter Kasting wrote: > There is another fix, which is to disable to warning within the file or > globally for GCC versions less than X. GCC exposes a number of different > macros and switches that let you determine the version precisely either from > script or in the preprocessor, and we already have a file that holds > compiler-specific magic. > The reason this would be nice compared to the whitelist proposal is that it > wouldn't produce false negatives. The assumption is that there are only a > small number of these kinds of cases, so enumerating them is not going to do > awful things to our code. This works for warnings we know about now, but not warnings that will occur in the future, which is the larger problem. I'd say we break the automated Ubuntu builds every couple of weeks (and get an additional report from users at about that same rate). -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] whitlisting compilers for -Werror
On Sat, Nov 21, 2009 at 7:21 AM, rahul wrote:
>>I happen to find this warning very useful, just as I find our policy
>>to make warnings hard errors in our own code helpful.
> Yes, of course. That's a good practice. But what about the end-users
> who have to deal with warnings as hard errors.
I have been meaning to bring this up again. I think I proposed this
before but was shot down.
We should whitelist known compiler versions that build successfully
with -Werror, and then turn it off for the rest. Unless we have a
buildbot tracking a given compiler version, it is likely that -Werror
makes us unable to build with that version of the compiler.
Concrete proposal:
- whitelist the compiler version used on our buildbots to always use -Werror
- turn off -Werror by default on other compilers
- make it easy to turn on -Werror back on if someone wants to fight
some warnings
I have been particularly frustrated with gcc warning bugs that have
been fixed in newer versions of gcc. In older gccs, the following
code produces a "variable may be used uninitialized" warning depending
on your optimization settings.
int x;
{ x = 3; }
printf("%d\n", x);
The fix is to put in a redundant initialization of x, but people
(reasonably) will remove them when working on the code.
Here's a patch I've been working on to add these redundant initializers:
http://build.chromium.org/buildbot/try-server/builders/linux/builds/9235/steps/gclient/logs/patch
Smarter compilers already recognize the existing code is correct, but gcc warns.
Some example changes I have made in this area recently:
"This is needed to work around a gcc bug when building with -Os."
(on the older gcc 4.3 only)
http://src.chromium.org/viewvc/chrome?view=rev&revision=32186
"fix a warning in the process_util unittest" (that only came up on
fta's build, not on our builds on ghardy or karmic)
http://src.chromium.org/viewvc/chrome?view=rev&revision=32648
--
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] gcl upload error
A guess, but it looks like it's attempting to find your email address out of your SVN authorization data, and that the computer you're on has no SVN auth data. Try something like "svn ls --username=mycommitern...@chromium.org svn://..." and log in if it prompts you. On Sat, Nov 21, 2009 at 12:46 AM, Munjal Doshi wrote: > I get the following error when running gcl upload when it tries to send the > job to try server after successfully uploading files: > Traceback (most recent call last): > File "C:\Tools\depot_tools\gcl.py", line 1273, in ? > sys.exit(main()) > File "C:\Tools\depot_tools\gcl.py", line 1244, in main > UploadCL(change_info, argv[3:]) > File "C:\Tools\depot_tools\gcl.py", line 865, in UploadCL > TryChange(change_info, trychange_args, swallow_exception=True) > File "C:\Tools\depot_tools\gcl.py", line 901, in TryChange > prog='gcl try') > File "C:\Tools\depot_tools\trychange.py", line 526, in TryChange > options.scm.ProcessOptions() > File "C:\Tools\depot_tools\trychange.py", line 177, in ProcessOptions > self.options.email = scm.SVN.GetEmail(gcl.GetRepositoryRoot()) > File "C:\Tools\depot_tools\scm.py", line 450, in GetEmail > for credfile in os.listdir(auth_dir): > WindowsError: [Errno 3] The system cannot find the path specified: > 'C:\\Users\\munjal\\AppData\\Roaming\\auth\\svn.simpl > e/*.*' > Does anyone know what hte problem is? > -Munjal > > -- > 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] class has virtual method but non-virtual destructor
On Fri, Nov 20, 2009 at 4:23 AM, rahul wrote: > I was trying to compile chromium today on Linux and I got this error. > This error occurred because of -Werror CFLAG set in the Makefile. I > remedied by writing a one-liner to delete all occurrences of -Werror > from CFLAGS in all Makefiles. > > However, this error intrigued me. I saw through the code and the > classes in question have declared virtual methods but haven't declared > a destructor. In that case, the compiler generates the destructor. > > > Base *b = new Sub(); > delete b; > > To the best of my knowledge, if Base is the class which defines > virtual methods but non-virtual destructor, delete can cause a memory > leak if Sub happens to be taking more memory than Base. I think that > the destructor for a class with virtual methods has either to be > "public virtual" or "protected non-virtual" for the proper freeing of > memory. > > > Would someone help me clarify this? > > I know there might be some scenarios where this can be done > intentionally but looks like there are more arguments for adding a > virtual destructor than not adding one. I see that this is done for > the Delegates. Also, if this is one of the intended special cases, can > someone explain how to compile chromium then? Deleting -Werror from > CFLAGS is an ugly hack at best. Your analysis is correct. However, a virtual destructor is not needed in the case where you never delete through the Base*. It turns out for our codebase that is very common (due to lots of "observer"-like patterns), so we decided to not rely on this compiler warning. It's only caused horrible bugs once or twice! :) The correct fix would be to disable this particular warning in build/common.gypi. However, I'm puzzled why nobody else has encountered the problem you're mentioning. Can you provide some details about your compiler, system configuration, etc.? -- 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] Some people still making new toolstrip-based extensions
On Thu, Nov 19, 2009 at 5:58 PM, Aaron Boodman wrote: > We're going to have to explain again when we actually remove > toolstrips, because some people won't have seen the first announcement > (understandably): > > http://www.guyvider.com/2009/11/i-love-chrome-extensions.html It wouldn't be too hard to cook up a patch that makes all toolstrips contain "WARNING: Toolstrips will be removed soon, migrate your extensions" before the extensions are displayed. After all, part of the reason to remove them is because they have all of that extra empty space... -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] StringPrintf and friends are now checked
GCC-compiled code (Mac/Linux) will now warn / fail to compile if you
pass the wrong types to our printf-like functions (StringPrintf,
etc.). This would have caught at least two bugs I've seen in the
past.
There is one twist to be aware of if you haven't seen it before. The
% format specifiers for printing int64s and size_ts vary between
platforms, so they are wrapped in macros from C99.
See base/format_macros.h. In brief, there are macros starting with
PRI that can be interpolated into format strings.
E.g.:
printf("This is a percent-x-styled int64: %" PRIx64 "\n", my_int64);
If you run into any trouble feel free to ping me for help. If you
develop on Windows, this checking will frequently only manifest as
trybot warnings, so please be careful.
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] user-contributed translations
I persistently get questions from users wanting to provide localization for Chrome. I believe our answer is that we don't accept user-contributed translations. Is there a FAQ somewhere I can link these users to? Where would such a FAQ belong? Also, another option for these users is to write their own translations and let downstream (Chromium distributors) ship them. For example, note the hundreds of translations in Ubuntu: https://translations.launchpad.net/ubuntu/karmic/+translations Does anyone have pointers on how they might be able to set up these translations? -- 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] support for WATCHLISTS in git-cl
On Thu, Nov 19, 2009 at 12:56 PM, Paweł Hajdan Jr. wrote: > It turns out that WATCHLISTS aren't fully effective because git-cl doesn't > support them. It doesn't look very hard to implement the support for git-cl > because there is already a watchlists.py file, but then there are some > questions: > - should the watchlists.py file (from depot_tools) be copied to the git-cl > repo or should git-cl try to locate it (upload.py is copied) Can we hook it into the PRESUBMIT script instead? That seems cleaner to me. > - should watchlists.py be integrated into upload.py (probably not)? The metric I use is: is this something used by other users of git-cl? I think watchlists are not. -- 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] huge binary drop of native client code
On Wed, Nov 18, 2009 at 4:43 PM, Bradley Nelson wrote: > Backing things out shortly. No rush; if you need the code, it's ok. (It'd be nice if you used deps_os though.) > It didn't break nacl's trybots or waterfall because they're less pared down, > and probably got thru a try job on mac by chance on the DEPs roll. > I think the right way to avoid this in the future would be a common source > size check in both nacl and chrome's PRESUBMIT.py > I'll add such a thing shortly. Thank you! -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] huge binary drop of native client code
It seems someone (not blaming them in particular) checked in 300mb of Windows 64 binaries in the native client tree. This check-in also seems to have hosed the trybots (they time out while attempting to fetch this data). A /b/slave/linux/build/src/native_client/src/third_party/mingw-w64/mingw-w64-src_20091116.tar.bz2 command timed out: 300 seconds without output, killing pid 15342 elapsedTime=978.505349 update failed, trying 4 more times after 300 seconds Rather than the obvious rant, I'd like to start a thread on something constructive: What can we do to protect our tree from this sort of thing in the future? - Do we need a trybot for NaCL trunk like we do for WebKit? - Would presubmit scripts help? (I guess that won't help since they're in DEPS?) - Could a style guide that prohibits checking in large binaries help reviewers catch this? - Any other ideas? -- 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] building without svg
On Tue, Nov 17, 2009 at 10:49 AM, Jonathan Dixon wrote: > This is tangential to the core of your question, but just to check, are > asserts disabled on linux release builds? This is a good thing to check! But it looks like they are. > There are numerous calls to ASSERT within the templated functions in > SVGAnimateedProperty so it seems they could easily blow up the binary size > if the template is instantiated many times. Eric the SVG master was not surprised this file shows up; he says it is all templates and is instantiated once per property in SVG. On the other hand, he fairly points out that maybe there are other bits to worry about first. I was hoping there was some low hanging fruit. (I am still suspicious of logging.h.) I am investigating further more and will post again once I have some better results. -- 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 matrix-view perf dashboard
On Mon, Nov 16, 2009 at 4:05 PM, Steven Knight wrote: > Let me know if you notice any problems or have any suggestions for making > this more useful. I've noticed it's basically impossible to load this page over a moderately fast internet connection because of the quantity of data displayed. I see 13*19 = 117 iframes, each with HTML and a large JSON data file to load. It'd be nice if there was a view that showed some higher-level overviews that let you drill down. Even splitting it by OS would be handy. -- 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] building without svg
You're off by a digit -- read only data is 2mb. On Mon, Nov 16, 2009 at 3:27 PM, Eric Seidel wrote: > Yay data! Thank you Evan. > > If I'm reading your email correctly, your script can only account for > 3MB (7.5%) of our binary. :( 26.5MB (67%) is unknown to your script > and 20MB of what nm does see is labeled "read only data". Of the 3MB > nm does understand, 700K (1.7% of the total final binary) is > SVGAnimatedProperty.h. > > Seems like we need to know where the other 92.5% of our binary is > going before we take action against specific files. > > -eric > > On Mon, Nov 16, 2009 at 12:33 AM, Evan Martin wrote: >> I spent some quality time with nm. With it I can take a release >> binary (so all the inlining and optimizations like dead code removal >> have been done) and display symbol sizes as well as which file they're >> from. >> >> My Release Linux build stripped is 39.5mb. (The size bots show ~44mb, >> which I think is a Chrome vs Chromium thing. It is curious how the >> Windows binary is nearly half the size of the Linux or Mac one.) >> >> My hacky script managed to total up stats for only 23mb of the binary. >> I'm not sure where the rest is going but it could be the ICU data >> tables or even just references to external functions in shared >> objects. >> >> Below are the top offenders, in bytes, contributing to binary size >> (recall again that this is a release build), as measured by how nm >> attributes symbols to source files. Note that it didn't attribute a >> bunch of code (for reasons I don't understand) and those are summed in >> the plain "code" entry below. >> >> And like I had guessed, SVG at the top! I promise I didn't cook these >> to confirm my own hypothesis. Also note that much of the rest is >> template-heavy code -- I was surprised to see logging.h scores almost >> 100kb. >> >> 2043226 read only data >> 762291 third_party/WebKit/WebCore/svg/SVGAnimatedProperty.h >> 394334 /usr/include/c++/4.4/bits/vector.tcc >> 270298 /usr/include/c++/4.4/bits/stl_tree.h >> 262889 uninitialized data >> 230389 code >> 196369 ./base/task.h >> 187574 third_party/WebKit/JavaScriptCore/wtf/HashTable.h >> 184647 third_party/WebKit/JavaScriptCore/wtf/HashMap.h >> 157126 ./ipc/ipc_message_utils.h >> 140424 v8/src/x64/codegen-x64.cc >> 136807 third_party/libxml/xmlschemas.c >> 117240 third_party/WebKit/WebCore/css/CSSStyleSelector.cpp >> 113895 v8/src/runtime.cc >> 103056 chrome/renderer/render_view.cc >> 97702 ./base/logging.h >> 95653 third_party/glew/src/glew.c >> 95389 third_party/libxml/parser.c >> 89488 /usr/include/c++/4.4/bits/stl_algo.h >> 84431 third_party/WebKit/JavaScriptCore/wtf/Vector.h >> 83865 v8/src/objects.cc >> 82528 third_party/icu/source/common/uchar_props_data.c >> 82042 third_party/WebKit/WebCore/css/CSSParser.cpp >> 81699 third_party/WebKit/WebCore/dom/Document.cpp >> 79284 third_party/libxml/xpath.c >> 73821 third_party/icu/source/i18n/ucol.cpp >> 73796 third_party/WebKit/WebCore/rendering/RenderBlock.cpp >> 68578 third_party/WebKit/WebCore/loader/FrameLoader.cpp >> 59865 third_party/libxml/HTMLparser.c >> 59048 third_party/WebKit/WebCore/svg/SVGAnimatedTemplate.h >> 58057 third_party/libxml/relaxng.c >> 57535 >> out/Release/obj/gen/protoc_out/chrome/browser/sync/protocol/sync.pb.cc >> 56253 v8/src/parser.cc >> 56000 third_party/icu/source/i18n/decimfmt.cpp >> 54954 global ctors >> 51952 v8/src/api.cc >> >> >> On Fri, Nov 13, 2009 at 2:39 PM, Evan Martin wrote: >>> We track total binary size here: >>> http://build.chromium.org/buildbot/perf/dashboard/sizes.html >>> >>> I don't know of any place we track per-module sizes. >>> >>> On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel wrote: >>>> Do we have any hard data about where our binary size goes? It seems >>>> such data would be very useful. >>>> >>>> On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin wrote: >>>>> I measured that SVG is nearly a sixth of the binary size of a Chrome >>>>> debug build. That's not only more compile time, it's also more link >>>>> time for each incremental link and more time for the debugger to grind >>>>> it when starting gdb. For my day-to-day debugging I would like to >>>>> build without SVG (and many other bits, but let's start with SVG). >>>>&
Re: [chromium-dev] building without svg
I spent some quality time with nm. With it I can take a release binary (so all the inlining and optimizations like dead code removal have been done) and display symbol sizes as well as which file they're from. My Release Linux build stripped is 39.5mb. (The size bots show ~44mb, which I think is a Chrome vs Chromium thing. It is curious how the Windows binary is nearly half the size of the Linux or Mac one.) My hacky script managed to total up stats for only 23mb of the binary. I'm not sure where the rest is going but it could be the ICU data tables or even just references to external functions in shared objects. Below are the top offenders, in bytes, contributing to binary size (recall again that this is a release build), as measured by how nm attributes symbols to source files. Note that it didn't attribute a bunch of code (for reasons I don't understand) and those are summed in the plain "code" entry below. And like I had guessed, SVG at the top! I promise I didn't cook these to confirm my own hypothesis. Also note that much of the rest is template-heavy code -- I was surprised to see logging.h scores almost 100kb. 2043226 read only data 762291 third_party/WebKit/WebCore/svg/SVGAnimatedProperty.h 394334 /usr/include/c++/4.4/bits/vector.tcc 270298 /usr/include/c++/4.4/bits/stl_tree.h 262889 uninitialized data 230389 code 196369 ./base/task.h 187574 third_party/WebKit/JavaScriptCore/wtf/HashTable.h 184647 third_party/WebKit/JavaScriptCore/wtf/HashMap.h 157126 ./ipc/ipc_message_utils.h 140424 v8/src/x64/codegen-x64.cc 136807 third_party/libxml/xmlschemas.c 117240 third_party/WebKit/WebCore/css/CSSStyleSelector.cpp 113895 v8/src/runtime.cc 103056 chrome/renderer/render_view.cc 97702 ./base/logging.h 95653 third_party/glew/src/glew.c 95389 third_party/libxml/parser.c 89488 /usr/include/c++/4.4/bits/stl_algo.h 84431 third_party/WebKit/JavaScriptCore/wtf/Vector.h 83865 v8/src/objects.cc 82528 third_party/icu/source/common/uchar_props_data.c 82042 third_party/WebKit/WebCore/css/CSSParser.cpp 81699 third_party/WebKit/WebCore/dom/Document.cpp 79284 third_party/libxml/xpath.c 73821 third_party/icu/source/i18n/ucol.cpp 73796 third_party/WebKit/WebCore/rendering/RenderBlock.cpp 68578 third_party/WebKit/WebCore/loader/FrameLoader.cpp 59865 third_party/libxml/HTMLparser.c 59048 third_party/WebKit/WebCore/svg/SVGAnimatedTemplate.h 58057 third_party/libxml/relaxng.c 57535 out/Release/obj/gen/protoc_out/chrome/browser/sync/protocol/sync.pb.cc 56253 v8/src/parser.cc 56000 third_party/icu/source/i18n/decimfmt.cpp 54954 global ctors 51952 v8/src/api.cc On Fri, Nov 13, 2009 at 2:39 PM, Evan Martin wrote: > We track total binary size here: > http://build.chromium.org/buildbot/perf/dashboard/sizes.html > > I don't know of any place we track per-module sizes. > > On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel wrote: >> Do we have any hard data about where our binary size goes? It seems >> such data would be very useful. >> >> On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin wrote: >>> I measured that SVG is nearly a sixth of the binary size of a Chrome >>> debug build. That's not only more compile time, it's also more link >>> time for each incremental link and more time for the debugger to grind >>> it when starting gdb. For my day-to-day debugging I would like to >>> build without SVG (and many other bits, but let's start with SVG). >>> >>> I put on one obvious patch and one patch I'm not sure about at >>> https://bugs.webkit.org/show_bug.cgi?id=31490 >>> >>> Does anyone have thoughts about the right way to disable SVG in the GYP >>> files? >>> Here's the hacky second patch mentioned above: >>> https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196 >>> In particular, I'm not sure of the right way to conditionally build >>> the SVGNames bits. >>> >>> I've seen in some cases files are completely wrapped with "#if >>> ENABLE(FOO)"; do you know when that is appropriate? >>> >>> -- >>> 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] building without svg
We track total binary size here: http://build.chromium.org/buildbot/perf/dashboard/sizes.html I don't know of any place we track per-module sizes. On Fri, Nov 13, 2009 at 2:33 PM, Eric Seidel wrote: > Do we have any hard data about where our binary size goes? It seems > such data would be very useful. > > On Fri, Nov 13, 2009 at 2:14 PM, Evan Martin wrote: >> I measured that SVG is nearly a sixth of the binary size of a Chrome >> debug build. That's not only more compile time, it's also more link >> time for each incremental link and more time for the debugger to grind >> it when starting gdb. For my day-to-day debugging I would like to >> build without SVG (and many other bits, but let's start with SVG). >> >> I put on one obvious patch and one patch I'm not sure about at >> https://bugs.webkit.org/show_bug.cgi?id=31490 >> >> Does anyone have thoughts about the right way to disable SVG in the GYP >> files? >> Here's the hacky second patch mentioned above: >> https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196 >> In particular, I'm not sure of the right way to conditionally build >> the SVGNames bits. >> >> I've seen in some cases files are completely wrapped with "#if >> ENABLE(FOO)"; do you know when that is appropriate? >> >> -- >> 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] building without svg
I measured that SVG is nearly a sixth of the binary size of a Chrome debug build. That's not only more compile time, it's also more link time for each incremental link and more time for the debugger to grind it when starting gdb. For my day-to-day debugging I would like to build without SVG (and many other bits, but let's start with SVG). I put on one obvious patch and one patch I'm not sure about at https://bugs.webkit.org/show_bug.cgi?id=31490 Does anyone have thoughts about the right way to disable SVG in the GYP files? Here's the hacky second patch mentioned above: https://bug-31490-attachments.webkit.org/attachment.cgi?id=43196 In particular, I'm not sure of the right way to conditionally build the SVGNames bits. I've seen in some cases files are completely wrapped with "#if ENABLE(FOO)"; do you know when that is appropriate? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: refactoring and git
On Fri, Nov 6, 2009 at 10:50 AM, Yaar Schnitman wrote:
> Git is totally confusing my renames and new files. Take a look:
> .../{WebSearchableFormData.h => WebElement.h} | 49 -
> webkit/api/public/WebSearchableFormData.h | 4 +-
> webkit/api/public/{WebNode.h => WebInputElement.h} | 51 --
> webkit/api/public/WebNode.h | 39 ++--
> ...sswordAutocompleteListener.h => WebElement.cpp} | 33 ---
> .../WebPasswordAutocompleteListener.h} | 14 ++-
> .../api/src/{WebNode.cpp => WebInputElement.cpp} | 56 +--
> webkit/api/src/WebNode.cpp | 14 +++
> And I didn't even move or deleted the files that git thinks I renamed (e.g.
> WebNode.h is alive and well).
> Is there any way to fix that?
> Will it actually create that mess in svn too
> when I git cl dcommit? I did mess up git cl upload...
In general, yes. I don't know your particular problem but I agree
"something looks messed up".
--
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-developer] Coping with configurations differences in sources
On Mon, Nov 9, 2009 at 6:38 PM, Bradley Nelson wrote: > Currently they are porting base + app to 64-bit for windows. > They only need a limited subset of functionality for nacl, so they have only > made some source files 64-bit clean. > They would like to simply disable the rest for 64-bit (at least for now). We are 64-bit clean on Linux; I would expect much of base is shared? My recollection is it only took Dean (and Joel?) a week or two to get us the rest of the way to 64-bit clean. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: 437k files checked out for an official build
BTW, the trick I always use for deleting directories on Windows 'cause it's so slow is: mv dirname foo; rm -rf foo & that way you can start your build or whatever again immediately, because the target directory is "gone" immediately. On Tue, Nov 10, 2009 at 10:39 AM, Evan Martin wrote: > Note in Anthony's mail he said he was clobbering the build directory, > not the checkout. > > I do not have very many files in my build directories: > > $ find Debug | wc -l > 10499 > $ find Release | wc -l > 10290 > > I think this is not "we have a lot of files because we do a lot of > stuff" but rather that something has gone horribly wrong. > Anthony, did you happen to notice any large collections of files that > were in the delete list? > > On Mon, Nov 9, 2009 at 6:41 PM, Thomas Van Lenten > wrote: >> Right, but the builds need these files to run the tests to make sure the >> bits are good. >> The problem is some tests leave logs and such in the tree after running, if >> we could ensure nothing changes in the tree, we might be able to change the >> scripts to simply update. Or maybe we do the same gclient revert the >> trybots do to make sure it is a completely clean tree for the build. >> TVL >> >> >> On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow wrote: >>> >>> This is related to the thread (last Friday?) about making a light weight >>> checkout of Chromium the default. >>> Btw a quick look indicates that 100k are Google specific files (hermetic >>> build environment and such). 200k are layout tests. So that leaves "only" >>> 150k filesprobably many of which are still test related. >>> On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge >>> wrote: >>>> >>>> Howdy, >>>> Was just clobbering a build directory this morning, and noticed it was >>>> deleting ~437 thousand files from a single Chrome official windows build >>>> directory, which took approximately 20-30 minutes to do a delete. Perhaps >>>> my view isn't oriented correctly, but this seems like a very high number of >>>> files. This isn't a high priority issue for the 4.0 timeframe, indeed may >>>> not be a high priority issue at all, but I'd like to turn it over to our >>>> developer community to see if anyone has any thoughts on the matter. So w/ >>>> that... >>>> Kind Regards, >>>> >>>> Anthony Laforge >>>> Technical Program Manager >>>> Mountain View, CA >>>> >>>> >>> >>> >>> >> >> >> --~--~-~--~~~---~--~~ >> Chromium Developers mailing list: chromium-dev@googlegroups.com >> View archives, change email options, or unsubscribe: >> http://groups.google.com/group/chromium-dev >> >> -~--~~~~--~~--~--~--- >> >> > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: 437k files checked out for an official build
Note in Anthony's mail he said he was clobbering the build directory, not the checkout. I do not have very many files in my build directories: $ find Debug | wc -l 10499 $ find Release | wc -l 10290 I think this is not "we have a lot of files because we do a lot of stuff" but rather that something has gone horribly wrong. Anthony, did you happen to notice any large collections of files that were in the delete list? On Mon, Nov 9, 2009 at 6:41 PM, Thomas Van Lenten wrote: > Right, but the builds need these files to run the tests to make sure the > bits are good. > The problem is some tests leave logs and such in the tree after running, if > we could ensure nothing changes in the tree, we might be able to change the > scripts to simply update. Or maybe we do the same gclient revert the > trybots do to make sure it is a completely clean tree for the build. > TVL > > > On Mon, Nov 9, 2009 at 9:35 PM, Jeremy Orlow wrote: >> >> This is related to the thread (last Friday?) about making a light weight >> checkout of Chromium the default. >> Btw a quick look indicates that 100k are Google specific files (hermetic >> build environment and such). 200k are layout tests. So that leaves "only" >> 150k filesprobably many of which are still test related. >> On Mon, Nov 9, 2009 at 5:37 PM, Anthony LaForge >> wrote: >>> >>> Howdy, >>> Was just clobbering a build directory this morning, and noticed it was >>> deleting ~437 thousand files from a single Chrome official windows build >>> directory, which took approximately 20-30 minutes to do a delete. Perhaps >>> my view isn't oriented correctly, but this seems like a very high number of >>> files. This isn't a high priority issue for the 4.0 timeframe, indeed may >>> not be a high priority issue at all, but I'd like to turn it over to our >>> developer community to see if anyone has any thoughts on the matter. So w/ >>> that... >>> Kind Regards, >>> >>> Anthony Laforge >>> Technical Program Manager >>> Mountain View, CA >>> >>> >> >> >> > > > --~--~-~--~~~---~--~~ > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev > > -~--~~~~--~~--~--~--- > > -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Simulating keyboard input
On Fri, Nov 6, 2009 at 8:16 AM, Simon Stewart wrote: > I've noticed a difference between firefox and chrome, and was > wondering whether it was deliberate. Generally, the way to resolve these issues is to also test Safari and IE. We almost always match Safari, so differences there are frequently bugs. If we match Safari but differ from IE/Firefox, then it's a WebKit bug. If we match Safari and Safari matches IE, then that is likely intentional. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum wrote: > I want to make it clear, and it might be obvious by now, but > test_shell isn't interesting to me. I just want the fastest browser > engine that I can get. > > What makes Chromium different than WebKitGTK+ for my project, is that > Chromium renders the GTK stuff correctly with CSS transformations. > It's also snappier. Conceptually Chrome is a bunch of layers, from top to bottom 1) chrome+ui junk 2) multiprocess rendering 3) webkit API 4) webkit Test shell covers layer 3 and down. Unfortunately, all the performance you like is in layer 2. We don't have a simple place to cut for that; however, since Chrome and test_shell are both just clients of the WebKit API, you could write your own client (like test_shell) and then copy the performant bits out of Chrome. It will require some work, but if it were easy then your job would be boring. :) -- 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: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 10:10 PM, Ben Goodger (Google) wrote: > Can there be a way to apply this to a local tree only so that you can revert > then revert the revert quickly locally so you can figure out why your change > broke? I know this doesn't answer the question you are asking, but in case other people had the same question I added a section to our Git cookbook on how to do this: http://code.google.com/p/chromium/wiki/GitCookbook#Reverting_and_undoing_reverts --~--~-~--~~~---~--~~ 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: Compiling error after I did a 'gclient sync'
On Tue, Nov 3, 2009 at 8:36 PM, n179911 wrote: > And when i got to a different directory trying to use git to get > Webkit code, I get this error "possible repository corruption on the > remote side", not sure if these 2 are related. > > git clone git://git.webkit.org/WebKit.git . > Initialized empty Git repository in /Users/samuel/Webkit/.git/ > remote: error: failed to unpack compressed delta at offset 486539223 > from ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack > remote: error: failed to read object > 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 at offset 486539219 from > ./objects/pack/pack-c7fcbbd90f8a0e469e7e218ffcef0bb43aa4114d.pack > remote: fatal: object 23c5a57a8a0c94e1b895d432e8799dbf5533dc18 is corrupted > remote: aborting due to possible repository corruption on the remote side. > fatal: early EOF > fatal: index-pack failed I wonder if you've ran out of disk space. If not, it is probably worth bringing that up on webkit-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: Compiling error after I did a 'gclient sync'
It has been working fine for me. Is it possible you have the wrong version of WebKit? What does tools/sync-webkit-git.py say? On Tue, Nov 3, 2009 at 6:46 PM, n179911 wrote: > > Thanks. Kenneth, > > I fixed the "ENABLE_3D_CANVAS" redefined error. But I still get the > following compilation error: > > In file included from > /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../bindings/v8/DerivedSourcesAllInOne.cpp:65: > > /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:40: > error: no matching function for call to > 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments&, int)' > ../bindings/v8/ScriptCallStack.h:58: note: candidates are: > WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments&, > unsigned int, WebCore::String, int) > ../bindings/v8/ScriptCallStack.h:46: note: > WebCore::ScriptCallStack::ScriptCallStack(const > WebCore::ScriptCallStack&) > > > > On Tue, Nov 3, 2009 at 6:40 PM, n179911 wrote: >> Thanks Kenneth. >> >> I tried this. But I get >> >> I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources/i386 >> -I/Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/DerivedSources >> -c >> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/DerivedSources/Debug/webkit/HTMLElementFactory.cpp >> -o >> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/Debug/webcore_bindings.build/Objects-normal/i386/HTMLElementFactory.o >> : error: "ENABLE_3D_CANVAS" redefined >> : error: this is the location of the previous definition >> : error: this is the location of the previous definition >> >> and also: >> >> /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8Console.cpp:49: >> error: no matching function for call to >> 'WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments&, int)' >> ../bindings/v8/ScriptCallStack.h:58: note: candidates are: >> WebCore::ScriptCallStack::ScriptCallStack(const v8::Arguments&, >> unsigned int, WebCore::String, int) >> ../bindings/v8/ScriptCallStack.h:46: note: >> WebCore::ScriptCallStack::ScriptCallStack(const >> WebCore::ScriptCallStack&) >> >> >> >> On Mon, Nov 2, 2009 at 10:38 PM, Kenneth Russell wrote: >>> On Mon, Nov 2, 2009 at 10:27 PM, n179911 wrote: Hi, I have tried syncing up chromium HEAD by doing this (since i use git for chromium and webkit). $ git pull (update chromium) $ gclient sync $ tools/sync-webkit-git.py (update webkit) But i got the following errors when I compile it. It appears the method 'CanvasRenderingContext3D::attachShader' is called with the wrong number of parameters. Does anyone know how to fix it? Thank you. chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:90: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*&, WebCore::CanvasShader*&)' ../html/canvas/CanvasRenderingContext3D.h:64: note: candidates are: void WebCore::CanvasRenderingContext3D::attachShader(WebCore::CanvasProgram*, WebCore::CanvasShader*, WebCore::ExceptionCode&) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:101: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*&, unsigned int&, WebCore::String&)' ../html/canvas/CanvasRenderingContext3D.h:65: note: candidates are: void WebCore::CanvasRenderingContext3D::bindAttribLocation(WebCore::CanvasProgram*, long unsigned int, const WebCore::String&, WebCore::ExceptionCode&) /Users/samuel/chromium3/src/third_party/WebKit/WebCore/WebCore.gyp/../../../../xcodebuild/WebCore.build/DerivedSources/Debug/bindings/V8CanvasRenderingContext3D.cpp:111: error: no matching function for call to 'WebCore::CanvasRenderingContext3D::bindBuffer(unsigned int&, WebCore::CanvasBuffer*&)' ../html/canvas/CanvasRenderingContext3D.h:66: note: candidates are: void WebCore::CanvasRenderingContext3D::bindBuffer(long unsigned int, WebCore::CanvasBuffer*, WebCore::ExceptionCode&) >>> >>> It looks like upstream WebKit changes have broken our WebGL >>> implementation again. The reason you're running into this is probably >>> that you synced a more recent version of WebKit than is described in >>> the DEPS file. Your best b
[chromium-dev] Re: revert now, ask questions later? WAS: Reverting a change, the fast way
On Tue, Nov 3, 2009 at 2:34 PM, Peter Kasting wrote: > If a change closes the tree, the change author has 1 or 2 minutes to respond > to a ping. The change should be reverted if the author doesn't respond, if > he says to revert, or if he does not say he has a fix within the next 5 > minutes. Pinging the author is important, especially if there are special circumstances (like it only fails on the bot and they want to ssh in to examine something). --~--~-~--~~~---~--~~ 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: refactoring and git
Another option is to do one TBR commit where you just fork the file with no changes, then work again as normal. Pretty ugly though. :) On Tue, Nov 3, 2009 at 9:29 AM, Drew Wilson wrote: > In my case, git didn't quite figure out that my refactoring (splitting a > file into two) should also link up the new file to the history of the old. > There are magic flags I could pass (-C) to make git more aggressive about > matching up files to histories, but it turns out that passing those flags > also generates a bunch of false positives (at least in my case): git thought > that unrelated files were actually copies of one another. > In the end, I'm probably just going to land the patch via svn and manually > setup the history linkage via svn copy. > -atw > > On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin wrote: >> >> Generally it should Just Work. If it doesn't, I'd like to hear about it. >> >> http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies >> >> On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay wrote: >> > Are there best practices we can follow that will help the scripts be >> > more accurate? For example, if we move the file, make sure that we >> > commit it in the new location before making any text changes? If so, >> > we could at least document that. >> > >> > Erik >> > >> > >> > On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin wrote: >> >> >> >> I'm not sure which news you're referring to. :) >> >> >> >> To answer Jeremy's request: briefly, git doesn't track renames at all >> >> (which are conceptually differences between versions) which makes >> >> sense when you consider what it does track (conceptually, only >> >> collections of files and an ordering between collections). Instead, >> >> tools like "git diff" know how to infer renames from the content, and >> >> then the Rietveld uploader sorta knows how to munge them into a >> >> Subversion-compatible format. (And when you dcommit to svn it >> >> converts those inferred renames into real renames.) It usually works >> >> pretty well except when it doesn't. >> >> >> >> If you can convince "git diff" through some combination of flags that >> >> a rename or copy happened, then that info can be communicated to svn. >> >> >> >> So two sources of glitches: (1) can't convince git that two files are >> >> related, typically because the text between them is too different; (2) >> >> the Rietveld uploader isn't synthesizing Subversion renames well >> >> enough. (2) is a bug that I (or realistically, you) can fix, while >> >> (1) frequently means that tracking that history doesn't really matter >> >> too much. >> >> >> >> On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. >> >> wrote: >> >>> That's a good news. Can that info be put somewhere in the UsingGit >> >>> wiki >> >>> page? >> >>> >> >>> On Mon, Nov 2, 2009 at 23:56, Evan Martin wrote: >> >>>> >> >>>> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson >> >>>> wrote: >> >>>> > I'm doing some refactoring in the chromium worker code, and I got >> >>>> > the >> >>>> > following review feedback: >> >>>> > "small request: can the files that were branched from existing >> >>>> > files be >> >>>> > "svn >> >>>> > copy'd" instead of copying manually and "svn added"? This will >> >>>> > preserve >> >>>> > history >> >>>> > and will make it easier to see what changed in the review." >> >>>> > Is there a way to do this with git? I do want to make my reviewers >> >>>> > happy >> >>>> > :) >> >>>> >> >>>> Git has an ...odd... way of thinking about renames. The pieces you >> >>>> need to know are: >> >>>> 1) Does git believe you did a rename? Consult "git diff -M -C --stat >> >>>> origin..." and see if it prints renames. >> >>>> 2) If no, ping me off-list and I'll help you out. >> >>>> 3) If yes, Rietveld should be able to display the diff properly. >> >>>> However, this code is relatively untested (we have to convert the Git >> >>>> renames into SVN-style "renames" -- SVN doesn't actually support true >> >>>> renames, oddly enough) so it could be wrong. In that case, also ping >> >>>> me off-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: Can't build chrome; "NameError: name '_toolset' is not defined". Can't sync webkit. :-(
On Tue, Nov 3, 2009 at 8:06 AM, Dan Kegel wrote: > I get > > NameError: name '_toolset' is not defined while loading dependencies > of base/base.gyp while loading dependencies of app/app.gyp while > loading dependencies of build/all.gyp while trying to load > build/all.gyp > > when building or even just running 'gclient runhooks --force'. > > Also, when I do 'gclient sync', it does the usual syncing... > until it comes to webkit, where it hangs for a while, then reports > svn: Can't read from connection: Connection reset by peer > (This is with the committer repo from my home machine over > the public internet.) > > Wonder if there's some connection between the two problems... It's possible that some of your svn checkouts weren't fully synced. Try "gclient sync --force". --~--~-~--~~~---~--~~ 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: refactoring and git
Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies On Tue, Nov 3, 2009 at 9:16 AM, Erik Kay wrote: > Are there best practices we can follow that will help the scripts be > more accurate? For example, if we move the file, make sure that we > commit it in the new location before making any text changes? If so, > we could at least document that. > > Erik > > > On Tue, Nov 3, 2009 at 7:58 AM, Evan Martin wrote: >> >> I'm not sure which news you're referring to. :) >> >> To answer Jeremy's request: briefly, git doesn't track renames at all >> (which are conceptually differences between versions) which makes >> sense when you consider what it does track (conceptually, only >> collections of files and an ordering between collections). Instead, >> tools like "git diff" know how to infer renames from the content, and >> then the Rietveld uploader sorta knows how to munge them into a >> Subversion-compatible format. (And when you dcommit to svn it >> converts those inferred renames into real renames.) It usually works >> pretty well except when it doesn't. >> >> If you can convince "git diff" through some combination of flags that >> a rename or copy happened, then that info can be communicated to svn. >> >> So two sources of glitches: (1) can't convince git that two files are >> related, typically because the text between them is too different; (2) >> the Rietveld uploader isn't synthesizing Subversion renames well >> enough. (2) is a bug that I (or realistically, you) can fix, while >> (1) frequently means that tracking that history doesn't really matter >> too much. >> >> On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. >> wrote: >>> That's a good news. Can that info be put somewhere in the UsingGit wiki >>> page? >>> >>> On Mon, Nov 2, 2009 at 23:56, Evan Martin wrote: >>>> >>>> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson wrote: >>>> > I'm doing some refactoring in the chromium worker code, and I got the >>>> > following review feedback: >>>> > "small request: can the files that were branched from existing files be >>>> > "svn >>>> > copy'd" instead of copying manually and "svn added"? This will preserve >>>> > history >>>> > and will make it easier to see what changed in the review." >>>> > Is there a way to do this with git? I do want to make my reviewers happy >>>> > :) >>>> >>>> Git has an ...odd... way of thinking about renames. The pieces you >>>> need to know are: >>>> 1) Does git believe you did a rename? Consult "git diff -M -C --stat >>>> origin..." and see if it prints renames. >>>> 2) If no, ping me off-list and I'll help you out. >>>> 3) If yes, Rietveld should be able to display the diff properly. >>>> However, this code is relatively untested (we have to convert the Git >>>> renames into SVN-style "renames" -- SVN doesn't actually support true >>>> renames, oddly enough) so it could be wrong. In that case, also ping >>>> me off-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: refactoring and git
I'm not sure which news you're referring to. :) To answer Jeremy's request: briefly, git doesn't track renames at all (which are conceptually differences between versions) which makes sense when you consider what it does track (conceptually, only collections of files and an ordering between collections). Instead, tools like "git diff" know how to infer renames from the content, and then the Rietveld uploader sorta knows how to munge them into a Subversion-compatible format. (And when you dcommit to svn it converts those inferred renames into real renames.) It usually works pretty well except when it doesn't. If you can convince "git diff" through some combination of flags that a rename or copy happened, then that info can be communicated to svn. So two sources of glitches: (1) can't convince git that two files are related, typically because the text between them is too different; (2) the Rietveld uploader isn't synthesizing Subversion renames well enough. (2) is a bug that I (or realistically, you) can fix, while (1) frequently means that tracking that history doesn't really matter too much. On Mon, Nov 2, 2009 at 10:28 PM, Paweł Hajdan Jr. wrote: > That's a good news. Can that info be put somewhere in the UsingGit wiki > page? > > On Mon, Nov 2, 2009 at 23:56, Evan Martin wrote: >> >> On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson wrote: >> > I'm doing some refactoring in the chromium worker code, and I got the >> > following review feedback: >> > "small request: can the files that were branched from existing files be >> > "svn >> > copy'd" instead of copying manually and "svn added"? This will preserve >> > history >> > and will make it easier to see what changed in the review." >> > Is there a way to do this with git? I do want to make my reviewers happy >> > :) >> >> Git has an ...odd... way of thinking about renames. The pieces you >> need to know are: >> 1) Does git believe you did a rename? Consult "git diff -M -C --stat >> origin..." and see if it prints renames. >> 2) If no, ping me off-list and I'll help you out. >> 3) If yes, Rietveld should be able to display the diff properly. >> However, this code is relatively untested (we have to convert the Git >> renames into SVN-style "renames" -- SVN doesn't actually support true >> renames, oddly enough) so it could be wrong. In that case, also ping >> me off-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: refactoring and git
On Mon, Nov 2, 2009 at 2:47 PM, Drew Wilson wrote: > I'm doing some refactoring in the chromium worker code, and I got the > following review feedback: > "small request: can the files that were branched from existing files be "svn > copy'd" instead of copying manually and "svn added"? This will preserve > history > and will make it easier to see what changed in the review." > Is there a way to do this with git? I do want to make my reviewers happy :) Git has an ...odd... way of thinking about renames. The pieces you need to know are: 1) Does git believe you did a rename? Consult "git diff -M -C --stat origin..." and see if it prints renames. 2) If no, ping me off-list and I'll help you out. 3) If yes, Rietveld should be able to display the diff properly. However, this code is relatively untested (we have to convert the Git renames into SVN-style "renames" -- SVN doesn't actually support true renames, oddly enough) so it could be wrong. In that case, also ping me off-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: readability extension (experience writeup)
On Sat, Oct 31, 2009 at 3:41 PM, Aaron Boodman wrote: >> - The docs are behind the code (had to read the code once or twice to >> figure out what was going wrong). > > Were you using trunk or dev? I was using dev. I think I just searched on Google and clicked through to whichever docs I found -- I didn't realize there were two sets. Should we always point users to trunk until extensions are in beta? But yes, the trunk docs look great, and I see they've also addressed my prior complaint about organization. --~--~-~--~~~---~--~~ 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 much RAM needed to get past linking? (Linux)
On Fri, Oct 30, 2009 at 10:10 AM, Akira wrote: > I was building on Fedora 10 and was able to compile but the > linking stage (see below) consumes more and more memory- the 500Mb of > remaining memory, then another 1Gb of swap- before being killed. Are you using gold (the new binutils linker)? gold is significantly faster and smaller. If this problem is caused by using the old linker, we should update the build instructions to just say that we require gold. --~--~-~--~~~---~--~~ 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: Compiler warning with Arch Linux and make
On Sun, Nov 1, 2009 at 8:01 AM, Alexander Teinum wrote: > Success. That's great! If you have any notes that would be useful to other Arch users, please update the instructions on the wiki at http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites (There's a section with distro-specific notes.) > Adding 'remove_webcore_debug_symbols' to include.gypi probably solved > my problem (although I did a debug build now). This is the first time > that I have had success compiling Chromium in Arch Linux with make. > And it's also the first time that I have gotten a debug build working > in Arch Linux. It is possible that your compile problem was a temporary problem that was fixed. Our tree tends to break and be repaired pretty rapidly, so frequently you can run "gclient sync" and discover your problems have been fixed. > I don't know if it makes any difference, but I built with V=1. That shouldn't matter. --~--~-~--~~~---~--~~ 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: readability extension (experience writeup)
I've updated this to the browser actions API. The diff is mostly deleting lines, since it is now much easier to do this kind of thing: http://neugierig.org/software/git/?url=chrome-readability/commit/&id=9768c8fa1f807f85a2387310214b7ff6b4153e1a I was able to pack my extension and install it as well, all on Linux. Pretty much everything was great -- my only points of confusion follow. I'm almost certain y'all already know about all of these, but just in case... - The docs are behind the code (had to read the code once or twice to figure out what was going wrong). - Not exactly clear sometimes which error console you're supposed to look at; the workflow of "reload, see what error happened this time" takes a few too many clicks. Would be nice if chrome://extensions/ remembered whether I had the developer tools turned on or off. - Got one browser crash while developing. But I think we've fixed some crashers seen on the current dev channel on trunk, so I hope it was one of those. On Sat, Sep 12, 2009 at 7:02 PM, Evan Martin wrote: > [resend, I think I screwed up the previous three tries] > I wrote an extension that adds a page action to trigger Readability: > http://lab.arc90.com/experiments/readability/ > > It's basically just a glorified bookmarklet. > > Code is here: > http://neugierig.org/software/git/?url=chrome-readability/ > Browse it here: > http://neugierig.org/software/git/?url=chrome-readability/tree/ > > I can't provide a .crx because I wasn't able to figure out how to > build one, which I think means I can't actually install it. :~( > > Here's some feedback on the process. I know extensions are still > under development, and that surely most if not all of these are > already known bugs, and that others are probably my fault for doing it > on Linux. I thought it would still be helpful to give an overview of > points of confusion I ran into, in case any of these aren't yet known > bugs. > > - Weight. > This feels like a *lot* of code (content script, page action, > background page, manifest, message ports) just to make a bookmarklet > appear in the URL bar. I wonder if there's a place for a "simple" > extension API for bookmarklet-y sorts of things? > > - Making my page action show up. > It wasn't clear to me how to make my action just always show up. > I think I may have done it wrong: > http://neugierig.org/software/git/?url=chrome-readability/tree/background.html > since it feels unreliable (sometimes it doesn't show). > > - The failure modes are confusing. > Sometimes it prints to the console (when I've made a typo in my > manifest); other times it prints to the error console of the extension > (bugs in my background js); other times it prints to the page's error > console (bugs in my content script). Many of those times there's no > obvious way to map the error back to the line that is failing. > > - JS console. > Do we really have no UI to get to the JS console? I had to open the > developer tools, then guess that one of the icons at the bottom of > the window would show me the messages. > > - The docs around content scripts communicating with the embedding > page aren't too clear. See e.g.: > http://code.google.com/chrome/extensions/content_scripts.html#messaging > That section is mostly just a big example but for example nowhere is > the postMessage API described. I'd prefer it to be laid out more > like: > - how to make each endpoint listen for messages > - how to make each endpoint send a message > > - Doc organization. > It would've been clearer to me if there is one more level of nesting. > Sections like toolstrips, page actions are features with manifest > edits as well as APIs, while sections like tabs and windows are just > API references. > > - Building the .crx. > strace -fo log chromium-browser --user-data-dir=/home/martine/test > --pack-extension=`pwd`/readext > --pack-extension-key=chrome-readability.pem > Doesn't show it ever trying to create my .pem. Maybe it's not implemented, > but it'd be nice if it at least complained in that case. > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: git users and svn:eol-style
On Thu, Oct 29, 2009 at 5:28 PM, Evan Martin wrote: > If you add the junk to your ~/.subversion/config that's specified on this page > http://dev.chromium.org/developers/coding-style > then git will do the right thing as well. (I just tested it on a > local svn repo to be sure.) BTW, it looks like Yaar helpfully added this to the commit instructions a month ago! http://code.google.com/p/chromium/wiki/UsingGit#Committing --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: git users and svn:eol-style
On Thu, Oct 29, 2009 at 5:13 PM, John Abd-El-Malek wrote: > Per the Chromium style guide > (http://dev.chromium.org/developers/coding-style), we require all new files > to have the svn:eol-style property set. We even have a presubmit check for > it in case you don't configure Subversion to automatically add them per the > above previous link. > git users seem to not have such a presubmit check, This is because eol-style is an SVN-specific concept, so there's no real way to check it client-side. The proper place to enforce this is the server. *shrug* > so nothing reminds them > to add them. Can the git-cl script be modified to do this, and if not > quickly, can git users please try to remember and follow this? If you add the junk to your ~/.subversion/config that's specified on this page http://dev.chromium.org/developers/coding-style then git will do the right thing as well. (I just tested it on a local svn repo to be sure.) --~--~-~--~~~---~--~~ 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: Switching vs2008 to be preferred when present.
On Thu, Oct 29, 2009 at 2:38 PM, Mike Belshe wrote: > 2) If you turn on Intellisense, it crashes like crazy very regularly. I've > turned off intellisense, but it is a big loss in productivity to do so That was my experience with VS2005, but I am used to not having Intellisense anyway. --~--~-~--~~~---~--~~ 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 can we kill scons?
On Wed, Oct 28, 2009 at 1:23 PM, Albert J. Wong (王重傑) wrote: > I actually got some weird warnings on the make build a while back when I > specified the same file in two sources entries...something about circular > dependencies and make ignore one. But don't remember the exact scenario. > I betcha it isn't a problem in chrome cause it'd only trigger a bug if the > file was compiled with different flags that modified behavior. Since our > defines and compiler options are so stable (especially within one target), > building once probably doesn't break stuff... Currently, as far as I know, no files in Chrome require this "compile twice" behavior. I am skeptical of the utility of gyp features that are unused by Chrome. But this may be the magic bullet to make -fPIC on 64-bit work. I think I still see situations where the generated strings aren't properly rebuilt in the make build. You have to run it twice. At this point, given the number of people hammering on it, I suspect the gyp rules are wrong and that the make build parallelizes too aggressively, but that is likely just wishful thinking and there's a subtle bug in there. :( That means for the build bots to switch, they need to always run make twice to be sure everything was built. (PS: currently every time you run make it rebuilds some NACL stuff too. I am so tired of NACL busting my build that I just turned it off locally.) --~--~-~--~~~---~--~~ 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 9:07 AM, Dan Kegel wrote: > On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin wrote: >>> 3) Startup time is faster than calculator. >> >> I'm not sure if you're kidding. Do you mean Windows calculator? > > On my home linux box (Jaunty, reasonably fast), > warm startup time of chrome is less > than the warm startup time of gnome calculator. > Strange but true. Yeah, that's why I was asking -- it wouldn't surprise me if we were faster than the GNOME one. Without any numbers I'd blame the icon theme stuff (Elliot found it can do a truly ludicrous number of disk accesses on startup). --~--~-~--~~~---~--~~ 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 Tue, Oct 27, 2009 at 9:11 PM, Adam Barth wrote: > My three laptops have relatively comparable hardware and run Chrome on > Windows, Mac, and Linux respectively. The Linux version of Chrome > feels ridiculously faster than Windows and Mac. Do we understand why > this is? Can we make Windows and Mac feel that fast too? My first instinct is to say because (1) we're awesome and (2) Linux is awesome, but I'd prefer to have facts back it up. :) There's a "perf" link on http://build.chromium.org that has builders tracking various metrics. If we get perf tests for the behaviors you care about, we can better compare and improve them. On the other hand, I'm not sure if the hardware lines up between platforms so maybe the comparisons I do below are not valid... > General observations: General comments: Linux tends to be "lighter" which means it does better on older hardware, so depending on what sorts of laptops you're talking about that could be a major factor. Windowses later than 2000 or so need surprising amounts of hardware to run well. (I don't mention Mac below because there hasn't been much performance work there yet.) > 1) Scroll performance is extremely good. Even on Gmail, I can only > get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, > it doesn't even look like I can do that. On "plain" pages (one scrollbar on the right, no Flash) scrolling is literally shifting the pixels down. On Linux we do this by sending a command to the X server, which is a single process that even has the graphics drivers built in so it talks directly to your graphics card and can in theory do a hardware-accelerated copy. I would expect this to be pretty fast. However, Gmail is a "complicated" page (the main scrollbar is an iframe) so in that case I guess rendering speed is getting involved. There I'd expect Windows Chrome to be faster because the compiler is better and there have been more people looking at performance (I saw in another thread that tcmalloc, currently only used on Windows, improved the page cycler by 50%?). The page cycler perf graphs are intended to test rendering speed. Do the numbers match your perception? I can't get the right graphs to load right now. It looks like spew from NOTIMPLEMENTED()s may be obscuring the data. > 2) Tab creation is very fast. Maybe the zygote is helping here? Can > we pre-render the NTP on other platforms? The zygote is paused right at process start, before we've even started a renderer. On the other hand Windows process creation is more expensive. There is a "new tab" graph that attempts to measure this. The various lines on the graph are tracking how quickly we get to each stage in constructing the page. We hit the first line 20ms faster on Linux than Windows likely due to the zygote and "slow" Windows process creation, but process startup seems to be a relatively small part of the total time. Linux hits other lines later and Linux and Windows hit the finish line at around the same time. In your case, I wonder if you have more history accumulated on your Windows profile, making the new tab computation more expensive than the equivalent one on the Linux box. I'd expect the faster file system on Linux to eventually be help here. (My experience with git has been you get an order of magnitude slower each step from Linux->Mac->Windows, but that could be git or hardware-specific.) > 3) Startup time is faster than calculator. I'm not sure if you're kidding. Do you mean Windows calculator? Maybe there's something wrong with your Windows box -- maybe a virus scanner or disk indexer or some other crap procmon will show is continually thrashing your computer. Or maybe you have a spare Chrome instance on another virtual desktop on your Linux box so clicking the Chrome button is just telling it to show another window. The startup tests are intended to track startup performance, and again the Windows graphs are much better than the Linux ones. However, the difference between the two is milliseconds and my experience as a user is that Chrome rarely starts that fast, so I wonder if these graphs are really measuring what a user perceives (which frequently involves disk). In the limit, I'd expect us to pay a lot more on Linux due to using more libraries, GTK initialization, round trips to the X server, etc. but I don't know much about Windows here. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: A Dictionary-Evaluation Plan
2009/10/28 Hironori Bono (坊野 博典) : > Even though this is still a random thought, I would personally like to > use chromium to evaluate the new dictionaries: i.e. uploading the new > dictionaries to our dictionary server, changing the chromium code to > use the updated ones, asking users to compare the new dictionaries > with the old ones and give us their feedbacks (*1). If users like the > new dictionaries, we would like to release the new ones. Otherwise we > will keep the old ones. In the web search world when we made changes like these, we'd try to measure it without users giving explicit feedback. For example: give some users the new dictionary, and others the old one. Log which entry index from the dictionary suggestion list people are frequently choosing, then compare the aggregate counts between the two sets of users. (Maybe call the "Add to Dictionary" menu option -1.) For a better dictionary, I'd expect people to use the earlier entries from the suggestion list more frequently, and the "Add to Dictionary" option less frequently. This can be done with our existing histogram framework and I believe Jim wrote a framework within that for doing these sorts of experiments. It still might be worth soliciting feedback from users directly. For example, if the new dictionary is missing a common word the above measure would get a high count of "Add to Dictionary", and maybe users could tell us about this. But in general, you get higher quality data when you involve more users, and a spreadsheet will be limited to people who understand the English instructions. --~--~-~--~~~---~--~~ 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' Native Client Plugin hides my NPAPI plugin
On Tue, Oct 27, 2009 at 2:50 PM, Evan Martin wrote: > On Fri, Oct 23, 2009 at 1:58 AM, Anselm R Garbe wrote: >> However, I'm not sure if chrome resp. libnpGoogleNaClPluginChrome.a >> does it right with exporting these symbols as plain C symbols because >> this might conflict with other existing plugins as well in the same >> way. > > I checked in a fix for this in r30253. Thanks for bringing up the > problem, and please let us know if you encounter any other problems. Amusingly, this change apparently also made a bunch of Mac plugin tests pass, so doubly thanks for bringing it up. ;) --~--~-~--~~~---~--~~ 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' Native Client Plugin hides my NPAPI plugin
On Fri, Oct 23, 2009 at 1:58 AM, Anselm R Garbe wrote: > However, I'm not sure if chrome resp. libnpGoogleNaClPluginChrome.a > does it right with exporting these symbols as plain C symbols because > this might conflict with other existing plugins as well in the same > way. I checked in a fix for this in r30253. Thanks for bringing up the problem, and please let us know if you encounter any other problems. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
