Re: [webkit-dev] Request for Position: Compute Pressure API

2021-05-05 Thread Alex Christensen via webkit-dev
Has anyone discussed how this can increase the precision of fingerprinting?  It 
seems to reveal more information or more precise information about what else is 
going on on a user’s system.

> On May 5, 2021, at 11:37 AM, Olivier Yiptong via webkit-dev 
>  wrote:
> 
> Hello WebKit devs,
> 
> We'd like to get WebKit's position on the Compute Pressure API.
> 
> Description:
> 
> We propose a new API that conveys the utilization of CPU resources on the 
> user's device. This API targets applications that can trade off CPU resources 
> for an improved user experience. For example, many applications can render 
> video effects with varying degrees of sophistication. These applications aim 
> to provide the best user experience, while avoiding driving the user's device 
> in a high CPU utilization regime.
> 
> High CPU utilization is undesirable because it strongly degrades the user 
> experience. Many smartphones, tablets and laptops become uncomfortably hot to 
> the touch. The fans in laptops and desktops become so loud that they disrupt 
> conversations or the users’ ability to focus. In many cases, a device under 
> high CPU utilization appears to be unresponsive, as the operating system may 
> fail to schedule the threads advancing the task that the user is waiting for.
> 
> Thanks!
> 
> Specification Title: Compute Pressure API
> Specification URL: https://oyiptong.github.io/compute-pressure/ 
> 
> Explainger: https://github.com/oyiptong/compute-pressure/blob/main/README.md 
> 
> ChromeStatus.com entry: https://chromestatus.com/features/5597608644968448 
> 
> TAG design review request: 
> https://github.com/w3ctag/design-reviews/issues/621 
> 
> Mozilla Request for Position: 
> https://github.com/mozilla/standards-positions/issues/521 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-29 Thread Alex Christensen via webkit-dev
Thanks, David.  I think we’re on the same page now.

> On Apr 29, 2021, at 12:47 PM, David Benjamin  wrote:
> 
> Ah yes, that is confusing. Not quite. What's going on here is that we've 
> moved 3DES (and SHA-1 server signatures) under a fallback connection, so our 
> first connection won't advertise them, but on error the second one will. This 
> means that, for compatibility and security purposes, we do support 3DES. But 
> when you look at the ClientHellos, it'll look like we don't.
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ
>  
> 
Ah, yes.  Now I see that when connecting to https://3des.badssl.com/ Chrome 
will send a retry client hello with TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

> (By the way, it looks like, on my machine, Safari on Big Sur also supports 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA.)
You are correct.  I overlooked that one, which upon closer inspection was right 
next to the other ones the whole time.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Alex Christensen via webkit-dev
I don’t see the goal as “keep non-Unified-Source building” but rather “prevent 
unrelated build fixes when we add another file later”.  Right now when we add a 
new file we often have to sprinkle includes, declarations, and other build 
fixes in files unrelated to the current change.  If we had a bot building 
without unification we would be informed at the time we write the problematic 
code.

> On Apr 29, 2021, at 9:55 AM, Darin Adler via webkit-dev 
>  wrote:
> 
> Given the issue is that there are people that are using non-Unified-Source 
> building for their development, the best fix is to add post-commit and EWS 
> builders for one of those platforms. I do not support the idea of adding an 
> additional builder just to “keep non-Unified-Source building” if no 
> actively-supported platform is not choosing that build style.
> 
> Specifically, if Sony people are most affected by this, I suggest we find a 
> way to add Sony PlayStation post-commit and EWS builders.
> 
> I am not convinced that we should add some kind of abstract “correct 
> compilation” that is a separate builder.
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] New EWS Non-Unified builder

2021-04-29 Thread Alex Christensen via webkit-dev
I’d be excited to have this.  Those build failures have been bothering me ever 
since we started using unified builds.  We would have a way to see more 
problems in our code that are currently hidden.

> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> In Igalia we have been discussing the need of deploying a new builder
> which builds WebKit using non-unified sources, and we know that at least
> the folks at Sony are also in favor.
> 
> One side effect of Unified Source building is that it hides compilation
> errors. The kinds of errors that usually get hidden by unified builds
> are missing headers inclusions and missing definitions of functions
> declared inline; the latter being tricky to debug because it results in
> mysterious linker errors. This is caused by unified builds stashing
> several .cpp files together for compilation, so the definitions and
> header inclusions done in one “leak” into the others. As for missing
> header inclusion errors, a source file might include a header definition
> as a co-lateral effect of being stashed together with another file that
> indeed includes the missing header.
> 
> These hidden compilation errors may arise later at some point if unified
> source files are stashed together in a different manner.
> 
> The current situation is requiring periodical maintenance. You can check
> build fixes commits due to unified source compilation with:
> 
>$ git log --pretty=short --grep "Non-unified"
> 
> Here are some examples:
>https://bugs.webkit.org/show_bug.cgi?id=222652
>https://bugs.webkit.org/show_bug.cgi?id=222755
>https://bugs.webkit.org/show_bug.cgi?id=221701
> 
> A new builder which builds WebKit with non-unified Source will highly
> help to improve this situation. Compilation errors will be detected as
> soon as possible and will save a lot of time not only for the developers
> who are currently doing this manual maintenance but for anyone who would
> like to build WebKit, and may stumble on compilation errors accidentally
> introduced due to unified sources.
> 
> While correct compilation of the codebase can only be guaranteed with
> non-unified source builds, we do not propose switching the current EWS
> compilation builders to non-unified because it's slower and the EWS
> LayoutTests and API test bots use the products built by the EWS builders
> — we do not want to delay getting results from those. That's why we are
> proposing a new builder: it will run on parallel, resulting in no
> slowdown for the other EWS builders, which will keep using unified
> builds.
> 
> How this new builder will impact developers? The EWS LayoutTest bots
> take at least 1 hour to complete a build. We think that as long as this
> new EWS Non-Unified builder is within that time budget, this new EWS
> wont' slow down development speed.
> 
> Thoughts?
> 
> Best regards,
> 
> Diego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-28 Thread Alex Christensen via webkit-dev
They are aware of this thread now, but I can’t comment on any future plans.  I 
do have a few quick questions, though. 

A quick glance at the client hellos sent by browsers shows this:
Safari on Big Sur sends TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) and 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) in its supported cipher suites 
section of the client hello.
Firefox 88 sends TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Chrome 90 sends no cipher suites with 3DES.

This might be why Chrome measures 0.00% use of TLS_RSA_WITH_3DES_EDE_CBC_SHA - 
because it doesn’t advertise that it supports it.  It seems to me that you’ve 
already removed support for 3DES in Chrome.  What was the measured use of 3DES 
cipher suites in the release before you removed support?  We have measured 
slightly above 0.00% use in a browser that does send 3DES cipher suites in its 
client hellos.

If you haven’t already removed support, how would one use it?  I’ll admit I 
haven’t gone through all the possibilities of renegotiation that TLS has.

> On Apr 28, 2021, at 8:21 AM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Your measurement of 0.00% use in Chrome is exciting.
> 
> Making this change would almost certainly not be a change in WebKit but I’ve 
> reached out to the people who manage our crypto code.
> 
>> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>>  wrote:
>> 
>> 
>> Looks like this change is clearly safe.
>> 
>> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
>> they're controlled by the operating system's TLS backend and crypto policy. 
>> 3DES has been disabled for a while now on modern systems, and users have not 
>> reported any compat issues, which is not surprising given your finding of 
>> 0.00%.
>> 
>> Michael
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: Removing 3DES from TLS

2021-04-28 Thread Alex Christensen via webkit-dev
Your measurement of 0.00% use in Chrome is exciting.

Making this change would almost certainly not be a change in WebKit but I’ve 
reached out to the people who manage our crypto code.

> On Apr 28, 2021, at 7:14 AM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> 
> Looks like this change is clearly safe.
> 
> I doubt Safari controls its own TLS ciphersuite settings. In WebKitGTK, 
> they're controlled by the operating system's TLS backend and crypto policy. 
> 3DES has been disabled for a while now on modern systems, and users have not 
> reported any compat issues, which is not surprising given your finding of 
> 0.00%.
> 
> Michael
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

2021-04-06 Thread Alex Christensen via webkit-dev
I’m also wondering why 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits
 says it should only retry GET requests.  Is that just to avoid re-uploading 
large POST requests?  

> On Apr 6, 2021, at 10:02 AM, David Benjamin  wrote:
> 
> Hi Alex, thanks for the comments! Responses inline.
> 
> On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen  <mailto:achristen...@apple.com>> wrote:
> I’m glad to see ALPS and bytes sent over the network used instead of 
> additional reliance on state on the client.  We don’t want to introduce a 
> super cookie on the client, and we want to minimize breakage when a user 
> agent decides to remove state to prevent tracking.
> 
> Well, with regards to cross-site tracking, I'll note that Accept-CH cache is 
> already naturally partitioned because it only applies to top-level loads. 
> Subresources follow a delegation model. But, yeah, one of the nice outcomes 
> of Client Hint Reliability is it makes the Accept-CH cache actually a cache, 
> so the UA can scope or clear it with less worry. I think reducing the 
> performance and functionality gap between new and returning clients is 
> generally valuable for this sort of thing. I hope Client Hint Reliability is 
> useful in this regard.
> 
> I can’t say I’ve followed this development closely or even thought through it 
> all completely, but here are some initial thoughts:
> 
> My first thought is that it seems excessive to have a way to specify support 
> of client hints both in the TLS handshake and in HTTP/{2,3} frames.  I guess 
> that’s why you wrote 
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
>  
> <https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms>
> 
> I think you may have misunderstood the reference to two mechanisms. The TLS 
> ALPS extension and h2/h3 frames are part of the same mechanism. It's a 
> layering thing. TLS provides a generic spot to stick protocol-specific 
> settings early enough in the handshake, and then HTTP/{2,3} define how to use 
> it. (We don't want every new feature like this to require an update to the 
> TLS server.)
> 
> Rather, the reference is to (1) Critical-CH HTTP response header and (2) TLS 
> ALPS + h2/h3 frames. I'd love to avoid the redundancy, but I think this is 
> the best option given all the design constraints. And yeah the explainer 
> discusses why.
>  
> I don’t think that requiring a site to be running software that supports 
> client hints is a good prerequisite to using client hints, so I don’t think 
> that’s a good reason to have two mechanisms.
> 
> I'm not sure I'm parsing this sentence right. It sounds like you both don't 
> think server software changes are a good requisite, but also don't think it's 
> good to have a mechanism with lower server software requirements?
Oops!  Remove the first “don’t” in my sentence.
>  
> Sites can change with open connections, but if a site changes its client 
> hints acceptance, wouldn’t that be a good reason to terminate all the open 
> connections and require renegotiation?
> 
> Sites don't really work that way architecturally. You may have, for instance, 
> a CDN frontend handling TLS and H2/H3, but it contacts the origin server that 
> developers actually upload content to. In such deployments, there usually 
> isn't a way to signal an update to all connections like that. Moreover, 
> there's a race condition here. The client may request the resource at the 
> same time as the server signaling the new preferences.
>  
> Wildcard subdomains in the certificate is an interesting problem.
> 
> I'll add that cross-name pooling further complicates any hope of signaling 
> existing connections above.
>  
> If it is decided that multiple mechanisms are necessary, their interaction 
> should be well defined.  What if the server said one thing in ALPS but said 
> something different in an HTTP/{2,3} frame?  What if I have multiple 
> connections open to the same server and get different client hint headers?
> 
> Agreed it should be well-defined. I touched on this briefly in 
> draft-davidben-http-client-hint-reliability-02, but not in full detail. The 
> IETF and W3C/WHATWG split is a bit fun at the boundaries of the web platform 
> and network protocols. :-) I think we'll probably put the full Fetch 
> integration in https://github.com/WICG/client-hints-infrastructure 
> <https://github.com/WICG/client-hints-infrastructure>, alongside the other 
> Client Hints bits.
> 
> The interaction we think works best is that ALPS/frames and 
> Accept-CH/Critical-CH are conceptually two separate sources of hint requests, 
> with the expectation that the 

Re: [webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

2021-04-05 Thread Alex Christensen via webkit-dev
I’m glad to see ALPS and bytes sent over the network used instead of additional 
reliance on state on the client.  We don’t want to introduce a super cookie on 
the client, and we want to minimize breakage when a user agent decides to 
remove state to prevent tracking.

I can’t say I’ve followed this development closely or even thought through it 
all completely, but here are some initial thoughts:

My first thought is that it seems excessive to have a way to specify support of 
client hints both in the TLS handshake and in HTTP/{2,3} frames.  I guess 
that’s why you wrote 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
I don’t think that requiring a site to be running software that supports client 
hints is a good prerequisite to using client hints, so I don’t think that’s a 
good reason to have two mechanisms.
Sites can change with open connections, but if a site changes its client hints 
acceptance, wouldn’t that be a good reason to terminate all the open 
connections and require renegotiation?
Wildcard subdomains in the certificate is an interesting problem.

If it is decided that multiple mechanisms are necessary, their interaction 
should be well defined.  What if the server said one thing in ALPS but said 
something different in an HTTP/{2,3} frame?  What if I have multiple 
connections open to the same server and get different client hint headers?

In 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits
 you specify that a client should not retry more than once per request to avoid 
infinite loops, but in 
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#server-triggered-retry
 you use the possibility of infinite loops as a reason that a server-triggered 
retry isn’t a good solution.  I think a server-triggered retry is a good 
solution and we should be able to expect that if someone wants their website to 
work, then they will do what it takes to make their servers work correctly.  
Don’t we have the possibility of infinite redirects today?

> On Apr 5, 2021, at 4:32 PM, Mike Taylor via webkit-dev 
>  wrote:
> 
> Hi there,
> 
> Complimentary to 
> https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html, 
> Chromium intends to ship the ALPS + ACCEPT_CH HTTP/2 and HTTP/3 frames 
> portions of the Client Hints reliability proposal, and we would like to 
> solicit WebKit's position.
> 
> As mentioned in the linked thread, the Client Hint Reliability proposal is a 
> set of features aimed at making Client Hints more reliably available and 
> mitigating mis-matches between a site's preferences and the preferences 
> stored in the browser.
> 
> In particular, The ACCEPT_CH HTTP/2 and HTTP/3 frames, combined with the TLS 
> ALPS extension, are a connection-level optimization to deliver the server’s 
> Client Hint preferences in time for the first HTTP request.
> 
> Specifications:
> 
> https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability 
> (section 4)
> https://tools.ietf.org/html/draft-vvv-httpbis-alps
> https://tools.ietf.org/html/draft-vvv-tls-alps
> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#connection-level-settings
> 
> thanks,
> Mike
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] User Agent Client Hints

2020-11-11 Thread Alex Christensen
If I understand this correctly, the state of having received an Accept-CH 
header field in a response to a previous request is used to determine whether 
these new Sec-CH-* header fields will be sent.  Not only does this add a new 
place to store bits on the client (as acknowledged by 
https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition 

 ) but it also seems to not provide a method for a server to receive client 
hint header fields on the first request from a client.  Would both of these 
concerns be resolved if we used something like ALPN instead of needing to store 
state on the client?  Am I understanding the Client Hints Infrastructure 
correctly?

> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Nov 2, 2020, at 8:56 AM, Yoav Weiss mailto:y...@yoav.ws>> 
>> wrote:
>> 
>> Thanks for re-reviewing, Maciej!
>> 
>> Adding Mike Taylor, who's likely to take a closer look at this.
>> 
>> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak > > wrote:
>> 
>> I just did a fresh review of that spec and explainer. Thanks for addressing 
>> many of the previous issues. This addresses many of the potential objections.
>> 
>> Here’s the new issues I filed:
>> 
>> https://github.com/WICG/ua-client-hints/issues/141 
>> 
>> https://github.com/WICG/ua-client-hints/issues/142 
>> 
>> https://github.com/WICG/ua-client-hints/issues/143 
>> 
>> https://github.com/WICG/ua-client-hints/issues/144 
>> 
>> https://github.com/WICG/ua-client-hints/issues/145 
>> 
>> https://github.com/WICG/ua-client-hints/issues/146 
>> 
>> https://github.com/WICG/ua-client-hints/issues/147 
>> 
>> https://github.com/WICG/ua-client-hints/issues/148 
>> 
>> https://github.com/WICG/ua-client-hints/issues/149 
>> 
>> https://github.com/WICG/ua-client-hints/issues/150 
>> 
>> https://github.com/WICG/ua-client-hints/issues/151 
>> 
>> 
>> 
>> Thanks for filing those! We'll take a look and respond shortly.
>>  
>> Most of these are minor/editorial, but I think 151 is potentially a 
>> deal-breaker. I may be misreading the spec, but as written 
>> getHighEntropyValues seems to give access to all of the high entropy client 
>> hints to third-party scripts in the first party context, and scripts running 
>> in third-party iframes, regardless of which ones the site has opted into via 
>> the relevant HTTP header. 
>> 
>> That's indeed the case, as we didn't consider the Client Hints opt-in to be 
>> something that impacts the availability of the JS API. (as it doesn't do 
>> that for other hints)
> 
> We’re currently deeply skeptical of implementing any of the other client 
> hints due to their expansion of fingerprinting surface, so I don’t feel 
> particularly compelled by that precedent. That said, it’s likely the other 
> client hints have this same problem, where they expose fingerprinting surface 
> way more widely than they may be intending to.
> 
>> That would be a huge problem, as it would grant a lot of active 
>> fingerprinting surface unnecessarily 
>> 
>> We did discuss 
>>  
>> adding a Feature Policy (now Permission Policy) to that effect. Would that 
>> help with your concerns?
> 
> My understanding is that feature policy applies at the frame level, and 
> therefore could not be used to control what happens when a third-party script 
> in a first party context calls the API. Even for third-party iframes, it 
> seems like Feature Policy could only default-deny this JS API entirely, and 
> would not be able to filter the results down to the set delegated via HTTP 
> headers (or otherwise). Maybe you intend a feature policy per individual high 
> entropy hint, but first of all that seems like overkill, and second, the spec 
> is clearly not written to support such filtering.
> 
> So no, it would not address the concerns.
> 
> I think the best approach is to limit the hints to those opted into (or, in 
> case of a third-party frame, delegated). That or remove the script API 
> entirely. The origin-based delegation model that works well at the HTTP level 
> is not well aligned with the widespread practice of including third-party 
> scripts in the top frame.
> 
> The spec does not eve allow denying the request entirely as written. A 
> non-normative Note suggests 

