Re: [webkit-dev] Another WPT bite

2017-05-11 Thread Simon Fraser
> 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

2017-05-11 Thread Anne van Kesteren
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

2017-05-11 Thread youenn fablet
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

2017-05-11 Thread Ryosuke Niwa
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

2017-05-11 Thread Geoffrey Garen
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

2017-05-11 Thread Daniel Ferreira (theiostream)
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

2017-05-11 Thread Sam Weinig


> 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

2017-05-11 Thread Yusuke SUZUKI
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

2017-05-11 Thread Konstantin Tokarev


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

2017-05-11 Thread 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

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