Re: [webkit-dev] assumption about point packing in multit-touch tests
On Wed, Jul 18, 2012 at 9:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Though the W3C spec allows packing more than one touch point update in a single touch event, it says nothing about how these updates should be packed, so I think that the current tests are too restrictive and should be relaxed to stop assuming anything about how the updates are packed into events. In practice, every port does the exact same thing for the delivery of touch events. It is also what the Web content expects nowadays. It looks like this spec needs an update, not the WebKit tests. Could you please elaborate on how the spec would be updated? Thanks, Tomeu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Using commit-queue doesn't mean you can use build failures
Hi all, Using commit-queue doesn't pardon a committer from causing build failures. Notice that the commit queue only builds runs tests on Chromium Linux port. Thus, any build failure that doesn't manifest itself on Chromium Linux port — namely any JSC-specific or Windows/Mac specific build failures — won't be caught. The current policy specifically says the committer is responsible for making sure his or her patch builds passes tests: http://www.webkit.org/coding/contributing.html So please make sure your patch at least builds if you're landing a patch via commit queue. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Using commit-queue doesn't mean you can use build failures
(from the right address...) Hi, I don't think it is a reasonable expectation especially for non-chromium developers. It is possible for a change to break chromium-linux, chromium-win or chromium-mac, that means developers needs to have Linux, Mac and Windows machines to ensure the successful build since there is no EWS for these configurations. More reasonable baseline would be getting all EWS builds green and/or watching the tree until landed patch goes green. And in my understanding, these are in fact our current norm. Regards, -- morrita On Thu, Jul 19, 2012 at 3:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, Using commit-queue doesn't pardon a committer from causing build failures. Notice that the commit queue only builds runs tests on Chromium Linux port. Thus, any build failure that doesn't manifest itself on Chromium Linux port — namely any JSC-specific or Windows/Mac specific build failures — won't be caught. The current policy specifically says the committer is responsible for making sure his or her patch builds passes tests: http://www.webkit.org/coding/contributing.html So please make sure your patch at least builds if you're landing a patch via commit queue. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Using commit-queue doesn't mean you can use build failures
On Thu, Jul 19, 2012 at 12:39 AM, Hajime Morrita morr...@chromium.orgwrote: It is possible for a change to break chromium-linux, chromium-win or chromium-mac, that means developers needs to have Linux, Mac and Windows machines to ensure the successful build since there is no EWS for these configurations. Sure, I'm not asking them to locally build their patches on every single port configuration. More reasonable baseline would be getting all EWS builds green and/or watching the tree until landed patch goes green. And in my understanding, these are in fact our current norm. This is exactly what I'm asking. If you're landing a patch, you should be at least responsible for making sure things build. It's unreasonable for someone to claim that build failure isn't his or her fault just because he or she used the commit queue. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] assumption about point packing in multit-touch tests
On Wednesday, July 18, 2012 12:53:35 PM ext Benjamin Poulain wrote: On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso to...@tomeuvizoso.net wrote: Though the W3C spec allows packing more than one touch point update in a single touch event, it says nothing about how these updates should be packed, so I think that the current tests are too restrictive and should be relaxed to stop assuming anything about how the updates are packed into events. In practice, every port does the exact same thing for the delivery of touch events. It is also what the Web content expects nowadays. I think it would be better if it were _allowed_ if the platform delivered multiple touch events for individual touch point updates. I mean in some way it is in fact up to the user to the extend that if my mind wants to move two fingers simultaenously it might just happen that one finger moves first and only a few milliseconds later the second finger starts moving. Nevertheless I agree that the tests are good that way because they do require the platform to at least _support_ multiple updates in one event. On a low level that requirement is satisfied by Cocoa touch events, WM_TOUCH on Windows and even the Linux kernel supports it, from the kernel protocol up to protocols like wayland with a specific touch_frame event to indicate the end of a contact point list update with multiple points. It seems it's only XInput that stands out, and Qt for example covers it up again by just remembering the state of the other touch points. But since there is no notion that indicates the end of an multi point touch update, we end up with multiple touch events. It looks like this spec needs an update, not the WebKit tests. I don't think the spec should be changed so that XInput based platforms cannot satisfy the spec requirements. But I agree that the tests are good the way they are because they enforce the requirement to at least possibly support multiple updates in one event. Another argument for keeping the current behaviour in the tests is that the JavaScript API (initTouchEvent) takes a touch _list_, and theoretically JS could send a (synthetic) touch even that way. It would be wrong to split that event up into multiple events with one per changed touch point. So I think it's only fair to require the platform to at least support the same semantics. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] assumption about point packing in multit-touch tests
It looks like this spec needs an update, not the WebKit tests. I don't think the spec should be changed so that XInput based platforms cannot satisfy the spec requirements. But I agree that the tests are good the way they are because they enforce the requirement to at least possibly support multiple updates in one event. It is not unusual to have a provision for implementation details like XInput. Describing how it is supposed to work help making implementations more consistent. Anyway, this should be discussed on the W3C list, not this list. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Last revision known to compile and work on windows
Hi, What svn revision should I get if I want to compile a custom webkit version on windows ? Thanks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Bugzilla migration: Today 5pm PDT
bugs.webkit.org is moving to our new hardware today at 5pm PDT. I apologize for the short notice, but we had some last minute technical issues and weren't sure we would be able to do it, but I also didn't want to postpone this until next week. Downtime will be 1-2 hours. If this timing is especially bad for you, please let me know. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] About WebIDL supplemental interfaces
Hello Webkitters! The latest WD for WebIDL defines a supplemental interface of an interface A as any element of the acyclic graph of interfaces that is connected to A through implements statements or through the inheritance chain of another supplemental interface: http://www.w3.org/TR/WebIDL/#dfn-supplemental-interface However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Hi Andrei I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Currently, no. (Correct me if I'm wrong.) However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental The current WebKitIDL implementation is on the way. Eventually we want to remove the [Supplemental] IDL attribute and support the A implements B syntax as defined in the WebIDL. Do you have any alternative solution to make CSS Regions work without the A implements B syntax? If no, maybe it's time to consider supporting the A implements B syntax (, which would require a substantial amount of work though:-). On Thu, Jul 19, 2012 at 5:08 PM, Andrei Bucur abu...@adobe.com wrote: Hello Webkitters! The latest WD for WebIDL defines a supplemental interface of an interface A as any element of the acyclic graph of interfaces that is connected to A through implements statements or through the inheritance chain of another supplemental interface: http://www.w3.org/TR/WebIDL/#dfn-supplemental-interface However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Kentaro Hara, Tokyo, Japan (http://haraken.info) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Last revision known to compile and work on windows
http://build.webkit.org/waterfall?category=AppleWin Windows release build http://build.webkit.org/builders/Apple%20Win%20Release%20%28Build%29?numbuilds=50 Currently debug build is not working properly I guess... Hope this helps Pravin On Thu, Jul 19, 2012 at 3:49 PM, foru...@smartmobili.com wrote: Hi, What svn revision should I get if I want to compile a custom webkit version on windows ? Thanks __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Hey Kentaro, On 7/19/12 6:20 PM, Kentaro Hara hara...@chromium.org wrote: Hi Andrei I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Currently, no. (Correct me if I'm wrong.) However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental The current WebKitIDL implementation is on the way. Eventually we want to remove the [Supplemental] IDL attribute and support the A implements B syntax as defined in the WebIDL. Do you have any alternative solution to make CSS Regions work without the A implements B syntax? If no, maybe it's time to consider supporting the A implements B syntax (, which would require a substantial amount of work though:-). The only way I can see this implemented without the new syntax is by writing some crazy hacks, probably very similar with how EventTarget works. And even then I'm not sure everything will work out well. Right now, hacking things in does not seem to worth the effort, especially if it's going to be removed once the implements syntax gets in. I'm open to suggestions though :). However, it would be nice to have the new syntax on board sooner than later. Is there a roadmap for adding this in WebKit? I'm sure you are very busy so having a timeline would allow other hackers help move the implementation forward :). Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
On Thu, Jul 19, 2012 at 9:29 AM, Andrei Bucur abu...@adobe.com wrote: Hey Kentaro, On 7/19/12 6:20 PM, Kentaro Hara hara...@chromium.org wrote: Hi Andrei I'm asking this because CSS Regions spec defines the Region interface as an WebIDL supplemental interface that needs to be implemented by any object that can be a region (Element, Pseudo elements etc.). Is there a way in WebKit to write an interface that implements another as specified by WebIDL? Currently, no. (Correct me if I'm wrong.) However, WebKitIDL defines Supplemental more like a partial interface: http://trac.webkit.org/wiki/WebKitIDL#Supplemental The current WebKitIDL implementation is on the way. Eventually we want to remove the [Supplemental] IDL attribute and support the A implements B syntax as defined in the WebIDL. Do you have any alternative solution to make CSS Regions work without the A implements B syntax? If no, maybe it's time to consider supporting the A implements B syntax (, which would require a substantial amount of work though:-). The only way I can see this implemented without the new syntax is by writing some crazy hacks, probably very similar with how EventTarget works. And even then I'm not sure everything will work out well. Right now, hacking things in does not seem to worth the effort, especially if it's going to be removed once the implements syntax gets in. I'm open to suggestions though :). Can you say what specifically in the CSS regions spec is giving you trouble? Adam However, it would be nice to have the new syntax on board sooner than later. Is there a roadmap for adding this in WebKit? I'm sure you are very busy so having a timeline would allow other hackers help move the implementation forward :). Thanks, Andrei. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Hello Adam, Sure: http://www.w3.org/TR/2012/WD-css3-regions-20120503/#the-region-interface The spec does not explicitly states that the Region should be supplemental, however after raising some issues on www-style ( http://lists.w3.org/Archives/Public/www-style/2012Jul/0251.html ) and talking them through (offline) it seemed the best way to solve them was making Region supplemental for Element and any other object that could become region. Right now, I'm feeling out the situation to see how feasible this is to be implemented in WebKit. Andrei. From: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org Date: Thursday, July 19, 2012 7:31 PM To: Andrei Bucur abu...@adobe.commailto:abu...@adobe.com Cc: Kentaro Hara hara...@chromium.orgmailto:hara...@chromium.org, webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About WebIDL supplemental interfaces Can you say what specifically in the CSS regions spec is giving you trouble? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Update on the chromium-android port
Hi WebKit, I wanted to give you an update on the progress of the chromium-android port. It's been almost a year since Andrei Popescu announced that we were refactoring the Android port to be based on Chromium: http://lists.webkit.org/pipermail/webkit-dev/2011-August/017738.html. Since, then we've made a lot of progress, https://bugs.webkit.org/showdependencytree.cgi?id=66687hide_resolved=0, but there's still a lot of work left to do: https://bugs.webkit.org/showdependencytree.cgi?id=66687hide_resolved=1. First of all, I would like to thank the WebKit community for being supportive of this effort. I know there have been some contentious issues, but, by and large, we've found workable solutions. It's easy to forget that not all open-source projects are as healthy as WebKit. Having watched other folks upstream their ports of WebKit, I know that it can be a bit hard to get a broader picture of how things are progressing just by following the individual bugs and patches. To give you a better sense of where we are today, I'd like to share a couple milestones that we've passed recently: 1) The branch now has less than 5000 lines of code changed from trunk. Of these changes, about half are in WebCore and half are in the WebKit layer. The remaining changes to WebCore are mainly related to overflow scrolling https://bugs.webkit.org/show_bug.cgi?id=78862 and text autosizing https://bugs.webkit.org/show_bug.cgi?id=84186. 2) The chromium-android port is now able to run both text and image tests in DumpRenderTree. Many text-based tests are passing, but most image-based tests as failing because of some bugs in font rendering and color swizzling. The next milestone we're aiming for is API compatibility between the branch and trunk. Once we have API compatibility, we'll be able to build Chromium on Android with WebKit either from the branch or from trunk. If you're interested in following our progress towards this milestone, you can CC yourself on this meta bug: https://bugs.webkit.org/show_bug.cgi?id=91648 Thanks again, and happy hacking! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
What else can become a region besides an element? If there aren't too many interfaces, we can just copy/paste this stanza into each IDL, like we do for EventTarget. If there are a lot of them, then I agree that you'll probably want a fancier Supplemental feature. One way to approach that is to make the [Supplemental] attribute take a list of interfaces. That should be straightforward to implement given our current implementation of Supplemental. Adam On Thu, Jul 19, 2012 at 9:58 AM, Andrei Bucur abu...@adobe.com wrote: Hello Adam, Sure: http://www.w3.org/TR/2012/WD-css3-regions-20120503/#the-region-interface The spec does not explicitly states that the Region should be supplemental, however after raising some issues on www-style ( http://lists.w3.org/Archives/Public/www-style/2012Jul/0251.html ) and talking them through (offline) it seemed the best way to solve them was making Region supplemental for Element and any other object that could become region. Right now, I'm feeling out the situation to see how feasible this is to be implemented in WebKit. Andrei. From: Adam Barth aba...@webkit.org Date: Thursday, July 19, 2012 7:31 PM To: Andrei Bucur abu...@adobe.com Cc: Kentaro Hara hara...@chromium.org, webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About WebIDL supplemental interfaces Can you say what specifically in the CSS regions spec is giving you trouble? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On 19.07.2012 19:53, Andreas Kling wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com mailto:beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org mailto:alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com mailto:beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org mailto:alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here... I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? Maybe because the displayed information is not appropriate? E.g., you would like someString.utf8().data() instead of someString FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? Regards, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? A possible technical reason - that I am 100% theorizing about - is that it might bring in more libraries at link time or runtime since it would be the absolute first use of stream operators in the project. That possibility aside, the stronger part of my objection is language purity. WebCore uses C++ as C with classes and I don't think it's worth it to confuse new (or existing) contributors about that going forward. Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. Definitely. ~Brady -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 3:01 PM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: On 19.07.2012 19:53, Andreas Kling wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? Say you have a low powered machine that can't link WebKit in debug even stripped out of SVG etc... Maybe because the displayed information is not appropriate? E.g., you would like someString.utf8().data() instead of someString FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. I think we have some of those. Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? Regards, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About WebIDL supplemental interfaces
Adam, Currently, an Element is the only thing represented in the object model that can become a CSS Region. Pseudo-elements (::before and ::after) can become CSS Regions, but AFAIK there isn't yet a representation of those in the OM. I'm hoping this changes in the future (I'm working on a spec that addresses this), so that could be a second copy. I can construct a region chain now that includes pseudo-element Regions, and the NamedFlow interface is supposed to return a sequence of Regions from its getRegions() method. So ideally we'd have a way of returning a Region interface for those pseudo-elements that have been added to the region chain. Alan On 7/19/12 10:50 AM, Adam Barth aba...@webkit.org wrote: What else can become a region besides an element? If there aren't too many interfaces, we can just copy/paste this stanza into each IDL, like we do for EventTarget. If there are a lot of them, then I agree that you'll probably want a fancier Supplemental feature. One way to approach that is to make the [Supplemental] attribute take a list of interfaces. That should be straightforward to implement given our current implementation of Supplemental. Adam On Thu, Jul 19, 2012 at 9:58 AM, Andrei Bucur abu...@adobe.com wrote: Hello Adam, Sure: http://www.w3.org/TR/2012/WD-css3-regions-20120503/#the-region-interface The spec does not explicitly states that the Region should be supplemental, however after raising some issues on www-style ( http://lists.w3.org/Archives/Public/www-style/2012Jul/0251.html ) and talking them through (offline) it seemed the best way to solve them was making Region supplemental for Element and any other object that could become region. Right now, I'm feeling out the situation to see how feasible this is to be implemented in WebKit. Andrei. From: Adam Barth aba...@webkit.org Date: Thursday, July 19, 2012 7:31 PM To: Andrei Bucur abu...@adobe.com Cc: Kentaro Hara hara...@chromium.org, webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About WebIDL supplemental interfaces Can you say what specifically in the CSS regions spec is giving you trouble? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: On 19.07.2012 19:53, Andreas Kling wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? The beauty of this discussion is that people who prefer the purity of using only the debugger can continue using only the debugger and ignore what printf'ers need to do. That said, to address your question of what is your problem with using a debugger, many issues in WebKit are highly timing related, or highly dependent on multiple threads or even multiple processes interacting. Many crashes I've had the pleasure of working on go away simply by hitting a breakpoint, and many misbehaviors correct themselves the same way. Most of the time the debugger is good enough for me. Other times the mix of the debugger and printf's has been what cracked the case. Occasionally ignoring the debugger completely and viewing an event stream of printfs has been the only reasonable way to monitor the complex interactions of what is going on. FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Some of us don't use gdb. I'm not sure if these work directly in lldb or if there is an lldb alternative. But... Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? Having a set of debug-build-only functions is also useful in the debugger without having to turn to the pretty-printers. I don't see how adding printf helpers for debug builds negatively affects debugger purists, but I do see how it helps at least a handful of prolific contributors to the project be more productive. Thanks, ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
19.07.2012, 22:06, Alexis Menard alexis.men...@openbossa.org: Say you have a low powered machine that can't link WebKit in debug even stripped out of SVG etc... ... or you want to debug on device which cannot run debug WebKit under gdb because of memory limit. ... or you want to print some value from code which is executed too many times during page load and setting breakpoint is just non-productive. -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
One reason for preferring printf syntax is that it results in dramatically more compact code. In JSC we take advantage of this to have debug printf support built even in release builds. So or example if you want CodeBlock to print itself in a release build, you don't first have to #define a bunch of things - the relevant method is already built. The reason for the compactness is the number of calls for a typical printing action. Consider this: dataLog(foo %d bar %x baz %p\n, a, b, c); This is one procedure call and one string constant. Note that the machine code to get the string constant is often as big as a procedure call, on some platforms. Now consider the stream form: thingy foo a bar someWeirdNonsenseToEnableHex b baz c endl; This is 8 procedure calls and three string constants. This code will be somewhere around 8 times fatter. Hence, you will be less likely to want to enable such debug statements in release builds both due to fears concerning unnecessary increases in binary size, and unnecessary increases in compile times. And I'm not even going to start complaining about how unnatural it is to set padding preferences, switch to hex, etc. -Filip On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On 19.07.2012 20:15, Brady Eidson wrote: On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com mailto:oliver.bucht...@googlemail.com wrote: On 19.07.2012 19:53, Andreas Kling wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com mailto:beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org mailto:alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com mailto:beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org mailto:alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? The beauty of this discussion is that people who prefer the purity of using only the debugger can continue using only the debugger and ignore what printf'ers need to do. That said, to address your question of what is your problem with using a debugger, many issues in WebKit are highly timing related, or highly dependent on multiple threads or even multiple processes interacting. Many crashes I've had the pleasure of working on go away simply by hitting a breakpoint, and many misbehaviors correct themselves the same way. Most of the time the debugger is good enough for me. Other times the mix of the debugger and printf's has been what cracked the case. Occasionally ignoring the debugger completely and viewing an event stream of printfs has been the only reasonable way to monitor the complex interactions of what is going on. FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Some of us don't use gdb. I'm not sure if these work directly in lldb or if there is an lldb alternative. But... Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? Having a set of debug-build-only functions is also useful in the debugger without having to turn to the pretty-printers. I don't see how adding printf helpers for debug builds negatively affects debugger purists, but I do see how it helps at least a handful of prolific contributors to the project be more productive. Thanks, ~Brady Accepted. Regards, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? Maybe because the displayed information is not appropriate? E.g., you would like someString.utf8().data() instead of someString FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? I would love to see a set of useful pretty printers that we could share. Do you have any we could use as a starting point? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 7:20 PM, Filip Pizlo fpi...@apple.com wrote: dataLog(foo %d bar %x baz %p\n, a, b, c); Reasoning and valid arguments aside, that actually looks totally beautiful. Do want. -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
I should note that WTF already has an API for this. See DataLog.h. In JSC we've been using it quite extensively to add pretty printers for a bunch of classes. -Filip On Jul 19, 2012, at 11:03 AM, Brady Eidson beid...@apple.com wrote: On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? A possible technical reason - that I am 100% theorizing about - is that it might bring in more libraries at link time or runtime since it would be the absolute first use of stream operators in the project. That possibility aside, the stronger part of my objection is language purity. WebCore uses C++ as C with classes and I don't think it's worth it to confuse new (or existing) contributors about that going forward. Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. Definitely. ~Brady -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On 19.07.2012 20:26, Maciej Stachowiak wrote: On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? Maybe because the displayed information is not appropriate? E.g., you would like someString.utf8().data() instead of someString FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? I would love to see a set of useful pretty printers that we could share. Do you have any we could use as a starting point? Regards, Maciej I have written some for other projects... not yet for webkit. Brady noted that there are some of them around? I could provide some pretty-printers, if necessary... Regards, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo fpi...@apple.com wrote: One reason for preferring printf syntax is that it results in dramatically more compact code. In JSC we take advantage of this to have debug printf support built even in release builds. So or example if you want CodeBlock to print itself in a release build, you don't first have to #define a bunch of things - the relevant method is already built. As the Changelog said in the patch, thingy() ... are not meant to land but to help you locally. The reason for the compactness is the number of calls for a typical printing action. Consider this: dataLog(foo %d bar %x baz %p\n, a, b, c); This is one procedure call and one string constant. Note that the machine code to get the string constant is often as big as a procedure call, on some platforms. Now consider the stream form: thingy foo a bar someWeirdNonsenseToEnableHex b baz c endl; Ok you give me a valid example (and nice looking) for you in JSC. Nobody force you to use the thingy if you don't like it. It seems low level printf is better for you, great! Now see another use case : LayoutRect rect; printf(Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(), rect.height()); for me to get the rect values. thingy() rect; (as LayoutRect could have a overload, I give an example in the patch with IntRect) Granted we can achieve it with a printf(Rect is %s, debug(rect)); same provided that debug() for a LayoutRect is implemented. One way or another I'm fine. I just want to ease the process here. This is 8 procedure calls and three string constants. This code will be somewhere around 8 times fatter. Hence, you will be less likely to want to enable such debug statements in release builds both due to fears concerning unnecessary increases in binary size, and unnecessary increases in compile times. As I said, we do not want to land these thingy() . And I'm not even going to start complaining about how unnatural it is to set padding preferences, switch to hex, etc. Which is not what the class is meant to solve. -Filip On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 11:15 AM, Brady Eidson beid...@apple.com wrote: On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: On 19.07.2012 19:53, Andreas Kling wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling Hi, I am probably one of those people who much dislike printf-debugging. What is your problem with using a debugger? The beauty of this discussion is that people who prefer the purity of using only the debugger can continue using only the debugger and ignore what printf'ers need to do. I usually avoid using printfs at all cost and prefer using a proper debugger with IDE front end. However, That said, to address your question of what is your problem with using a debugger, many issues in WebKit are highly timing related, or highly dependent on multiple threads or even multiple processes interacting. Many crashes I've had the pleasure of working on go away simply by hitting a breakpoint, and many misbehaviors correct themselves the same way. Most of the time the debugger is good enough for me. Other times the mix of the debugger and printf's has been what cracked the case. Occasionally ignoring the debugger completely and viewing an event stream of printfs has been the only reasonable way to monitor the complex interactions of what is going on. I can't agree more on these points. Also, if you have to debug a function that gets called million times and only subset of them matter, then going through each call with gdb is much less productive than printf based logging at times. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 11:35 AM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: On 19.07.2012 20:26, Maciej Stachowiak wrote: On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.buchtala@googlemail.**com oliver.bucht...@googlemail.com wrote: FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? I would love to see a set of useful pretty printers that we could share. Do you have any we could use as a starting point? I have written some for other projects... not yet for webkit. Brady noted that there are some of them around? I could provide some pretty-printers, if necessary... There are some already in WebKit/Tools/gdb/webkit.py. It already includes formatters for WTF::String, WTF::CString and more. Feel free to add more to it. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
But I do want a debugging utility to does land, is always compiled in, and that everyone enjoys using. -Filip On Jul 19, 2012, at 11:37 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo fpi...@apple.com wrote: One reason for preferring printf syntax is that it results in dramatically more compact code. In JSC we take advantage of this to have debug printf support built even in release builds. So or example if you want CodeBlock to print itself in a release build, you don't first have to #define a bunch of things - the relevant method is already built. As the Changelog said in the patch, thingy() ... are not meant to land but to help you locally. The reason for the compactness is the number of calls for a typical printing action. Consider this: dataLog(foo %d bar %x baz %p\n, a, b, c); This is one procedure call and one string constant. Note that the machine code to get the string constant is often as big as a procedure call, on some platforms. Now consider the stream form: thingy foo a bar someWeirdNonsenseToEnableHex b baz c endl; Ok you give me a valid example (and nice looking) for you in JSC. Nobody force you to use the thingy if you don't like it. It seems low level printf is better for you, great! Now see another use case : LayoutRect rect; printf(Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(), rect.height()); for me to get the rect values. thingy() rect; (as LayoutRect could have a overload, I give an example in the patch with IntRect) Granted we can achieve it with a printf(Rect is %s, debug(rect)); same provided that debug() for a LayoutRect is implemented. One way or another I'm fine. I just want to ease the process here. This is 8 procedure calls and three string constants. This code will be somewhere around 8 times fatter. Hence, you will be less likely to want to enable such debug statements in release builds both due to fears concerning unnecessary increases in binary size, and unnecessary increases in compile times. As I said, we do not want to land these thingy() . And I'm not even going to start complaining about how unnatural it is to set padding preferences, switch to hex, etc. Which is not what the class is meant to solve. -Filip On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 4:11 PM, Filip Pizlo fpi...@apple.com wrote: But I do want a debugging utility to does land, is always compiled in, and that everyone enjoys using. The header itself in the patch would land so you can use it right away (and compile even in release). But the actual traces or thingy() calls in the code are not meant to stay/land. I'm not sure I'm clear. -Filip On Jul 19, 2012, at 11:37 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo fpi...@apple.com wrote: One reason for preferring printf syntax is that it results in dramatically more compact code. In JSC we take advantage of this to have debug printf support built even in release builds. So or example if you want CodeBlock to print itself in a release build, you don't first have to #define a bunch of things - the relevant method is already built. As the Changelog said in the patch, thingy() ... are not meant to land but to help you locally. The reason for the compactness is the number of calls for a typical printing action. Consider this: dataLog(foo %d bar %x baz %p\n, a, b, c); This is one procedure call and one string constant. Note that the machine code to get the string constant is often as big as a procedure call, on some platforms. Now consider the stream form: thingy foo a bar someWeirdNonsenseToEnableHex b baz c endl; Ok you give me a valid example (and nice looking) for you in JSC. Nobody force you to use the thingy if you don't like it. It seems low level printf is better for you, great! Now see another use case : LayoutRect rect; printf(Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(), rect.height()); for me to get the rect values. thingy() rect; (as LayoutRect could have a overload, I give an example in the patch with IntRect) Granted we can achieve it with a printf(Rect is %s, debug(rect)); same provided that debug() for a LayoutRect is implemented. One way or another I'm fine. I just want to ease the process here. This is 8 procedure calls and three string constants. This code will be somewhere around 8 times fatter. Hence, you will be less likely to want to enable such debug statements in release builds both due to fears concerning unnecessary increases in binary size, and unnecessary increases in compile times. As I said, we do not want to land these thingy() . And I'm not even going to start complaining about how unnatural it is to set padding preferences, switch to hex, etc. Which is not what the class is meant to solve. -Filip On Jul 19, 2012, at 10:53 AM, Andreas Kling kl...@webkit.org wrote: On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson beid...@apple.com wrote: On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote: On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, For those who secretly use printf debugging :). I know the recommended way is to use a debugger and it's not the point of this discussion. A lot of us do this, and sometimes it's necessary. I agree with the gripe and support adding something easier. So I propose wtf() and its stream operator. Usage : wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322 There is no reason to bring in stream operators - that are willfully absent from WebCore - just for debugging. But it's really nice for that purpose, and somehow match std::cout And we quite purposefully don't use std::cout in the project. Overloading functions works just as well. I'm not sure to understand what you mean here… I mean relying on C++'s overloading of functions for the different types you'd like to printf debug. void debug(WebCore::String); void debug(WebCore::Frame*); void debug(WebCore::Node*); etc etc etc. debug(someFrame); debug(someNode); debug(someString); Especially that last one would help me from remembering how to type printf(%s, someString.utf8().data()) which is all I've ever really wanted. Hello fellow printfers! While I'm just as ashamed of my printf habits as the next guy, I think it'd be great if we could move forward with this somehow. Coming from a background in Qt, the stream operator syntax looks perfectly normal to me, perhaps you could expand on why we want to avoid using these in WebKit. Is there a technical reason, or is it more of a language purity issue? Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods as suggested would still be massively useful. -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Alexis
Re: [webkit-dev] About WebIDL supplemental interfaces
It sounds like you don't have a problem today, but you might have a problem in the future. I'd recommend going with the simple solution today and worrying about future problems in the future. Adam On Thu, Jul 19, 2012 at 11:04 AM, Alan Stearns stea...@adobe.com wrote: Adam, Currently, an Element is the only thing represented in the object model that can become a CSS Region. Pseudo-elements (::before and ::after) can become CSS Regions, but AFAIK there isn't yet a representation of those in the OM. I'm hoping this changes in the future (I'm working on a spec that addresses this), so that could be a second copy. I can construct a region chain now that includes pseudo-element Regions, and the NamedFlow interface is supposed to return a sequence of Regions from its getRegions() method. So ideally we'd have a way of returning a Region interface for those pseudo-elements that have been added to the region chain. Alan On 7/19/12 10:50 AM, Adam Barth aba...@webkit.org wrote: What else can become a region besides an element? If there aren't too many interfaces, we can just copy/paste this stanza into each IDL, like we do for EventTarget. If there are a lot of them, then I agree that you'll probably want a fancier Supplemental feature. One way to approach that is to make the [Supplemental] attribute take a list of interfaces. That should be straightforward to implement given our current implementation of Supplemental. Adam On Thu, Jul 19, 2012 at 9:58 AM, Andrei Bucur abu...@adobe.com wrote: Hello Adam, Sure: http://www.w3.org/TR/2012/WD-css3-regions-20120503/#the-region-interface The spec does not explicitly states that the Region should be supplemental, however after raising some issues on www-style ( http://lists.w3.org/Archives/Public/www-style/2012Jul/0251.html ) and talking them through (offline) it seemed the best way to solve them was making Region supplemental for Element and any other object that could become region. Right now, I'm feeling out the situation to see how feasible this is to be implemented in WebKit. Andrei. From: Adam Barth aba...@webkit.org Date: Thursday, July 19, 2012 7:31 PM To: Andrei Bucur abu...@adobe.com Cc: Kentaro Hara hara...@chromium.org, webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] About WebIDL supplemental interfaces Can you say what specifically in the CSS regions spec is giving you trouble? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Mystery of resolve_global bytecode instruction
On Jul 19, 2012, at 2:28 AM, wingoog moon wingoo...@gmail.com wrote:
Hi all.
I'm trying to understand how resolve_global instruction works for several
days. Let's look at the code
void JIT::emit_op_resolve_global(Instruction* currentInstruction, bool)
{
// Fast case
void* globalObject = m_codeBlock-globalObject();
unsigned currentIndex = m_globalResolveInfoIndex++;
GlobalResolveInfo* resolveInfoAddress =
(m_codeBlock-globalResolveInfo(currentIndex));
// Check Structure of global object
move(TrustedImmPtr(globalObject), regT0); //loads address of globalObject
to eax(regT0)
move(TrustedImmPtr(resolveInfoAddress), regT2);// loads address of
resolveInfoAddress to ecx(regT2)
loadPtr(Address(regT2, OBJECT_OFFSETOF(GlobalResolveInfo, structure)),
regT1);
addSlowCase(branchPtr(NotEqual, regT1, Address(regT0,
JSCell::structureOffset(; // Structures don't match // Do some checking
// Load cached property
// Assume that the global object always uses external storage.
loadPtr(Address(regT0, OBJECT_OFFSETOF(JSGlobalObject,
m_propertyStorage)), regT0); // loads m_propertyStorage to eax
// Here is interesting thing happens
// offset member of GlobalResolveInfo class is always 0;
No, it isn't. It may be initially zero, but the offset changes.
load32(Address(regT2, OBJECT_OFFSETOF(GlobalResolveInfo, offset)), regT1);
//move value of GlobalResolveInfo offset member(it's always 0 ) to edx(regT1)
//So here we always mov same value to eax(regT0), regardless of whether our
global Array , String or Object
loadPtr(BaseIndex(regT0, regT1, ScalePtr), regT0);
emitValueProfilingSite();
emitPutVirtualRegister(currentInstruction[1].u.operand);
}
So
1. What is mystery of this instruction, how it's really works let's say for
this example???
var a=Array(5);
var s=String;
var o=Object;
2. What is in m_propertyStorage, and when it's sets?
In your version of the code (which is a bit old), m_propertyStorage points to
an array that holds the values of all of the properties of the object.
Thanks for attention!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 10, 2012, at 8:52 AM, Brady Eidson beid...@apple.com wrote:
On Jul 10, 2012, at 5:25 AM, Alexis Menard alexis.men...@openbossa.org
wrote:
On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson beid...@apple.com wrote:
On Jul 9, 2012, at 2:43 PM, Alexis Menard alexis.men...@openbossa.org
wrote:
Hi,
For those who secretly use printf debugging :). I know the
recommended way is to use a debugger and it's not the point of this
discussion.
A lot of us do this, and sometimes it's necessary. I agree with the gripe
and support adding something easier.
So I propose wtf() and its stream operator.
Usage :
wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322
There is no reason to bring in stream operators - that are willfully absent
from WebCore - just for debugging.
But it's really nice for that purpose, and somehow match std::cout
And we quite purposefully don't use std::cout in the project.
Overloading functions works just as well.
I'm not sure to understand what you mean here…
I mean relying on C++'s overloading of functions for the different types
you'd like to printf debug.
void debug(WebCore::String);
void debug(WebCore::Frame*);
void debug(WebCore::Node*);
etc etc etc.
debug(someFrame);
debug(someNode);
debug(someString);
Especially that last one would help me from remembering how to type
printf(%s, someString.utf8().data()) which is all I've ever really wanted.
In principle, we could also have this support multiple arguments, so you could
write:
debug(frame: , someFrame, node: , someNode, string, someString);
This would be no more verbose than the style, but could compile to a single
function call at the call site and therefore could be relatively compact. I
would find this easier to deal with than a unary function or a printf-style
format string. The way you'd do this is by defining template functions which
call a unary overloaded function for each argument:
templatetypename A, typename B debug(A a, B b)
{
debug(a);
debug(b);
}
templatetypename A, typename B, typename C debug(A a, B b, C c)
{
debug(a);
debug(b);
debug(c);
}
templatetypename A, typename B, typename C, typename D debug(A a, B b, C c, D
d)
{
debug(a);
debug(b);
debug(c);
debug(d);
}
... and so on up to some reasonable number of arguments.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 19, 2012, at 2:46 PM, Antti Koivisto akoivi...@gmail.com wrote:
Maciej Stachowiak m...@apple.com kirjoitti 20.7.2012 kello 0.27:
In principle, we could also have this support multiple arguments, so you
could write:
debug(frame: , someFrame, node: , someNode, string, someString);
I think this is the way to go for the easy syntax. A format string version
should also be available.
I'm totally on board with this, too.
~Brady
antti
This would be no more verbose than the style, but could compile to a
single function call at the call site and therefore could be relatively
compact. I would find this easier to deal with than a unary function or a
printf-style format string. The way you'd do this is by defining template
functions which call a unary overloaded function for each argument:
templatetypename A, typename B debug(A a, B b)
{
debug(a);
debug(b);
}
templatetypename A, typename B, typename C debug(A a, B b, C c)
{
debug(a);
debug(b);
debug(c);
}
templatetypename A, typename B, typename C, typename D debug(A a, B b, C
c, D d)
{
debug(a);
debug(b);
debug(c);
debug(d);
}
... and so on up to some reasonable number of arguments.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On 07/19/2012 11:27 PM, Maciej Stachowiak wrote:
On Jul 10, 2012, at 8:52 AM, Brady Eidsonbeid...@apple.com wrote:
On Jul 10, 2012, at 5:25 AM, Alexis Menardalexis.men...@openbossa.org wrote:
On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidsonbeid...@apple.com wrote:
On Jul 9, 2012, at 2:43 PM, Alexis Menardalexis.men...@openbossa.org wrote:
Hi,
For those who secretly use printf debugging :). I know the
recommended way is to use a debugger and it's not the point of this
discussion.
A lot of us do this, and sometimes it's necessary. I agree with the gripe and
support adding something easier.
So I propose wtf() and its stream operator.
Usage :
wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322
There is no reason to bring in stream operators - that are willfully absent
from WebCore - just for debugging.
But it's really nice for that purpose, and somehow match std::cout
And we quite purposefully don't use std::cout in the project.
Overloading functions works just as well.
I'm not sure to understand what you mean here…
I mean relying on C++'s overloading of functions for the different types you'd
like to printf debug.
void debug(WebCore::String);
void debug(WebCore::Frame*);
void debug(WebCore::Node*);
etc etc etc.
debug(someFrame);
debug(someNode);
debug(someString);
Especially that last one would help me from remembering how to type printf(%s,
someString.utf8().data()) which is all I've ever really wanted.
In principle, we could also have this support multiple arguments, so you could
write:
debug(frame: , someFrame, node: , someNode, string, someString);
This would be no more verbose than the style, but could compile to a single
function call at the call site and therefore could be relatively compact. I would
find this easier to deal with than a unary function or a printf-style format string.
The way you'd do this is by defining template functions which call a unary overloaded
function for each argument:
templatetypename A, typename B debug(A a, B b)
{
debug(a);
debug(b);
}
templatetypename A, typename B, typename C debug(A a, B b, C c)
{
debug(a);
debug(b);
debug(c);
}
templatetypename A, typename B, typename C, typename D debug(A a, B b, C c,
D d)
{
debug(a);
debug(b);
debug(c);
debug(d);
}
... and so on up to some reasonable number of arguments.
But neither these compile to a single function call. Or we could define
simple inline debug() overrides but we could also do that with the
stream operator. And anyway, if the actual calls are not supposed to
land than it doesn't matter how compact it is. For me the stream
operator is a bit nicer.
-kbalazs
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 19, 2012, at 2:58 PM, Balazs Kelemen kbal...@webkit.org wrote:
On 07/19/2012 11:27 PM, Maciej Stachowiak wrote:
On Jul 10, 2012, at 8:52 AM, Brady Eidsonbeid...@apple.com wrote:
On Jul 10, 2012, at 5:25 AM, Alexis Menardalexis.men...@openbossa.org
wrote:
On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidsonbeid...@apple.com wrote:
On Jul 9, 2012, at 2:43 PM, Alexis Menardalexis.men...@openbossa.org
wrote:
Hi,
For those who secretly use printf debugging :). I know the
recommended way is to use a debugger and it's not the point of this
discussion.
A lot of us do this, and sometimes it's necessary. I agree with the
gripe and support adding something easier.
So I propose wtf() and its stream operator.
Usage :
wtf()HelloWorld34.53322323; will output : Hello World 3
4.53322
There is no reason to bring in stream operators - that are willfully
absent from WebCore - just for debugging.
But it's really nice for that purpose, and somehow match std::cout
And we quite purposefully don't use std::cout in the project.
Overloading functions works just as well.
I'm not sure to understand what you mean here…
I mean relying on C++'s overloading of functions for the different types
you'd like to printf debug.
void debug(WebCore::String);
void debug(WebCore::Frame*);
void debug(WebCore::Node*);
etc etc etc.
debug(someFrame);
debug(someNode);
debug(someString);
Especially that last one would help me from remembering how to type
printf(%s, someString.utf8().data()) which is all I've ever really
wanted.
In principle, we could also have this support multiple arguments, so you
could write:
debug(frame: , someFrame, node: , someNode, string, someString);
This would be no more verbose than the style, but could compile to a
single function call at the call site and therefore could be relatively
compact. I would find this easier to deal with than a unary function or a
printf-style format string. The way you'd do this is by defining template
functions which call a unary overloaded function for each argument:
templatetypename A, typename B debug(A a, B b)
{
debug(a);
debug(b);
}
templatetypename A, typename B, typename C debug(A a, B b, C c)
{
debug(a);
debug(b);
debug(c);
}
templatetypename A, typename B, typename C, typename D debug(A a, B b, C
c, D d)
{
debug(a);
debug(b);
debug(c);
debug(d);
}
... and so on up to some reasonable number of arguments.
But neither these compile to a single function call. Or we could define
simple inline debug() overrides but we could also do that with the stream
operator. And anyway, if the actual calls are not supposed to land than it
doesn't matter how compact it is. For me the stream operator is a bit nicer.
This goal of not landing the actual calls is nice in theory, but we quickly
found in JSC that it's impractical. We did this for a while: each time someone
needed to debug something, they'd add some printf's, find the bug, delete the
printf's, land the change. Then the next person to debug the code would add in
the same printf's, find another bug, delete those printf's again, and land the
change. Rinse and repeat. This got horrible very quickly.
So instead, we decided on the dataLog() API, and made the policy that for any
sizeable set of dataLog() calls that were found to be useful for a particular
debugging task, we would encapsulate them behind a dump() method on the
relevant class and land that method along with the fixes. The thing that we
would _not_ land is the call to the dump() method. The point being that it's
easier to add back in the call to dump(), than it is to add back in all of the
calls to dataLog(). And even in some cases, we did land the call to dump(),
behind a check of some flag that can be flipped in one .cpp file or via an
environment variable, or even via a command-line switch if you wanted to go so
far.
We've found that this is nicer in the long term and has sped up debugging for a
lot of common scenarios.
Thus, I tend to think that we want to come up with a debug printing API that
produces sufficiently compact code that this is practical. I kind of like
Maciej's approach; I think it could work, though you risk template bloat. A
good compiler and linker will probably reduce that bloat, but such things are
imperfect.
It's also possible that our obsession with ensuring that the debug code (i.e.
the innards of the dump() methods) is compact is unfounded. With the dataLog()
API I found that it generally adds much less than 1% to the size of the
JavaScriptCore library, so we declared victory. But maybe we can give
ourselves more latitude and use a nicer API.
In summary, I'm not arguing against having a nicer debug API than the current
dataLog(); I'm arguing quite the opposite: that we should investigate such an
API, and that the API should be robust enough that we
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Jul 19, 2012, at 3:09 PM, Filip Pizlo fpi...@apple.com wrote: On Jul 19, 2012, at 2:58 PM, Balazs Kelemen kbal...@webkit.org wrote: But neither these compile to a single function call. Or we could define simple inline debug() overrides but we could also do that with the stream operator. And anyway, if the actual calls are not supposed to land than it doesn't matter how compact it is. For me the stream operator is a bit nicer. This goal of not landing the actual calls is nice in theory, but we quickly found in JSC that it's impractical. We did this for a while: each time someone needed to debug something, they'd add some printf's, find the bug, delete the printf's, land the change. Then the next person to debug the code would add in the same printf's, find another bug, delete those printf's again, and land the change. Rinse and repeat. This got horrible very quickly. There's also been an ebb and flow of this with LOG() in WebCore and WebKit over the years. Currently we're in a long ebb... I used to be a proponent of checking in sensible LOG statements that multiple people could benefit from, but the syntax of having only printf() style formatters quickly make many potentially useful statements unwieldily. This new proposal has the potential to clean up old LOG's and more easily introduce new ones going forward. In summary, I'm not arguing against having a nicer debug API than the current dataLog(); I'm arguing quite the opposite: that we should investigate such an API, and that the API should be robust enough that we land not just the API but also allow for the landing of dump() methods for classes that webkittens find themselves having to frequently add printf-style debugging to. I wasn't originally considering the outcome of this thread to be a new log() pattern that we could actually land in code. But seeing the form of Maciej's proposal has me tacitly excited. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Is bugzilla down ?
Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is bugzilla down ?
See my earlier email about the migration. -Bill On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is bugzilla down ?
The notification was sent when I was sleeping. I read it now. Thanks, Gyuyoung. -Original Message- From: William Siegrist [mailto:wsiegr...@apple.com] Sent: Friday, July 20, 2012 10:36 AM To: gyuyoung@samsung.com Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Is bugzilla down ? See my earlier email about the migration. -Bill On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Bugzilla migration: Today 5pm PDT
On Jul 19, 2012, at 7:25 AM, William Siegrist wsiegr...@apple.com wrote: bugs.webkit.org is moving to our new hardware today at 5pm PDT. I apologize for the short notice, but we had some last minute technical issues and weren't sure we would be able to do it, but I also didn't want to postpone this until next week. Downtime will be 1-2 hours. I ran into a problem with the first database load, so I am having to redo it. Bugzilla will be down for a while longer. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is bugzilla down ?
If it weren't too much trouble, it might be nice to show some kind of under maintenance page in the future so that we know for sure it's due to the migration instead of migration-related outage. - Ryosuke On Thu, Jul 19, 2012 at 6:36 PM, William Siegrist wsiegr...@apple.comwrote: See my earlier email about the migration. -Bill On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is bugzilla down ?
I think the notice was simply lost in all the bike-shedding of late. :) Thank you Bill for taking care of the migration. I saw and appreciated your email notice earlier. -eric On Thu, Jul 19, 2012 at 7:00 PM, Ryosuke Niwa rn...@webkit.org wrote: If it weren't too much trouble, it might be nice to show some kind of under maintenance page in the future so that we know for sure it's due to the migration instead of migration-related outage. - Ryosuke On Thu, Jul 19, 2012 at 6:36 PM, William Siegrist wsiegr...@apple.com wrote: See my earlier email about the migration. -Bill On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is bugzilla down ?
Yeah a maintenance page would be nice, but usually these outages aren't so long. I did have a 503 on the old server for the first DB move. The need to re-do the DB migration made this a lot messier then it should have been since it happened after the DNS change. I like to be paranoid and leave httpd off entirely while we're transferring data, which makes a maintenance page hard to put up. Anyway, bugzilla is back. -Bill On Jul 19, 2012, at 7:09 PM, Eric Seidel e...@webkit.org wrote: I think the notice was simply lost in all the bike-shedding of late. :) Thank you Bill for taking care of the migration. I saw and appreciated your email notice earlier. -eric On Thu, Jul 19, 2012 at 7:00 PM, Ryosuke Niwa rn...@webkit.org wrote: If it weren't too much trouble, it might be nice to show some kind of under maintenance page in the future so that we know for sure it's due to the migration instead of migration-related outage. - Ryosuke On Thu, Jul 19, 2012 at 6:36 PM, William Siegrist wsiegr...@apple.com wrote: See my earlier email about the migration. -Bill On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Bugzilla migration: Today 5pm PDT
On Jul 19, 2012, at 6:59 PM, William Siegrist wsiegr...@apple.com wrote: On Jul 19, 2012, at 7:25 AM, William Siegrist wsiegr...@apple.com wrote: bugs.webkit.org is moving to our new hardware today at 5pm PDT. I apologize for the short notice, but we had some last minute technical issues and weren't sure we would be able to do it, but I also didn't want to postpone this until next week. Downtime will be 1-2 hours. I ran into a problem with the first database load, so I am having to redo it. Bugzilla will be down for a while longer. Sorry for blowing way past the time estimate, but it turns out our test DB migrations, and our first real migration, were not loading all of the data due to some improperly encoded values, which made them take way less time. In case anyone is curious, the bugs.webkit.org dump is 24GB. Bugzilla is back up. As always, let me know if you see any problems or missing data. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