Re: [webkit-dev] Moving things around a bit in libsoup code

2020-08-12 Thread Alex Christensen
There were also a few lines of PLATFORM(PLAYSTATION) code I wasn’t sure what to 
do with, too.

> On Aug 12, 2020, at 9:06 AM, Alex Christensen  wrote:
> 
> I’m preparing a fairly substantial change to the ownership of some important 
> objects in WebKit in https://bugs.webkit.org/show_bug.cgi?id=203547 
> <https://bugs.webkit.org/show_bug.cgi?id=203547> and it has required some 
> moving of settings from WebProcessPool to WebsiteDataStoreConfiguration.  
> I’ve done most of those, but WebProcessPool::platformInitializeNetworkProcess 
> in WebProcessPoolSoup.cpp requires some members be moved to a different 
> object.  Could someone who works on GTK/WPE do that in a separate patch and 
> I’ll rebase?  I’m planning to land my big patch in the next week or two, so I 
> thought I’d give you a heads up rather than just breaking libsoup networking.
> 
> Thanks, and happy coding!
> Alex
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Moving things around a bit in libsoup code

2020-08-12 Thread Alex Christensen
I’m preparing a fairly substantial change to the ownership of some important 
objects in WebKit in https://bugs.webkit.org/show_bug.cgi?id=203547 
 and it has required some 
moving of settings from WebProcessPool to WebsiteDataStoreConfiguration.  I’ve 
done most of those, but WebProcessPool::platformInitializeNetworkProcess in 
WebProcessPoolSoup.cpp requires some members be moved to a different object.  
Could someone who works on GTK/WPE do that in a separate patch and I’ll rebase? 
 I’m planning to land my big patch in the next week or two, so I thought I’d 
give you a heads up rather than just breaking libsoup networking.

Thanks, and happy coding!
Alex___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

2020-07-15 Thread Alex Christensen
I think it is still quite useful to fix non-unified builds.  Otherwise adding a 
file usually involves many unrelated build fixes.

> On Jul 14, 2020, at 5:25 PM, Fujii Hironori  wrote:
> 
> 
> 
> On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig  > wrote:
> While I don’t want to take away from what Darin is saying here about correct 
> usage of forward declaration and , I’d like to understand why 
> we have two different compilation models supported in WebKit. Is there a 
> reason both need to be supported? Can we remove one?
> 
> 
> I also want to know that. Does anyone still need non-unified builds?
> 
> I introduced other unnecessary header inclusion, and Darin asked me to fix it.
> https://bugs.webkit.org/show_bug.cgi?id=214204#c25
>  Reducing header 
> inclusion can easily cause build breakages for non-unified builds.
> So, I fixed non-unified build breakage in r264332 and r264333 as the 
> preparation for that.
> Non-unified builds was more broken than I expected. Does anyone still need it?
> Should we maintain non-unified builds until C++20 modules will nullify 
> unified builds?
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Switching open source Debug bots to building and testing with configuration --force-opt=O3

2020-06-18 Thread Alex Christensen
It sounds to me like Mark’s suggestion does not lose anything.  It’s just for 
JSC “Debug” which currently is not running because it’s too slow.  If he called 
it “ReleaseWithAssert” it would make it more clear what is going on and we 
would all appreciate the additional information those bots provide.

> On Jun 17, 2020, at 9:48 PM, Simon Fraser  wrote:
> 
> I also object to losing good stack traces for crashes on Debug bots.
> 
> Also, I don't think Debug bots should build something different from what I 
> build at my desk.
> 
> Simon
> 
>> On Jun 17, 2020, at 1:36 PM, Mark Lam > > wrote:
>> 
>> Hi folks,
>> 
>> We're planning to switch the JSC EWS bot and build.webkit.org 
>>  Debug build and test bots to building with the 
>> following set first:
>> ./Tools/Scripts/set-webkit-configuration --force-opt=O3
>> 
>> This means the Debug builds will be built with optimization level forced to 
>> O3.
>> 
>> Why are we doing this?
>> 1. So that the JSC EWS will start catching ASSERT failures.
>> 2. JSC stress test Debug bots have been timing out and not running tests at 
>> all.  Hopefully, this change will fix this issue.
>> 3. Tests will run to completion faster and we’ll catch regressions sooner.
>> 
>> The downside: crash stack traces will be like Release build stack traces.  
>> But I don’t think we should let this deter us.  It’s not like there’s no 
>> stack information.  And just as we do with debugging Release build test 
>> failures, we can always do a Debug build locally to do our debugging.
>> 
>> We would like to apply this change to all Debug build and test bots, not 
>> just the JSC ones.  Does anyone strongly object to this change?
>> 
>> Thanks.
>> 
>> Cheers,
>> Mark
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Position on User-Agent Client Hints

2020-05-08 Thread Alex Christensen
Last I recall talking about this, we did not oppose to client hits header 
fields in general, just some specific ones that expose information we do not 
wish to expose to reduce fingerprinting information.  For example, I think we 
do oppose adding Device-Memory because that currently cannot be queried through 
WebKit any other way, but I don’t think we oppose adding Viewport-Width which 
is trivial to query with 100% accuracy once you have JavaScript on the client.  
I think Downlink and RTT were in a grey area because they can indeed be 
measured other ways, but we don’t want to possibly increase the fingerprinting 
information by providing values that can be used for more effective client 
fingerprinting, such as if we were to send the exact same value to multiple 
servers.

I don’t think this is an official position, just what I recall from TPAC 
discussions in Lyon.

> On May 8, 2020, at 12:14 AM, Maciej Stachowiak  wrote:
> 
> Accidentally removed Yoav from Cc and I’m not sure if he is on this list.
> 
>> On May 8, 2020, at 12:04 AM, Maciej Stachowiak  wrote:
>> 
>> 
>> I would consider myself mildly positive as to the direction, but that’s my 
>> personal view for the moment, absent consultation with my colleagues. I will 
>> solicit more viewpoints.
>> 
>> I particularly appreciate the responsiveness to feedback and that Yoav in 
>> particular has been willing to iterate.
>> 
>> I think there’s a number of things in the spec that should be cleaned up 
>> before an implementation ships enabled by default, specifically around 
>> interop, privacy, and protection against UA lockouts. I know there are PRs 
>> in flight for some of these issues. I think it would be good to get more of 
>> the open issues to resolution before actually shipping this.
>> 
>> Regards,
>> Maciej
>> 
>>> On May 7, 2020, at 4:22 PM, Michael Catanzaro  wrote:
>>> 
>>> My personal $0.02: I'm mildly supportive of this spec. It's certainly an 
>>> improvement on existing HTTP user agent headers. I appreciate that you 
>>> worked to incorporate feedback into the spec and considered the concerns of 
>>> small browsers.
>>> 
>>> Is it going to solve all the problems caused by user agent headers? No. If 
>>> WebKit implements the spec, we're surely going to eventually need a quirks 
>>> list for user agent client hints to decide which websites to lie to, just 
>>> like we already have quirks for the user agent header. And as long as 
>>> Chrome sends a user agent header that includes the string "Chrome", it's 
>>> unlikely we'll be able to get rid of the existing quirks list. But I think 
>>> client hints will probably reduce the amount of websites that 
>>> *accidentally* break WebKit, by replacing wild west UA header parsing with 
>>> well-defined APIs, and adding some GREASE for good measure. The promise of 
>>> freezing Chrome's UA header sounds nice, as it makes quirks easier to 
>>> maintain. And being able to ration entropy by revealing details about the 
>>> platform on an active rather than passive basis is quite appealing.
>>> 
>>> The spec attracted some misplaced concern about negative impact to small 
>>> browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about 
>>> this spec as I was initially, especially after I was convinced that the 
>>> GREASE is never going to be enough to remove our quirks list, but it's 
>>> certainly not going to *hurt* small browsers.
>>> 
>>> This spec has received some pretty harsh criticism from the user tracking 
>>> industry (some call it the "ad industry"). Not historically a friend of 
>>> WebKit, so sounds good to me. ;)
>>> 
>>> One concern I haven't mentioned elsewhere is that frozen UA header might 
>>> encourage deeper levels of fingerprinting than are currently used, e.g. for 
>>> ad fraud prevention. caddy has started blocking WebKitGTK users based on 
>>> TLS handshake fingerprint (yes, really!) [1]. If techniques like that take 
>>> off as a result of this, that could potentially backfire on us quite badly. 
>>> But websites could choose to do such things today anyway, client hints or 
>>> no, and if so, the solution will be for us to just try even harder to look 
>>> more like Chrome.
>>> 
>>> Seems like a net positive overall. I don't work for Apple and can't say 
>>> whether it might be implemented by WebKit.
>>> 
>>> Michael
>>> 
>>> [1] 
>>> https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
>>> [2] https://mitm.watch/
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Use of [[maybe_unused]]

2020-01-14 Thread Alex Christensen
I think that would still use 1 extra byte per object, which isn’t ideal but we 
may be ok with that.

In general [[maybe_unused]] tells the compiler to stop telling us about 
potential speedups.  Usually that speedup is just a value in a register or on 
the stack, which has a relatively small cost, but sometimes it can be a large 
cost if it’s using lots of memory.  We may choose that’s ok.

> On Jan 14, 2020, at 11:55 AM, Suzuki, Basuke  wrote:
> 
>>> `sessionID` is used in RELEASE_LOG_IF_ALLOWED() and we have empty
>>> implementation of RELEASE_LOG() so that it's ended up with unused
>>> parameter warning of sessionID. We can add UNUSED_PARAM(sessionID) in
>>> this case, but [[maybe_unused]] is more correct choice to describe the code
>>> because sessionID is actually used.
>> 
>> In this case you could use RELEASE_LOG_DISABLED but I agree
>> [[maybe_unused]] would be better.  I’m ok with it as long as all the ports 
>> are
>> OK with it, including support in their oldest supported compiler.
> 
> Got it. I'll try sending to EWS to see it works for every ports. 
> 
>> I think it would be better to put #if PLATFORM(COCOA) around member
>> variables like this because I don’t think [[maybe_unused]] will remove the
>> additional byte in the structure.  Otherwise we’re just wasting memory.
> 
> Let us think about the cost to maintain platform dependent implementation of 
> this class.
> Because the member variable is assigned in constructor, we have to make 
> platform dependent
> Constructor which is usually hard to maintain and want to away from that if 
> possible.
> 
> How about this?
> 
> template  struct Unused { explicit Empty(T) { } };
> 
> #if PLATFORM(COCOA)
> bool m_isHTTPSCheckEnabled;
> #else
> [[maybe_unused]] Unused m_isHTTPSCheckEnabled;
> #endif
> 
> 
> -
> Basuke Suzuki
> SONY PlayStation

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Use of [[maybe_unused]]

2020-01-13 Thread Alex Christensen
> On Jan 13, 2020, at 4:08 PM, Suzuki, Basuke  wrote:
> 
> `sessionID` is used in RELEASE_LOG_IF_ALLOWED() and we have empty 
> implementation of RELEASE_LOG() so that it's ended up with unused parameter 
> warning of sessionID. We can add UNUSED_PARAM(sessionID) in this case, but 
> [[maybe_unused]] is more correct choice to describe the code because 
> sessionID is actually used.
In this case you could use RELEASE_LOG_DISABLED but I agree [[maybe_unused]] 
would be better.  I’m ok with it as long as all the ports are OK with it, 
including support in their oldest supported compiler.

> This member variable is only used in COCOA port. 
> (https://github.com/WebKit/webkit/blob/master/Source/WebKit/NetworkProcess/NetworkLoadChecker.cpp#L203)
> 
> We can add UNUSED_PARAM(isHTTPSUpgradeEnabled) in our platform code, but 
> adding [[maybe_unused]] in the header file is straight forward.
I think it would be better to put #if PLATFORM(COCOA) around member variables 
like this because I don’t think [[maybe_unused]] will remove the additional 
byte in the structure.  Otherwise we’re just wasting memory.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

2019-11-04 Thread Alex Christensen
When the lambda is mutable or has a trailing return type, the () is currently 
required by the C++ grammar, so we can’t say to always omit ().  We could say 
to always have it, to only have it when necessary, or have no code style 
guideline.  I think we should always have spaces before and after, though.

> On Nov 3, 2019, at 3:27 AM, Ryosuke Niwa  wrote:
> 
> 
> 
> On Sat, Nov 2, 2019 at 8:25 PM Ryosuke Niwa  > wrote:
> 
> On Sat, Nov 2, 2019 at 7:54 PM Chris Dumez  > wrote:
> 
> 
>> On Nov 2, 2019, at 7:38 PM, Ryosuke Niwa > > wrote:
>> 
>> 
>> 
>> On Sat, Nov 2, 2019 at 1:23 AM Antti Koivisto > > wrote:
>> 
>> On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa > > wrote:
>> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro > > wrote:
>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa > > wrote:
>> > Namely, some people write a lambda as:
>> > auto x = [] () { }
>> > 
>> > with a space between [] and () while others would write it as:
>> > 
>> > auto x = []() { }
>> 
>> : I omit the () when there are no parameters, as in these examples.
>> 
>> I guess that's another thing we should decide. Should we, or should we not 
>> have () when there are no arguments.
>> 
>> I think this is easily settled by voting via exiting practice. We have 1287 
>> instances of [&] { and 107 instances of [&]() { and &] () { across the whole 
>> WebKit.
>> 
>> That’s good to know. Why don’t we go with the status quo then.
>> 
>> In this case, we do put a space between ] or ) and {, right?
> 
> How is this the conclusion from Antti’s comment?
> 
> Based on the discussion so far, it thought no space had a slight lead.
> 
> I think you’re conflating this discussion with the other email thread about a 
> space between [] and ().
> 
> Here, I’m talking about placing a space after [] before { as in:
> [] { }
> 
> As opposed to:
> []{ }
> 
> We never use the latter style whether it’s other control flow statements like 
> if, while, or for, or for function definitions.
> 
> - R. Niwa
> 
> -- 
> - R. Niwa
> -- 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WinCairo EWS

2019-09-27 Thread Alex Christensen
The WinCairo EWS bot has been in pretty sad shape for a while, providing no 
useful information and lots of false negatives.  Could someone please fix it or 
remove it?  See https://ews-build.webkit.org/#/builders/12/builds/5501 
 for an example.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

2019-08-23 Thread Alex Christensen
This may be a tangent, but I wouldn’t mind replacing our use of std::unique_ptr 
with a smart pointer with "const T* get() const” and “T* get()” instead of 
std::unique_ptr’s “T* get() const”.  I think that would help us write more 
const-correct code.

> On Aug 23, 2019, at 9:10 AM, Darin Adler  wrote:
> 
>> On Aug 23, 2019, at 7:26 AM, Antti Koivisto  wrote:
>> 
>> Could WTF::makeUnique simply use FastMalloc by default? We could then remove 
>> most of these messy annotations.
>> 
>> This would require replacing std::unique_ptr with a type that knows how to 
>> free the objects correctly (bring back OwnPtr!) but that doesn't seem like a 
>> big deal. It wouldn't play well with mixed use of OwnPtr and new/delete but 
>> that should be avoided in any case.
> 
> I also suggested this, and you can see Yusuke’s response here 
> .
> 
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] John Wilander is a WebKit reviewer

2019-08-16 Thread Alex Christensen
I’m pleased to announce that John Wilander is now a WebKit reviewer.

John has been working on WebKit for several years now, and has done a lot of 
work on Intelligent Tracking Prevention and other security-related features.

Please join me in congratulating him!

- Alex Christensen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Which WTF headers still should be in C++11?

2019-06-20 Thread Alex Christensen
I hope so.  Let’s give it a try.

> On Jun 19, 2019, at 7:49 PM, Tim Horton  wrote:
> 
> This was a hopefully-shortlived internal complication. I think this is 
> already fixed and we could probably revert this change. Is that right, Alex?
> 
>> On Jun 19, 2019, at 7:38 PM, Fujii Hironori > > wrote:
>> 
>> Hi,
>> 
>> wtf/CheckedArithmetic.h has been converted from C++14 to C++11.
>> 
>> Bug 195187 – Change CheckedArithmetic to not use std::enable_if_t.
>> https://bugs.webkit.org/show_bug.cgi?id=195187 
>> 
>> Which WTF headers still should be in C++11?
>> 
>> - Fujii
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] What is the status of Network Error Logging and Reporting API?

2019-06-03 Thread Alex Christensen
I think they should be "under consideration" for https://webkit.org/status/

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] IPC implementation help in haiku's webkit port

2019-05-28 Thread Alex Christensen
It sounds like your design requires work on the main thread to create a 
connection to another process which is causing a deadlock when the main thread 
is waiting for another reply.  If I were working on this I would compare with 
an existing implementation to see what process and thread each step is running 
on.

