Re: [webkit-dev] Another WPT bite
On Thu, May 11, 2017 at 11:32 PM, Anne van Kesteren wrote: > On Fri, May 12, 2017 at 6:46 AM, Simon Fraser wrote: >> I was under the impression that tests upstreamed from vendor repositories >> would land in WPT tests >> with minimal review, based on the fact that they had been reviewed when >> landed in the vendor repo. > > I think that's under the expectation that those reviewing WPT changes > have some familiarity with the structure of WPT. > > >> What's to stop 4 vendors from upstreaming similar but non-identical tests >> for a given feature? > > Usually when a new feature is in development developers from the > various vendors use the relevant standards forum to coordinate on > testing and avoid duplication. Also, if someone is fixing a bug or implementing a feature with a new test, and some other starts passing / failing, then the person would be compelled to either modify the existing test or de-duplicating the test. We all have to be diligent in this regard but it's not much worse than what we have to do in WebKit to avoid keep adding similar tests. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Another WPT bite
On Fri, May 12, 2017 at 6:46 AM, Simon Fraser wrote: > I was under the impression that tests upstreamed from vendor repositories > would land in WPT tests > with minimal review, based on the fact that they had been reviewed when > landed in the vendor repo. I think that's under the expectation that those reviewing WPT changes have some familiarity with the structure of WPT. > What's to stop 4 vendors from upstreaming similar but non-identical tests for > a given feature? Usually when a new feature is in development developers from the various vendors use the relevant standards forum to coordinate on testing and avoid duplication. -- https://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Another WPT bite
> On May 11, 2017, at 9:30 PM, Anne van Kesteren wrote: > > On Tue, May 9, 2017 at 8:27 PM, Simon Fraser wrote: >> I'm also concerned that with 4 vendors upstreaming their WPT tests, the WPT >> repo will just become a morass of partially overlapping tests that takes 4x >> longer to run than a curated repo. > > Why do you think WPT is not curated? It's an actively maintained test > suite. Treating it as a dumping ground would be a mistake I think. > > For WHATWG standards we make sure to update corresponding tests for > each change to the standard as well at which point any needed cleanup > occurs (we didn't start out with this process unfortunately so there's > definitely some cleanup left to be done here and there, but that's > true for each software project). I was under the impression that tests upstreamed from vendor repositories would land in WPT tests with minimal review, based on the fact that they had been reviewed when landed in the vendor repo. What's to stop 4 vendors from upstreaming similar but non-identical tests for a given feature? Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Another WPT bite
On Tue, May 9, 2017 at 8:27 PM, Simon Fraser wrote: > I'm also concerned that with 4 vendors upstreaming their WPT tests, the WPT > repo will just become a morass of partially overlapping tests that takes 4x > longer to run than a curated repo. Why do you think WPT is not curated? It's an actively maintained test suite. Treating it as a dumping ground would be a mistake I think. For WHATWG standards we make sure to update corresponding tests for each change to the standard as well at which point any needed cleanup occurs (we didn't start out with this process unfortunately so there's definitely some cleanup left to be done here and there, but that's true for each software project). -- https://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Another WPT bite
Patch just landed. Location is LayoutTests/http/wpt. I also forgot to say that, should you want to write http served tests, it might make sense to use this folder instead of http/tests. Y Le jeu. 11 mai 2017 à 19:05, Sam Weinig a écrit : > > On May 8, 2017, at 9:31 PM, youenn fablet wrote: > > Hi all, > > Discussing with some WebKittens, testharness.js is more and more used in > WebKit. > Is it time to make testharness.js the recommended way of writing > LayoutTests? > > > I am in favor of this. If we simplified the question to some form of, “do > we really need both testharness.js/testharnessreport.js and > js-test-pre.js/js-test-post.js?” > I am even more in favor, as having two test harnesses seems unnecessary, > cumbersome and unfriendly to new contributors, > > Do I think all tests should use testharness.js? No. Just as currently I > don’t think all tests should use testharness.js/testharnessreport.js. But > for many tests of new web platform features, it seems quite reasonable to > start using this harness, as the benefits, which include a good feature > set, easier interoperability with other browsers, and a reduced cost to > upstreaming to web-platform-tests, out weigh the costs, leaning something > new (there are probably other costs I am forgetting). > > > To continue moving forward, some of us are proposing to serve all tests in > LayoutTests/wpt through the WPT server [1]. > This would serve some purposes like increasing the use of WPT goodies: > file-specific headers, templated tests (*.any.js), IDLParser, server-side > scripts... > It could also ease test migration from WebKit to W3C WPT. > > > This seems uncontroversial and great to me (which would make sense since I > asked you if we could do it). It’s just a new directory, like > LayoutTests/http where we can put tests that use the WPT server. > > - Sam > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Fwd: Port WebKit to GNUstep
Are you intending to maintain this port going forward? The bar for introducing a new port in the WebKit repository is pretty high due to the maintenance cost it incurs to all other contributors. Unless you're intending to maintain your own port, and then contribute to the rest of the WebKit project unrelated to your port work, we kindly ask you to maintain your port in some downstream repository such as a GitHub fork. - R. Niwa On Thu, May 11, 2017 at 7:54 PM, Daniel Ferreira (theiostream) wrote: > Hi there, > > My name is Daniel Ferreira and as a Google Summer of Code project I > decided to tackle the ten-year-long[1] effort of porting WebKit to > GNUstep one more time (and hopefully get somewhere this time). > > Since 2009, GNUstep has gained a lot of maturity in its graphics stack > and on its implementation of CoreFoundation, so now having a WebKit > port in it seems like a more plausible goal – as well as a fun > challenge. This is very important to GS since it still has no web > browser running on top of it. > > Also since 2009, it seems like WebKit has gained mature ports on GTK > and Qt, which has made the demand for a GNUstep port quite smaller for > the project. However, it does seem interesting to offer a > cross-platform port that adds portability to a lot of currently > Mac-specific code – a goal a GNUstep port would fulfill. > > In an ideal world, GNUstep would be mature enough for us to build the > Mac port on a Linux machine pointing to GNUstep libraries and all > would be well. Sadly, this is not the case and a GNUstep port on > WebKit would require some adjustments on WebKit (although GNUstep > certainly would receive many patches as well implementing stuff WebKit > would use). > > That being said, I decided to try compiling WTF as a first approach to > this undertaking, and I introduced a "PlatformGNUstep.cmake" file that > is mostly a copy of PlatformMac.cmake. It ends up defining > WTF_PLATFORM_MAC and WTF_PLATFORM_GNUSTEP as code macros, and whenever > there is some Mac-specific code that GNUstep can't tackle, we try a > cross-platform alternative. Otherwise, the behavior is just like that > of the Mac port. > > Through some adjustments to WebKit code (e.g. GNUstep does not support > XPC, QOS, Mach kernel memory operations, so in these cases we either > do nothing or use Linux-specific code as an implementation) and > GNUstep adjustments (regarding some missing CoreFoundation functions), > I managed to get WTF compiled and linked. I'm now moving on to > JavaScriptCore to be able to test everything (and very likely spend > quite some time figuring out the most diverse issues that will show > up). > > That being said, I will send a patch as soon as I get JSC in a > semi-decent state. However I wondered if this introduce new platform + > do the same thing as Mac port with some exceptions approach seems > reasonable to the project now that I have realized it is actually > feasible. > > Thanks, > -- Daniel. > > [1]: https://lists.webkit.org/pipermail/webkit-dev/2009-October/010333.html > ___ > 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] Port WebKit to GNUstep
No. The bar is much higher for introducing a new port to WebKit. Geoff > On May 11, 2017, at 7:54 PM, Daniel Ferreira (theiostream) > wrote: > > Hi there, > > My name is Daniel Ferreira and as a Google Summer of Code project I > decided to tackle the ten-year-long[1] effort of porting WebKit to > GNUstep one more time (and hopefully get somewhere this time). > > Since 2009, GNUstep has gained a lot of maturity in its graphics stack > and on its implementation of CoreFoundation, so now having a WebKit > port in it seems like a more plausible goal – as well as a fun > challenge. This is very important to GS since it still has no web > browser running on top of it. > > Also since 2009, it seems like WebKit has gained mature ports on GTK > and Qt, which has made the demand for a GNUstep port quite smaller for > the project. However, it does seem interesting to offer a > cross-platform port that adds portability to a lot of currently > Mac-specific code – a goal a GNUstep port would fulfill. > > In an ideal world, GNUstep would be mature enough for us to build the > Mac port on a Linux machine pointing to GNUstep libraries and all > would be well. Sadly, this is not the case and a GNUstep port on > WebKit would require some adjustments on WebKit (although GNUstep > certainly would receive many patches as well implementing stuff WebKit > would use). > > That being said, I decided to try compiling WTF as a first approach to > this undertaking, and I introduced a "PlatformGNUstep.cmake" file that > is mostly a copy of PlatformMac.cmake. It ends up defining > WTF_PLATFORM_MAC and WTF_PLATFORM_GNUSTEP as code macros, and whenever > there is some Mac-specific code that GNUstep can't tackle, we try a > cross-platform alternative. Otherwise, the behavior is just like that > of the Mac port. > > Through some adjustments to WebKit code (e.g. GNUstep does not support > XPC, QOS, Mach kernel memory operations, so in these cases we either > do nothing or use Linux-specific code as an implementation) and > GNUstep adjustments (regarding some missing CoreFoundation functions), > I managed to get WTF compiled and linked. I'm now moving on to > JavaScriptCore to be able to test everything (and very likely spend > quite some time figuring out the most diverse issues that will show > up). > > That being said, I will send a patch as soon as I get JSC in a > semi-decent state. However I wondered if this introduce new platform + > do the same thing as Mac port with some exceptions approach seems > reasonable to the project now that I have realized it is actually > feasible. > > Thanks, > -- Daniel. > > [1]: https://lists.webkit.org/pipermail/webkit-dev/2009-October/010333.html > ___ > 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] Fwd: Port WebKit to GNUstep
Hi there, My name is Daniel Ferreira and as a Google Summer of Code project I decided to tackle the ten-year-long[1] effort of porting WebKit to GNUstep one more time (and hopefully get somewhere this time). Since 2009, GNUstep has gained a lot of maturity in its graphics stack and on its implementation of CoreFoundation, so now having a WebKit port in it seems like a more plausible goal – as well as a fun challenge. This is very important to GS since it still has no web browser running on top of it. Also since 2009, it seems like WebKit has gained mature ports on GTK and Qt, which has made the demand for a GNUstep port quite smaller for the project. However, it does seem interesting to offer a cross-platform port that adds portability to a lot of currently Mac-specific code – a goal a GNUstep port would fulfill. In an ideal world, GNUstep would be mature enough for us to build the Mac port on a Linux machine pointing to GNUstep libraries and all would be well. Sadly, this is not the case and a GNUstep port on WebKit would require some adjustments on WebKit (although GNUstep certainly would receive many patches as well implementing stuff WebKit would use). That being said, I decided to try compiling WTF as a first approach to this undertaking, and I introduced a "PlatformGNUstep.cmake" file that is mostly a copy of PlatformMac.cmake. It ends up defining WTF_PLATFORM_MAC and WTF_PLATFORM_GNUSTEP as code macros, and whenever there is some Mac-specific code that GNUstep can't tackle, we try a cross-platform alternative. Otherwise, the behavior is just like that of the Mac port. Through some adjustments to WebKit code (e.g. GNUstep does not support XPC, QOS, Mach kernel memory operations, so in these cases we either do nothing or use Linux-specific code as an implementation) and GNUstep adjustments (regarding some missing CoreFoundation functions), I managed to get WTF compiled and linked. I'm now moving on to JavaScriptCore to be able to test everything (and very likely spend quite some time figuring out the most diverse issues that will show up). That being said, I will send a patch as soon as I get JSC in a semi-decent state. However I wondered if this introduce new platform + do the same thing as Mac port with some exceptions approach seems reasonable to the project now that I have realized it is actually feasible. Thanks, -- Daniel. [1]: https://lists.webkit.org/pipermail/webkit-dev/2009-October/010333.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Another WPT bite
> On May 8, 2017, at 9:31 PM, youenn fablet wrote: > > Hi all, > > Discussing with some WebKittens, testharness.js is more and more used in > WebKit. > Is it time to make testharness.js the recommended way of writing LayoutTests? I am in favor of this. If we simplified the question to some form of, “do we really need both testharness.js/testharnessreport.js and js-test-pre.js/js-test-post.js?” I am even more in favor, as having two test harnesses seems unnecessary, cumbersome and unfriendly to new contributors, Do I think all tests should use testharness.js? No. Just as currently I don’t think all tests should use testharness.js/testharnessreport.js. But for many tests of new web platform features, it seems quite reasonable to start using this harness, as the benefits, which include a good feature set, easier interoperability with other browsers, and a reduced cost to upstreaming to web-platform-tests, out weigh the costs, leaning something new (there are probably other costs I am forgetting). > To continue moving forward, some of us are proposing to serve all tests in > LayoutTests/wpt through the WPT server [1]. > This would serve some purposes like increasing the use of WPT goodies: > file-specific headers, templated tests (*.any.js), IDLParser, server-side > scripts... > It could also ease test migration from WebKit to W3C WPT. This seems uncontroversial and great to me (which would make sense since I asked you if we could do it). It’s just a new directory, like LayoutTests/http where we can put tests that use the WPT server. - Sam___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reminder: be careful when printing sized integer types
Or, alternative way is casting the value to `unsigned long long` and always using %llu for uint64_t. uint64_t value = ...; printf("%llu", (unsigned long long)value); Regards, Yusuke Suzuki On Wed, May 10, 2017 at 4:07 AM, Michael Catanzaro wrote: > Hi, > > This is just a reminder to avoid a case that occasionally causes warnings > for GTK+. On Mac, uint64_t is (I assume) a typedef for unsigned long long. > But on Linux 86_64 it's a typedef for unsigned long. This means they have > to be printed differently. Using "%llu" to print a uint64_t (presumably) > works on Mac, but it causes compiler warnings on Linux. The right way is > unfortunately to use "%" PRIu64, which expands to "%llu" on Mac and "%lu" > on Linux. There are variants on these macros for many different integer > types: http://en.cppreference.com/w/cpp/types/integer > > It's verbose, but helps us avoid warnings. And since it's declared in > stdint.h/cstdint, if you're using uint64_t then it's already available. > > Thanks, > > 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] Idiom for functions with all return values in a switch case
11.05.2017, 11:18, "Osztrogonác Csaba" : > Hi, > > On 2017.05.11. 0:32, Andy Estes wrote: >>> On May 10, 2017, at 3:17 PM, Michael Catanzaro >>> wrote: >>> >>> On Tue, May 9, 2017 at 2:57 PM, Ryosuke Niwa wrote: One annoying thing is that I've seen clang complaining about that return statement being an unreachable statement while gcc doesn't :(. So we probably shouldn't have return statement, not to mention that 0 may not be a valid enum value. >>> >>> In that case, I think I'll go with RELEASE_ASSERT_NOT_REACHED() for now... >>> since otherwise GCC is going to complain in release builds if there is no >>> return statement. (Won't clang complain about that too?) >> >> Clang won’t complain if the switch is exhaustive and all cases return. >> >> Andy > > It isn't possible to check if all cases return if there is > no default label in the switch, see these comments for details: > https://bugs.webkit.org/show_bug.cgi?id=150842#c3 If you create enum value that is outside of range of defined enum members, like 2 in your example, it's already unspecified behavior. In case of enum with holes it may be correct, but I don't think we have many of those. > > GCC's warning is correct and clang won't complain, > but undefined behaviour can happen in runtime. > > br, > Ossy > ___ > 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] Idiom for functions with all return values in a switch case
Hi, On 2017.05.11. 0:32, Andy Estes wrote: On May 10, 2017, at 3:17 PM, Michael Catanzaro wrote: On Tue, May 9, 2017 at 2:57 PM, Ryosuke Niwa wrote: One annoying thing is that I've seen clang complaining about that return statement being an unreachable statement while gcc doesn't :(. So we probably shouldn't have return statement, not to mention that 0 may not be a valid enum value. In that case, I think I'll go with RELEASE_ASSERT_NOT_REACHED() for now... since otherwise GCC is going to complain in release builds if there is no return statement. (Won't clang complain about that too?) Clang won’t complain if the switch is exhaustive and all cases return. Andy It isn't possible to check if all cases return if there is no default label in the switch, see these comments for details: https://bugs.webkit.org/show_bug.cgi?id=150842#c3 GCC's warning is correct and clang won't complain, but undefined behaviour can happen in runtime. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev