Re: [webkit-dev] Re: [webkit-changes] [29033] trunk
On Dec 29, 2007, at 11:20 PM, Alp Toker wrote: The discussion in bug #16669 suggests this was a clean-up to make conditional database support consistent with conditional icon database support. A quick grep shows precedent for this with other features, eg. Frame.cpp: #if ENABLE(SVG) #include SVGDocument.h #include SVGDocumentExtensions.h #include SVGNames.h #include XLinkNames.h #endif If it's causing trouble with other build systems it might be better to add guards within the header files instead. No strong feelings either way. It's not about build systems. Either approach works with any build system. There are two approaches -- #if in the headers and #if in source files where they include the headers. Despite what Jan Alonzo claimed in that bug, we are consistently doing the #if in all the headers for these features; the #if in source files are mistakes. It's not good to have these be inconsistent. I don't like the change to make DATABASE less like SVG and XPATH and XSLT. The #if at include sites approach is better for people who want to omit the code entirely for features that are not enabled. You don't even need the headers in your patch. But the #if in headers approach is probably lower maintenance, since there are usually multiple includes for each header. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re: [webkit-changes] [29033] trunk
On Dec 31, 2007, at 1:58 PM, Darin Adler wrote: The #if at include sites approach is better for people who want to omit the code entirely for features that are not enabled. You don't even need the headers in your patch. But the #if in headers approach is probably lower maintenance, since there are usually multiple includes for each header. I meant to say you don't even need the headers in your source tree or include path above. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cancel non-terminating JavaScriptCore JSEvaluate()?
On Dec 28, 2007, at 2:35 PM, Dan Waylonis wrote: If I send some non-terminating code (e.g., while(1);) to JSEvaluate(), is there a way to have a watchdog thread/timer notice that JSEvaluate() is not terminating (after some amount of time) and cancel the code evaluation? I seem to remember reading that Safari3 has something like this. WebKit does have this feature. However, the JavaScriptCore API does not export the feature so that you can use it with functions like JSEvaluate. That's something that will have to be added for a future version of the API. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re: [webkit-changes] [29033] trunk
Not necessarily -- I believe there are a number of generated headers that don't get generated if corresponding features are disabled, so the headers need to have #if ENABLED(...) checks around them... i think :D --Oliver On Dec 31, 2007, at 8:36 PM, Jan Alonzo wrote: (reposting to the list) On Jan 1, 2008 8:58 AM, Darin Adler [EMAIL PROTECTED] wrote: snip There are two approaches -- #if in the headers and #if in source files where they include the headers. Despite what Jan Alonzo claimed in that bug, we are consistently doing the #if in all the headers for these features; the #if in source files are mistakes. Yes, my mistake because i didn't poke in each of the header files and based my comment on what I've seen in some of the source files #if'ng header files. It's good to know that #ifng headers in source files is a bug. Thanks for the clarification. Cheers ___ 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