> On May 27, 2019, at 11:49 PM, Rajagopalan Gangadharan  
> wrote:
> 
> Hello Everybody,
> 
> I stumbled upon a problem in an attempt to port webkit to haiku. Before 
> everything I would like to take few moments to explain about state of the 
> port. 
> 
> 1) We have a well maintained WebKitLegacy port on haiku. 
> 2) Now in the process of porting latest webkit to haiku currently at fixing 
> IPC. We didnt want to use BSD sockets and would like to use Native messaging 
> framework [BMessage : https://www.haiku-os.org/docs/api/classBMessage.html 
>  ] because our native 
> application waits for BMessage in its main thread as a result we cant wait 
> for both sockets and BMessage on same thread. Also we would like to maintain 
> the haiku ecosystem :) .
> 
> 3) We need process id of the intended process we would like to connect to 
> send data [BMessenger: https://www.haiku-os.org/docs/api/classBMessenger.html 
>  ] So instead of 
> exchanging socket id's we would just exchange pid's
> 
> 4) We were able to successfully deliver and process the messages. Currently 
> we were able to proceed until creating a connection between network process 
> and webprocess(NetworkConnectionToWebProcess).
> 
> Now where we are stuck is that After creating a connection between network 
> process and webprocess we would have to reply back to webprocess about the 
> connection info( pid of network process in our case ). I see the reply is an 
> alias of DelayedReply(CompletionHandler) according to the 
> derived sources.
> Unfortunately the webprocess is indefinitely waiting for reply from 
> webprocessproxy for which we are unable to "reply" .
> 
> Could anyone point me where I would have went wrong or what could be done to 
> fix this and any better ways for implementing this.
> 
> Please check the source references for more info:
> NetworkProcessProxy: [ 
> https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp#L150
>  
> ]
> 
> NetworkProcess [ 
> https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/NetworkProcess/haiku/NetworkProcessHaiku.cpp#L98
>  
> 
>  ]
> 
> ConnectionHaiku : 
> [https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Source/WebKit/Platform/IPC/haiku/ConnectionHaiku.cpp
>  
> 
>  ]
> 
> Attachment : [ 
> https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Source/WebKit/Platform/IPC/haiku/AttachmentHaiku.cpp
>  
> 
>  ]
> I believe these places are currently in focus 
> For further reference please check 
> [https://github.com/RAJAGOPALAN-GANGADHARAN/webkit/tree/ipc-iteration2 
> ]
> 
> Thank you
> Regards
> G.Rajagopalan
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] C++17 is here. Should we use it?

2019-05-07 Thread Alex Christensen
If you have a minimum-requirements system that you want to keep building, put 
build infrastructure on build.webkit.org so we can see when things break.

We plan to actively push to update requirements again in 2021.

> On May 7, 2019, at 11:46 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 07.05.2019, 16:53, "Michael Catanzaro" :
>> Since there were no objections, I've updated the policy on the wiki:
>> 
>> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
> 
> Note that since we have to support libstdc++ 6.x, most of C++17 standard
> library features () should be disallowed. Those include std::filesystem, 
> std::string_view, etc. Core language features should be fine.
> -- 
> Regards,
> Konstantin
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] C++17 is here. Should we use it?

2019-04-23 Thread Alex Christensen
I’m interpreting the lack of objection to mean there is no reason not to 
proceed with https://bugs.webkit.org/show_bug.cgi?id=197131 once I get 
everything working nicely.

> On Apr 19, 2019, at 3:16 PM, Alex Christensen  wrote:
> 
> It’s always fun to reply to two year old emails.
> 
> I would like to have a plan to start using and requiring C++17 in WebKit.  
> Based on my minimal research, I believe that DebianBuster is frozen but not 
> yet released.  Is there something we are still waiting for, or could we begin 
> making the switch?
> 
>> On Aug 4, 2017, at 4:00 PM, Michael Catanzaro  wrote:
>> 
>> On Fri, Aug 4, 2017 at 3:48 PM, Yusuke SUZUKI  wrote:
>>> Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler 
>>> dependencies.
>> 
>> As a result of the C++14 discussion on this list a few months ago, we 
>> relaxed our dependencies policy [1] to allow upgrading to GCC 5 one year 
>> earlier than planned, to the displeasure of some of our distributors who now 
>> have to build a custom compiler as part of their WebKit builds. We would 
>> prefer not to relax the policy further.
>> 
>> Our current schedule looks like:
>> 
>> * GCC 6 could be required in April 2018 (next Ubuntu LTS release)
>> * GCC 7 (required for C++17) could be required likely late in 2019 (next 
>> Debian stable release)
>> 
>> Is that acceptable for Apple?
>> 
>> Michael
>> 
>> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] C++17 is here. Should we use it?

2019-04-19 Thread Alex Christensen
It’s always fun to reply to two year old emails.

I would like to have a plan to start using and requiring C++17 in WebKit.  
Based on my minimal research, I believe that DebianBuster is frozen but not yet 
released.  Is there something we are still waiting for, or could we begin 
making the switch?

> On Aug 4, 2017, at 4:00 PM, Michael Catanzaro  wrote:
> 
> On Fri, Aug 4, 2017 at 3:48 PM, Yusuke SUZUKI  wrote:
>> Possibly, mcatanzaro and clopez know much about WebKitGTK+ compiler 
>> dependencies.
> 
> As a result of the C++14 discussion on this list a few months ago, we relaxed 
> our dependencies policy [1] to allow upgrading to GCC 5 one year earlier than 
> planned, to the displeasure of some of our distributors who now have to build 
> a custom compiler as part of their WebKit builds. We would prefer not to 
> relax the policy further.
> 
> Our current schedule looks like:
> 
> * GCC 6 could be required in April 2018 (next Ubuntu LTS release)
> * GCC 7 (required for C++17) could be required likely late in 2019 (next 
> Debian stable release)
> 
> Is that acceptable for Apple?
> 
> Michael
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

2019-03-21 Thread Alex Christensen
A more specific example of why I object is that I want to do things like add a 
pointer to the thread an object was created on if ASSERT_DISABLED is false so I 
can assert if things are done on invalid threads.  If I do this in a class like 
RefCounted, this rule would make me add a guarded initializer to every 
RefCounted class. 

> On Mar 21, 2019, at 1:37 PM, Alex Christensen  wrote:
> 
> I object.  I don’t find using { *this } in a header disorienting at all.  I 
> think it’s better than adding many duplicate lines in each constructor and 
> risking forgetting one.  I think if we were to remove all the 
> m_attributeOwnerProxy initializers in WebKit it would add lots of duplication 
> with little benefit. If it were a class with a default constructor we would 
> have a high risk of forgetting a constructor somewhere.
> 
>> On Mar 20, 2019, at 9:22 AM, Simon Fraser  wrote:
>> 
>>> On Mar 14, 2019, at 1:06 PM, Filip Pizlo  wrote:
>>> 
>>> I like to draw this distinction: is the initializer a constant?
>>> 
>>> It’s not a constant if it relies on arguments to the constructor. “This” is 
>>> an argument to the constructor. 
>>> 
>>> It’s also not a constant if it involves reading the heap. 
>>> 
>>> So, like you, I would want to see this code done in the constructor. But 
>>> I’m not sure that my general rule is the same as everyone’s. 
>> 
>> This seems like a reasonable proposal to me: only use initializers when 
>> their input is constant data.
>> 
>> Any objections?
>> 
>> Simon
>> 
>>> 
>>> -Filip
>>> 
>>>> On Mar 14, 2019, at 12:59 PM, Simon Fraser  wrote:
>>>> 
>>>> I've seen some code recently that initializes non-POD members via 
>>>> initializers. For example, SVGAElement has:
>>>> 
>>>> AttributeOwnerProxy m_attributeOwnerProxy { *this };
>>>> 
>>>> I find this a little disorientating, and would normally expect to see this 
>>>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier 
>>>> to find places to set breakpoints, and the ordering of initialization is 
>>>> easier to see.
>>>> 
>>>> Are people OK with this pattern, or should we discourage it via the style 
>>>> guidelines (and style checker)?
>>>> 
>>>> Simon
>>>> 
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

2019-03-21 Thread Alex Christensen
I object.  I don’t find using { *this } in a header disorienting at all.  I 
think it’s better than adding many duplicate lines in each constructor and 
risking forgetting one.  I think if we were to remove all the 
m_attributeOwnerProxy initializers in WebKit it would add lots of duplication 
with little benefit. If it were a class with a default constructor we would 
have a high risk of forgetting a constructor somewhere.

> On Mar 20, 2019, at 9:22 AM, Simon Fraser  wrote:
> 
>> On Mar 14, 2019, at 1:06 PM, Filip Pizlo  wrote:
>> 
>> I like to draw this distinction: is the initializer a constant?
>> 
>> It’s not a constant if it relies on arguments to the constructor. “This” is 
>> an argument to the constructor. 
>> 
>> It’s also not a constant if it involves reading the heap. 
>> 
>> So, like you, I would want to see this code done in the constructor. But I’m 
>> not sure that my general rule is the same as everyone’s. 
> 
> This seems like a reasonable proposal to me: only use initializers when their 
> input is constant data.
> 
> Any objections?
> 
> Simon
> 
>> 
>> -Filip
>> 
>>> On Mar 14, 2019, at 12:59 PM, Simon Fraser  wrote:
>>> 
>>> I've seen some code recently that initializes non-POD members via 
>>> initializers. For example, SVGAElement has:
>>> 
>>>  AttributeOwnerProxy m_attributeOwnerProxy { *this };
>>> 
>>> I find this a little disorientating, and would normally expect to see this 
>>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier 
>>> to find places to set breakpoints, and the ordering of initialization is 
>>> easier to see.
>>> 
>>> Are people OK with this pattern, or should we discourage it via the style 
>>> guidelines (and style checker)?
>>> 
>>> Simon
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Encoding and decoding ProcessID

2019-02-27 Thread Alex Christensen
WKProcessID is only used in 2 functions that are only used for testing, so it’s 
probably not too important as long as your tests work.

Also, earlier you said "Our uint32_t is a signed integer.”  If that’s true, 
you’re going to have some bigger problems.

> On Feb 26, 2019, at 11:47 PM, Rajagopalan Gangadharan  
> wrote:
> 
> WTF::ProcessID and WKProcessID are supposed to be of same type right? As 
> different types create ambiguity . As sam Weining suggested we made 
> WTF::ProcessID to be int32_t but WKProcessID is pid_t so can we also 
> explicitly make WKProcessID to be int32_t (will it conform to the current 
> webkit model? )or is there any way I could fix this( any implicit casting )
>  
> Regards,
> G.Rajagopalan
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Code Style: Opinion on returning void

2019-02-20 Thread Alex Christensen
I like it mostly for its brevity, but I also think it would be strange that 
changing a return type from bool to void or vice versa would require touching 
all its call sites.

> On Feb 20, 2019, at 1:20 PM, Chris Dumez  wrote:
> 
>> 
>> On Feb 20, 2019, at 1:14 PM, Maciej Stachowiak > > wrote:
>> 
>> 
>> It seems like `return foo();` where foo() is a void function can always be 
>> replaced with `foo(); return;` for greater clarity at the cost of one extra 
>> line break. For people who prefer the one-line style, can you say why you 
>> don’t like the other way?
> 
> We do not allow more than one statement per line so it would be:
> foo();
> return;
> 
> Also, since we favor early returns in WebKit, things like:
> If (!nok)
> return completionHandler(Failed);
> 
> Would become:
> If (!nok) {
> completionHandler(Failed);
> return;
> }
> 
> It is not a big deal but I personally prefer the most concise version. 
> Especially, it is not uncommon to have multiple early returns.
> I think more concise is better and I personally do not see a readability 
> issue here. It does not really matter what the completion handler is 
> returning.
> 
>> 
>>  - Maciej
>> 
>>> On Feb 20, 2019, at 10:33 AM, Simon Fraser >> > wrote:
>>> 
>>> I find it mind bending. It makes me wonder if the author made a coding 
>>> error.
>>> 
>>> Simon
>>> 
 On Feb 20, 2019, at 7:48 AM, Daniel Bates >>> > wrote:
 
 Thanks for the opinion!
 
 Dan
 
 On Feb 20, 2019, at 7:26 AM, Saam Barati >>> > wrote:
 
> I prefer it as well.
> 
> - Saam
> 
> On Feb 20, 2019, at 6:58 AM, Chris Dumez  > wrote:
> 
>> I also prefer allowed returning void. 
>> 
>> Chris Dumez
>> 
>> On Feb 19, 2019, at 10:35 PM, Daniel Bates > > wrote:
>> 
>>> 
>>> 
>>> On Feb 19, 2019, at 9:42 PM, Ryosuke Niwa >> > wrote:
>>> 
 On Tue, Feb 19, 2019 at 8:59 PM Daniel Bates >>> > wrote:
 > On Feb 7, 2019, at 12:47 PM, Daniel Bates >>> > > wrote:
 >
 > Hi all,
 >
 > Something bothers me about code like:
 >
 > void f();
 > void g()
 > {
 > if (...)
 > return f();
 > return f();
 > }
 >
 > I prefer:
 >
 > void g()
 > {
 > if (...) {
 > f();
 > return
 > }
 > f();
 > }
 >
 Based on the responses it seems there is sufficient leaning to codify
 the latter style.
 
 I don't think there is a sufficient consensus as far as I can tell. 
 Geoff 
>>> 
>>> I didn't get this from Geoff's remark. Geoff wrote:
>>> 
>>> ***“return f()” when f returns void is a bit mind bending.***
>>> Don't want to put words in Geoff's mouth. So, Geoff can you please 
>>> confirm: for the former style, for the latter style, no strong opinion.
>>> 
 and Alex both expressed preferences for being able to return void,
>>> 
>>> I got this from Alex's message
>>> 
 and Saam pointed out that there is a lot of existing code which does 
 this. 
>>> 
>>> I did not get this. He wrote emphasis mine:
>>> 
>>> I've definitely done this in JSC. ***I don't think it's super 
>>> common***, but I've also seen code in JSC not written by me that also 
>>> does this.
>>> 
 Zalan also said he does this in his layout code.
>>> 
>>> I did not get this, quoting, emphasis mine:
>>> 
>>> I use this idiom too in the layout code. I guess I just prefer a more
>>> compact code.
>>> ***(I don't feel too strongly about it though)***
>>> 
>>> By the way, you even acknowledged that "WebKit ... tend[s] to have a 
>>> separate return.". So, I inferred you were okay with it. But from this 
>>> email I am no longer sure what your position is. Please state it 
>>> clearly.
>>> 
 - R. Niwa
 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
 ___
 webkit-dev mailing list
 

Re: [webkit-dev] Code Style: Opinion on returning void

2019-02-07 Thread Alex Christensen
If you search for “return completionHandler” in WebKit you will find over a 
hundred instances.  Most if not all of them return void.  It means call the 
completion handler and return.  I probably wrote most of them and obviously 
think it’s a fabulous idiom.

> On Feb 7, 2019, at 2:32 PM, Geoffrey Garen  wrote:
> 
> FWIW, I’ve always felt conflicted about this case.
> 
> I very much prefer early return to if/else chains.
> 
> However, “return f()” when f returns void is a bit mind bending.
> 
> So, I can’t use my preferred style in functions that return void. Boo. 
> 
> Geoff
> 
>> On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
>> 
>> Hi all,
>> 
>> Something bothers me about code like:
>> 
>> void f();
>> void g()
>> {
>>if (...)
>>return f();
>>return f();
>> }
>> 
>> I prefer:
>> 
>> void g()
>> {
>>if (...) {
>>f();
>>return
>>}
>>f();
>> }
>> 
>> Does it bother you? For the former? For the latter? Update our style guide?
>> 
>> Opinions, please.
>> 
>> Dan
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] libsoup and libcurl networking implementations

2019-01-18 Thread Alex Christensen
TL; DR could someone get my patch from 
https://bugs.webkit.org/show_bug.cgi?id=193580 working on Linux and Windows?

As part of the quest to reduce process-global state especially in the 
NetworkProcess, I’m moving NetworkStorageSession ownership from a static map to 
a member variable of the NetworkProcess object.  To accomplish this I 
eliminated all calls to NetworkStorageSession::storageSession and 
NetworkStorageSession::defaultStorageSession in WebCore, replacing them by a 
client call to get a NetworkStorageSession from the WebKit/WebKitLegacy layer 
in https://trac.webkit.org/r240117 but I did not remove all such calls from the 
libsoup and libcurl networking implementations.  The call to 
NetworkStorageSession::defaultStorageSession CurlResourceHandleDelegate.cpp and 
ResourceHandleCurl.cpp shouldn't be too hard to remove by asking the 
NetworkingContext for the storage instead of calling the static functions, but 
the calls in DNSResolveQueueSoup.cpp are a little bit trickier.  On Cocoa 
platforms, DNS lookup relies on state that is more global than a 
NetworkSession.  On Linux right now, it seems to use state on the default 
NetworkStorageSession, which is effectively global right now.  I think the best 
solution that maintains the status quo right now would be to keep the default 
NetworkStorageSession global in WebKit2 right now, but that requires a little 
bit more work than I can do blindly and iteratively with EWS.  I’d appreciate 
someone with a Linux development machine getting it working.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] AppleWin/WinCairo Resources

2019-01-15 Thread Alex Christensen
I don’t think there’s a fundamental reason why the resources and code can’t be 
moved.  Just make sure everything still works

> On Jan 7, 2019, at 10:45 AM, stephan.sz...@sony.com wrote:
> 
> Hi,
>  
> While working with (non-legacy) WebKit for WinCairo, we realized that we need 
> to support loading the missingImage and similar resources.
>  
> On https://bugs.webkit.org/show_bug.cgi?id=188175#c6 
> , Fujii-san mentioned that 
> it’d probably be the time to fix the fixme at
> https://github.com/WebKit/webkit/blob/c4b88ee56e4f77201ffdcaf6a5988cbc43e199f3/Source/WebKitLegacy/win/WebKitDLL.cpp#L171
>  
> 
> for loadResourceIntoBuffer.  Is there any reason that sharing the loading 
> code, the actual resource files, rc file or resource.h would be a problem 
> (especially for AppleWin)? And, if we want to share them, are there 
> suggestions about where to move those files? Could we move it down to WebCore 
> to be shared?
>  
> Thanks,
> Stephan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Reducing globals

2018-12-20 Thread Alex Christensen
It’s been three weeks.  Is anyone maintaining the soup or curl loading code?

