Re: [chromium-dev] WebKit roll status
http://codereview.chromium.org/400027/diff2/27001:30003/30013 On Tue, Dec 8, 2009 at 13:30, Adam Langley wrote: > On Tue, Dec 8, 2009 at 1:27 PM, Dimitri Glazkov > wrote: > > Let's go with this. You'll have a chance all about the great > > rebaselining tool in the process. :) > > > > Michael will roll and add all the failures to expectations, creating a > > bug for you to rebaseline. > > Ok. Markus is going to do a quick WK patch, before we roll, to set the > defaults to something like the current values. > > > AGL > -- 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] WebKit roll status
Oh, yes, that wouldn't be surprising :-/ There now is a new WebKit API for setting the scrollbar colors in Linux, and theWebKit change doesn't set the colors. That's waiting for the second half of the changelist which is pending in http://codereview.chromium.org/400027 Even after that pending changelist is going to be submitted, the pixel tests will probably fail, as the new code has slightly different pixel values than the old code. We could change that, but it would make the code much uglier. So, at this time, there are a couple of choices. Let me know, what you prefer: - fix the problem with the black scrollbars in testshell. This is easy. The WebKit change currently sets all colors to zero, unless somebody explicitly sets them to something else. We can pick different default values that will at least make the scrollbars visible. This would still require rebasing the pixel tests. And we have to make a decision on whether to apply this as an incremental change or whether to rollback the current WebKit change. It's gonna be a rely simple low-risk change. - add ugly backwards compatibility code that realizes the situation when colors for the scrollbars have never been set and that then falls back on using the exact same old pixel values. I am not in favor of this, but if the consensus is that that's what we should do, I'll change the code accordingly. Markus -- 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: Quick question about struct initialization
The only time where this does not quite work is if the very first field in
the struct/class is not a POD that can be initialized to zero.
A common example would be "struct sigaction" on Linux. The first field is an
anonymous union holding both sa_handler and sa_sigaction. So, this code
wouldn't compile:
struct sigaction sa = { 0 };
You could write
struct sigaction sa = { { 0 } };
instead. But this code might not compile on anything other than Linux. As
the union is clearly an implementation-specific detail. A better option
would be to explicitly specify one well-known field:
struct sigaction sa = { .sa_handler = 0 };
Of course, in this particular case, you would rarely want to completely zero
out the structure anyway. Instead, you would want to set at least some
fields. So, the natural way to write this code would be:
struct sigaction sa = {
.sa_handler = MySignalHandler,
.sa_flags = SA_RESTART
};
This code is guaranteed to do the right thing, and to zero out all the other
fields in the structure.
Markus
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Debugging symbols for system libraries
Yesterday, I updated the install script at http://src.chromium.org/svn/trunk/src/build/install-build-deps.sh Please let me know, if you encounter any problems and I'll fix them. It now installs not only the libraries necessary to build Chromium, it also installs the debugging symbols for these libraries. This will give you correct line number information when tracing through system libraries (e.g. GTK or SSL). In some cases, this will also give you correct stack traces where you weren't able to get these earlier. You can even see the source code for the system libraries in GDB. Just use "apt-get source" to download the sources to anywhere on your system, and then point GDB to it using the "dir" command. You can put this command into your "~/.gdbinit" file. So, you don't have to do that each time you start GDB. As before, the script only works on Ubuntu. It probably works on any Debian based system, but that is untested. Please note that Ubuntu does not by default ship 32bit versions of all the system libraries, if you are running a 64bit operating system. The script knows about this and downloads the Debian packages for the 32bit distribution and then repackages the library files on the fly. This temporarily requires downloading a lot of data. You might not want to do this, if you are on a slow Internet connection. The script prompts you and you can opt out. Markus --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
