Re: [webkit-dev] How to integrate HbbTV with WebKit
Please do not cross-post. A cursory internet search shows HbbTV has little to do with WebKit. What spec covers HbbTV? What other browsers implement such? Your mail does not seem appropriate for this list. -eric On Sun, Jun 19, 2011 at 10:26 PM, Vicky Tux sssein...@gmail.com wrote: Hi, We have to implement HbbTV specification using WebKit. We have no idea to integrate HbbTV with WebKit. So please advice us, below queries for developing HbbTV. 1. How to add new HTML tags and attributes in WebKit? 2. How to add new styles in WebKit? 3. How to add new class,method and property in JavaScript? 4. Please share HbbTV related sample code for our development purpose. It's very helpful for us. Regards, Vicky. ___ 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] DOM tree vs. Render tree
I'm not sure this will help you Song, but here is a talk I gave a couple years back which talks some about the DOM vs. Rendering tree separation: http://www.youtube.com/watch?v=RVnARGhhs9w Best of luck in your exploration. -eric On Thu, Jun 16, 2011 at 4:34 PM, Darin Adler da...@apple.com wrote: On Jun 16, 2011, at 4:30 PM, song.7@nokia.com wrote: Thanks, but why not generate a tree according to document ang css style at the same time? Or why is the post style decision needed? I can see from your question that you didn’t understand, but I’m not sure how to clear things up. The DOM tree needs to match the document structure and can’t be influenced by style. This is what makes the DOM API work; the DOM tree is a parsed form of the document explicitly exposed as API. Style can change many ways at times when the DOM must not change, for example, when a stylesheet finishes loading, the styles from that sheet can affect how the DOM elements are displayed. We can’t change the DOM tree in response to style changes. I think we’ll have to get to a more specific question to have a useful discussion. -- 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] 194 bugs in pending-commit
On a similar note of bug cleanup, I have also seen lot of issues which are still in Unconfirmed state, even though the bug analysis says either the issue is not reproducible etc etc. So, Is there a way to clean up such bugs so that they don't unnecessarily come up in queries. What is the traditional procedure we follow in such cases? Thanks, Rahaman On Sun, Jun 19, 2011 at 10:18 AM, Eric Seidel e...@webkit.org wrote: webkit-patch upload clears all flags when obsoleting a patch. We could make it not clear r- if you like. I know of no way to construct a query like http://webkit.org/pending-commit in our current bugzilla without clearing r+ on obsolete patches/closed bugs. We clear flags (specifically r+) to make the life of those going through http://webkit.org/pending-commit easier (like sever folks tried to do this afternoon). Similarly, our current bugzilla doesn't automatically clear r? on closed bugs. So we have webkit-patch clean-review-queue to do that. The history information for any bug is always easily accessed via the history link in the upper-right corner of a bug, like: https://bugs.webkit.org/show_activity.cgi?id=62114 -eric On Sat, Jun 18, 2011 at 9:01 PM, Antonio Gomes toniki...@gmail.com wrote: IIRC, Mozilla's bugzilla can hide obsolete patches (?). If so, why can not webkit's bugzilla? I actually do not like the way the review flags are cleared today only in order to make the tools and pending-xxx pages happier. IMO the review flags give much about the history of the bug. In that matter, I dislike webkit-patch's ways of clearing r- flags of patches while it marks it as obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very helpful to me to understand the chronological progresses in the bug. What is the reason for clearing r- flag while uploading a new one, instead of only making it obsolete? On Sat, Jun 18, 2011 at 2:23 AM, Adam Barth aba...@webkit.org wrote: On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting pkast...@chromium.org wrote: On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org wrote: 2) Mark the patch as obsolete / clear the review flag if we're not going to land the patch. Does the slash mean do both? I have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the only r+ed patch on it is already marked obsolete. Yeah, Bugzilla kind of sucks. That page isn't smart enough to hide the obsolete patches. If you have EditBugs, you can run webkit-patch clean-pending-commit, which will automatically remove the review flags from obsolete patches. Eric and I have been meaning to having one of the bots do that periodically, but we haven't set that up yet. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- --Antonio Gomes ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Jun 19, 2011, at 12:48 PM, Darin Adler wrote: The arguments about abandoning PassRefPtr for arguments entirely are attacking a straw man. We know PassRefPtr offers an important optimization and do not want to drop that! I posited it not as a straw man but rather as an option I myself put on the table. Seems most folks agree it is a bad one. Also, examining the pros and cons of using PassRefPtr in all the cases where we do now vs in none of the cases where we do now sheds light on the relative advantages and disadvantages of using it only in some of the cases where we do now. Note that I listed using PassRefPtr for arguments less often (but not never) as a separate option. On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote: (1) Use PassRefPtr for every parameter that takes ownership. I still think this is the appropriate rule, and always have, but I think “takes ownership” is not defined to my satisfaction. Pro (of using PassRefPtr for every parameter that takes ownership): Bright-line rule; fairly clear how to apply it. This is where my problem comes in. I am not sure what the bright-line rule is. It's approximately this function will put the relevant parameter in a RefPtr data member or global. The DOM is more complicated, because much of the internal refcounting is done manually instead of using RefPtrs. Generally, in the DOM, the rule is that all reachable objects need to be kept alive, so reference counting is used to implement reachability, which does not match with my sense of the word ownership. Reference-counted objects have shared ownership. Every object holding a reference to any other owns it. We could stop using the word ownership and instead of take ownership say take a persistent reference. For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line: a) Hands off ownership to what could possibly be the sole owner in most code paths. b) Keeps a reference to the object after the function completes in most code paths. c) Takes a reference to the object at least once in most code paths. d) Hands off ownership to what could possibly be the sole owner in some code paths. e) Keeps a reference to the object after it completes in some code paths. f) Takes a reference to the object at least once in some code paths. Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all? Yes, (b) or (e). I haven't thought about whether most code paths or some code paths makes more sense, but I'm not sure there are a lot of cases in our code where it makes a difference. I don't think it makes sense to talk about a sole owner of a refcounted object. If there is a sole owner at any given time, it is at best temporary. PassRefPtr is about clearly and efficiently transferring a reference, it doesn't need it to necessarily be the sole then-existing reference. […snip…] Similarly, some functions call out to operations that could cause the last owner for one of their arguments to dereference the object. They are likely to fit into category (c) or (f). In a sense the caller does have to pass ownership of the object, because the operation can only be successfully done if the function takes ownership to make sure the object does not disappear while the code is working with it. My understanding is that our current rule doesn't call for taking a PassRefPtr argument in this case, but I can see how it would make sense and would add helpful type checking. I tried to find the examples that bother me. Here are some DOM examples where the term ownership seems wrong, and it’s more about reachability: HTMLCollection::create: Does a collection own the node it is rooted in? MessageEvent::initMessageEvent: Does a message event own the source DOM window? Range::create: Does a range own the document its nodes are in and the nodes that are used to specify the endpoints? Storage::create: Does a storage object own its storage area? UIEvent::create: Does an event own its abstract view? It seems to me that all of these objects become shared-owners of the respective parameter, in the sense of holding a persistent reference. Some don't literally stick it in a RefPtr but they do the moral equivalent. Here are some examples that are not purely DOM reachability that I find confusing: Document::setTitleElement: Does a document own its title element? FrameLoaderClient::dispatchWillSubmitForm: Does communication of a pending form submission involve passing ownership of form state? Ditto. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to call JavaScript function from WebKit
Hi, anyone help me, how to call JavaScript function from webkit and give the example code.. Thanks Regards, Vicky. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Are roll-outs getting a little out of hand?
Hi, Darin Adler wrote: I noticed these three roll-outs: http://trac.webkit.org/changeset/89190 It broke all non-V8 build as you mentioned later because of stricter gcc treats warnings as errors. I checked the bug today , and suggested a fix for the build fail: https://bugs.webkit.org/show_bug.cgi?id=62904 http://trac.webkit.org/changeset/89191 The original change was committed by a Qt developer. I think the minimum requirment is that a developer should build his/her patch at least on his/her platform before landing. (Fixed patch was already landed.) http://trac.webkit.org/changeset/89192 It broke 22 tests on all platform, and the author, Oliver Hunt confirmed this rollout was fine. (Fixed patch was already landed.) Were all of these necessary? Was there a way to fix the problem instead of rolling out in any of these cases? It might be. Fix for the 1st and the 2nd build break was quite simple. But I don't have time to fix them on saturday morning. I think rolling out was better than leaving the build broken for 2 days and let the authors to fix their bugs themselves. Broken build is the worst thing, because buildbot can't catch new layout regressions if the build is broken. In my opinion WebKit developers should take contributing rules seriously to make the lives of other developers easier. http://www.webkit.org/coding/contributing.html Regression tests Once you have made your changes, you need to run the regression tests, which is done via the run-webkit-tests script. All tests must pass. Patches will not be landed in the tree if they break existing layout tests. Keeping the tree green Your change must at least compile on all platforms. Rolling out is the last thing what I do with a wrong patch. First I try to contact the author and/or the reviewer on #webkit. If he/she doesn't answer, I try to fix the bug myself (if I have time and enough knowledge to do it.) After a roll-out I usually help the author to fix the Qt part of the patch. br, Csaba Osztrogonác (Ossy) University of Szeged ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] no more mail
plece no send more information,thank YO SOY EL QUE YO SOY FRED ANGEL NESARA 1618 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
20.06.2011, в 03:22, Maciej Stachowiak написал(а): For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line: a) Hands off ownership to what could possibly be the sole owner in most code paths. b) Keeps a reference to the object after the function completes in most code paths. c) Takes a reference to the object at least once in most code paths. d) Hands off ownership to what could possibly be the sole owner in some code paths. e) Keeps a reference to the object after it completes in some code paths. f) Takes a reference to the object at least once in some code paths. Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all? Yes, (b) or (e). I haven't thought about whether most code paths or some code paths makes more sense, but I'm not sure there are a lot of cases in our code where it makes a difference. I don't think it makes sense to talk about a sole owner of a refcounted object. If there is a sole owner at any given time, it is at best temporary. PassRefPtr is about clearly and efficiently transferring a reference, it doesn't need it to necessarily be the sole then-existing reference. I think that to make this complete, the rules need to be transitive. A function that passes its argument to another function taking a PassRefPtr should itself take a PassRefPtr. That's the case in https://bugs.webkit.org/show_bug.cgi?id=52981, for instance. It doesn't seem that analyzing code for most/some code paths takes ownership would be any easier that analyzing it for any caller gives away ownership. Yet it's the latter where PassRefPtr is beneficial. Why base the rule on something that's disconnected from actual benefit? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to integrate HbbTV with WebKit
20.06.2011, 10:31, Eric Seidel e...@webkit.org: Please do not cross-post. A cursory internet search shows HbbTV has little to do with WebKit. What spec covers HbbTV? What other browsers implement such? Seems like Opera implements it: http://www.opera.com/press/releases/2009/10/15/ -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to integrate HbbTV with WebKit
HbbTV does not appear to be an open standard: http://pda.etsi.org/pda/home.asp?wki_id=hsZ9g8-p%27v475895z4LHX [[ This publication is copyright protected. ETSI continues to assert its rights on ETSI documents published in any form. For additional copyright information about this publication please refer to the copyright statement contained in the document. The document that you are downloading is provided to you on the condition that it may not be modified, redistributed, sold or repackaged in any form without the prior consent of ETSI and where appropriate other copyright holders. It is strictly for your private use. If you do not agree with these conditions please go back now, else if you agree with these conditions, you can start downloading the document. ]] Compare that license with the one the W3C grants with its specifications: http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 [[ Permission to copy, and distribute the contents of this document, or the W3C document from which this statement is linked, in any medium for any purpose and without fee or royalty is hereby granted, provided that you include the following on ALL copies of the document, or portions thereof, that you use: 1) A link or URL to the original W3C document. 2) The pre-existing copyright notice of the original author, or if it doesn't exist, a notice (hypertext is preferred, but a textual representation is permitted) of the form: Copyright © [$date-of-document] World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231; 3) If it exists, the STATUS of the W3C document. ]] That's not to say we never implement non-open standards or that we implement all open standards, just that the bar for non-open standards is significantly higher than the bar for open standards, like those published by the W3C or the IETF. Adam 2011/6/20 Konstantin Tokarev annu...@yandex.ru: 20.06.2011, 10:31, Eric Seidel e...@webkit.org: Please do not cross-post. A cursory internet search shows HbbTV has little to do with WebKit. What spec covers HbbTV? What other browsers implement such? Seems like Opera implements it: http://www.opera.com/press/releases/2009/10/15/ -- Regards, Konstantin ___ 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] UNCONFIRMED bugs
We should probably turn off the UNCONFIRMED state. At this time in the WebKit project there is no useful distinction between UNCONFIRMED and NEW. I haven’t seen any useful distinction between UNCONFIRMED, NEW, ASSIGNED, and REOPENED in the WebKit bug database. While I can imagine projects where those are used to communicate something helpful to bug management, this is not true of our project at this time. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UNCONFIRMED bugs
20.06.2011, в 9:42, Darin Adler написал(а): We should probably turn off the UNCONFIRMED state. At this time in the WebKit project there is no useful distinction between UNCONFIRMED and NEW. I haven’t seen any useful distinction between UNCONFIRMED, NEW, ASSIGNED, and REOPENED in the WebKit bug database. While I can imagine projects where those are used to communicate something helpful to bug management, this is not true of our project at this time. I previously objected to removing UNCONFIRMED, since NEW practically meant someone who knows what an actionable bug looks like has seen this, and I've been using this distinction when choosing whether to open a bug from my RSS feed. This distinction has eroded since then, so I also think that we don't need UNCONFIRMED any more. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Mon, Jun 20, 2011 at 9:19 AM, Alexey Proskuryakov a...@webkit.org wrote: I think that to make this complete, the rules need to be transitive. A function that passes its argument to another function taking a PassRefPtr should itself take a PassRefPtr. That's the case in https://bugs.webkit.org/show_bug.cgi?id=52981, for instance. I agree. Most of editing bugs come from breaking that transitive rule. I even want it be enforced by some C++ idiom; e.g. replace all raw pointers in argument list by PassRawPtr, which cannot be converted to PassRefPtr or RefPtr. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 194 bugs in pending-commit
I had one of the bugs in this state, and I had not landed it because I had been meaning to do some more testing to see if it caused regressions. However, someone CQ+'ed it over the weekend, and it was committed w/o my involvement. Fortunately, it did not appear to cause massive regressions (thankfully, since I wasn't around and wouldn't have been able to triage/diagnose any issues), but, for at least some patches, I would like to prevent this from occurring in the future. Would it have been better to mark the patch as CQ- just to be safer (and clearer), or is there some other recommended way to indicate that I want a patch to be reviewed but it may not be ready to be landed? -- Dirk On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org wrote: There are a 194 open bugs with an R+ patches attached to them: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc=%5C%5BS60%5C%5Dlong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= Please take a minute to look through this list and clean out any bugs you know about. (Looks like 5 of them are assigned to me, so I'll be following my own advice shortly.) Some recommended actions: 1) Close the bug if the patch has already been landed. 2) Mark the patch as obsolete / clear the review flag if we're not going to land the patch. 3) Mark the patch commit-queue+ if you'd like the commit queue to land the patch. 4) Land the patch manually if the patch needs some tweaking before landing. Thanks, and happy bug scrubbing! Adam ___ 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] 194 bugs in pending-commit
In general it's pretty safe to cq+ a patch, especially an old one. Since the cq + EWS tests patches better than just about any committer ever does manually. :) We built infrastructure to have the sherriff-bot auto-rollout patches which caused any tree redness. If folks want, we could turn that on, which gets rid of the the cq might land my patch while I'm not looking problem. But yes, setting cq- is a great way to make sure no one cq+'s your patch. -eric On Mon, Jun 20, 2011 at 11:50 AM, Adam Barth aba...@webkit.org wrote: If you want to be extra sure that someone won't commit-queue your patch, you can mark it commit-queue-. Generally, though, we don't mark patches from committers commit-queue+ unless the committer has marked the patch commit-queue?. Adam On Mon, Jun 20, 2011 at 11:35 AM, Dirk Pranke dpra...@chromium.org wrote: I had one of the bugs in this state, and I had not landed it because I had been meaning to do some more testing to see if it caused regressions. However, someone CQ+'ed it over the weekend, and it was committed w/o my involvement. Fortunately, it did not appear to cause massive regressions (thankfully, since I wasn't around and wouldn't have been able to triage/diagnose any issues), but, for at least some patches, I would like to prevent this from occurring in the future. Would it have been better to mark the patch as CQ- just to be safer (and clearer), or is there some other recommended way to indicate that I want a patch to be reviewed but it may not be ready to be landed? -- Dirk On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org wrote: There are a 194 open bugs with an R+ patches attached to them: https://bugs.webkit.org/buglist.cgi?query_format=advancedshort_desc_type=notregexpshort_desc=%5C%5BS60%5C%5Dlong_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%2Bfield0-1-0=nooptype0-1-0=equalsvalue0-1-0= Please take a minute to look through this list and clean out any bugs you know about. (Looks like 5 of them are assigned to me, so I'll be following my own advice shortly.) Some recommended actions: 1) Close the bug if the patch has already been landed. 2) Mark the patch as obsolete / clear the review flag if we're not going to land the patch. 3) Mark the patch commit-queue+ if you'd like the commit queue to land the patch. 4) Land the patch manually if the patch needs some tweaking before landing. Thanks, and happy bug scrubbing! Adam ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UNCONFIRMED bugs
On Jun 20, 2011, at 12:30 PM, Ryosuke Niwa wrote: For all practical purposes, NEW has been equivalent to AVAILABLE in WebKit. To me it seems that WebKit’s closer equivalent of AVAILABLE is Assigned To = webkit-unassig...@lists.webkit.org -- Darin PS: Apologies to everyone for hijacking this thread. I now realize I should have started a new one to respond to the comment about UNCONFIRMED. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] hook to re-author commit queue patches seems broken/off
For example, this patch http://trac.webkit.org/changeset/89287 says it is by commit-qu...@webkit.org but it should say mrobin...@webkit.org. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] UNCONFIRMED bugs
On Tue, Jun 21, 2011 at 5:33 AM, Darin Adler da...@apple.com wrote: On Jun 20, 2011, at 12:30 PM, Ryosuke Niwa wrote: For all practical purposes, NEW has been equivalent to AVAILABLE in WebKit. To me it seems that WebKit’s closer equivalent of AVAILABLE is Assigned To = webkit-unassig...@lists.webkit.org It looks like new bugs from anonymous users are automatically created both UNCONFIRMED and Assigned To = webkit-unassig...@lists.webkit.org. This would preclude using Assigned To = webkit-unassig...@lists.webkit.org as an indicator of AVAILABLE in Dirk's sense, right? FWIW we (the Chrome team in Sydney) have been triaging CSS UNCONFIRMED bugs and putting actionable ones into the NEW state for the last quarter or so. We tend to weed out about half of the reported bugs, so this feels useful :) Cheers, -Shane -- Darin PS: Apologies to everyone for hijacking this thread. I now realize I should have started a new one to respond to the comment about UNCONFIRMED. ___ 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] hook to re-author commit queue patches seems broken/off
No, the server is fine. That change was committed by mrobin...@igalia.com, which is not a committer address, so no rewriting was performed. -Bill On Jun 20, 2011, at 2:49 PM, Eric Seidel wrote: I think svn.webkit.org has been having some troubles today. I know there was some discussion of SSL errors involving svn.webkit.org in #webkit. wsiegrist maintains the hook (it's not even in the repository iirc). -eric On Mon, Jun 20, 2011 at 2:40 PM, David Levin le...@chromium.org wrote: For example, this patch http://trac.webkit.org/changeset/89287 says it is by commit-qu...@webkit.org but it should say mrobin...@webkit.org. dave ___ 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] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Jun 20, 2011, at 9:19 AM, Alexey Proskuryakov wrote: 20.06.2011, в 03:22, Maciej Stachowiak написал(а): For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line: a) Hands off ownership to what could possibly be the sole owner in most code paths. b) Keeps a reference to the object after the function completes in most code paths. c) Takes a reference to the object at least once in most code paths. d) Hands off ownership to what could possibly be the sole owner in some code paths. e) Keeps a reference to the object after it completes in some code paths. f) Takes a reference to the object at least once in some code paths. Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all? Yes, (b) or (e). I haven't thought about whether most code paths or some code paths makes more sense, but I'm not sure there are a lot of cases in our code where it makes a difference. I don't think it makes sense to talk about a sole owner of a refcounted object. If there is a sole owner at any given time, it is at best temporary. PassRefPtr is about clearly and efficiently transferring a reference, it doesn't need it to necessarily be the sole then-existing reference. I think that to make this complete, the rules need to be transitive. A function that passes its argument to another function taking a PassRefPtr should itself take a PassRefPtr. That's the case in https://bugs.webkit.org/show_bug.cgi?id=52981, for instance. It doesn't seem that analyzing code for most/some code paths takes ownership would be any easier that analyzing it for any caller gives away ownership. In general it only requires inspecting the source of the function, and possibly the signatures of function it calls. The analysis for any caller gives away ownership requires searching over all of WebCore to find possible call sites. And it can easily change If we think the transitivity problem is a hazard, we could make PassRefPtr refuse to implicitly convert from raw pointers. Then to pass a raw pointer to a function that uses PassRefPtr you'd have to make a RefPtr first (or adopt, if the ref is unowned). That would make takes ownership analysis purely local to the function source. Yet it's the latter where PassRefPtr is beneficial. Why base the rule on something that's disconnected from actual benefit? Because it's simpler to read the source of your own function than to visit all call sites, and it's more obvious that when you change what the function does you may need to change the signature. Regards, Macij ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Mon, Jun 20, 2011 at 5:25 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 20, 2011, at 9:19 AM, Alexey Proskuryakov wrote: 20.06.2011, в 03:22, Maciej Stachowiak написал(а): For a shared ownership model there are multiple possible definitions of whether a function takes ownership to an object passed as an argument. Here are some of my attempts to describe the bright line: a) Hands off ownership to what could possibly be the sole owner in most code paths. b) Keeps a reference to the object after the function completes in most code paths. c) Takes a reference to the object at least once in most code paths. d) Hands off ownership to what could possibly be the sole owner in some code paths. e) Keeps a reference to the object after it completes in some code paths. f) Takes a reference to the object at least once in some code paths. Is the bright line rule you have in mind (b) or perhaps (e)? Or something not listed here at all? Yes, (b) or (e). I haven't thought about whether most code paths or some code paths makes more sense, but I'm not sure there are a lot of cases in our code where it makes a difference. I don't think it makes sense to talk about a sole owner of a refcounted object. If there is a sole owner at any given time, it is at best temporary. PassRefPtr is about clearly and efficiently transferring a reference, it doesn't need it to necessarily be the sole then-existing reference. I think that to make this complete, the rules need to be transitive. A function that passes its argument to another function taking a PassRefPtr should itself take a PassRefPtr. That's the case in https://bugs.webkit.org/show_bug.cgi?id=52981, for instance. It doesn't seem that analyzing code for most/some code paths takes ownership would be any easier that analyzing it for any caller gives away ownership. In general it only requires inspecting the source of the function, and possibly the signatures of function it calls. The analysis for any caller gives away ownership requires searching over all of WebCore to find possible call sites. And it can easily change If we think the transitivity problem is a hazard, we could make PassRefPtr refuse to implicitly convert from raw pointers. Then to pass a raw pointer to a function that uses PassRefPtr you'd have to make a RefPtr first (or adopt, if the ref is unowned). That would make takes ownership analysis purely local to the function source. I thought the problem was that a Pass*Ptr could silently 0 itself out and people use it directly. So the real problem functions are anything the fact that a Pass*Ptr can be used like a pointer and that another Pass*Ptr can slurp out its contents so easily (and you can't spot this in the code well). Maybe each of those operations should be more explicit? (Then we could probably even catch these issues automatically. If *.passPtr() is called and then *.get() is called later in the same function, mark it as an error. Not perfect but good enough.) Yet it's the latter where PassRefPtr is beneficial. Why base the rule on something that's disconnected from actual benefit? Because it's simpler to read the source of your own function than to visit all call sites, and it's more obvious that when you change what the function does you may need to change the signature. This seems much easier, less error prone, and more stable. dave Regards, Macij ___ 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] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
20.06.2011, в 17:25, Maciej Stachowiak написал(а): Yet it's the latter where PassRefPtr is beneficial. Why base the rule on something that's disconnected from actual benefit? Because it's simpler to read the source of your own function than to visit all call sites, and it's more obvious that when you change what the function does you may need to change the signature. I do not see how you are describing a practical coding situation here. I do not start with a dozen call sites all over the code base, and then write a function they all call. On the other hand, when adding a new call site that wants to pass ownership away, and the called function doesn't take a PassRefPtr, it's immediately obvious that it's not going to work. Even when following a cargo cult rule is easier (not uncommon!), the problem of it being disconnected from the actual benefit still remains. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New page for viewing test failures on build.webkit.org
On Jun 1, 2011, at 4:41 PM, Adam Barth wrote: Looks like a good start. Thanks! Have you considered a test-centric view (instead of a bot-centric view)? That might make it easier to see what's going on globally across the project. I have considered it, and I agree. That's basically what http://webkit.org/b/61059 is about. -Adam On Wed, Jun 1, 2011 at 12:22 PM, Adam Roben aro...@apple.com wrote: Hi all- Before I go on vacation for 2.5 weeks, I wanted to let you know about a new page I've been working on on build.webkit.org. You can see it here: http://build.webkit.org/TestFailures/ The idea of the page is to provide a single place to go to find out what tests are failing on the bots and when they started failing. It also tries to make it easy to file bugs about the failures. It is pretty ugly, and has some glaring bugs (search Bugzilla for TestFailures). But I've found it useful already. I hope you will, too! Please file bugs and feature requests in the Tools / Tests component of Bugzilla, include the word TestFailures in the bug, and CC me. The code lives in Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures. Let me know what you think! -Adam ___ 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] Different Versions of WebkitSupportLibrary.zip
On Jun 1, 2011, at 8:38 PM, Brian Stuart wrote: Hi All, I am trying to build a fork of WebKit on windows that requires a version of WebKitSupportLibrary.zip different than the one currently available from http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html In the script “WebKitTools/Scripts/update-webkit-support-libs” it’s looking for a version of WebKitSupportLibrary.zip with a checksum of a1341aadbcce1ef26dad2b2895457314 Does anyone know where I can download the correct version of WebKitSupportLibrary.zip? Are you trying to build an old version of WebKit? update-webkit-support-libs no longer uses a checksum to verify the version of the zip file. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Different Versions of WebkitSupportLibrary.zip
On Jun 20, 2011, at 11:21 PM, Brian Stuart wrote: Thanks for your reply, Yes I need to build an older version of webkit that was forked and has some custom changes. Any idea where I might find the correct version of WebkitSupportLibrary.zip? Old versions of WebKitSupportLibrary.zip aren't made available anywhere. (And even if you did have an old WebKitSupportLibrary.zip lying around, you'd also need the matching old version of Safari in order for the WebKit you built with it to actually be usable.) You could try using the latest version of update-webkit-support-libs and WebKitSupportLibrary.zip. Hopefully it will work with your old version of WebKit without requiring too many changes. -Adam On Jun 20, 2011, at 8:00 PM, Adam Roben wrote: On Jun 1, 2011, at 8:38 PM, Brian Stuart wrote: Hi All, I am trying to build a fork of WebKit on windows that requires a version of WebKitSupportLibrary.zip different than the one currently available from http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html In the script “WebKitTools/Scripts/update-webkit-support-libs” it’s looking for a version of WebKitSupportLibrary.zip with a checksum of a1341aadbcce1ef26dad2b2895457314 Does anyone know where I can download the correct version of WebKitSupportLibrary.zip? Are you trying to build an old version of WebKit? update-webkit-support-libs no longer uses a checksum to verify the version of the zip file. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Mon, Jun 20, 2011 at 6:11 PM, Alexey Proskuryakov a...@webkit.org wrote: 20.06.2011, в 17:25, Maciej Stachowiak написал(а): Yet it's the latter where PassRefPtr is beneficial. Why base the rule on something that's disconnected from actual benefit? Because it's simpler to read the source of your own function than to visit all call sites, and it's more obvious that when you change what the function does you may need to change the signature. I do not see how you are describing a practical coding situation here. I do not start with a dozen call sites all over the code base, and then write a function they all call. On the other hand, when adding a new call site that wants to pass ownership away, and the called function doesn't take a PassRefPtr, it's immediately obvious that it's not going to work. Even when following a cargo cult rule is easier (not uncommon!), the problem of it being disconnected from the actual benefit still remains. Here's a few benefits: 1. It makes the code more self-documenting. It clearly indicates that this function intends to take a reference to the item. 2. It is consistent with the rules for PassOwnPtr. It is nice to have one set of things in mind that are consistent. 3. Just like one shouldn't document a function based on who calls it because that may change, it makes sense to base the argument types on the how the function uses them not on the callers. - WBR, Alexey Proskuryakov ___ 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] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
20.06.2011, в 21:29, David Levin написал(а): Here's a few benefits: 1. It makes the code more self-documenting. It clearly indicates that this function intends to take a reference to the item. 2. It is consistent with the rules for PassOwnPtr. It is nice to have one set of things in mind that are consistent. 3. Just like one shouldn't document a function based on who calls it because that may change, it makes sense to base the argument types on the how the function uses them not on the callers. 1 and 3 sound very closely related. Yet I'm not sure if they are good. PassRefPtr is useful even if the function doesn't take any kind of ownership. It's useful when callers want to get rid of ownership, and then they can do that efficiently. As Maciej mentioned, eventually we may be able to get rid of PassRefPtr, and use C++0x move semantics. But applicability of move semantics also depends on how a function is called, not on what it is going to do with its arguments. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Lets use PassRefPtr for arguments less; lets use RefPtr for locals and data members more
On Mon, Jun 20, 2011 at 9:39 PM, Alexey Proskuryakov a...@webkit.org wrote: 20.06.2011, в 21:29, David Levin написал(а): Here's a few benefits: 1. It makes the code more self-documenting. It clearly indicates that this function intends to take a reference to the item. 2. It is consistent with the rules for PassOwnPtr. It is nice to have one set of things in mind that are consistent. 3. Just like one shouldn't document a function based on who calls it because that may change, it makes sense to base the argument types on the how the function uses them not on the callers. 1 and 3 sound very closely related. Yet I'm not sure if they are good. True, I didn't think of it that way when I wrote it. :) I feel like they are good, but I could be wrong. (I always have felt like knowing who is owning something is one of those tricky things when reading code so I've appreciated this but it may be of limited value when taking about ref counted items.) And I like 2 but it isn't critical. PassRefPtr is useful even if the function doesn't take any kind of ownership. It's useful when callers want to get rid of ownership, and then they can do that efficiently. I don't understand this. How it is more efficient to pass ownership if a function isn't taking ownership? It seems like passing in a raw pointer would be the most efficient in this case. As Maciej mentioned, eventually we may be able to get rid of PassRefPtr, and use C++0x move semantics. But applicability of move semantics also depends on how a function is called, not on what it is going to do with its arguments. Good point. Makes sense. dave - WBR, Alexey Proskuryakov ___ 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