> On Dec 3, 2018, at 1:03 PM, Alex Christensen  wrote:
> 
> 
> 
>> On Dec 3, 2018, at 12:55 PM, basuke.suz...@sony.com wrote:
>> 
>> Alex,
>> 
>> Got it. Curl port will catch up this move soon.
> Great!  Thanks!
>> 
>> I just want to confirm my understanding about Network Session. It is pretty 
>> similar concept with Cocoa's URLSession, isn't it?
> It tries.
>> 
>> Curl Port uses default NetworkSession at everywhere so that it is almost 
>> same with global NetworkProcess. We need to move forward to support 
>> NetworkSession correctly.
>> 
>> -
>> Basuke Suzuki
>> SONY PlayStation
>> 
>> 
>>> -Original Message-
>>> From: webkit-dev  On Behalf Of Alex
>>> Christensen
>>> Sent: Thursday, November 29, 2018 6:15 PM
>>> To: Webkit Development List 
>>> Subject: [webkit-dev] Reducing globals
>>> 
>>> I am embarking on a journey to reduce the number of global variables and
>>> singletons we use instead member variables on the proper objects.  Feel 
>>> free to
>>> join!
>>> 
>>> Specifically, I’m looking into reducing the number of members in the
>>> NetworkProcessCreationParameters structure.  Many of them need to go to
>>> NetworkSessionCreationParameters instead.  Could those maintaining the
>>> libsoup and libcurl networking implementations please lend a hand and move 
>>> the
>>> members enclosed in USE(SOUP) or USE(CURL)?  I have done similar moves in
>>> https://trac.webkit.org/changeset/238654/webkit and
>>> https://trac.webkit.org/changeset/238630/webkit if you would like a pattern 
>>> to
>>> follow.
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Alex Christensen
We can definitely make our own WTF::Optional instead of using std::optional and 
change its move constructor/operator= and I personally think that would not be 
worth it but if I’m in the minority I’ll deal with it.  We cannot diverge from 
the C++ standards that say that moving from an object leaves the object in an 
undefined state, and right now in WebKit we are relying quite a lot on that 
undefined state.  I think that is the bigger problem that Chris was trying to 
solve.

> On Dec 17, 2018, at 4:32 PM, Ryosuke Niwa  wrote:
> 
> Let me add this.
> 
> The situation we have here is analogous to having a member function "move()" 
> which leave std::optional in undefined state as in:
> 
> std::optional a;
> std::optional b = a.move();
> 
> would leave a in some undefined state. I don't care what C++ standards say or 
> what STL does. That's insane.
> Every object should remain in a well defined state after performing an 
> operation.
> 
> - R. Niwa
> 
> 
> On Mon, Dec 17, 2018 at 4:22 PM Ryosuke Niwa  <mailto:rn...@webkit.org>> wrote:
> It's true that WTFMove or std::move doesn't do anything if the moved variable 
> is not used because WTFMove / std::move is just a type cast.
> 
> However, that behavior is orthogonal from the issue that calling WTFMove / 
> std::move on std::optional, and the returned value is assigned to another 
> std::optional, the original std::optional will be left a bad state.
> 
> I completely disagree with your assessment that this calls for the use of 
> std::exchange.
> 
> 
> On Mon, Dec 17, 2018 at 3:55 PM Alex Christensen  <mailto:achristen...@apple.com>> wrote:
> Let me give a concrete example on why, even with our nice-to-use WTF types, 
> the state of a C++ object is undefined after being moved from:
> 
> #include 
> #include 
> #include 
> 
> class Test : public RefCounted { };
> 
> void useParameter(RefPtr&& param)
> {
>   RefPtr usedParam = WTFMove(param);
> }
> 
> void dontUseParameter(RefPtr&&) { }
> 
> int main() {
>   RefPtr a = adoptRef(new Test);
>   RefPtr b = adoptRef(new Test);
>   std::cout << "a null? " << !a << std::endl;
>   std::cout << "b null? " << !b << std::endl;
>   useParameter(WTFMove(a));
>   dontUseParameter(WTFMove(b));
>   std::cout << "a null? " << !a << std::endl;
>   std::cout << "b null? " << !b << std::endl;
>   return 0;
> }
> 
> // clang++ test.cpp -I Source/WTF -L WebKitBuild/Debug -l WTF -framework 
> Foundation -L /usr/lib -l icucore --std=c++17 && ./a.out  
>  
> // a null? 0  
>   
> // b null? 0  
>   
> // a null? 1  
>   
> // b null? 0  
>  
> 
> 
> As you can see, the internals of callee dontUseParameter (which could be in a 
> different translation unit) affects the state of the local variable b in this 
> function.  This is one of the reasons why the state of a moved-from variable 
> is intentionally undefined, and we can’t fix that by using our own 
> std::optional replacement.  If we care about the state of a moved-from 
> object, that is what std::exchange is for.  I think we should do something to 
> track and prevent the use of moved-from values instead of introducing our own 
> std::optional replacement.
> 
>> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>> 
>> Yeah, it seems like making std::optional more in line with our own 
>> convention provides more merits than downsides here. People are using 
>> WTFMove as if it's some sort of a swap operation in our codebase, and as 
>> Maciej pointed out, having rules where people have to think carefully as to 
>> when & when not to use WTFMove seems more troublesome than the proposed fix, 
>> which would mean this work for optional.
>> 
>> - R. Niwa
>> 
>> On Mon, Dec 17, 2018 at 2:24 PM Geoffrey Garen > <mailto:gga...@apple.com>> wrote:
>> I don’t understand the claim about “undefined behavior” here. As Maciej 
>> pointed out, these are our libraries. We 

Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Alex Christensen
Let me give a concrete example on why, even with our nice-to-use WTF types, the 
state of a C++ object is undefined after being moved from:

#include 
#include 
#include 

class Test : public RefCounted { };

void useParameter(RefPtr&& param)
{
  RefPtr usedParam = WTFMove(param);
}

void dontUseParameter(RefPtr&&) { }

int main() {
  RefPtr a = adoptRef(new Test);
  RefPtr b = adoptRef(new Test);
  std::cout << "a null? " << !a << std::endl;
  std::cout << "b null? " << !b << std::endl;
  useParameter(WTFMove(a));
  dontUseParameter(WTFMove(b));
  std::cout << "a null? " << !a << std::endl;
  std::cout << "b null? " << !b << std::endl;
  return 0;
}

// clang++ test.cpp -I Source/WTF -L WebKitBuild/Debug -l WTF -framework 
Foundation -L /usr/lib -l icucore --std=c++17 && ./a.out
   
// a null? 0

// b null? 0

// a null? 1

// b null? 0
   


As you can see, the internals of callee dontUseParameter (which could be in a 
different translation unit) affects the state of the local variable b in this 
function.  This is one of the reasons why the state of a moved-from variable is 
intentionally undefined, and we can’t fix that by using our own std::optional 
replacement.  If we care about the state of a moved-from object, that is what 
std::exchange is for.  I think we should do something to track and prevent the 
use of moved-from values instead of introducing our own std::optional 
replacement.

> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa  wrote:
> 
> Yeah, it seems like making std::optional more in line with our own convention 
> provides more merits than downsides here. People are using WTFMove as if it's 
> some sort of a swap operation in our codebase, and as Maciej pointed out, 
> having rules where people have to think carefully as to when & when not to 
> use WTFMove seems more troublesome than the proposed fix, which would mean 
> this work for optional.
> 
> - R. Niwa
> 
> On Mon, Dec 17, 2018 at 2:24 PM Geoffrey Garen  <mailto:gga...@apple.com>> wrote:
> I don’t understand the claim about “undefined behavior” here. As Maciej 
> pointed out, these are our libraries. We are free to define their behaviors.
> 
> In general, “undefined behavior” is an unwanted feature of programming 
> languages and libraries, which we accept begrudgingly simply because there 
> are practical limits to what we can define. This acceptance is not a mandate 
> to carry forward undefined-ness as a badge of honor. In any case where it 
> would be practical to define a behavior, that defined behavior would be 
> preferable to undefined behavior.
> 
> I agree that the behavior of move constructors in the standard library is 
> undefined. The proposal here, as I understand it, is to (a) define the 
> behaviors move constructors in WebKit and (b) avoid std::optional and use an 
> optional class with well-defined behavior instead.
> 
> Because I do not ❤️ security updates, I do ❤️ defined behavior, and so I ❤️ 
> this proposal.
> 
> Geoff
> 
>> On Dec 17, 2018, at 12:50 PM, Alex Christensen > <mailto:achristen...@apple.com>> wrote:
>> 
>> This one and the many others like it are fragile, relying on undefined 
>> behavior, and should be replaced by std::exchange.  Such a change was made 
>> in https://trac.webkit.org/changeset/198755/webkit 
>> <https://trac.webkit.org/changeset/198755/webkit> and we probably need many 
>> more like that, but we are getting away with relying on undefined behavior 
>> which works for us in most places.
>> 
>>> On Dec 17, 2018, at 11:24 AM, Chris Dumez >> <mailto:cdu...@apple.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 17, 2018, at 11:10 AM, Chris Dumez >>> <mailto:cdu...@apple.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 17, 2018, at 10:27 AM, Alex Christensen >>>> <mailto:achristen...@apple.com>> wrote:
>>>>> 
>>>>>>>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez >>>>>>>> <mailto:cdu...@app

Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Alex Christensen
This one and the many others like it are fragile, relying on undefined 
behavior, and should be replaced by std::exchange.  Such a change was made in 
https://trac.webkit.org/changeset/198755/webkit and we probably need many more 
like that, but we are getting away with relying on undefined behavior which 
works for us in most places.

> On Dec 17, 2018, at 11:24 AM, Chris Dumez  wrote:
> 
> 
> 
>> On Dec 17, 2018, at 11:10 AM, Chris Dumez > <mailto:cdu...@apple.com>> wrote:
>> 
>> 
>> 
>>> On Dec 17, 2018, at 10:27 AM, Alex Christensen >> <mailto:achristen...@apple.com>> wrote:
>>> 
>>>>>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez >>>>>> <mailto:cdu...@apple.com>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> As far as I know, our convention in WebKit so far for our types has 
>>>>>>> been that types getting moved-out are left in a valid “empty” state.
>>> This is not necessarily true.  When we move out of an object to pass into a 
>>> function parameter, for example, the state of the moved-from object depends 
>>> on the behavior of the callee.  If the callee function uses the object, we 
>>> often have behavior that leaves the object in an “empty” state of some 
>>> kind, but we are definitely relying on fragile undefined behavior when we 
>>> do so because changing the callee to not use the parameter changes the 
>>> state of the caller.  We should never assume that WTFMove or std::move 
>>> leaves the object in an empty state.  That is always a bug that needs to be 
>>> replaced by std::exchange.
>> 
>> Feel like we’re taking about different things. I am talking about move 
>> constructors (and assignment operators), which have a well defined behavior 
>> in WebKit. And it seems you are talking about WTFMove(), which despite the 
>> name does not “move” anything, it is merely a cast.
>> In the case you’re talking about the caller does NOT call the move 
>> constructor, it merely does a cast so I do not think your comment 
>> invalidates my statement. Note that in my patch, I was nearly WTFMove()ing 
>> the data member and assigning it to a local variable right away, calling the 
>> move constructor.
> 
> Also note that may of us already rely on our move constructors’ behavior, 
> just search for WTFMove(m_responseCompletionHandler) in:
> https://trac.webkit.org/changeset/236463/webkit 
> <https://trac.webkit.org/changeset/236463/webkit>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Watch out for std::optional's move constructor

2018-12-17 Thread Alex Christensen
 On Dec 14, 2018, at 1:37 PM, Chris Dumez >>> > wrote:
>>> 
 
 As far as I know, our convention in WebKit so far for our types has been 
 that types getting moved-out are left in a valid “empty” state.
This is not necessarily true.  When we move out of an object to pass into a 
function parameter, for example, the state of the moved-from object depends on 
the behavior of the callee.  If the callee function uses the object, we often 
have behavior that leaves the object in an “empty” state of some kind, but we 
are definitely relying on fragile undefined behavior when we do so because 
changing the callee to not use the parameter changes the state of the caller.  
We should never assume that WTFMove or std::move leaves the object in an empty 
state.  That is always a bug that needs to be replaced by std::exchange.

> On Dec 14, 2018, at 3:20 PM, youenn fablet  wrote:
> 
> Is it too late to ask for a std::optional change?
Yes

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebCorePrefix.h vs. config.h

2018-12-08 Thread Alex Christensen
CMake on Mac should not affect the decision here.  I added that as a hack in 
http://trac.webkit.org/r172346 as part of an experimental project that isn’t 
being used by anyone.  If we decide to resume CMake on Mac development and that 
has moved, we will find a better way to solve the same build problem.

> On Dec 8, 2018, at 3:22 PM, Darin Adler  wrote:
> 
> OK, here’s my answer after thinking on it a bit:
> 
> Best would be to eliminate “config.h”: Change “config.h” into an empty file 
> first, then remove all “config.h” includes, and then remove the file. But to 
> do that, we need to make sure every build system for WebKit supports prefix 
> headers. I don’t know how close to that we are. Maybe close? How can we 
> quickly find out?
> 
> Lacking that, I think we can and should change “config.h” so it’s just an 
> include of “WebCorePrefix.h”, or the other way around. I think it would be 
> valuable to keep the feature where we try to catch cases where we forget to 
> include “config.h”, on the platforms that use a prefix header, for the 
> benefit of the platforms that do not. That might mean small complexity 
> remains and one file won’t literally just be a trivial include of the other.
> 
> I suppose it’s also important to verify that there is no benefit to 
> precompiling less than all of what “config.h” includes.
> 
> — Darin
> 
> PS: I don’t think we know that there is only one configuration that needs 
> “config.h”. That second code snippet from your original message, Alexey, was 
> only relevant for platforms that are trying to support macOS without prefix 
> headers, and there could be any number of non-macOS cases. (And that include 
> seems like a relatively recent change done by someone who didn’t fully 
> understand the original scheme.)
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Reducing globals

2018-12-03 Thread Alex Christensen


> On Dec 3, 2018, at 12:55 PM, basuke.suz...@sony.com wrote:
> 
> Alex,
> 
> Got it. Curl port will catch up this move soon.
Great!  Thanks!
> 
> I just want to confirm my understanding about Network Session. It is pretty 
> similar concept with Cocoa's URLSession, isn't it?
It tries.
> 
> Curl Port uses default NetworkSession at everywhere so that it is almost same 
> with global NetworkProcess. We need to move forward to support NetworkSession 
> correctly.
> 
> -
> Basuke Suzuki
> SONY PlayStation
> 
> 
>> -Original Message-
>> From: webkit-dev  On Behalf Of Alex
>> Christensen
>> Sent: Thursday, November 29, 2018 6:15 PM
>> To: Webkit Development List 
>> Subject: [webkit-dev] Reducing globals
>> 
>> I am embarking on a journey to reduce the number of global variables and
>> singletons we use instead member variables on the proper objects.  Feel free 
>> to
>> join!
>> 
>> Specifically, I’m looking into reducing the number of members in the
>> NetworkProcessCreationParameters structure.  Many of them need to go to
>> NetworkSessionCreationParameters instead.  Could those maintaining the
>> libsoup and libcurl networking implementations please lend a hand and move 
>> the
>> members enclosed in USE(SOUP) or USE(CURL)?  I have done similar moves in
>> https://trac.webkit.org/changeset/238654/webkit and
>> https://trac.webkit.org/changeset/238630/webkit if you would like a pattern 
>> to
>> follow.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Reducing globals

2018-11-29 Thread Alex Christensen
I am embarking on a journey to reduce the number of global variables and 
singletons we use instead member variables on the proper objects.  Feel free to 
join!

Specifically, I’m looking into reducing the number of members in the 
NetworkProcessCreationParameters structure.  Many of them need to go to 
NetworkSessionCreationParameters instead.  Could those maintaining the libsoup 
and libcurl networking implementations please lend a hand and move the members 
enclosed in USE(SOUP) or USE(CURL)?  I have done similar moves in 
https://trac.webkit.org/changeset/238654/webkit and 
https://trac.webkit.org/changeset/238630/webkit if you would like a pattern to 
follow.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] unified sources build + forwarding headers that are copies

2017-11-14 Thread Alex Christensen
Our CMakeLists.txt have many instances of checks like “if (WIN32)” that assume 
that if you are running CMake on Windows then you are building for Windows.  If 
you can make these checks work for you without breaking the existing Windows 
builds, then we would welcome such improvements.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Move to NavigationClient

2017-10-23 Thread Alex Christensen
I’m not sure I understand your concern.  Deciding policies is definitely part 
of navigation.  Why would it be important to have the clients be separate 
objects?

> On Oct 22, 2017, at 9:22 AM, Alfonso Guerra <hupernike...@gmail.com> wrote:
> 
> 
> 
> On Oct 20, 2017 4:30 PM, "Alex Christensen" <achristen...@apple.com 
> <mailto:achristen...@apple.com>> wrote:
> Right now we have an API::LoaderClient, API::PolicyClient and an 
> API::NavigationClient.  We intend to remove the first two in the future in 
> favor of the API::NavigationClient.  
> 
> Is there a semantic model this design decision is based on?
> 
> From the current semantic and architectural perspectives, it sounds like it 
> would be a mistake. Particularly merging navigation duties with policy. Not 
> helpful to all clients.
> 
> 
> Warmest regards,
> Alfonso Guerra
> Founder/CEO
> Apokalypse Software Corp
> @Huperniketes
> (626) 667-4285

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Move to NavigationClient

2017-10-20 Thread Alex Christensen
Also, the authentication challenge API also needs redesigning.  Right now you 
get an AuthenticationChallenge from which you get an 
AuthenticationDecisionListener to respond to.  Could these become one object in 
the GTK API?  The current design is based somewhat on the 
NSURLAuthenticationChallenge.sender model, and modern WebKit is moving towards 
a completion handler model.

> On Oct 20, 2017, at 1:45 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> On Fri, Oct 20, 2017 at 3:30 PM, Alex Christensen <achristen...@apple.com> 
> wrote:
>> Right now we have an API::LoaderClient, API::PolicyClient and an 
>> API::NavigationClient. We intend to remove the first two in the future in 
>> favor of the API::NavigationClient. I have been working to add calls to the 
>> NavigationClient to make it a replacement for the LoaderClient and 
>> PolicyClient. The linux ports, however, have WebKitPolicyClient and 
>> WebKitLoaderClient. Could someone working on Linux replace these with an 
>> implementation of API::NavigationClient?
> 
> Thanks for the heads-up. We'll discuss who will do this work.
> 
> Michael
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] 'CSSPropertyNames.h': No such file or directory

2017-10-02 Thread Alex Christensen
That is supposed to be generated.  Maybe something’s failing to generate that, 
or maybe the command isn’t getting called somehow.  See 
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/CMakeLists.txt#L3819

