Re: [webkit-dev] Code Search for webkit.org
I usually search the copy of WebKit that's in the Chromium sub-index of code search. It's at most one day behind ToT WebKit (plus Code Search crawl/indexing delays): http://www.google.com/codesearch#search/exact_package=chromiumq=file%3A%5Esrc/third_party/WebKit Mihai Mihai On Fri, Sep 30, 2011 at 8:33 AM, Tom Zakrajsek t...@codeaurora.org wrote: codesearch seems very cool, but I noticed that http://codesearch.google.com/#**search/q=package:webkithttp://codesearch.google.com/#search/q=package:webkitseems to be picking up WebKit from the android repo at git:// android.git.kernel.org/**platform/external/webkit.githttp://android.git.kernel.org/platform/external/webkit.git. Does that cause problems with the code being stale (more stale than just using a cached copy)? Is there a way to get it to look at git:// git.webkit.org/WebKit.**git http://git.webkit.org/WebKit.git? --tom On 09/08/2011 03:34 PM, Dimitri Glazkov wrote: I3 codesearch. It's fast, and it's accurate. :DG On Thu, Sep 8, 2011 at 2:52 PM, Eric Seidele...@webkit.org wrote: I'm curious how other developers search the WebKit code? I use http://codesearch.google.com/#**search/q=package:webkithttp://codesearch.google.com/#search/q=package:webkitfrom time to time. If others do too, we should make it a redirect from cs.webkit.org (like we do for cia.webkit.org). Or maybe folks have better code search solutions? grep -r? -eric __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] runtime settings in a ~/.webkitrc
Hi, isn't a good idea to make webkit read ~/.webkitrc file to enable/disable features at runtime? regards. Haithem. -- * If you ask a question - you will be a fool for 5 minutes, otherwise ignorant for rest of your life * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] runtime settings in a ~/.webkitrc
04.10.2011, 11:07, haithem rahmani haithem.rahm...@gmail.com: Hi,isn't a good idea to make webkit read ~/.webkitrc file to enable/disable features at runtime? regards. IMHO it is not. 1. WebKit is a library, not a self contained application, and settings should be managed by applications 2. There can be several different WebKit installations on one machine (e.g., WebKitGtk and QtWebKit, or different releases of one port) -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fastest image format
Hello, What is the fastest image format for wekbit ? I mean which image format (jpg, png, gif, etc.) is decoded and displayed fastest than the other ones ? I did a search on the forum and found nothing. Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fastest image format
04.10.2011, 13:22, Joe LaFritte joelafri...@yahoo.fr: Hello, What is the fastest image format for wekbit ? I mean which image format (jpg, png, gif, etc.) is decoded and displayed fastest than the other ones ? It heavily depends on hardware and used decoding libraries. -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] dispatchEvent is a noop on documents returned by parseFromString
Hi, In the context of https://bugs.webkit.org/show_bug.cgi?id=26147 ( No support of DOM events on a frameless document ) I am researching how to implement a fix. I'm thinking of two possible solutions, none of which is trivial. Probably because I'm new to the webkit codebase. a) modify the function void JSEventListener::handleEvent(ScriptExecutionContext* scriptExecutionContext, Event* event) found in http://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSEventListener.cpp so that it does not return without doing anything when there is no frame. However, given the extensive checks related to frames found in the function, I suspect that would cause more problems than it solves. b) modify the function EncodedJSValue JSC_HOST_CALL jsDOMParserPrototypeFunctionParseFromString(ExecState* exec) (or whatever generates this function) to assign the frame() of the global document to it. However, I suspect that this will have a number of undesirable side effects. I'm not sure if there are other ways to look for a solution. I would be very grateful if someone familiar with the codebase could provide me with a hint or point me in the right direction. Thanks in advance attachment: loic.vcf signature.asc Description: OpenPGP digital signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)
Filed a bug: https://bugs.webkit.org/show_bug.cgi?id=68971 On Mon, Aug 8, 2011 at 11:03, TAMURA, Kent tk...@chromium.org wrote: But is there any grouping we can do? Does each need a separate feature flag? I think separated feature flags are better. Suppose that all types are in ENABLE_INCOMPLETE_INPUT_TYPES and we finish to implement UI of one input type: * We can't enable ENABLE_INCOMPLETE_INPUT_TYPES because other types are not ready. * If the UI requires port-specific code, we can't move the input type out of ENABLE_INCOMPLETE_INPUT_TYPES flag for a port which already has the port-specific code because other ports are not ready. * Even if the UI is implemented by shadow DOM and requires no port-specific code, mobile ports might need another implementation and might want to disable the shadow DOM implementation. If we introduce separated features flags, we won't have such issues. On Sat, Aug 6, 2011 at 03:05, Darin Adler da...@apple.com wrote: On Aug 4, 2011, at 6:40 PM, TAMURA, Kent wrote: Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime, datetime-local, month, time, and week types. * We're going to implement dedicated UIs for them, and will want to disable it temporarily. * Their current implementations are insufficient and one might not want to ship them in browsers, but they were already shipped in some browsers. These are both good reasons to have a feature flag and I think it’s critical we do that. But is there any grouping we can do? Does each need a separate feature flag? -- Darin -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fastest image format
On Tue, Oct 4, 2011 at 2:22 AM, Joe LaFritte joelafri...@yahoo.fr wrote: What is the fastest image format for wekbit ? I mean which image format (jpg, png, gif, etc.) is decoded and displayed fastest than the other ones ? That likely depends on the image, the decoder, and the system in question. For example, BMPs can be stored as uncompressed data, which requires no transformation to display onscreen, but means the source data is much larger so the image takes longer to download. Similarly, the other image formats can generally support lots of different compression techniques and levels that have large effects on image size and decode time, especially if the decoders in question have optimized inner loops for your chip. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
On Tue, Oct 4, 2011 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote: In my understanding, we use pass by reference for out arguments when they have to be modified in callees. I had not heard this. Personally I weakly prefer pointers to non-const refs for outparams, but if there is convention the other way that's fine. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
On Tue, Oct 4, 2011 at 2:11 PM, Peter Kasting pkast...@chromium.org wrote: On Tue, Oct 4, 2011 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote: In my understanding, we use pass by reference for out arguments when they have to be modified in callees. I had not heard this. As far as I know, this is the convention used in the majority of WebCore. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
On Tue, Oct 4, 2011 at 2:06 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, It came to my attention that some people are using raw pointers to pass out-arguments (e.g. bug 69366). In my understanding, we use pass by reference for out arguments when they have to be modified in callees. If there's no objection, I'm going to file a bug upload a patch to state this explicitly in the style guideline. Could you explain why? Is it to document the nullity of the out-param? I personally find pointers for out parameters to be appropriate in many situations. It makes the side effects of manipulating the parameter more obvious, and it provides a clear way for the caller to indicate that they don't care about a certain out parameter. It sounds like you have reasons to prefer the opposite behavior. - James Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add explicit style guideline: should use type instead of type* for out arguments
On Oct 4, 2011, at 2:14 PM, James Robinson wrote: Could you explain why? Is it to document the nullity of the out-param? Sure, one reason is to document the non-nullity of the out parameter. I personally find pointers for out parameters to be appropriate in many situations. It makes the side effects of manipulating the parameter more obvious, and it provides a clear way for the caller to indicate that they don't care about a certain out parameter. It sounds like you have reasons to prefer the opposite behavior. For an optional out parameter, our style has been to use a pointer. For a non-optional, our style has been to use a reference. There are hundreds of these in WebCore and JavaScriptCore. It’s largely an arbitrary guideline, but one that has been around for years and I’d prefer not to change style unless there is a strong reason. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
On Oct 4, 2011, at 2:06 PM, Ryosuke Niwa wrote: It came to my attention that some people are using raw pointers to pass out-arguments (e.g. bug 69366). In my understanding, we use pass by reference for out arguments when they have to be modified in callees. If there's no objection, I'm going to file a bug upload a patch to state this explicitly in the style guideline. If it’s not already in there, I think you might also want to mention the related rule that encourages the use of the word “get” at the starts of the names of these functions with out arguments. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
Interesting. I thought historical policy was universally against the word get in function names. I guess you're suggesting that get should only be applied to function names which have an out-argument? -eric On Tue, Oct 4, 2011 at 6:00 PM, Darin Adler da...@apple.com wrote: On Oct 4, 2011, at 2:06 PM, Ryosuke Niwa wrote: It came to my attention that some people are using raw pointers to pass out-arguments (e.g. bug 69366). In my understanding, we use pass by reference for out arguments when they have to be modified in callees. If there's no objection, I'm going to file a bug upload a patch to state this explicitly in the style guideline. If it’s not already in there, I think you might also want to mention the related rule that encourages the use of the word “get” at the starts of the names of these functions with out arguments. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
At least we already have some of such mehods like: void Range::getBorderAndTextQuads(VectorFloatQuad) const; void VisiblePosition::getInlineBoxAndOffset(InlineBox* inlineBox, int caretOffset) const; void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*, int caretOffset) const; void FrameView::getTickmarks(VectorLayoutRect) const; bool Editor::getCompositionSelection(unsigned selectionStart, unsigned selectionEnd) const; On Wed, Oct 5, 2011 at 10:14 AM, Eric Seidel e...@webkit.org wrote: Interesting. I thought historical policy was universally against the word get in function names. I guess you're suggesting that get should only be applied to function names which have an out-argument? I once heard such a feed back on some review. And at least we already have some of such mehods like: void Range::getBorderAndTextQuads(VectorFloatQuad) const; void VisiblePosition::getInlineBoxAndOffset(InlineBox* inlineBox, int caretOffset) const; void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*, int caretOffset) const; void FrameView::getTickmarks(VectorLayoutRect) const; bool Editor::getCompositionSelection(unsigned selectionStart, unsigned selectionEnd) const; ...and more: http://codesearch.google.com/codesearch#search/exact_package=chromiumq=WebCore%20get.%2B%20file:h$ Personally prefer the get prefix for function with out-params since it's hard to feel it like an attribute/member variable. This is never a strong claim though. Regards, -- morrita -eric On Tue, Oct 4, 2011 at 6:00 PM, Darin Adler da...@apple.com wrote: On Oct 4, 2011, at 2:06 PM, Ryosuke Niwa wrote: It came to my attention that some people are using raw pointers to pass out-arguments (e.g. bug 69366). In my understanding, we use pass by reference for out arguments when they have to be modified in callees. If there's no objection, I'm going to file a bug upload a patch to state this explicitly in the style guideline. If it’s not already in there, I think you might also want to mention the related rule that encourages the use of the word “get” at the starts of the names of these functions with out arguments. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Add explicit style guideline: should use type instead of type* for out arguments
On Oct 4, 2011 5:57 PM, Darin Adler da...@apple.com wrote: I personally find pointers for out parameters to be appropriate in many situations. It makes the side effects of manipulating the parameter more obvious, and it provides a clear way for the caller to indicate that they don't care about a certain out parameter. It sounds like you have reasons to prefer the opposite behavior. For an optional out parameter, our style has been to use a pointer. For a non-optional, our style has been to use a reference. In addition, I normally prefer to have two overloaded inline functions to wrap the optional argunents in such cases to avoid callers from using raw pointers. There are hundreds of these in WebCore and JavaScriptCore. It’s largely an arbitrary guideline, but one that has been around for years and I’d prefer not to change style unless there is a strong reason. Right. That's the motivation behind my proposal. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
On Tue, Oct 4, 2011 at 2:14 PM, James Robinson jam...@google.com wrote:
Is it to document the nullity of the out-param?
Yes, and it also prevents mistakes like:
#include cstdio
class base { ... };
class derived : public base { ... };
void getBase(base* b) { *b = base(); }
int main() {
derived d;
getBase(d);
return 0;
}
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
On Oct 4, 2011, at 6:14 PM, Eric Seidel wrote: I thought historical policy was universally against the word get in function names. The policy has been to reserve the word get to mean a function that gets a value in an out argument, as opposed to a function that returns a value, which we instead name with a noun or adjective describing the value. I guess you're suggesting that get should only be applied to function names which have an out-argument? Right, that’s what we’ve been doing. But I see now that the rule is not as well known as I thought. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Chromium PLT regression
About a week ago, the Chromium project measured a PLT regression on Windows, Mac, and Linux: https://bugs.webkit.org/show_bug.cgi?id=69238 I don't know whether the regression affects any other ports, but according to the Chromium performance bots, the regression occurred in this range: http://trac.webkit.org/log/trunk/Source?rev=96091stop_rev=96066verbose=on Normally, the Chromium project has a bot continuously running the PLT against WebKit trunk, but, due to a configuration error, that bot was been offline for about 10 days, which, unfortunately, includes the time period in question. The bot is now back online: http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/intl1/report.html?history=150rev=-1 I'm not able to reproduce the regression locally. Sometime in the next couple days, when the tree is quiet (which probably means at night PST), I'd like to try to hunt down which revision in that range caused the regression by rolling out the patches. If I roll out your patch as part of this process, do not worry. I'll roll it back in shortly thereafter. My hope is that this experiment will allow us to isolate the exact revision that caused the regression. If anyone is able to reproduce the issue locally, that would certainly be better than me making a mess by rolling patches in and out of the main tree. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Chromium PLT regression
On Oct 4, 2011, at 10:37 PM, Adam Barth wrote: About a week ago, the Chromium project measured a PLT regression on Windows, Mac, and Linux: https://bugs.webkit.org/show_bug.cgi?id=69238 I don't know whether the regression affects any other ports, but according to the Chromium performance bots, the regression occurred in this range: http://trac.webkit.org/log/trunk/Source?rev=96091stop_rev=96066verbose=on Normally, the Chromium project has a bot continuously running the PLT against WebKit trunk, but, due to a configuration error, that bot was been offline for about 10 days, which, unfortunately, includes the time period in question. The bot is now back online: http://build.chromium.org/f/chromium/perf/linux-release-webkit-latest/intl1/report.html?history=150rev=-1 I'm not able to reproduce the regression locally. Sometime in the next couple days, when the tree is quiet (which probably means at night PST), I'd like to try to hunt down which revision in that range caused the regression by rolling out the patches. If I roll out your patch as part of this process, do not worry. I'll roll it back in shortly thereafter. My hope is that this experiment will allow us to isolate the exact revision that caused the regression. If anyone is able to reproduce the issue locally, that would certainly be better than me making a mess by rolling patches in and out of the main tree. Hi Adam, I think that configuring your bot to build and test old the revisions off trunk would be far better. Or, if for some reason that is impossible, then configuring it to work against a local repository. Or, if for some reason that is impossible, and you absolutely have to use svn.webkit.org for this purpose, then configuring it to build and test a branch that you will create for this purpose and on which you will run the experiment. It is almost unbelievable that the only way for you to track down a performance regression is to make changes to the source tree. —Dan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] The JSC Garbage Collector
Hi! I recently started looking through the JavaScriptCore codebase, and discovered that working on the GC would be a nice way to contribute. A starting point, I think, would be to implement code that allows moving objects around. I was thinking of doing this by adding a third field to the MethodTable which takes a hashtable mapping addresses of old objects to their new addresses. This function should then modify the structure in question accordingly (to modify the fields to point to the new memory locations wherever needed). This way a basic moving and compacting collector (with two spaces) could be implemented like: 1. Figure out the live objects. 2. Allocate space for them in the other allocation space. Put the old and new address pairs in a map. 3. Ask every live (old) object to re-orient itself using the map generated in (2). 4. Copy the old objects to their designated new locations. Does this make sense? I'm still pretty new to the JSC codebase so I'm not sure about most of what I just said. Another way is, of course, to keep references to references, as mentioned in [1]. I found this approach better since all the heavy lifting happens at GC time, and does not burden the runtime with a double deref. Thank you for your time! [1] http://trac.webkit.org/wiki/JS%20Core%20Garbage%20Collector -- Sanjoy Das http://playingwithpointers.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
