[chromium-dev] Re: PSA: Virtual dispatch doesn't work (as you might expect) in destructors!
On Fri, Oct 30, 2009 at 5:09 PM, David Levin le...@chromium.org wrote: 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. Good point. Given this, I'd suggest that the poison vtable approach would be better implemented as a compiler feature. When the flag is enabled, the compiler would specifically avoid these optimizations. Perhaps this would only work in debug builds. Erik 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: 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 e...@chromium.org 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: readability extension (experience writeup)
On Sat, Oct 31, 2009 at 4:29 PM, Evan Martin e...@chromium.org wrote: I've updated this to the browser actions API. Thanks for trying again. - 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? The docs on http://code.google.com/chrome/extensions are the ones for the dev channel, and they should be correct. Though there is some support for browser actions on dev right now, it was not complete and the API was in flux, so we purposely didn't document it. If you developed against that, you're probably going to have to change it for the next dev channel (sorry). You can always see the trunk docs, here: http://code.google.com/chrome/extensions/trunk - 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. We have a bug to keep the inspector open (http://crbug.com/25287). It is nontrivial to fix, but we're hoping to get it in for beta. As for knowing which console to look at, I agree it sucks. For now, we're going to have to just document it, but I hope to come up with some kind of master console output later. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fie Foh Fum! I smell the blood of the WebKit-man: MStone:4 is nigh.
The moon is high. The zombies, wizards and various other bizarre beings are prowling the streets. Which could mean only one thing: Tombstone 4 is coming to get us. http://crbug.com/horizon/webkit So be prepared, dear WebKit Chromium people. On Monday, check your bug list: http://crbug.com/?q=owner:me+Mstone:4 Make an effort. Fix yer bugs. Help us escape what could be a terrifying conclusion of this stable release. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