> On Oct 2, 2017, at 7:54 AM, Patrick Wright  wrote:
> 
> Trying to build webkit for android on Windows. Does anyone know where i can 
> start to diagnose these errors?
> 
> CSSPropertyNames.h
> HTTPHeaderNames.h
> WebCoreJSBuiltinInternals.h
> 
> the above header files were never generated. I assume there is javascript 
> file that I can look at for this.
> 
> I found "WebCoreJSBuiltinInternals.cpp" but it was generated by cmake. which 
> was basically zero help. 
>  
> 
> 
> 26>C:\Users\wrigh\Videos\webkit-master\Source\WebCore/platform/animation/Animation.h(27):
>  fatal error C1083: Cannot open include file: 'CSSPropertyNames.h': No such 
> file or directory (compiling source file 
> C:\Users\wrigh\Videos\webkit-master\Source\WebKit\WebProcess\WebPage\android\WebPageAndroid.cpp)
> 
> Cannot open include file: 'HTTPHeaderNames.h': No such file or directory 
> (compiling source file 
> C:\Users\wrigh\Videos\webkit-master\Source\WebKit\UIProcess\cairo\BackingStoreCairo.cpp)
> 26>AcceleratedDrawingArea.cpp
> 
> 'WebCoreJSBuiltinInternals.h': No such file or directory (compiling source 
> file 
> C:\Users\wrigh\Videos\webkit-master\Source\WebCore\bindings\js\JSDOMIterator.cpp)
> 17>ReadableStream.cpp
> 
> Much obliged
> 
> Patrick
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running Safari on the simulator

2017-09-27 Thread Alex Christensen
When I want to use the public iOS SDK for WebKit on iOS, I refer to Dan’s blog 
post at https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ 

We have bots using this configuration and they’re working successfully at 
https://build.webkit.org/waterfall?category=iOS 

Maybe you forgot to run configure-xcode-for-ios-development

> On Sep 27, 2017, at 7:10 AM, Frédéric WANG  wrote:
> 
> Hello,
> 
> I've recently upgraded XCode and rebuilt Safari but when I try running
> Safari on the simulator, I get the following errors:
> 
> Tools/Scripts/build-safari --ios-simulator --debug
> Tools/Scripts/run-safari --ios-simulator
> Quitting and launching iOS Simulator...
> Installing
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/Applications/MobileSafari.app.
> An error was encountered processing the command
> (domain=NSPOSIXErrorDomain, code=2):
> Failed to install the requested application
> An application bundle was not found at the provided path.
> Provide a valid path to the desired application bundle.
> Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546.
> 
> I can not find any MobileSafari.app in my WebKitBuild directory nor in
> the /Applications/ directory calculated by webkitdirs.pm ; trying to
> hardcode a different path in webkitdirs.pm I instead obtain:
> 
> Quitting and launching iOS Simulator...
> Installing
> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Applications/MobileSafari.app.
> An error was encountered processing the command
> (domain=IXUserPresentableErrorDomain, code=2):
> This app was unable to be installed.
> Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546.
> 
> Did anyone experience the same issue?
> 
> -- 
> Frédéric Wang
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

2017-08-30 Thread Alex Christensen

> On Aug 29, 2017, at 5:54 PM, Sam Weinig  wrote:
> In a completely other direction, what does this mean for use of Xcode? Can we 
> still build from Xcode? Debug?
CMake can generate Xcode files, so you can still develop and debug in Xcode.

> On Aug 29, 2017, at 5:37 PM, Carlos Alberto Lopez Perez  
> wrote:
> Does this means that Apple ports are going to switch to CMake?
We have not decided anything officially yet, and if we were to decide to do 
this then it would take quite a while to make the official switch.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Server Timing API

2017-08-17 Thread Alex Christensen
I think there’s interest.  The tricky part would be getting access to the HTTP 
trailers with NSURLSession, libsoup, and if there’s interest libcurl.  I can 
help out with the NSURLSession implementation if someone else gets it working 
with libsoup.

> On Aug 16, 2017, at 7:51 AM, Vazac, Charles  wrote:
> 
> ​Hi,
> 
> I’d like to add support for Server Timing and wanted to gauge interest for 
> supporting the feature.
> 
> The Server Timing API reads response headers and appends metrics to the 
> timing entry associated with the request/response cycle (either the 
> PerformanceNavigationTiming or PerformanceResourceTiming entry). This allows 
> applications and analytics vendors to collect and report the timing 
> associated with any segment of the request/response cycle, in order to 
> optimize application delivery.
> 
> Spec: 
> http://w3c.github.io/server-timing/ 
> 
> WebKit Bugzilla:
> https://bugs.webkit.org/show_bug.cgi?id=175569 
> 
> 
> Thanks!
> Charlie
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Looking to remove cygwin dependency for javascript tests for Windows ports

2017-08-02 Thread Alex Christensen
I think eventually running all tests on Windows without Cygwin would be a step 
in the right direction.

> On Aug 2, 2017, at 9:53 AM, Szabo, Stephan (San Francisco) 
>  wrote:
> 
> Hi,
> 
> As part of Sony's work on getting the jsconly build for Windows, we're also 
> looking at the possibility of trying to remove/reduce the dependency on 
> Cygwin for the javascript tests from run-javascript-tests since the build 
> itself runs from a normal windows shell. Internally we did a very preliminary 
> POC of a version of run-jsc-stress-tests for windows which built perl scripts 
> for the test scripts rather than shell scripts and were able to get a bunch 
> of the tests running. We attached that to 
> https://bugs.webkit.org/show_bug.cgi?id=174985 . Obviously, that's not a 
> reasonable version for inclusion, but we wanted to discuss whether there was 
> support for removing the dependency before doing too much more down this path.
> 
> Our current thinking is that if we go forward with this, we'd probably step 
> it as:
> 1. Move the test script and test runner code from run-jsc-stress-tests into a 
> ruby file that is included from the main script
> 2. Make an option to allow using an alternate version of the above
> 3. Make an alternate version that didn't rely on shell
> 
> Thanks,
> Stephan
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Building WebKit for an iOS device

2017-07-12 Thread Alex Christensen
WebKit can be built and run on the iOS simulator by anyone with the public iOS 
SDK.  I use https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ 
 when I forget 
how to do this.

I guess WebKit can be built for device, but I’m pretty sure WebKit cannot be 
put as the system framework on an iOS device without Apple-internal tools.  
With a lot of work you might be able to statically link everything into a 
custom app for local debugging, but I’m pretty sure such an app would be 
rejected by the App Store based on section 2.5.6 of 
https://developer.apple.com/app-store/review/guidelines/ 


> On Jul 12, 2017, at 8:31 AM, Frédéric WANG  wrote:
> 
> Hello,
> 
> For development and testing purpose, I was wondering if there is a way
> to produce a build of WebKit/Safari-mobile and to install it on a device
> (instead of using the iOS simulator)? And is there any specific
> requirement like having an Apple developer license and a registered device?
> 
> I know that we have a builder [1] and I just noticed the "--ios-device"
> parameter for the build-webkit script but I can't find any information
> on the official documentation [2] or on the WebKit wiki. I also tried
> searching this mailing list about the topic but could not find any
> relevant thread.
> 
> Thanks,
> 
> Frédéric
> 
> [1] https://build.webkit.org/builders/Apple%20iOS%2010%20Release%20(Build)
> [2] https://webkit.org/building-webkit/
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-06-23 Thread Alex Christensen
I’ve been using MSVC 2017 on my WinCairo bot for a while now and it builds 
fine.  It would take a bit to update our internal Windows infrastructure, but 
we should do that soon.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

2017-06-13 Thread Alex Christensen
Ok, maybe we can get rid of std::function, then!  I hadn’t used BlockPtr as 
much as Chris.  I’d be opposed to adding a copy constructor to WTF::Function 
because the non-copyability of WTF::Function is why we made it, and it has 
prevented many bugs.

I’ve also seen many cases where I have a WTF::Function that I want to make sure 
is called once and only once before destruction.  I wouldn’t mind adding a 
WTF::Callback subclass that just asserts that it has been called once.  That 
would’ve prevented some bugs, too, but not every use of WTF::Function has such 
a requirement.

> On Jun 13, 2017, at 12:31 PM, Chris Dumez <cdu...@apple.com> wrote:
> 
> We already have BlockPtr for passing a Function as a lambda block.
> 
> Chris Dumez
> 
> On Jun 13, 2017, at 12:29 PM, Alex Christensen <achristen...@apple.com 
> <mailto:achristen...@apple.com>> wrote:
> 
>> std::function, c++ lambda, and objc blocks are all interchangeable.  
>> WTF::Functions cannot be used as objc blocks because the latter must be 
>> copyable.  Until that changes or we stop using objc, we cannot completely 
>> eliminate std::function from WebKit.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Should we ever use std::function instead of WTF::Function?

2017-06-13 Thread Alex Christensen
std::function, c++ lambda, and objc blocks are all interchangeable.  
WTF::Functions cannot be used as objc blocks because the latter must be 
copyable.  Until that changes or we stop using objc, we cannot completely 
eliminate std::function from WebKit.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Idiom for functions with all return values in a switch case

2017-05-09 Thread Alex Christensen
I like switch statements without defaults when possible because if someone adds 
another enum value, it causes compiler warnings/errors and forces us to update 
all necessary code.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] !!Tests for equality comparison

2017-04-28 Thread Alex Christensen
I think we should definitely keep !pointerValue instead of pointerValue == 
nullptr for brevity and it makes sense to think “there’s not a pointer” when 
there is a pointer to null.  I appreciate the reminder that pointers and 
integers are the same thing at the assembly level when I write !integerValue 
but I don’t have strong feelings about it.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compile time increase over time

2017-04-24 Thread Alex Christensen
Thanks for the data, Carlos! This is a growing problem that is hurting 
productivity.  We’ve discussed it a bit and haven’t done enough about it.  Here 
are some of the ideas I’ve heard:

1) Reduce #includes by doing more forward declaring and less inlining.  We 
would probably need link time optimization to not lose performance benefits of 
inlining functions in headers.
2) Use distributed build tools and caches to cover up the problem.  WebKit 
would still be prohibitively hard to compile for people without lots of 
expensive computers, but we could greatly improve the productivity of large 
teams.
3) Use C++ modules
4) Put more commonly included headers into precompiled headers
5) I remember somebody claiming a few years ago that replacing #include 
“Something.h” with #include “path/to/Something.h” reduced compile times because 
it required fewer include paths, but I don’t think anybody has measured the 
improvement recently.
6) Optimize the compilers we use

We should look into all of these and more.  Compiling WebKit also uses a lot of 
memory, and our binary size continues to increase.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: upstream the WPE port

2017-04-21 Thread Alex Christensen
This is exciting news, Zan!  I’m happy to see innovative new uses of WebKit.

What kind of groups hope to use this new port?  What kind of groups hope to 
maintain this new port?  Will it be beneficial to the WebKit community to have 
their cooperative work?  I see having more groups motivated to organize things 
in a supportable way as positive.

I don’t think we should just use the C API as it is.  We want to eventually 
remove it completely.  If we do upstream WPE, I propose doing something like 
one of the following:
1. We could make a new C API that more closely mirrors the Cocoa API, to which 
we only add things we have committed to support.  This should be done in 
collaboration with the existing API owners.
2. We could mark parts of the existing C API as part of the API we have 
committed to maintaining.  There is a lot of messy stuff in the existing C API 
we eventually want to remove even before we remove the whole thing (old client 
versions, testing-only functions, private functions that access things we want 
to eventually organize differently, etc.).  For example, a lot of the things in 
WKContextPrivate.h should be moved from a multi-process-global approach to a 
WKWebView/WKPage-based organization.  The basic concepts are here to stay, 
though.
3. Have third parties who use the API just deal with whatever changes we throw 
at them.  This could be viable if there were only a few small groups using the 
API, but it would hinder innovative use of the API.  We might want to reserve 
the right to make API breaking changes anyway, though.

> On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote:
> 
> Hi,
> 
> the WebKit team at Igalia would like to propose upstreaming the WPE port
> of WebKit, taking on the duty to maintain it alongside the GTK+ port.
> 
> The WPE port started in 2014 as the 'WebKit for Wayland' project inside
> Igalia [1].  The port was derived from the GTK+ port, but avoided
> dependency on any GUI toolkit.  It relied on the Wayland display
> protocol for on-screen presentation.  That dependency was later dropped
> in favor of using generic interfaces to adapt to different
> platform-specific presentation systems.  This allows any vendor to
> simply provide the necessary backend implementations that are tailored
> to their platform.
> 
> The port is intended to be the Web platform engine of choice for
> embedded Linux systems.  Since late 2014 Igalia has been sponsored by
> Metrological to further develop the WPE port, targeting primarily
> various set-top box platforms.  Miguel Gomez blogged about this effort
> back in December [2].  The port can also address other embedded use
> cases, for instance in-vehicle infotainment or digital signage.
> 
> The GTK+ and WPE ports mostly have the same dependencies except for the
> GTK+ toolkit library.  That enables the two ports to already share a lot
> of code.  The biggest difference between the two is that the WPE port
> exposes the WebKit2 C API, while the GTK+ port exposes a GObject-based
> API.  Apart from that, the maintainers' plan is to further align the two
> ports as much as possible, ideally simply stacking the GTK+ port on top
> of WPE, with only a few additional tweaks for GTK+ integration.  This
> would lessen the maintenance burden for both ports and the project as a
> whole.
> 
> The WebKit team at Igalia thinks this port is on stable footing and has
> solid prospects for the future.  That's why we'd like to join the
> upstream community and continue our work there.
> 
> The patch with the port changes is in bug #171110 [3].  We have existing
> x86_64 buildbot configurations [4] that we would have to port over to
> the webkit.org build master.  We're planning further builder and tester
> configurations for ARM architectures in the future.  Layout test
> baselines would be landed separately.  (Those too would be subject to
> alignment with the GTK+ port.)
> 
> We're happy to address any questions or considerations.
> 
> Regards,
> Zan
> 
> [1]
> https://lists.webkit.org/pipermail/webkit-dev/2014-December/027087.html
> [2]
> https://blogs.igalia.com/magomez/2016/12/19/wpe-web-platform-for-embedded/
> [3] https://bugs.webkit.org/show_bug.cgi?id=171110
> [4] https://build-webkit.igalia.com/waterfall?category=WPE
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] EFL port?

2017-02-14 Thread Alex Christensen

> Konstantin Tokarev maintains a Qt port at https://github.com/annulen/webkit 
>  - sounds like you could do something like 
> that.
We have accepted the upstreaming of many patches from this repository into 
WebKit.  That reduces Konstantin’s maintenance burden and makes WebKit better 
organized without holding back our development.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CSS Parse error in element.

2017-02-03 Thread Alex Christensen
I would start looking at HTMLLinkElement::parseAttribute.
LinkHeader.cpp contains parsers for link headers, which are related.  Yoav 
knows more about those.  Those parsers ought to be united more.

