[webkit-dev] JavascriptCore API: Typed arrays
Hello, looking at the current version of JavascriptCore's C API there seems to be no way to access the data of TypedArrays. Is this true, or did I miss something? If not, are there plans to expose that part to C someday? E.g., then one could access the underlying C arrays from within a native extension. Cheers, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://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 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 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
