Re: [webkit-dev] msys support/WinCE support
On Mon, 11 Jul 2011 21:30:44 -0700, Brent Fulgham bfulg...@gmail.com wrote: Is the WinCE port still active? I don't know about your other questions, but Patrick Gansterer (paroga) maintains the WinCE port. I believe it is active. Correct, I still maintain the WinCE port and provide the buildbot for it. There is code in old-run-webkit-tests attempting to support msys configurations. (Which appears to be used by the WinCE port?) WinCE port does not use any testing scripts at the moment. :-( Is this an active configuration? Or can we remove msys support when transitioning to new-run-webkit-tests. Feel free to remove all WinCE code of it. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] msys support/WinCE support
Thank you. Will do. On Mon, Jul 11, 2011 at 11:10 PM, Patrick Gansterer par...@paroga.com wrote: On Mon, 11 Jul 2011 21:30:44 -0700, Brent Fulgham bfulg...@gmail.com wrote: Is the WinCE port still active? I don't know about your other questions, but Patrick Gansterer (paroga) maintains the WinCE port. I believe it is active. Correct, I still maintain the WinCE port and provide the buildbot for it. There is code in old-run-webkit-tests attempting to support msys configurations. (Which appears to be used by the WinCE port?) WinCE port does not use any testing scripts at the moment. :-( Is this an active configuration? Or can we remove msys support when transitioning to new-run-webkit-tests. Feel free to remove all WinCE code of it. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] PSA: Removing support for Apache 1.3 in WebKit
On Jul 11, 2011, at 9:33 PM, Eric Seidel wrote: Eventually we might transition the cygwin port to Apache2 https://bugs.webkit.org/show_bug.cgi?id=22517 discusses this a little bit. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Slow idioms with WTF::String
Hi folks. The key to fast use of WTF::String is to avoid creating temporary WTF::StringImpl objects or temporary copies of string data. With the latest enhancements to WTF::String, here are the preferred fast ways to build a new string: - A single expression with the + operator and arguments of type WTF::String, char, UChar, const char*, const UChar*, Vectorchar, and WTF::AtomicString. - A call to the WTF::makeString function. - An expression that uses a single function on the string, or uses the + operator exactly once, or the += operator with the types it supports directly. - WTF::StringBuilder, in cases where the logic to compute the pieces of the string has complex branching logic or requires a loop. Here are acceptable, but not preferred ways to build a new string: - Building up a VectorUChar followed by WTF::String::adopt. I believe StringBuilder is always better, so we should probably retire this idiom. Inefficient ways to build a new string include any uses of more than one of the following: - WTF::String::append. - The += operator. There are other operations that modify the WTF::String; none of those are efficient if the string in question is then modified further. - WTF::String::insert. - WTF::String::replace. In addition, there are quite a few operations that return a WTF::String, and none of those are efficient if the string in question is then modified further. - WTF::String::number. - WTF::String::substring. - WTF::String::left. - WTF::String::right. - WTF::String::lower. - WTF::String::upper. - WTF::String::stripWhiteSpace. - WTF::String::simplifyWhiteSpace. - WTF::String::removeCharacters. - WTF::String::foldCase. - WTF::String::format. - WTF::String::fromUTF8. One reason I bring this up is that if we wanted to make combinations of these more efficient, we might be able to use techniques similar to those used in StringOperators.h to make it so the entire result string is built at one time, eliminating unnecessary copies of the string characters and intermediate StringImpl objects on the heap. It would be interesting to find out how often the inefficient idioms are used. Until recently, there was no significantly better alternative to the inefficient idioms, so it’s highly likely we have them in multiple places. A quick grep showed me inefficient uses of += in XMLDocumentParser::handleError and XPath::FunTranslate::evaluate, parseRFC822HeaderFields, InspectorStyleSheet::addRule, drawElementTitle in DOMNodeHighlighter.cpp, WebKitCSSTransformValue::cssText, CSSSelector::selectorText, CSSPrimitiveValue::cssText, CSSBorderImageValue::cssText, and CSSParser::createKeyframeRule. I would not be surprised if at least some of these will show up immediately with the right kind of performance test. The CSS parsing and serialization functions seem almost certain to be measurably slow. I’m looking for two related things: 1) A clean way to find and root out uses of the inefficient idioms that we can work on together as a team. 2) Some ways to further refine WTF::String so it’s harder to “use it wrong”. I don’t have any immediate steps in mind, but one possibility would be to remove functions that are usually part of poorly-performing idioms, pushing WebKit programmers subtly in the direction of operations that don’t build intermediate strings. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Slow idioms with WTF::String
On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com wrote: Hi folks. The key to fast use of WTF::String is to avoid creating temporary WTF::StringImpl objects or temporary copies of string data. With the latest enhancements to WTF::String, here are the preferred fast ways to build a new string: - A single expression with the + operator and arguments of type WTF::String, char, UChar, const char*, const UChar*, Vectorchar, and WTF::AtomicString. - A call to the WTF::makeString function. - An expression that uses a single function on the string, or uses the + operator exactly once, or the += operator with the types it supports directly. - WTF::StringBuilder, in cases where the logic to compute the pieces of the string has complex branching logic or requires a loop. Here are acceptable, but not preferred ways to build a new string: - Building up a VectorUChar followed by WTF::String::adopt. I believe StringBuilder is always better, so we should probably retire this idiom. Inefficient ways to build a new string include any uses of more than one of the following: - WTF::String::append. - The += operator. There are other operations that modify the WTF::String; none of those are efficient if the string in question is then modified further. - WTF::String::insert. - WTF::String::replace. In addition, there are quite a few operations that return a WTF::String, and none of those are efficient if the string in question is then modified further. - WTF::String::number. - WTF::String::substring. - WTF::String::left. - WTF::String::right. - WTF::String::lower. - WTF::String::upper. - WTF::String::stripWhiteSpace. - WTF::String::simplifyWhiteSpace. - WTF::String::removeCharacters. - WTF::String::foldCase. - WTF::String::format. - WTF::String::fromUTF8. One reason I bring this up is that if we wanted to make combinations of these more efficient, we might be able to use techniques similar to those used in StringOperators.h to make it so the entire result string is built at one time, eliminating unnecessary copies of the string characters and intermediate StringImpl objects on the heap. It would be interesting to find out how often the inefficient idioms are used. Until recently, there was no significantly better alternative to the inefficient idioms, so it’s highly likely we have them in multiple places. A quick grep showed me inefficient uses of += in XMLDocumentParser::handleError and XPath::FunTranslate::evaluate, parseRFC822HeaderFields, InspectorStyleSheet::addRule, drawElementTitle in DOMNodeHighlighter.cpp, WebKitCSSTransformValue::cssText, CSSSelector::selectorText, CSSPrimitiveValue::cssText, CSSBorderImageValue::cssText, and CSSParser::createKeyframeRule. I would not be surprised if at least some of these will show up immediately with the right kind of performance test. The CSS parsing and serialization functions seem almost certain to be measurably slow. I’m looking for two related things: 1) A clean way to find and root out uses of the inefficient idioms that we can work on together as a team. 2) Some ways to further refine WTF::String so it’s harder to “use it wrong”. I don’t have any immediate steps in mind, but one possibility would be to remove functions that are usually part of poorly-performing idioms, pushing WebKit programmers subtly in the direction of operations that don’t build intermediate strings. -- Darin This thread resonates very deeply with me (idioms that make it hard to write slow code == pure goodness), but I suspect we really ought to build performance tests to help support these improvements. It is easy to put a lot of energy into optimizing code that provides no measurable benefit :-/ -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Slow idioms with WTF::String
Excited to see WTF::String getting easier to use efficiently! On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com wrote: I would not be surprised if at least some of these will show up immediately with the right kind of performance test. The CSS parsing and serialization functions seem almost certain to be measurably slow. Yes indeed. Serialization code is very inefficient now. On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com wrote: Here are acceptable, but not preferred ways to build a new string: - Building up a VectorUChar followed by WTF::String::adopt. I believe StringBuilder is always better, so we should probably retire this idiom. Inefficient ways to build a new string include any uses of more than one of the following: - WTF::String::append. - The += operator. MarkupAccumulator and StyledMarkupAccumulator do exactly this. MarkupAccumulator have many appendX member functions where X is the name of a node type. When one of those functions is called, it'll create a VectorUChar which is passed around helper functions to build up the serialization for the node. The VectorUChar is then adopted as String and put into a VectorString. The resultant vector is aggregated as one giant String at the end. It seems like the solution here is to use StringBuilder? StyledMarkupAccumulator is somewhat tricker to make efficient because it'll reverse the order of Strings in VectorString when aggregating the vector. Since we wouldn't know the last String (the first substring to appear in the final serialization) at the beginning, we can't use StringBuilder. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Slow idioms with WTF::String
On Jul 12, 2011, at 10:31 AM, Darin Fisher wrote: On Tue, Jul 12, 2011 at 10:25 AM, Darin Adler da...@apple.com wrote: I would not be surprised if at least some of these will show up immediately with the right kind of performance test. The CSS parsing and serialization functions seem almost certain to be measurably slow. I’m looking for two related things: 1) A clean way to find and root out uses of the inefficient idioms that we can work on together as a team. 2) Some ways to further refine WTF::String so it’s harder to “use it wrong”. I don’t have any immediate steps in mind, but one possibility would be to remove functions that are usually part of poorly-performing idioms, pushing WebKit programmers subtly in the direction of operations that don’t build intermediate strings. This thread resonates very deeply with me (idioms that make it hard to write slow code == pure goodness), but I suspect we really ought to build performance tests to help support these improvements. It is easy to put a lot of energy into optimizing code that provides no measurable benefit :-/ I think we are in agreement. I think my “I would not be surprised if these show up with the right kind of performance test” comment wasn’t direct enough. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
Hi all, On a related note, we've found that as of iOS 4.3.3 Mobile Safari will also not play .wav files under the same conditions. (Unverified SSL cert, manually accepted by the user.) The error is: The Movie cannot be played. I've updated ID# 9697244 at http://bugreport.apple.com. But can anyone see a good reason why a browser would refuse to play a .wav file, but happily render .html, .jpg, .css, etc? -Paul -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Mossman, Paul (Paul) Sent: June 29, 2011 1:33 PM To: Adam Barth Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419) Thanks Adam! I've filed an Enhancement with Apple: Bug ID# 9697244. -Paul -Original Message- From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth Sent: June 28, 2011 1:28 PM To: Mossman, Paul (Paul) Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419) This isn't a WebKit issue. It's an issue for the embedding application. You'll need to file a bug with the relevant browser vendor. For Apple, you can use https://bugreport.apple.com/ or Chromium, you can use http://new.crbug.com/ Good luck! Adam On Tue, Jun 28, 2011 at 8:39 AM, Mossman, Paul (Paul) paulmoss...@avaya.com wrote: Hi all, I originally sent this to webkit-help, but I probably should have posted it here instead. I'd like to request an alternate resolution to the following issue: https://bugs.webkit.org/show_bug.cgi?id=41419 We should log the reason when a secure wss WebSocket connection could not be established (was: Secure wss WebSocket connections cannot be established) Consider an example https://appliance.example.com, which uses a self-signed SSL certificate. iOS Safari will warn the user: Cannot Verify Server Identify Safari can't verify the identity of appliance.example.com. Would you like to continue anyway? Cancel / Details / Continue The user chooses to Continue. Safari then trusts the identity of appliance.example.com, and proceeds. The resulting HTML may spawn additional https:// requests, which will also proceed. Suppose though that a wss:// connection to appliance.example.com is initiated. As issue 41419 states, this will fail in Safari and WebKit (r87480.) Chrome on the other hand, consider the user's acceptance of the server's identity as valid for both wss:// and https:// connection. This seems reasonable. The user accepted the server's identity, with no caveat on the protocol. Can this behaviour be implemented in WebKit as the resolution to issue 41419? -Paul paulmoss...@avaya.com ___ 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] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
12.07.2011, в 11:15, Mossman, Paul (Paul) написал(а): On a related note, we've found that as of iOS 4.3.3 Mobile Safari will also not play .wav files under the same conditions. (Unverified SSL cert, manually accepted by the user.) The error is: The Movie cannot be played. I've updated ID# 9697244 at http://bugreport.apple.com. Please file a new bug at http://bugreport.apple.com for that issue. It's always easier to mark bugs as duplicates than to split them if we want to make such adjustments later. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] wav file question
On Jul 12, 2011, at 11:15 AM, Mossman, Paul (Paul) wrote: But can anyone see a good reason why a browser would refuse to play a .wav file, but happily render .html, .jpg, .css, etc? This is not an appropriate question for webkit-dev as it is not a question about the development of WebKit. A good place to get answers about this are in the iOS Dev Center and Safari Dev Center. Generally speaking, media playback on webpages has to be user-initiated in iOS. This is covered in various Apple documentation, such as Safari HTML5 Audio and Video Guide, but typically that concentrates on the audio element rather than directly loading a wav file. But please don’t ask followup questions about this on this mailing list, since it’s off topic for the list. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
I apologize for the confusion. Thank you Alexey and Darin for your guidance. I've filed ID# 9761774 at http://bugreport.apple.com. Cheers. -Paul -Original Message- From: Alexey Proskuryakov [mailto:a...@webkit.org] Sent: July 12, 2011 2:25 PM To: Mossman, Paul (Paul) Cc: webkit-dev Development Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419) 12.07.2011, в 11:15, Mossman, Paul (Paul) написал(а): On a related note, we've found that as of iOS 4.3.3 Mobile Safari will also not play .wav files under the same conditions. (Unverified SSL cert, manually accepted by the user.) The error is: The Movie cannot be played. I've updated ID# 9697244 at http://bugreport.apple.com. Please file a new bug at http://bugreport.apple.com for that issue. It's always easier to mark bugs as duplicates than to split them if we want to make such adjustments later. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Slow idioms with WTF::String
How about using RopeImpl as JSString does to boost operator+=? Not sure how bad it affects simple strings. Then another idea is to introduce a LargeString implemented with ropes for special purposes like parsers. Another slow case is converting a const C string to WTF::String every time. For example, return (m_httpHeaderFields.contains(If-Match) || m_httpHeaderFields.contains(If-Modified-Since) || m_httpHeaderFields.contains(If-None-Match) || m_httpHeaderFields.contains(If-Range) || m_httpHeaderFields.contains(If-Unmodified-Since)); This function creates 5 Strings (calls fastMalloc 5 times), and also calculates the hash key 5 times, and then throws them away. 2011/7/12 Darin Adler da...@apple.com: Hi folks. The key to fast use of WTF::String is to avoid creating temporary WTF::StringImpl objects or temporary copies of string data. With the latest enhancements to WTF::String, here are the preferred fast ways to build a new string: - A single expression with the + operator and arguments of type WTF::String, char, UChar, const char*, const UChar*, Vectorchar, and WTF::AtomicString. - A call to the WTF::makeString function. - An expression that uses a single function on the string, or uses the + operator exactly once, or the += operator with the types it supports directly. - WTF::StringBuilder, in cases where the logic to compute the pieces of the string has complex branching logic or requires a loop. Here are acceptable, but not preferred ways to build a new string: - Building up a VectorUChar followed by WTF::String::adopt. I believe StringBuilder is always better, so we should probably retire this idiom. Inefficient ways to build a new string include any uses of more than one of the following: - WTF::String::append. - The += operator. There are other operations that modify the WTF::String; none of those are efficient if the string in question is then modified further. - WTF::String::insert. - WTF::String::replace. In addition, there are quite a few operations that return a WTF::String, and none of those are efficient if the string in question is then modified further. - WTF::String::number. - WTF::String::substring. - WTF::String::left. - WTF::String::right. - WTF::String::lower. - WTF::String::upper. - WTF::String::stripWhiteSpace. - WTF::String::simplifyWhiteSpace. - WTF::String::removeCharacters. - WTF::String::foldCase. - WTF::String::format. - WTF::String::fromUTF8. One reason I bring this up is that if we wanted to make combinations of these more efficient, we might be able to use techniques similar to those used in StringOperators.h to make it so the entire result string is built at one time, eliminating unnecessary copies of the string characters and intermediate StringImpl objects on the heap. It would be interesting to find out how often the inefficient idioms are used. Until recently, there was no significantly better alternative to the inefficient idioms, so it’s highly likely we have them in multiple places. A quick grep showed me inefficient uses of += in XMLDocumentParser::handleError and XPath::FunTranslate::evaluate, parseRFC822HeaderFields, InspectorStyleSheet::addRule, drawElementTitle in DOMNodeHighlighter.cpp, WebKitCSSTransformValue::cssText, CSSSelector::selectorText, CSSPrimitiveValue::cssText, CSSBorderImageValue::cssText, and CSSParser::createKeyframeRule. I would not be surprised if at least some of these will show up immediately with the right kind of performance test. The CSS parsing and serialization functions seem almost certain to be measurably slow. I’m looking for two related things: 1) A clean way to find and root out uses of the inefficient idioms that we can work on together as a team. 2) Some ways to further refine WTF::String so it’s harder to “use it wrong”. I don’t have any immediate steps in mind, but one possibility would be to remove functions that are usually part of poorly-performing idioms, pushing WebKit programmers subtly in the direction of operations that don’t build intermediate strings. -- 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] Slow idioms with WTF::String
Hi Yong, On 12 July 2011 18:10, Yong Li yong.li.web...@gmail.com wrote: Another slow case is converting a const C string to WTF::String every time. For example, return (m_httpHeaderFields.contains(If-Match) || m_httpHeaderFields.contains(If-Modified-Since) || m_httpHeaderFields.contains(If-None-Match) || m_httpHeaderFields.contains(If-Range) || m_httpHeaderFields.contains(If-Unmodified-Since)); This function creates 5 Strings (calls fastMalloc 5 times), and also calculates the hash key 5 times, and then throws them away. In this case, the code already indicates it is not optimal: HTTPHeaderMap.h: // Alternate accessors that are faster than converting the char* to AtomicString first. bool contains(const char*) const; Also this converting can probably be fixed by using DEFINE_STATIC_LOCAL(AtomicString,...). Cheers, Rob. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Followup to the WML discussion
As a follow-up to this question, should Webkit support WCSS now that WML has been removed? There has been a patch sitting around for a while waiting to do this here: https://bugs.webkit.org/show_bug.cgi?id=59786 On Sun, Apr 24, 2011 at 6:22 PM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, To make progress on the question of whether to remove support for WML, I sent an informal poll the the WebKit reviewers mailing list. (In the interests of transparency, I've included the full text of the email below.) The poll contained a single question: 1. Should WebKit support WML? A) Yes, WebKit should continue to support WML behind ENABLE(WML) B) No, WebKit should remove support for WML 17 reviewers responded to the poll, and all 17 chose option (B). This poll is not a binding vote in any way, but, based on this information, I recommend that we remove support for WML. Thanks, Adam -- Forwarded message -- From: Adam Barth aba...@webkit.org Date: Wed, Apr 20, 2011 at 1:58 PM Subject: Poll about removing WML To: webkit-reviewers Hi webkit-reviewers, There's been some discussion on webkit-dev recently about whether we should remove support for WML. To get a sense for how the project leadership feels about removing support for WML, I've created a simple one-question poll: http://www.surveymonkey.com/s/xxx If you have an opinion about whether WebKit should support WML, please take a minute to fill out the poll. (If you don't have an opinion, please feel free to ignore the poll.) This poll is not a binding vote in any way. I'd just like to informally gather some data on how folks who are deeply involved with the project feel about this feature. I'll send out the results of the poll to webkit-dev on Sunday morning (in advance of the WebKit meeting). Thanks everyone, 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] Remote Debugging v8 - Android
Hi Steve,We would +1 for this feature in Android (and iOS too).--GlanOn Jul 7, 2011, at 6:11 AM, Steve Block wrote:You need to check with Android port owners on whether they intend to enableINSPECTOR in their builds and expose remote debugging capabilities.I'm afraid we have no plans right now to enable this feature.Steve-- Google UK LimitedRegistered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQRegistered in England Number: 3977902___webkit-dev mailing listwebkit-dev@lists.webkit.orghttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev Glan ThomasSr. Front-end Engineerg...@tapulous.comhttp://tapulous.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Followup to the WML discussion
On Jul 12, 2011, at 4:42 PM, Luke Macpherson wrote: As a follow-up to this question, should Webkit support WCSS now that WML has been removed? Seems an obvious no. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Followup to the WML discussion
12.07.2011, в 16:42, Luke Macpherson написал(а): As a follow-up to this question, should Webkit support WCSS now that WML has been removed? There was an IRC discussion of that a few months ago, which hasn't been captured in the bug. WCSS is also apparently needed for XHTML-MP, which we haven't removed support for (yet?) - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Mon, Jul 11, 2011 at 11:52 AM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Jul 11, 2011 at 10:46 AM, Adam Barth aba...@webkit.org wrote: On Mon, Jul 11, 2011 at 12:30 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 10, 2011, at 12:11 PM, Adam Barth wrote: On Sun, Jul 10, 2011 at 12:01 PM, James Robinson jam...@google.com wrote: On Jul 10, 2011 10:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, In trying to understand how our LayoutTest results system works, I've created a digram of the fallback graph among the various platform-specific directories: https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US Unfortunately, the fallback graph is not a tree, as one might imagine initially. I'd like to propose two small changes, which will hopefully make the system more sensible globally. I'm happy to do all the work required to make these changes: 1) The win port should fall back either to all (the platform independent results) or to mac, but not to mac-snowleopard, as it does currently. (I slightly prefer all, but mac would also be fine with me.) 2) The chromium port should fall back directly to all rather than taking a detour through various Apple-maintained ports, as it does currently. These changes have the following virtues: A) The resulting fallback graph will be a tree, making the fallback graph easier to understand for both humans and automated tools. B) The Chromium port will behave more like the other ports (e.g., GTK and Qt), rather than being a parasite on Apple-maintained ports. These changes might increase the number of image baselines we store in the tree for chromium-mac-derived ports (because there will be fewer redundant fallback paths), but I expect that cost to be relatively small because essentially every port has different image baselines anyway Could you measure this? I suspect that not falling back on the mac pixel results will mean checking in a few thousand more pngs, but that's just a guess. That seems possible: abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-mac$ find . -name *.png | wc -l 900 abarth@quadzen:~/git/webkit/LayoutTests/platform/mac$ find . -name *.png | wc -l 6688 abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-win$ find . -name *.png | wc -l 5988 abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-linux$ find . -name *.png | wc -l 5731 Adding thousands more PNGs would be unfortunate, especially if a significant number of them are going to be rolled over frequently. I wouldn't expect a significant number of them to change frequently. What are the concrete benefits of the fallback graph being a tree? There are two main benefits: 1) A tree is much easier to understand than a rats nest of interwoven fallback paths. Today, the graph is close to a tree so it's possible for experts to understand how things work, but if we continue to add non-transitive paths, the situation will quickly spiral out of control. For folks who aren't experts about how the system works today, I doubt they could correctly predict the consequence of certain actions. One of my short-term goals is to make managing the expecte results easier, which is why I'm interested in having the system be understandable to non-experts. 2) Without a tree structure, it's difficult to compute the optimum assignments of expected results to directories. With a tree structure, it's very easy. If all the children of a node have the same result, you can delete the result at the children and promote it to the parent. That reasoning is false for our current fallback graph. The correct rule for when you can promote a result instead requires reasoning over all paths (of which, of course, there are exponentially many). I'm not sure I understand in what sense you're using the word optimum here. Normally I would define it as fewest overall baselines in the tree. Using my definition, it seems possible that having multiple parents could result in fewer baselines. Example: if chromium-mac is allowed to fallback on chromium, then mac, then all (rather than just chromium then all or mac then all) you may need fewer total baselines Of course, I'm not sure that fewest overall baselines is in fact the goal we should be shooting for. I definitely agree that a tree is easier to understand. This of course is the same debate as single inheritance vs. multiple ... multiple may reduce the total lines of code, but be harder to understand NRWT has nearly all of the code needed to make it easy to evaluate what the total impact of changing the paths would be. I think I had some scripts to do this long ago but I've lost them. I should be able to reconstruct them this afternoon. Okay, following up ... I think I'm actually responsible for making the fallback path not be a tree, from when I introduced the 'chromium' directory, so perhaps
Re: [webkit-dev] LayoutTests results fallback graph
On Tue, Jul 12, 2011 at 8:05 PM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Jul 11, 2011 at 11:52 AM, Dirk Pranke dpra...@chromium.org wrote: On Mon, Jul 11, 2011 at 10:46 AM, Adam Barth aba...@webkit.org wrote: On Mon, Jul 11, 2011 at 12:30 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 10, 2011, at 12:11 PM, Adam Barth wrote: On Sun, Jul 10, 2011 at 12:01 PM, James Robinson jam...@google.com wrote: On Jul 10, 2011 10:53 AM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, In trying to understand how our LayoutTest results system works, I've created a digram of the fallback graph among the various platform-specific directories: https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit?hl=en_US Unfortunately, the fallback graph is not a tree, as one might imagine initially. I'd like to propose two small changes, which will hopefully make the system more sensible globally. I'm happy to do all the work required to make these changes: 1) The win port should fall back either to all (the platform independent results) or to mac, but not to mac-snowleopard, as it does currently. (I slightly prefer all, but mac would also be fine with me.) 2) The chromium port should fall back directly to all rather than taking a detour through various Apple-maintained ports, as it does currently. These changes have the following virtues: A) The resulting fallback graph will be a tree, making the fallback graph easier to understand for both humans and automated tools. B) The Chromium port will behave more like the other ports (e.g., GTK and Qt), rather than being a parasite on Apple-maintained ports. These changes might increase the number of image baselines we store in the tree for chromium-mac-derived ports (because there will be fewer redundant fallback paths), but I expect that cost to be relatively small because essentially every port has different image baselines anyway Could you measure this? I suspect that not falling back on the mac pixel results will mean checking in a few thousand more pngs, but that's just a guess. That seems possible: abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-mac$ find . -name *.png | wc -l 900 abarth@quadzen:~/git/webkit/LayoutTests/platform/mac$ find . -name *.png | wc -l 6688 abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-win$ find . -name *.png | wc -l 5988 abarth@quadzen:~/git/webkit/LayoutTests/platform/chromium-linux$ find . -name *.png | wc -l 5731 Adding thousands more PNGs would be unfortunate, especially if a significant number of them are going to be rolled over frequently. I wouldn't expect a significant number of them to change frequently. What are the concrete benefits of the fallback graph being a tree? There are two main benefits: 1) A tree is much easier to understand than a rats nest of interwoven fallback paths. Today, the graph is close to a tree so it's possible for experts to understand how things work, but if we continue to add non-transitive paths, the situation will quickly spiral out of control. For folks who aren't experts about how the system works today, I doubt they could correctly predict the consequence of certain actions. One of my short-term goals is to make managing the expecte results easier, which is why I'm interested in having the system be understandable to non-experts. 2) Without a tree structure, it's difficult to compute the optimum assignments of expected results to directories. With a tree structure, it's very easy. If all the children of a node have the same result, you can delete the result at the children and promote it to the parent. That reasoning is false for our current fallback graph. The correct rule for when you can promote a result instead requires reasoning over all paths (of which, of course, there are exponentially many). I'm not sure I understand in what sense you're using the word optimum here. Normally I would define it as fewest overall baselines in the tree. Using my definition, it seems possible that having multiple parents could result in fewer baselines. Example: if chromium-mac is allowed to fallback on chromium, then mac, then all (rather than just chromium then all or mac then all) you may need fewer total baselines Of course, I'm not sure that fewest overall baselines is in fact the goal we should be shooting for. I definitely agree that a tree is easier to understand. This of course is the same debate as single inheritance vs. multiple ... multiple may reduce the total lines of code, but be harder to understand NRWT has nearly all of the code needed to make it easy to evaluate what the total impact of changing the paths would be. I think I had some scripts to do this long ago but I've lost them. I should be able to reconstruct them this afternoon. Okay, following up ... I think I'm actually responsible for making the fallback path
Re: [webkit-dev] LayoutTests results fallback graph
On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke dpra...@chromium.org wrote: Hum. I take it back ... it still wouldn't be a tree, since chromium-mac-leopard would fall back to chromium-mac-snowleopard, then mac-leopard, but chromium-mac-snow-leopard would fall back to mac-snowleopard (giving chromium-mac-snowleopard two parents). And it looks like chromium-mac-leopard picks up 3,494 baselines from mac-leopard :(. Can we create chromium-mac and move everything that's shared between chromium-mac-leopard and chromium-mac-snowleopard there? It seems wrong for chromium-mac-leopard to fallback to chromium-mac-snowleopard. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Tue, Jul 12, 2011 at 8:34 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke dpra...@chromium.org wrote: Hum. I take it back ... it still wouldn't be a tree, since chromium-mac-leopard would fall back to chromium-mac-snowleopard, then mac-leopard, but chromium-mac-snow-leopard would fall back to mac-snowleopard (giving chromium-mac-snowleopard two parents). And it looks like chromium-mac-leopard picks up 3,494 baselines from mac-leopard :(. Can we create chromium-mac and move everything that's shared between chromium-mac-leopard and chromium-mac-snowleopard there? It seems wrong for chromium-mac-leopard to fallback to chromium-mac-snowleopard. This somewhat surprising fallback strategy is common across ports. The why is explained on this wiki page: http://trac.webkit.org/wiki/LayoutTestsSearchPath Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] LayoutTests results fallback graph
On Tue, Jul 12, 2011 at 9:01 PM, Adam Barth aba...@webkit.org wrote: On Tue, Jul 12, 2011 at 8:34 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke dpra...@chromium.org wrote: Hum. I take it back ... it still wouldn't be a tree, since chromium-mac-leopard would fall back to chromium-mac-snowleopard, then mac-leopard, but chromium-mac-snow-leopard would fall back to mac-snowleopard (giving chromium-mac-snowleopard two parents). And it looks like chromium-mac-leopard picks up 3,494 baselines from mac-leopard :(. Can we create chromium-mac and move everything that's shared between chromium-mac-leopard and chromium-mac-snowleopard there? It seems wrong for chromium-mac-leopard to fallback to chromium-mac-snowleopard. This somewhat surprising fallback strategy is common across ports. The why is explained on this wiki page: http://trac.webkit.org/wiki/LayoutTestsSearchPath In addition, we do actually have a 'chromium-mac'; we don't have a 'chromium-mac-snowleopard'. I think I mixed that in my mind while typing this with the apple mac ports, where there are mac-leopard, mac-sl, and mac ports (the latter representing lion/future). Once Lion ships, chromium will undoubtedly add a chromium-mac-snowleopard dir. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