> On Feb 3, 2017, at 1:17 AM, Atul Sowani  wrote:
> 
> At present I am focusing on CSSParser::findURI() particularly and 
> CSSParser::realLex() other related functionality in CSSParser.cpp - hope I am 
> on right track. ;-)
> 
> Please let me know if I should be looking at some other functionality as well 
> to resolve this issue.
> 
> Thanks!
> Atul.
> 
> On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani  > wrote:
> Hi,
> 
> I came across an issue in qtwebkit CSS parser while working on a PhantomJS 
> crash. The issue seems to be with parsing of  type 
> elements in an HTML page. What I observed is that the parser is trying to 
> interpret the value for href given inside double-quotes. The value contains a 
> "-" (e.g. "http://some.domain.com/some-page-etc-etc 
> "). The "-" sign is being 
> interpreted as minus and then things go wrong. In another case I found that 
> "\g" embedded in the value (e.g. 
> "http://some.domain.com/some-page/global/something 
> ") is also creating 
> issues. In essence, the parser is trying to interpret the value, which I 
> believe, it should not.
> 
> I am willing to dive further into it to debug and fix the issue, but looking 
> at the complexity and size of WebCore, I think I would benefit a lot to 
> expedite a fix, if I could get some tips about which code area/functionality 
> I should specifically focus in the WebCore. Looking forward to some help in 
> this regard.
> 
> Thanks,
> Atul.
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebCore/platform standalone library

2017-01-18 Thread Alex Christensen
Windows must also stay a static library.  I can volunteer the 
currently-completely-experimental-anyways Mac CMake build to have PAL as a 
shared library.  It would be nice if people had more of a reason to keep it 
working.
> On Jan 18, 2017, at 1:23 PM, Michael Catanzaro  wrote:
> 
> On Wed, 2017-01-18 at 12:17 -0800, Myles C. Maxfield wrote:
>> Static (At least for the Xcode projects. I imagine the cmake-based
>> projects could do whatever they want here).
> 
> For GTK+ we really want static as well, we do not want a new shared
> library. So no difference here.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebCore/platform standalone library

2017-01-12 Thread Alex Christensen
If PAL were a shared library in a CMake build, then it wouldn’t build 
successfully if there were layering violations.  I think we should do something 
like that to enforce good design, even if the Mac Xcode projects treat it as a 
static library or even just a part of WebCore.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [webkit-reviewers] usage of auto

2017-01-10 Thread Alex Christensen

>> I’d love to see examples where using auto substantially hurts readability so 
>> we could debate them.
I once saw a RefPtr changed to auto in some generated code where it 
was unclear what the return type was.  For at least one generated instance the 
return type was Something* that needed a reference kept alive by the caller, so 
this change caused a subtle use-after-free bug.  See 
https://trac.webkit.org/changeset/201345 


Also when we change what a return type is but there are call sites that use 
auto, we may miss checking to see if everything is ok at a call site that 
compiles successfully even though it has different meaning.

I’ll admit auto has grown on me quite a bit since I wrote 
https://lists.webkit.org/pipermail/webkit-dev/2014-January/026000.html 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-01-09 Thread Alex Christensen

> On Jan 9, 2017, at 7:39 AM, Carlos Alberto Lopez Perez  
> wrote:
> 
> On 09/01/17 01:09, Michael Catanzaro wrote:
>> On Sun, 2017-01-08 at 18:59 +0100, z...@falconsigh.net wrote:
>>> For the record, GCC 5 has complete C++14 support. The current
>>> requirement is 4.9, so the bump would be minimal.
>>> https://gcc.gnu.org/projects/cxx-status.html#cxx14
>> We would need to redefine our dependencies policy:
>> 
>> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>> 
>> We just recently crafted that policy. I kinda like it because it
>> provides a clear formula for deciding whether a compiler is too new to
>> be required or not. It means we would support GCC 4.9 until roughly
>> next spring/summer, one year from the next Debian release. We could
>> either (a) drop Debian from the policy, which I support doing anyway
>> because it does not take our security updates, or we could (b) define
>> the policy in terms of runtime dependencies, rather than build
>> dependencies (which I think Carlos Garcia wanted to do anyway). Either
>> way makes it more likely that distributions will get cut off and choose
>> to not provide WebKit security updates. I would prefer not to do (b),
>> because in practice distributions will just not take our updates if
>> they can't use their default compiler.
>> 
> 
> I strongly oppose to do (a). Also, it is false that Debian doesn't take
> our updates. They take our updates in the backports repository for stable.
> 
> I also don't like (b).
> 
> Another idea is: (c) Drop the "one year after the release" requirement.
> Which means that we could update to minimum GCC version to 5.3 (the one
> in last Ubuntu LTS) when Debian 9 is released (which hopefully is
> expected to happen around the middle of 2017).
> 
> A date that I guess will be near enough to when VS2017 is released.
A mid-2017 upgrade would be quite reasonable.
> 
> This will mean that instead of supporting up to 3-year old dependencies
> we will only support up to 2-year old ones.
> I'm not particular enthusiast about this, but I'm ready to understand
> that supporting 3-year old dependencies is not realistic on a project
> like WebKit.
> 
>> Keep in mind that for a distro to upgrade from GCC 4.9 -> 5.0 is weeks
>> of effort unless you build GCC with the flag that turns on the old C++
>> ABI, but you have to switch to the new ABI eventually, so might as well
>> do it at the same time. I have to support WebKit for a distribution
>> that has been delaying the upgrade for this reason. GCC upgrades are
>> expensive and not fun. Even turning off the ABI switch, upgrading GCC
>> means lots of obscure C++ build failures in packages you're not
>> familiar with.
>> 
>> Michael
> 
> Another (maybe easier) way forward for building it on distros that have
> libstdc++ < 5.0 is to use clang.
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] update GCC version?

2017-01-07 Thread Alex Christensen

> On Jan 7, 2017, at 11:39 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 07.01.2017, 22:30, "Alex Christensen" <achristen...@apple.com>:
>> We are looking into using more C++14 features in WebKit, which would require 
>> increasing the minimum supported compiler versions.  For example, Yusuke’s 
>> patch in https://bugs.webkit.org/show_bug.cgi?id=165093 compiles 
>> successfully in clang and I verified it compiles successfully in VS2017RC, 
>> but it does not compile successfully in the minimum supported GCC version on 
>> linux because of lack of support for C++14 extended constexpr (see 
>> https://isocpp.org/wiki/faq/cpp14-language#extended-constexpr )
>> 
>> We are not ready to require VS2017 just yet.  It hasn’t even been fully 
>> released.  But there are many C++14 features that are not supported in 
>> VS2015 (see https://msdn.microsoft.com/en-us/library/hh567368.aspx and 
>> https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes ) and 
>> we would like to use these features in WebKit.
> 
> But how are you going to use these features before requiring VS2017?
We would not be able to.  This is a question about updating the GCC version 
after we require VS2017 which will probably be in the coming months.
> 
>> 
>> Would the linux community be able to increase the minimum supported GCC 
>> version?
>> ,
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> -- 
> Regards,
> Konstantin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] update GCC version?

2017-01-07 Thread Alex Christensen
We are looking into using more C++14 features in WebKit, which would require 
increasing the minimum supported compiler versions.  For example, Yusuke’s 
patch in https://bugs.webkit.org/show_bug.cgi?id=165093 
 compiles successfully in clang 
and I verified it compiles successfully in VS2017RC, but it does not compile 
successfully in the minimum supported GCC version on linux because of lack of 
support for C++14 extended constexpr (see 
https://isocpp.org/wiki/faq/cpp14-language#extended-constexpr 
 )

We are not ready to require VS2017 just yet.  It hasn’t even been fully 
released.  But there are many C++14 features that are not supported in VS2015 
(see https://msdn.microsoft.com/en-us/library/hh567368.aspx 
 and 
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes 
 ) and we 
would like to use these features in WebKit.

Would the linux community be able to increase the minimum supported GCC version?___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WebKit build failed

2016-12-12 Thread Alex Christensen

> On Dec 12, 2016, at 4:30 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 12.12.2016, 12:25, "Plamen Dimitrov" :
>> Hi all, I am trying to build webkit wincairo 1) I've done 2, 3, 4, 5, 6, 7, 
>> 8, 9,10 and 13 from this list: 
>> https://webkit.org/webkit-on-windows/#installing-developer-tools 2) I've 
>> installed Ruby 2.0.0-p648 and DevKit-mingw64 from here: 
>> http://rubyinstaller.org/downloads/ 3) I've run "update-webkit"; 
>> "update-webkit --wincairo"; "update-webkit-wincairo-libs" from VS2015 native 
>> tool command prompt. And when I've run "build-webkit --wincairo --release" 
>> the build has failed with "C:\Program Files (x86)\Microsoft Visual Studio 
>> 14.0\VC\INCLUDE\type_traits(1469): error C2672: 'std::invoke': no matching 
>> overloaded function found" and "C:\Program Files (x86)\Microsoft Visual 
>> Studio 14.0\VC\INCLUDE\type_traits(1469): error C2893: Failed to specialize 
>> function template 'unknown-type std::invoke(_Callable &&,_Types &&...)'" 
>> Have you ever seen it before? Thank you in advance, Plamen.
I’ve never seen that build error before.  It’s possible there’s something wrong 
with your build configuration.  I would need more context than just this error 
message.  What file was being compiled when this error message was generated?  
Exactly what version of Visual Studio are you using?  Does your computer have 
other compilers installed that it might be using accidentally?  It is possible 
that the build was broken at the revision you tried, but I don’t think that is 
likely in this case.
>> ,
> 
> 
> Hi,
> 
> Unfortunately, it's quite possible that WinCairo does not build on some 
> arbitrary trunk revision. If you watch waterfall [1], you can often see 
> WinCairo bot failing to compile, and right now it's apparently having more 
> serious troubles and was put offline, so nobody working on other ports can 
> check if they introduce new build breaks for WinCairo.
I take the bot down occasionally and use it to verify fixes.  There were no 
serious troubles over the weekend, I just forgot to start it up again.  It 
should be working fine now.
> 
> The best option for you to proceed is to fix compilation error your self and 
> submit patches to bugzilla following usual procedure.
> 
> [1] https://build.webkit.org/waterfall
> 
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WinCairo Maintainers

2016-09-26 Thread Alex Christensen
It is quite nice to be able to build everything completely from source in one 
place.  This allows Windows software distributors to have more control over 
PlatformToolsets to reduce the need for distributing multiple merge modules.  
Some companies also have policies that they can only distribute software that 
they built completely from source.
> On Sep 26, 2016, at 11:54 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 26.09.2016, 21:46, "Alex Christensen" <achristen...@apple.com 
> <mailto:achristen...@apple.com>>:
>> Right now https://github.com/peavo/WinCairoRequirements 
>> <https://github.com/peavo/WinCairoRequirements> is the best maintained 
>> repository containing all the requirements, even if Per isn’t maintaining it 
>> any more.  If you fork it and add fixes, then yours would become the best 
>> maintained repository of those requirements.  I think it would be great if 
>> you did this.
> 
> It may make sense to use conan.io <http://conan.io/> to fetch dependencies. 
> There are ready to use packages for ICU, libpng, libjpeg-turbo, openssl, 
> libcurl, sqlite. At least this approach allow to decentralize maintenance and 
> compilation of binaries for each individual library.
> 
>>> On Sep 26, 2016, at 11:38 AM, Olmstead, Don <don.olmst...@sony.com> wrote:
>>> 
>>> I was wondering who was in charge of WinCairo now. We at Sony have been 
>>> using WinCairo to land anything that isn’t specific to our own internal 
>>> port but we don’t have any intention to ship anything using it.
>>> 
>>> We have some outstanding patches for the GitHub requirements 
>>> repository,https://github.com/peavo/WinCairoRequirements, that perarne was 
>>> running but he informed me that he will not be maintaining it going 
>>> forward. I was thinking about making a WinCairo org on GitHub and then 
>>> pushing the contents of that repo to it but I wanted to ask beforehand.
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ,
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> -- 
> Regards,
> Konstantin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] WinCairo Maintainers

2016-09-26 Thread Alex Christensen
Right now https://github.com/peavo/WinCairoRequirements 
 is the best maintained 
repository containing all the requirements, even if Per isn’t maintaining it 
any more.  If you fork it and add fixes, then yours would become the best 
maintained repository of those requirements.  I think it would be great if you 
did this.
> On Sep 26, 2016, at 11:38 AM, Olmstead, Don  wrote:
> 
> I was wondering who was in charge of WinCairo now. We at Sony have been using 
> WinCairo to land anything that isn’t specific to our own internal port but we 
> don’t have any intention to ship anything using it.
>  
> We have some outstanding patches for the GitHub requirements 
> repository,https://github.com/peavo/WinCairoRequirements 
> , that perarne was running but 
> he informed me that he will not be maintaining it going forward. I was 
> thinking about making a WinCairo org on GitHub and then pushing the contents 
> of that repo to it but I wanted to ask beforehand.
>  
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-23 Thread Alex Christensen
Updating to CMake 3.2 would also not cause us a problem.
> On Sep 23, 2016, at 1:14 AM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 23.09.2016, 00:59, "Alex Christensen" <achristen...@apple.com 
> <mailto:achristen...@apple.com>>:
>> Requiring CMake 3.0 would not cause us a problem.
> 
> Looks like anyone is fine with updating CMake to 3.0, however Fujii Hironori 
> is asking about CMake 3.2, and AFAIU updating to 3.0 won't help for his patch.
> .
> 
>>>  On Sep 21, 2016, at 5:06 AM, Michael Catanzaro <mcatanz...@igalia.com> 
>>> wrote:
>>> 
>>>  On Wed, 2016-09-21 at 18:09 +0900, Fujii Hironori wrote:
>>>>  Ubuntu 14.04 has GCC 4.8 and build fails with a following error
>>>>  message.
>>> 
>>>  Hm that's a good point. Looks like that ship has already sailed. No, we
>>>  don't want to support GCC 4.8. Our dependency policy is only a month
>>>  old, and we just didn't notice this yet. :)
>>> 
>>>  In that case, we're fine with requiring CMake 3.0 (the version in
>>>  Debian Jessie), but I think Apple is using a lower versions than that
>>>  so we need to hear from them. Alex?
>>> 
>>>  Michael
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

2016-09-22 Thread Alex Christensen
Requiring CMake 3.0 would not cause us a problem.
> On Sep 21, 2016, at 5:06 AM, Michael Catanzaro  wrote:
> 
> On Wed, 2016-09-21 at 18:09 +0900, Fujii Hironori wrote:
>> Ubuntu 14.04 has GCC 4.8 and build fails with a following error
>> message.
> 
> Hm that's a good point. Looks like that ship has already sailed. No, we
> don't want to support GCC 4.8. Our dependency policy is only a month
> old, and we just didn't notice this yet. :)
> 
> In that case, we're fine with requiring CMake 3.0 (the version in
> Debian Jessie), but I think Apple is using a lower versions than that
> so we need to hear from them. Alex?
> 
> Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Terminology for giving up ownership: take, release, move

2016-09-06 Thread Alex Christensen
I think “take" is a fine word to indicate that you are taking a value from a 
HashSet, just like “add" indicates you are adding to the set and remove 
indicates you are “removing" from the set.  It’s true that in all these cases 
the caller is doing the thing, not the object, but it makes sense in my mind.  
An alternative would be to change set.add(value) to a static function 
HashSet::add(set, value), set.remove(value) to HashSet::remove(set, value), and 
set.take(value) to HashSet::take(set, value), etc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Is someone going to fix Windows EWS?

2016-03-30 Thread Alex Christensen
I agree that it would be better to have one approach to copying forwarding 
headers, but there is a fundamental disagreement between the needs of the 
ports.  Windows needs the entire header to be copied into the forwarding 
directory because some internal builds are built without the other directories 
existing, such as JavaScriptCore being built without WTF being right next to 
it.  This will not change.  Linux ports want everything to be fast and 
automatic, so their forwarding headers are just a small file that #includes the 
relative path to the file being included.

Yesterday was a rough day for the CMake ports because I made WebCore more than 
one static library.  I think I know what’s wrong with the headers in clean 
builds and I’ll fix it soon.
> On Mar 30, 2016, at 10:06 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 30.03.2016, 19:47, "Brent Fulgham"  >:
>> This is happening because “Font.h” is referring to 
>> “”, which doesn’t always exist on Windows at the 
>> time the file is compiled. The CoreGraphicsSPI.h file lives in 
>> “WebCore/platform/spi/cg/CoreGraphicsSPI.h”, and can be found with a normal 
>> ‘#include “CoreGraphicsSPI.h”. It’s only after a post-build step copies the 
>> file to “DerivedSources/ForwardingHeaders/WebCore/CoreGraphicsSPI.h” that 
>> the ‘#include ” form works.
>> 
>> When a non-clean build is performed, this is fine, so EWS probably works 
>> properly most of the time. But if something prompts it to clean the build 
>> output, the file doesn’t exist and the build fails, improperly blaming the 
>> current patch.
>> 
>> I’ll talk to Alex about the copy phase of these headers and see if we can 
>> get this into proper position earlier.
> 
> Actually, for now we have 3 independent mechanisms of header copying with 
> CMake build:
> 
> 1. WEBKIT_CREATE_FORWARDING_HEADERS() CMake macro
> 2. Custom pre- and post-build commands which invoke xcopy (obviously 
> Windows-only)
> 3. Script Source/WebKit2/Scripts/generate-forwarding-headers.pl which AFAIU 
> looks into source files and determines which headers do actually need to be 
> copied, than copies them.
> 
> IMO it would be better to use one approach, and it looks like that 
> generate-forwarding-headers.pl is the most powerful option.
> 
>> 
>> Thanks,
>> 
>> -Brent
>> 
>>>  On Mar 30, 2016, at 9:28 AM, Alexey Proskuryakov  
>>> wrote:
>>> 
>>>  They fail like this: 
>>> https://webkit-queues.webkit.org/queue-status/win-ews/bots/ews202https://webkit-queues.webkit.org/results/1069527
>>> 
>>>  
>>> c:\cygwin\home\buildbot\webkit\source\webcore\platform\graphics\Font.h(57): 
>>> fatal error C1083: Cannot open include file: 'WebCore/CoreGraphicsSPI.h': 
>>> No such file or directory (compiling source file 
>>> C:\cygwin\home\buildbot\WebKit\Source\WebCore\DerivedSources.cpp) 
>>> [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCoreDerivedSources.vcxproj]
>>> 
>>>  It's quite surprising that the build passes after rolling out a patch, 
>>> thus making EWS think that the patch is to blame.
>>> 
>>>  - Alexey
>>> 
  30 марта 2016 г., в 9:20, Brent Fulgham  написал(а):
 
  Aside from ews206 being offline for some reason, all bot seem to be 
 running without any errors.
 
  Can you point me at a couple of the patches you were looking at? I 
 spot-checked a couple in the Review Queue and they seemed to be failing 
 for legitimate problems with the patches.
 
  Thanks,
 
  -Brent
 
>  On Mar 30, 2016, at 9:04 AM, Brent Fulgham  wrote:
> 
>  Looking now.
> 
>  -Brent
> 
>>  On Mar 30, 2016, at 9:02 AM, Darin Adler  wrote:
>> 
>>  Every patch I look at has a red bubble for Windows on EWS. Is someone 
>> planning on fixing this?
>> 
>>  — Darin
>>  ___
>>  webkit-dev mailing list
>>  webkit-dev@lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
>  ___
>  webkit-dev mailing list
>  webkit-dev@lists.webkit.org
>  https://lists.webkit.org/mailman/listinfo/webkit-dev
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 

Re: [webkit-dev] Building Webkit on Windows

2016-02-29 Thread Alex Christensen
Rakesh, you are building the AppleWin port of WebKit, which only has 32-bit 
binaries available, but you probably want to use the WinCairo port because the 
license of WebKitSupportLibrary.zip says you’re not allowed to redistribute it. 
 To build the WinCairo port, you will need to run update-webkit --wincairo and 
build-webkit --wincairo --64-bit.

This is not the source of your build failure, though.  It looks like you have 
your gperf executable inside of C:\Program Files… somewhere, and I believe we 
have never had anyone build WebKit with a configuration like this.  I think the 
solution is to put quotes around the %s at the very end of 
Source/WebCore/platform/network/create-http-header-name-table.  There might be 
a few more places where this is needed.  Could you please file a bug a 
bugs.webkit.org with a patch if you get it working?

