Re: [webkit-dev] LayoutTests results fallback graph
On Tue, Jul 12, 2011 at 9:01 PM, Adam Barth wrote: > On Tue, Jul 12, 2011 at 8:34 PM, Ryosuke Niwa wrote: >> On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke 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
Re: [webkit-dev] LayoutTests results fallback graph
On Tue, Jul 12, 2011 at 8:34 PM, Ryosuke Niwa wrote: > On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke 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 8:19 PM, Dirk Pranke 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:05 PM, Dirk Pranke wrote: > On Mon, Jul 11, 2011 at 11:52 AM, Dirk Pranke wrote: >> On Mon, Jul 11, 2011 at 10:46 AM, Adam Barth wrote: >>> On Mon, Jul 11, 2011 at 12:30 AM, Maciej Stachowiak wrote: On Jul 10, 2011, at 12:11 PM, Adam Barth wrote: > On Sun, Jul 10, 2011 at 12:01 PM, James Robinson > wrote: >> On Jul 10, 2011 10:53 AM, "Adam Barth" 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 ...
Re: [webkit-dev] LayoutTests results fallback graph
On Mon, Jul 11, 2011 at 11:52 AM, Dirk Pranke wrote: > On Mon, Jul 11, 2011 at 10:46 AM, Adam Barth wrote: >> On Mon, Jul 11, 2011 at 12:30 AM, Maciej Stachowiak wrote: >>> On Jul 10, 2011, at 12:11 PM, Adam Barth wrote: On Sun, Jul 10, 2011 at 12:01 PM, James Robinson wrote: > On Jul 10, 2011 10:53 AM, "Adam Barth" 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 tota
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] 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] 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
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 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 > 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] Slow idioms with WTF::String
Hi Yong,
On 12 July 2011 18:10, Yong Li 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] 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 :
> 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*, Vector, 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 Vector 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] 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] 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 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)
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] 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) > > 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] 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 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] 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 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 wrote: > > Here are acceptable, but not preferred ways to build a new string: > >- Building up a Vector 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 Vector which is passed around helper functions to build up the serialization for the node. The Vector is then adopted as String and put into a Vector. 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 Vector 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 Tue, Jul 12, 2011 at 10:25 AM, Darin Adler 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*, Vector, 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 Vector 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
[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*, Vector, 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 Vector 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] 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
Re: [webkit-dev] msys support/WinCE support
Thank you. Will do. On Mon, Jul 11, 2011 at 11:10 PM, Patrick Gansterer wrote: > On Mon, 11 Jul 2011 21:30:44 -0700, Brent Fulgham > 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
