[chromium-dev] Mac UI Types
Gentle reminder: NSRect, NSPoint, NSSize are all defined based on CGFloat. In 64bit, this is a double, not a float. So please make sure all code dealing with these is using CGFloat so we don't have issues in the future. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why is Linux Chrome so fast?
scrolling jank in gmail http://crbug.com/25741 Linus On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin e...@chromium.org wrote: 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.) I pulled out the laptops side-by-side to be more scientific about this. Here are the stats: XP: 2GB RAM, Core2 Duo, 2.00 GHz Ubuntu 9.10: 2GB RAM, Core 2 Duo, 2.40 GHz So, the Linux machine as 20% more CPU to work with. 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. Looking at this more carefully, scroll performance on Slashdot is great in both Windows and Linux. On Gmail (no chat mole), there's a noticeable difference. Here's a visualization of the numb on the scroll bar: || || || || || || -- -- Click here and pull down -- -- -- Linux: mouse latency gets to here || || -- Windows: mouse latency gets to here || || || || Admittedly, it's hard to see precisely, but it affects the feel. Scroll on Windows feels slightly heavier. 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. So, I retried this with a fresh profile on both. The differences are not as dramatic as I remember. I can't actually see a difference when I run them side-by-side. 3) Startup time is faster than calculator. I'm not sure if you're kidding. Do you mean Windows calculator? I meant Linux calculator. 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. I tried turning on the GTK theme. That killed startup performance. Side-by-side startup easily noticeably faster in Linux. To be more precise, drawing the first pixel is noticeably faster. Total startup time is harder to say. Interestingly startup drawing is different between Windows and Linux. We might want to film with a high-speed camera to see exactly what's going on, but here are my impressions: Linux draw order: 1) Fill entire window with blue (This looks bad, can we use a different color? White?). 2) Paint main UI widgets, including NTP. 3) Paint NTP thumbnails. I bet that (2) is actually broken in to two pieces, I just can't see it. Window draw order: 1) Paint NC region (the blue border around the edge). 2) Paint main UI widgets (without omnibox). 3) Blit NTP content area (the sweep from top to bottom is noticeable). 4) Paint omnibox. 5) Paint NTP thumbnails. Keep in mind that this all happens very fast, so I could be imagining things. Ideas for improving perceived windows startup time: 1) Draw a fake omnibox with the rest of the main UI widgets. Currently we draw the omnibox really late and it looks slow and bad. You can see this if you have a dark desktop wallpaper and you focus on where the omnibox will be. You'll see a dark rectangle inside the main toolbar which is the desktop showing through. We should never show a dark rectangle there. 2) Fill the main content area with white when drawing the main UI widgets. You can see this if you focus on the bottom of where the bookmark bar is going to be (especially when the bookmark bar is set to show only on the NTP). You'll see an edge there when the bookmark bar is draw by while the main content area is still transparent. There's no reason we should ever paint an edge there. I bet the reason Windows startup feels slower is whatever drawing operation we're using for the
[chromium-dev] browser/sync test fixit next week [Nov 2 - 6]
Hello! A heads-up that folks working on sync will be holding a test fixit next week, Nov 2 - 6. The motivation is to improve test coverage of our code, as there are many more chunks without any unit-test coverage whatsoever than there should be. The sync integration tests do tickle *most *of the code, but these take a lot more time and effort to run and debug, can't run on the public buildbot (yet!), and they also need TLC themselves because they have flakiness issues. We have a list of things to tacklehttp://code.google.com/p/chromium/issues/list?can=2q=Feature-Sync+fixit, some of the add tests here! variety, and some are make this thing more testable. Some require a pretty strong understanding of all the pieces in the system, and might not be suitable for a first-time dive into the sync engine :). But there is more generic low hanging fruit available as well! We are going to try to focus exclusively on these issues next week, which are filed under 'Feature-Sync' and 'Fixit'. [barring any emergencies of course, knock on wood!] Here is the list again: http://code.google.com/p/chromium/issues/list?can=2q=Feature-Sync+fixit. We may add more today/early next week, so make sure to check back! If you need a hand getting started or a bug you are interested in is unclear, folks on the cc-list or myself would be happy to try and shed some light for you. And remember, debugging sucks. Testing rocks! Tim --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
I'm sorry for introducing this pattern in base::Thread. It's bitten use several times over the course of the project. If you see a better design, please don't hesitate to fix it. Adam On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J Suggestion: don't call CleanUp in the destructor, but check that someone did. Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Linux] 'make' build maintenance
If you don't build with 'make', you can ignore this message.
Recent gyp changes have rearranged the 'obj' output directory for make
builds. This shouldn't affect how you build, but it will result in a
bunch of orphaned object files from previous builds, which might be
confusing, and will definitely waste space ('obj' can be several GBs
for a debug build). You may want to clobber your build directory as a
precaution.
Michael
--~--~-~--~~~---~--~~
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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:26 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 30, 2009 at 3:17 PM, Antoine Labour pi...@google.com wrote: On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.orgwrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J Suggestion: don't call CleanUp in the destructor, but check that someone did. I assume you mean Stop()? Yes, sorry, looking at the code, that's what I meant. The problem is when you have a class like ChromeThread inherit from base::Thread and then call Stop() in its destructor and then have someone else subclass ChromeThread and expect its CleanUp to be called. Yup, the pattern is dangerous, so instead of relying on Stop being called from the destructor, it should be explicitly done by the client (and moving Stop() to ~ChromeThread will only move the problem), and the destructor should check that it has been done. Antoine On Fri, Oct 30, 2009 at 3:16 PM, Adam Barth aba...@chromium.org wrote: I'm sorry for introducing this pattern in base::Thread. It's bitten use several times over the course of the project. If you see a better design, please don't hesitate to fix it. Adam Already filed a bug: http://crbug.com/26365 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New ffmpeg sumo lib requires libbz2-dev, and possibly a clobber build
As of r30640, on Linux and FreeBSD, we are now building the FFmpeg binaries as part of the normal Chromium build process. This means we now have a dependency on libbz2. :) Make sure to install the libbz2-dev package. I've updated the src/build/install-build-deps.sh script to reflect the new dependency. Also, in some situations, the linux build may require a clobber. If you see an issue where ffmpegsumo_nolink cannot resolve the uncompress symbol, try clobbering your build. It seems to work fine for most people, but every now and then a client seems borked. If you're curious to see the gritty change in full glory, the main change was here: http://src.chromium.org/viewvc/chrome?view=revrevision=30571. -Albert --~--~-~--~~~---~--~~ 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? -scott On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org wrote: Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? Or is there any sort of built in compiler warning that we could turn on? I did a bit of searching and was really surprised that I couldn't find any mention of such a thing. On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org wrote: Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? That's an intriguing idea. It seems like you could swap the real vtable ptr out on ctor/dtor entry, and replace it with a ptr to a poisoned vtable. This sounds like debug build stuff only. -scott On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:54 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org wrote: Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? Or is there any sort of built in compiler warning that we could turn on? I did a bit of searching and was really surprised that I couldn't find any mention of such a thing. It would have to be a really smart compiler, because you could call a function which calls another object's function which calls back to a virtual in your object. That's why I suggested a way to make vtable references fatal, so at least when doing development you could get a notification (and not check it in). -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:54 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org wrote: Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? Or is there any sort of built in compiler warning that we could turn on? I did a bit of searching and was really surprised that I couldn't find any mention of such a thing. The compiler could find if it's called directly from the destructor, but there's no way it'd find your case ! The virtual call happens on another thread. To Scott's question: you can blit NULL into the vtable field, if you know where it is (it's not too hard, but depends on the compiler). You'll know if you call it - you'll die. Better yet, you could have a static table of functions that print a message before dying and blit that one, but that gets trickier. Antoine On Fri, Oct 30, 2009 at 3:12 PM, Jeremy Orlow jor...@chromium.org wrote: I've spent a good deal of this week trying to track down what turned out to be a simple but fairly common problem: I forgot virtual dispatch only partially works in destructors. There have been several email threads about this, but it still bites us form time to time, so I thought it was worth another reminder. Details: I subclassed ChromeThread which subclasses base::Thread. base::Thread calls CleanUp on the thread right before termination. CleanUp is virtual. Both ChromeThread and my class override CleanUp(). base::Thread calls Stop() in its destructor to stop the thread (if it hasn't already been stopped). But by the time you hit destruction, the vtable is no longer available and thus the destructor of base::Thread (and anything it calls) does NOT have access to the vtable of ChromeThread (or my class). So, if you don't explicitly call Stop(), your subclass's CleanUp method will NOT be called. Thus the thread was going away without my CleanUp method ever being called. Obviously this affects more than just base::Thread. And this is also how you can hit errors with pure virtual methods being called. J --~--~-~--~~~---~--~~ 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: Inheritance in gyp configurations
Sounds really powerful...but this scares methough that could just be my
generalized fear of inheritance. However, if we start putting inheritance
into the system, I worry about the level of complexity the gyp specification
language will pick up and the possible breakages of information hiding that
it can entail.
Here's a couple of questions about syntax and semantics:
1) Do you support multiple inheritance? I notice the inherit_from is
specified as an array. That's scaryish.
2) If you do have multiple inheritance, how are conflicts handled? Are
they just rejected, or is there a pre-defined name resolution order? What
would you do with diamond shapes?
3) Is there a way to reference super, or various ancestors?
4) How does this interact with late-resolution variables?
5) How about conditionals? Can we conditionally inherit?
-Albert
On Thu, Oct 29, 2009 at 5:42 PM, Bradley Nelson bradnel...@google.comwrote:
configurations can now inherit from one or more other configurations, and
configurations which are not fully expressed should be marked 'abstract': 1,
So something like this:
'configurations': {
'Common: {
'abstract': 1,
# common settings
},
'Debug': {
'inherit_from': ['Common'],
# Debug specific
},
'Release': {
'inherit_from': ['Common'],
# Release specific
},
},
-BradN
On Thu, Oct 29, 2009 at 5:37 PM, Nick Carter n...@chromium.org wrote:
What does the syntax look like?
- nick
On Thu, Oct 29, 2009 at 3:22 PM, Bradley Nelson bradnel...@google.comwrote:
Hi All,
I've just rolled out an enhancement to gyp to support inheritance in
configurations.
This shouldn't have any noticeable effect other than reducing the
repetition needed for things like Purify/notcmalloc.
I've tested it as best I can, but please let me know if you experience
anything strange with Debug vs Release or with Purify/notcmalloc.
This was primarily meant as a baby step towards supporting x64
configurations in gyp on windows, but I thought I'd let this part soak
first.
-BradN
--~--~-~--~~~---~--~~
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: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 3:59 PM, Antoine Labour pi...@google.com wrote: On Fri, Oct 30, 2009 at 3:54 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 30, 2009 at 3:46 PM, Scott Hess sh...@chromium.org wrote: Just to be clear for those of us who are wobbly on C++, this is because during the constructor or destructor, your object is of the class in question, NOT of the class it will finally be, because in the constructor the subclass has not been constructed, yet, and in the destructor the subclass was already destructed. So calling to the subclass virtual implementation would be bad. Scott Meyers says: http://www.artima.com/cppsource/nevercall.html Is there any way we could modify an object to assert that it can't happen in development? Like scoped_vtable_killer declared in the constructor and destructor which makes calling a virtual method on that object fatal? Or is there any sort of built in compiler warning that we could turn on? I did a bit of searching and was really surprised that I couldn't find any mention of such a thing. The compiler could find if it's called directly from the destructor, but there's no way it'd find your case ! The virtual call happens on another thread. To Scott's question: you can blit NULL into the vtable field, if you know where it is (it's not too hard, but depends on the compiler). You'll know if you call it - you'll die. For the original issue this doesn't work b/c for virtual calls in the constructor/destructor, the compiler may optimize them to be non-virtual. Also, it looks like this keeps biting chromium: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475 Better yet, you could have a static table of functions that print a message before dying and blit that one, but that gets trickier. Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How can we kill scons?
To follow up on this thread, for people who didn't see the related gyp-developer discussion, I submitted the last make fix for the gyp tests today. This was my minimum sanity check before switching any buildbots over to make. I might start with some FYI bots this weekend, then do the main bots next week, though I'll probably wait on that until I have a chance to check on Evan's compile twice issue and get a test case for it. Michael On Thu, Oct 29, 2009 at 2:55 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: I've updated the LinuxBuildInstructions, and moved the old instructions to LinuxSconsBuild which parallels LinuxMakeBuild. I also made a quick attempt at searching for scons in both the Wiki and the Sites pages and updated whatever looked appropriate. Step #1 down. -Albert On Wed, Oct 28, 2009 at 1:47 PM, Antoine Labour pi...@google.com wrote: On Wed, Oct 28, 2009 at 1:37 PM, Evan Martin e...@chromium.org wrote: On Wed, Oct 28, 2009 at 1:23 PM, Albert J. Wong (王重傑) ajw...@chromium.org 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.) That was a regression that I think I fixed. Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