> On Feb 27, 2016, at 2:01 AM, Rakesh Sadhu <rakeshsa...@hotmail.com> wrote:
> 
> 
> Hi Thomas, 
> Thank for your  answer .
> However my build suddenly fails and I notice , its creating 32 bit binaries .
> I am attaching a build log file here .
> 
> regards
> RSadhu
> 
> 
> To: achristen...@apple.com
> From: thomas.brodt.li...@porabo.ch
> Date: Fri, 26 Feb 2016 09:15:06 +0100
> CC: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Building Webkit on Windows
> 
> Hi Alex
> 
> thank you for your prompt answer. That is good news because in the past I had 
> different difficulties in setting up a functional environment with several 
> trial and error steps inbetween, although I tried to exactly follow the 
> installation guide. I tend to create a virtual machine for a reliable 
> building environment, so with my next one I will try without the cygwin 
> installation. 
> 
> We use Webkit via COM interface on Windows in our application here, so I 
> build rather infrequently, and with a working build, we then can live for 
> some time. But for our use we would need 32bit dependencies, and if I 
> understood correctly, there are currently only 64bit available. That doesn't 
> matter at the moment, but when I am ready for our next build, I would ask 
> again if you don't mind.
> 
> Thanks for your help!
> 
> Thomas
> 
> Am 25.02.2016 um 19:17 schrieb Alex Christensen:
> That also applies to the WinCairo port.  I don’t think you’ll need GNU Make 
> any more now that we use CMake for Windows.  You also shouldn’t need to 
> install iTunes to build and run WinCairo.  With WinCairo, you will also need 
> the WinCairoDependencies.zip which you can get by running 
> Tools/Scripts/update-webkit-wincairo-libs.  Right now, only the 64-bit 
> dependencies are included in that zip, but let me know if you need 32-bit 
> dependencies.  They are from  
> <https://github.com/peavo/WinCairoRequirements>https://github.com/peavo/WinCairoRequirements
>  <https://github.com/peavo/WinCairoRequirements>  Then you should be able to 
> build with Tools/Scripts/build-webkit --wincairo --64-bit
> 
> We really should update the instructions on webkit.org <http://webkit.org/> 
> On Feb 25, 2016, at 12:17 AM, Thomas Brodt <thomas.brodt.li...@porabo.ch 
> <mailto:thomas.brodt.li...@porabo.ch>> wrote:
> 
> Does this also apply for the WinCairo port? Or does this port still require 
> cygwin?
> 
> Thomas
> 
> Am 24.02.2016 um 20:32 schrieb Alex Christensen:
> Those instructions are out of date.  The most up-to-date instructions about 
> building on Windows are  
> <http://trac.webkit.org/wiki/WindowsWithoutCygwin>http://trac.webkit.org/wiki/WindowsWithoutCygwin
>  <http://trac.webkit.org/wiki/WindowsWithoutCygwin>
> 
> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield <mmaxfi...@apple.com 
> <mailto:mmaxfi...@apple.com>> wrote:
> 
> What is the error you are seeing?
> 
> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu <rakeshsa...@hotmail.com 
> <mailto:rakeshsa...@hotmail.com>> wrote:
> 
> Hello ,
> I am trying to build webkit on Windows .
> I am following  steps from  
> <https://webkit.org/building-webkit-on-windows/>https://webkit.org/building-webkit-on-windows/
>  <https://webkit.org/building-webkit-on-windows/>
> However I am unable to find a way to build webkit using MSVS2015 or  Cygwin .
> Can anyone guide here please?
> regards
> RSadhu
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
&

Re: [webkit-dev] Building Webkit on Windows

2016-02-25 Thread Alex Christensen
That also applies to the WinCairo port.  I don’t think you’ll need GNU Make any 
more now that we use CMake for Windows.  You also shouldn’t need to install 
iTunes to build and run WinCairo.  With WinCairo, you will also need the 
WinCairoDependencies.zip which you can get by running 
Tools/Scripts/update-webkit-wincairo-libs.  Right now, only the 64-bit 
dependencies are included in that zip, but let me know if you need 32-bit 
dependencies.  They are from https://github.com/peavo/WinCairoRequirements 
<https://github.com/peavo/WinCairoRequirements>  Then you should be able to 
build with Tools/Scripts/build-webkit --wincairo --64-bit

We really should update the instructions on webkit.org <http://webkit.org/> 
> On Feb 25, 2016, at 12:17 AM, Thomas Brodt <thomas.brodt.li...@porabo.ch> 
> wrote:
> 
> Does this also apply for the WinCairo port? Or does this port still require 
> cygwin?
> 
> Thomas
> 
> Am 24.02.2016 um 20:32 schrieb Alex Christensen:
>> Those instructions are out of date.  The most up-to-date instructions about 
>> building on Windows are  
>> <http://trac.webkit.org/wiki/WindowsWithoutCygwin>http://trac.webkit.org/wiki/WindowsWithoutCygwin
>>  <http://trac.webkit.org/wiki/WindowsWithoutCygwin>
>> 
>>> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield <mmaxfi...@apple.com 
>>> <mailto:mmaxfi...@apple.com>> wrote:
>>> 
>>> What is the error you are seeing?
>>> 
>>> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu < 
>>> <mailto:rakeshsa...@hotmail.com>rakeshsa...@hotmail.com 
>>> <mailto:rakeshsa...@hotmail.com>> wrote:
>>> 
>>>> Hello ,
>>>> I am trying to build webkit on Windows .
>>>> I am following  steps from  
>>>> <https://webkit.org/building-webkit-on-windows/>https://webkit.org/building-webkit-on-windows/
>>>>  <https://webkit.org/building-webkit-on-windows/>
>>>> However I am unable to find a way to build webkit using MSVS2015 or  
>>>> Cygwin .
>>>> Can anyone guide here please?
>>>> regards
>>>> RSadhu
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Building Webkit on Windows

2016-02-24 Thread Alex Christensen
Those instructions are out of date.  The most up-to-date instructions about 
building on Windows are http://trac.webkit.org/wiki/WindowsWithoutCygwin

> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield  wrote:
> 
> What is the error you are seeing?
> 
> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu  > wrote:
> 
>> Hello ,
>> I am trying to build webkit on Windows .
>> I am following  steps from https://webkit.org/building-webkit-on-windows/ 
>> 
>> However I am unable to find a way to build webkit using MSVS2015 or  Cygwin .
>> Can anyone guide here please?
>> regards
>> RSadhu
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [cmake] Proposal: Move commonly used platform-dependent files in WebCore to .cmake include files.

2016-02-09 Thread Alex Christensen
Let’s go for it.  Less duplication is a good thing.  The only downside is the 
occasional “Which CMake file do I add this to?” but that should be just as 
straightforward as adding the file to multiple platform cmake files, if not 
more.
> On Feb 9, 2016, at 10:44 AM, Michael Catanzaro  wrote:
> 
> I'm curious what Martin and Alex think about this. It seems fine to me;
> the downside is there are more CMake files to maintain, the upside is
> the big ones should be slightly smaller, and we can reduce duplication
> between PlatformEFL.cmake and PlatformGTK.cmake.
> 
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Wincairo support for wss:// urls with websockets

2016-01-04 Thread Alex Christensen
Sorry for the late reply.

That repository *should* have no significant WebKit-specific changes, but it 
has some build fixes and probably some other minor changes.  I’m aware of one 
fix to pixman to support Windows XP, which is no longer supported by WebKit.  
The repository should be just copies of the upstream source with some 
modifications to the build system or a new build system to build in the same 
place as the other projects and the solution manages inter-project 
dependencies.  Things such as config.h’s and generated assembly of OpenSSL are 
checked in to the repository so it can be built with just Visual Studio 2015 
and nasm without using MinGW (although I think it could be made to use masm to 
just require Visual Studio).  Brent did most of the work in that repository and 
knows more about it.

WinCairo.sln should build everything and package it.

> On Dec 28, 2015, at 5:04 PM, Isaac Devine <is...@devinesystems.co.nz> wrote:
> 
> Hi Alex,
> 
> I'm wanting to upgrade the following:
> - curl to 7.46.0
> - openssl to  1.0.2d
> 
> The latest curl package comes with Visual studio 2015 projects, though their 
> configurations are different from the ones available in the WinCairo.sln 
> project (it has seperate configurations for openssl, wolfssl, winsppi, dll, 
> lib etc)
> Is the intention that WinCario.sln builds everything and packages it or would 
> it be acceptable to build the different projects individually? 
> 
> Thanks,
> Isaac
> 
> 
> On 29 December 2015 at 09:50, Isaac Devine <is...@devinesystems.co.nz 
> <mailto:is...@devinesystems.co.nz>> wrote:
> How are the webkit specific changes seperated from the upstream source in 
> that repository?
> 
> Is there a directory of patches somewhere?
> 
> On 29 December 2015 at 09:27, Alex Christensen <achristen...@apple.com 
> <mailto:achristen...@apple.com>> wrote:
> If you want to send a pull request for that, too, I would gladly accept it.  
> Also, the output needs to be called libicuuc and libicuin instead of icuuc 
> and icuin to match the AppleWin port, and it would be nice if it built it 
> into the same bin64, bin32, lib64, lib32, and include directories as 
> everything else.
> 
>> On Dec 28, 2015, at 12:13 PM, Isaac Devine <is...@devinesystems.co.nz 
>> <mailto:is...@devinesystems.co.nz>> wrote:
>> 
>> Thanks,
>> 
>> If you are updating to ICU 56.1, it doesn't build in visual studio 2015.
>> 
>> A patch that fixes this can be found at:
>> http://bugs.icu-project.org/trac/ticket/11822 
>> <http://bugs.icu-project.org/trac/ticket/11822>
>> 
>> 
>> On 29 December 2015 at 08:37, Alex Christensen <achristen...@apple.com 
>> <mailto:achristen...@apple.com>> wrote:
>> Send a pull request to 
>> https://github.com/achristensen07/WinCairoRequirements 
>> <https://github.com/achristensen07/WinCairoRequirements> or just send me an 
>> email with the changes you want to include.  I’m right in the middle of 
>> updating icu in that repository, so you might want to go back to 
>> a9b631e1146a696dc81b584c837ccfb7db5524b9
>> 
>> Alex
>> 
>>> On Dec 21, 2015, at 4:44 PM, Isaac Devine <is...@devinesystems.co.nz 
>>> <mailto:is...@devinesystems.co.nz>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have a patch that enables support for wss:// urls for websockets with the 
>>> wincairo port.
>>> 
>>> I haven't created a bug and attachment yet because it requires curl 7.45, 
>>> which is newer than the curl that the current wincairo build depends on. 
>>> 
>>> How do I go about proposing updates of the curl dependency?
>>> 
>>> Thanks,
>>> Isaac
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>> 
>> 
>> 
> 
> 
> 
> 
> -- 
> Isaac Devine
> Director
> Devine Systems Limited
> 
> +64 21 1700 929
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] DRT Test case video-canvas-drawing-output.html failed on Win Enviornment

2016-01-04 Thread Alex Christensen
Are you using the WinCairo port, which uses MediaFoundation for video, or the 
AppleWin port, which uses AVFoundation for video?  Linux uses GStreamer for 
video.  These are all completely different implementations of video players.  
It is quite possible there is a bug in one of them that needs to be fixed.

Is there one pixel whose value that is different, or many pixels that are 1 
unit different?  That particular test seems to have a tolerance of 2.
I think the colorspace management should be the same on all ports, but I’m not 
sure.

> On Jan 2, 2016, at 9:20 PM, ankit srivastav  wrote:
> 
> Hi All,
> 
> Working on a webkit DRT test case media/video-canvas-drawing-output.html .
> Test is getting failed on Win environment with only 1 pixel value difference.
> But is working fine on linux.
> Is this test should be added in the skipped list for windows ?
> Is their is some difference in clourspace management on win and Linux 
> environment ?
> 
> TIA.
> Ankit
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Wincairo support for wss:// urls with websockets

2015-12-28 Thread Alex Christensen
Send a pull request to https://github.com/achristensen07/WinCairoRequirements 
 or just send me an 
email with the changes you want to include.  I’m right in the middle of 
updating icu in that repository, so you might want to go back to 
a9b631e1146a696dc81b584c837ccfb7db5524b9

Alex

> On Dec 21, 2015, at 4:44 PM, Isaac Devine  wrote:
> 
> Hi all,
> 
> I have a patch that enables support for wss:// urls for websockets with the 
> wincairo port.
> 
> I haven't created a bug and attachment yet because it requires curl 7.45, 
> which is newer than the curl that the current wincairo build depends on. 
> 
> How do I go about proposing updates of the curl dependency?
> 
> Thanks,
> Isaac
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Wincairo support for wss:// urls with websockets

2015-12-28 Thread Alex Christensen
If you want to send a pull request for that, too, I would gladly accept it.  
Also, the output needs to be called libicuuc and libicuin instead of icuuc and 
icuin to match the AppleWin port, and it would be nice if it built it into the 
same bin64, bin32, lib64, lib32, and include directories as everything else.

> On Dec 28, 2015, at 12:13 PM, Isaac Devine <is...@devinesystems.co.nz> wrote:
> 
> Thanks,
> 
> If you are updating to ICU 56.1, it doesn't build in visual studio 2015.
> 
> A patch that fixes this can be found at:
> http://bugs.icu-project.org/trac/ticket/11822 
> <http://bugs.icu-project.org/trac/ticket/11822>
> 
> 
> On 29 December 2015 at 08:37, Alex Christensen <achristen...@apple.com 
> <mailto:achristen...@apple.com>> wrote:
> Send a pull request to https://github.com/achristensen07/WinCairoRequirements 
> <https://github.com/achristensen07/WinCairoRequirements> or just send me an 
> email with the changes you want to include.  I’m right in the middle of 
> updating icu in that repository, so you might want to go back to 
> a9b631e1146a696dc81b584c837ccfb7db5524b9
> 
> Alex
> 
>> On Dec 21, 2015, at 4:44 PM, Isaac Devine <is...@devinesystems.co.nz 
>> <mailto:is...@devinesystems.co.nz>> wrote:
>> 
>> Hi all,
>> 
>> I have a patch that enables support for wss:// urls for websockets with the 
>> wincairo port.
>> 
>> I haven't created a bug and attachment yet because it requires curl 7.45, 
>> which is newer than the curl that the current wincairo build depends on. 
>> 
>> How do I go about proposing updates of the curl dependency?
>> 
>> Thanks,
>> Isaac
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> 

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fetch API

2015-12-07 Thread Alex Christensen
Exciting!  Refactoring the network code is something that has been needed for a 
while.  Code can be modernized because much of it hasn’t been touched since we 
were using VS2005 and other old compilers.  Some things can maybe be removed, 
some things can be refactored, and many tests need to be added.  Sorry I don’t 
have any concrete examples, but I’m interested in assisting this work.

Alex

> On Dec 7, 2015, at 2:35 AM, youenn fablet  wrote:
> 
> Hi all,
> 
> I am interested in adding support for the fetch API 
> (https://fetch.spec.whatwg.org/#fetch-api 
> ).
> It is a more convenient way of doing programmatic network calls than XHR. It 
> also covers some more ground.
> The fetch API is currently implemented in Chromium and Firefox.
> I filed https://bugs.webkit.org/show_bug.cgi?id=151937 
>  for that purpose.
> 
> On a separate topic, I wonder whether it would be valuable to do some 
> refactoring on the loading code so as to better align it with the fetch 
> algorithm.
> 
> Thoughts, advices... most welcome.
> Thanks,
>y
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] NetworkSession

2015-11-19 Thread Alex Christensen
Yes, Carlos, that is correct.  I’m making it so ENABLE(NETWORK_PROCESS) is 
effectively always 1, usesNetworkProcess is effectively always true, and 
ProcessModel is always ProcessModelMultipleSecondaryProcesses.  I did this by 
removing the checks for NETWORK_PROCESS, usesNetworkProcess, and ProcessModel.  
We will still have a max process limit, and it can be set to 1, and that’s what 
I’ve used to get ready for this change, too.

Alex

> On Nov 19, 2015, at 12:04 AM, Carlos Garcia Campos <carlo...@webkit.org> 
> wrote:
> 
> El mié, 18-11-2015 a las 15:58 -0800, Alex Christensen escribió:
>> As part of this work, I’m also planning to remove the non-
>> NetworkProcess code, both run time and compile time. Based on
>> discussion at the WebKit contributors’ meeting I assume there is no
>> objection to this.  See https://bugs.webkit.org/show_bug.cgi?id=15141 
>> <https://bugs.webkit.org/show_bug.cgi?id=15141>
>> 8
> 
> No objections for GTK port. I guess then the single process model will
> become multiple model with max process limit = 1 internally, right?
> That's what we did in epiphany in preparation for this change. Or do
> you plan to remove/deprecate the single process model?
> 
>> Alex
>> 
>>> On Nov 9, 2015, at 11:32 AM, Alex Christensen <achristensen@apple.c
>>> om> wrote:
>>> 
>>> I made new abstractions for loading in WebKit2: NetworkSession and
>>> NetworkDataTask.  It is disabled by default right now, but if you
>>> switch USE_NETWORK_SESSION to 1, it mostly works on Mac with
>>> features like authentication challenges not implemented yet.  I
>>> believe these new abstractions fit better with libsoup, but I’d
>>> like feedback on what an actual libsoup implementation would need.
>>>  I’m planning on removing the ResourceHandle use in WebKit2 and the
>>> async/continue callbacks in ResourceHandleClient and ResourceHandle
>>> once this work is done.
>>> 
>>> Alex
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] NetworkSession

2015-11-18 Thread Alex Christensen
As part of this work, I’m also planning to remove the non-NetworkProcess code, 
both run time and compile time. Based on discussion at the WebKit contributors’ 
meeting I assume there is no objection to this.  See 
https://bugs.webkit.org/show_bug.cgi?id=151418 
<https://bugs.webkit.org/show_bug.cgi?id=151418>

Alex

> On Nov 9, 2015, at 11:32 AM, Alex Christensen <achristen...@apple.com> wrote:
> 
> I made new abstractions for loading in WebKit2: NetworkSession and 
> NetworkDataTask.  It is disabled by default right now, but if you switch 
> USE_NETWORK_SESSION to 1, it mostly works on Mac with features like 
> authentication challenges not implemented yet.  I believe these new 
> abstractions fit better with libsoup, but I’d like feedback on what an actual 
> libsoup implementation would need.  I’m planning on removing the 
> ResourceHandle use in WebKit2 and the async/continue callbacks in 
> ResourceHandleClient and ResourceHandle once this work is done.
> 
> Alex
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] NetworkSession

2015-11-09 Thread Alex Christensen
I made new abstractions for loading in WebKit2: NetworkSession and 
NetworkDataTask.  It is disabled by default right now, but if you switch 
USE_NETWORK_SESSION to 1, it mostly works on Mac with features like 
authentication challenges not implemented yet.  I believe these new 
abstractions fit better with libsoup, but I’d like feedback on what an actual 
libsoup implementation would need.  I’m planning on removing the ResourceHandle 
use in WebKit2 and the async/continue callbacks in ResourceHandleClient and 
ResourceHandle once this work is done.

Alex

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Mac CMake

2015-11-02 Thread Alex Christensen
Just to clarify, the CMake build on Mac is experimental and incomplete right 
now.  MiniBrowser and most of TestWebKitAPI are not built, and the frameworks 
probably can’t run any applications.
> On Nov 2, 2015, at 6:30 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote:
> 
> I succeed to build the Mac port with --cmake option locally. Great !
> 
> Gyuyoung.
> 
> On Sun, Nov 1, 2015 at 1:58 AM, Yusuke SUZUKI <utatane@gmail.com 
> <mailto:utatane@gmail.com>> wrote:
> Awesome!
> 
> ---
> Regards,
> Yusuke Suzuki
> 
> On Sat, Oct 31, 2015 at 6:32 AM, Geoffrey Garen <gga...@apple.com 
> <mailto:gga...@apple.com>> wrote:
> 
> 
>> On Oct 30, 2015, at 2:17 PM, Alex Christensen <achristen...@apple.com 
>> <mailto:achristen...@apple.com>> wrote:
>> 
>> I got the Mac CMake build to the point where it can compile and link 
>> frameworks successfully.  We will get a buildbot up soon, but in the 
>> meantime please try to add and remove files in the CMake build.Let me know 
>> if you have any questions or concerns or want to help out.  I don’t think it 
>> can be used to run Safari yet, but that’s hopefully coming soon.
>> 
>> If you want to try it out, run this command:
>> Tools/Scripts/build-webkit --cmake
>> 
>> Alex
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [webkit-help] Issue with Web Inspector debugger breakpoint handling (on Wincairo)

2015-10-02 Thread Alex Christensen

> On Oct 2, 2015, at 3:12 PM, Joseph Pecoraro  wrote:
> Is WinCairo using WebKit1 or WebKit2?
Windows is WebKit1-only.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] CMake on Windows

2015-09-28 Thread Alex Christensen
All the Windows buildbots are now using Windows.  We are planning to leave all 
the Visual Studio projects in the tree for a couple weeks, so if you make any 
changes like adding another file, please try to blindly add it to the Visual 
Studio build.  If you are wondering why the Windows EWS doesn’t see your 
changes, it is because EWS is using CMake.  Please let me know if you have any 
issues.

Thanks, 
Alex

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake on Windows

2015-09-28 Thread Alex Christensen
*All the Windows buildbots are now using CMake.
> On Sep 28, 2015, at 1:28 PM, Alex Christensen <achristen...@apple.com> wrote:
> 
> All the Windows buildbots are now using Windows.  We are planning to leave 
> all the Visual Studio projects in the tree for a couple weeks, so if you make 
> any changes like adding another file, please try to blindly add it to the 
> Visual Studio build.  If you are wondering why the Windows EWS doesn’t see 
> your changes, it is because EWS is using CMake.  Please let me know if you 
> have any issues.
> 
> Thanks, 
> Alex
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Windows Build Now on VS2015

2015-08-14 Thread Alex Christensen
The days of supporting VS2013 are behind us, so if it works with VS2015, go for 
it.  Not all c++14 features are supported, though.  See 
https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table

I’m not sure what the oldest gcc we support is.
 On Aug 14, 2015, at 5:49 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 Does this mean we can start using (most) C++14 features?
 
 
   antti
 
 
 On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham bfulg...@apple.com 
 mailto:bfulg...@apple.com wrote:
 Hi Floks,
 
 We’ve finished updating the various Windows builds to VS2015. Full regression 
 tests are now completing on these new builds, and seem to be comparable in 
 terms of stability and correctness.
 
 Please let me know if you encounter any new issues on Windows. I know that EA 
 encountered some JavaScript issues in a prior revision, but I haven’t been 
 able to replicate this problem (at least yet).
 
 VS2015 is churning out a number of new build warnings, which I hope to 
 address over the coming weeks. It will also likely have some useful static 
 analysis results in the Windows-specific portions of the code that we should 
 evaluate.
 
 Thanks,
 
 -Brent
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] TestWebKitAPI and CMake

2015-08-07 Thread Alex Christensen
Right now, the Mac and Windows ports have TestWebKitAPI built as a single 
executable.  Tools/TestWebKitAPI/CMakeLists.txt currently creates many 
executables to test things in groups.  I want to make the Windows port build 
everything with CMake at the beginning of next week, but I’m not sure how to 
proceed and build TestWebKitAPI.  I see 3 options:

1) Change the GTK and EFL ports to build and run one TestWebKitAPI executable.
2) Change the Windows and maybe eventually Mac ports to build many 
TestWebKitAPI executables (TestWTF, TestJavaScriptCore, etc.).  It would be 
easiest for me if this were done after removing the Visual Studio build system.
3) Maintain different CMake builds of TestWebKitAPI building one or many 
executables.  This would probably be the least invasive option.

I consider each option to have about equal merit, but I think I need input from 
the GTK and EFL maintainers before proceeding.  Either way, there would be 
slight differences between the ports because of things like WebKit2 not 
existing on Windows right now, so I suggest the third option.

Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] VS2015

2015-08-01 Thread Alex Christensen
As of r187726, you should be able to build Release 32-bit and 64-bit WebKit 
completely with Visual Studio 2015 with CMake.  Not all features are enabled in 
the CMake build, and we’re still waiting on a few fixes for Debug builds.  In 
anticipation of eventually requiring VS2015, I plan to switch my buildbot to 
use VS2015 early next week so we can notice if anything breaks.  This should 
require no changes to the WebKit repository, and we are not quite ready to 
remove VS2013 support yet.

Please let me know if you have any questions or issues, or if you want to help 
out with the transition.

Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] forwarding headers and CMake

2015-07-28 Thread Alex Christensen
In my work getting CMake working on Windows, I discovered a subtle difference 
in how forwarding headers are made.  In the existing build system, a forwarding 
header contains the entire contents of the original header.  In the current 
CMake build, the WEBKIT_CREATE_FORWARDING_HEADERS macro creates lots of one 
line files that #include the original file.

For example, my JSBase.h forwarding header contains only this one line:
#include “JavaScriptCore/API/JSBase.h”

In order to switch the Windows build over to use CMake, I’m pretty sure we 
would need the entire contents of the headers to be copied to the build 
directory.  Would changing this build behavior cause a problem for the GTK or 
EFL ports?  If so, I would probably make the forwarding headers macros port 
specific.

Alex
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake on Windows

2015-07-22 Thread Alex Christensen
Hopefully eventually, yes.

 On Jul 21, 2015, at 8:22 PM, Martin Robinson mrobin...@webkit.org wrote:
 
 This is great news! Do you plan to remove the WinCairo portion of the
 Visual Studio build?
 
 --Martin
 
 On Tue, Jul 21, 2015 at 4:29 PM, Alex Christensen
 achristen...@apple.com wrote:
 I plan to switch build-webkit --wincairo to use CMake in the near future.  
 We are not ready to remove the Visual Studio build system yet and won’t be 
 for a while, but a bot using CMake on Windows will help us notice if 
 anything breaks as we make more progress.  Building from 
 Source/WebKit/WebKit.vcxproj/WebKit.sln should be unaffected.  I think I’m 
 the only one with a WinCairo build bot, but please let me know if this will 
 cause a problem for anyone.
 
 Alex
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] CMake on Windows

2015-07-21 Thread Alex Christensen
I plan to switch build-webkit --wincairo to use CMake in the near future.  We 
are not ready to remove the Visual Studio build system yet and won’t be for a 
while, but a bot using CMake on Windows will help us notice if anything breaks 
as we make more progress.  Building from 
Source/WebKit/WebKit.vcxproj/WebKit.sln should be unaffected.  I think I’m the 
only one with a WinCairo build bot, but please let me know if this will cause a 
problem for anyone.

Alex

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Compilation issue with VS2015RC

2015-07-15 Thread Alex Christensen
I only did one 64-bit build with VS2015RC and I did not run into this crash.  
Please file another bug.  It’s definitely worth looking into.
My change to CSSPrimitiveValue.h in 
https://bugs.webkit.org/show_bug.cgi?id=146579 
https://bugs.webkit.org/show_bug.cgi?id=146579 is a hack that should not be 
committed, but it’s sure nice to be able to link successfully while doing 
experimental work.

 On Jul 14, 2015, at 5:20 PM, Vienneau, Christopher cvienn...@ea.com wrote:
 
 Using the changes in the patch you provided, I made progress but I have some 
 observations to report:
 I didn’t find the changes in ConsoleClient.cpp to be necessary, actually with 
 my version of webkit they didn’t build as is, I removed them.  I think that 
 the change to CSSPrimitiveValue.h is actually the part I was missing to fix 
 the linking error.
  
 When attempting to run with my test application I’m finding that most 
 websites, facebook.com http://facebook.com/ for example, are crashing in 
 LowLevelInterpreterWin.asm code identified by LowLevelInterpreter.asm:476:
   _offlineasm_doCall__177_loadConstantOrVariable__done:
 cmp rbx, rcx ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1798
 jne _offlineasm_doCall__opCallSlow
 movsxd rbx, dword ptr [32 + r8 + rsi * 8]; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:114
sal ebx, 3   ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1800
 neg rbx  ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1801
 add rbx, rbp ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1802
 mov qword ptr [24 + rbx], rcx; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1803
 movsxd rcx, dword ptr [24 + r8 + rsi * 8]; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:114
 mov dword ptr [36 + rbp], esi; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1805
 mov dword ptr [32 + rbx], ecx; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1806
 add rbx, 16  ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:1807
 mov rsp, rbx ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:472
 call qword ptr [32 + rdx]; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:476
 mov rcx, qword ptr [16 + rbp]; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:461
 mov edi, dword ptr [56 + rcx]; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:449
 sal rdi, 3   ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:450
 add rdi, 64  ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:451
 mov rsp, rbp ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:456
 sub rsp, rdi
 mov esi, dword ptr [36 + rbp]; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:45
 mov r8, qword ptr [16 + rbp] ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:46
 mov r8, qword ptr [104 + r8] ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:47
 movsxd rdx, dword ptr [8 + r8 + rsi * 8] ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:114
 mov qword ptr [0 + rbp + rdx * 8], rax   ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:49
 mov rcx, qword ptr [64 + r8 + rsi * 8]   ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint\LowLevelInterpreter.asm:118
 mov qword ptr [16 + rcx], rax; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:491
 add rsi, 9   ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:31
 jmp qword ptr [0 + r8 + rsi * 8] ; 
 ..\..\JavaScriptCore\local\JavaScriptCore\llint/LowLevelInterpreter64.asm:27
  
 I tried regenerating the asm files but still have the issue.  I expect that 
 some updates 

[webkit-dev] DirectX SDK

2015-07-02 Thread Alex Christensen
Heads up: my recent updating of ANGLE (r186169, r186172, r186201, and r186220) 
made it so WinCairo uses the DirectX SDK that comes with Visual Studio 2013, 
not the June 2010 DirectX SDK.  Please let me know if this causes a problem for 
anyone.

Alex

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake dependency bump?

2015-05-13 Thread Alex Christensen
I recant.  Upon talking to people who actually know what they are doing, I find 
that we should not have a problem using CMake 3.2.1 on Mac.  So let’s use all 
the latest and greatest features of CMake in WebKit and if there are any 
problems we will address them as needed.

Alex

On May 13, 2015, at 10:29 AM, Alex Christensen achristen...@apple.com wrote:

 I would not mind requiring 2.8.12 right now.  It would be a slight hinderance 
 to the progress of using CMake on Mac and Windows (which is admittedly slow 
 and only contributed to by me right now) but it would not cause much of a 
 problem for me personally.  Once it works, it would be much easier for us to 
 adopt if we could use the same build system that requires LLVM to be able to 
 be built with CMake 2.8.8.  I’m not sure why they use such an old version of 
 CMake or why they don’t bump their minimum version, but I don’t work on LLVM 
 much right now, so I don’t make those decisions.  If there is a way to keep 
 using CMake 2.8.8, then we would avoid some hopefully small issues in the 
 distant future, but that might not be worth it to miss out on using new 
 features right now.  If GTK and EFL agree that the benefits of the new 
 features outweigh slightly hindering the potential of uniting the build 
 system in the future, then go for it.
 
 Alex
 On May 13, 2015, at 2:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 Why would be helpful to stuck with a very old cmake version?
 CMake 2.8.8 was released on 18th Apr 2012 (3 years ago), and
 2.8.12 was released on 8th Oct 2013 (1.5 years ago). What is
 the blocker issue why you can't use the newer cmake? Could
 you explain the details? Wouldn't be easier to try to solve
 the issue you ran into with the newer cmake?
 
 As far as I know cmake isn't shipped with OS X, but please correct me
 if I'm wrong. Installing a binary cmake or building it from source isn't
 a big deal at all. Additionally what builds fine with 2.8.8, it should
 build fine with 2.8.12 too, including LLVM too.
 
 Otherwise is there an expected date when will cmake officially
 supported by Apple with buildbots and EWS too? This cmake on Mac
 project started near a year before, but unfortunately I can't see
 too big effort from Apple contributors, only your occasionally patches.
 
 I fully support to progress toward on this way if we can see
 a real intentions to switch to cmake once in the future.
 
 br,
 Ossy
 
 Alex Christensen írta:
 It would be quite helpful to my CMake on Mac effort (which isn't complete 
 yet) and the long-term CMaking of WebKit, JavaScriptCore, and in particular 
 JSC's FTL to keep the CMake requirements the same as LLVM, which are 2.8.8 
 right now.  I know CMake has cool new features that I would also like to 
 use, but I would oppose such a change right now if there is another way.
 http://llvm.org/docs/CMake.html
 Alex Christensen
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake dependency bump?

2015-05-13 Thread Alex Christensen
I would not mind requiring 2.8.12 right now.  It would be a slight hinderance 
to the progress of using CMake on Mac and Windows (which is admittedly slow and 
only contributed to by me right now) but it would not cause much of a problem 
for me personally.  Once it works, it would be much easier for us to adopt if 
we could use the same build system that requires LLVM to be able to be built 
with CMake 2.8.8.  I’m not sure why they use such an old version of CMake or 
why they don’t bump their minimum version, but I don’t work on LLVM much right 
now, so I don’t make those decisions.  If there is a way to keep using CMake 
2.8.8, then we would avoid some hopefully small issues in the distant future, 
but that might not be worth it to miss out on using new features right now.  If 
GTK and EFL agree that the benefits of the new features outweigh slightly 
hindering the potential of uniting the build system in the future, then go for 
it.

Alex
 On May 13, 2015, at 2:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:
 
 Hi,
 
 Why would be helpful to stuck with a very old cmake version?
 CMake 2.8.8 was released on 18th Apr 2012 (3 years ago), and
 2.8.12 was released on 8th Oct 2013 (1.5 years ago). What is
 the blocker issue why you can't use the newer cmake? Could
 you explain the details? Wouldn't be easier to try to solve
 the issue you ran into with the newer cmake?
 
 As far as I know cmake isn't shipped with OS X, but please correct me
 if I'm wrong. Installing a binary cmake or building it from source isn't
 a big deal at all. Additionally what builds fine with 2.8.8, it should
 build fine with 2.8.12 too, including LLVM too.
 
 Otherwise is there an expected date when will cmake officially
 supported by Apple with buildbots and EWS too? This cmake on Mac
 project started near a year before, but unfortunately I can't see
 too big effort from Apple contributors, only your occasionally patches.
 
 I fully support to progress toward on this way if we can see
 a real intentions to switch to cmake once in the future.
 
 br,
 Ossy
 
 Alex Christensen írta:
 It would be quite helpful to my CMake on Mac effort (which isn't complete 
 yet) and the long-term CMaking of WebKit, JavaScriptCore, and in particular 
 JSC's FTL to keep the CMake requirements the same as LLVM, which are 2.8.8 
 right now.  I know CMake has cool new features that I would also like to 
 use, but I would oppose such a change right now if there is another way.
 http://llvm.org/docs/CMake.html
 Alex Christensen
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] CMake dependency bump?

2015-05-12 Thread Alex Christensen
It would be quite helpful to my CMake on Mac effort (which isn’t complete yet) 
and the long-term CMaking of WebKit, JavaScriptCore, and in particular JSC’s 
FTL to keep the CMake requirements the same as LLVM, which are 2.8.8 right now. 
 I know CMake has cool new features that I would also like to use, but I would 
oppose such a change right now if there is another way.

http://llvm.org/docs/CMake.html

Alex Christensen

 On May 12, 2015, at 4:54 PM, ryuan Choi ryuan.c...@gmail.com wrote:
 
 Hi,
 
 I think that it is fine to the EFL port.
 
 Best Regards,
 Ryuan Choi
 
 
 2015-05-13 7:47 GMT+09:00 Michael Catanzaro mcatanz...@igalia.com 
 mailto:mcatanz...@igalia.com:
 Hi,
 
 For bug #144747 it would be helpful to require CMake 2.8.12, so that I
 can use the SYSTEM argument to target_include_directories. Would this
 be a problem for anyone (in particular, the EFL port)? It was released
 October 2013 and it's present in Ubuntu 14.04.
 
 Thanks,
 
 Michael
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev 
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WEBCORE_EXPORT

2015-02-23 Thread Alex Christensen
Last week I switched the iOS and Mac builds to use WEBCORE_EXPORT instead of 
WebCore.exp.in.  This should make maintenance easier, but there are a few 
quirks everybody should be aware of:

1) Do not use WEBCORE_EXPORT before a function defined in a header.  This will 
cause check-for-weak-vtables-and-externals to fail sometimes.  See 
http://trac.webkit.org/changeset/179974/trunk/Source/WebCore/dom/Range.h 
http://trac.webkit.org/changeset/179974/trunk/Source/WebCore/dom/Range.h for 
an example fix.
2) If you need to export the vtable of a class, put WEBCORE_EXPORT between 
“class and the class name, but not before method and member variable 
declarations.  Otherwise Visual Studio will not compile successfully after we 
get rid of WebKitExports.def.in.  See 
http://trac.webkit.org/changeset/180301/trunk/Source/WebCore/bridge/runtime_method.h
 
http://trac.webkit.org/changeset/180301/trunk/Source/WebCore/bridge/runtime_method.h
 for an example fix.

Alex___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


  1   2   >