[webkit-dev] Reminder: include everything that you use in implementation files

2020-11-11 Thread Brian Burg via webkit-dev
Hello folks,

I'd like to remind everyone to please include what you use in .cpp,  .mm, and 
other files. When reviewing patches, please
ensure that new mentions of classes, structs, etc. within an implementation 
file have a corresponding header include. 
All of our headers have #pragma once, so there is no downside to being more 
explicit.

I've been noticing an uptick in the number of unified sources-related build 
failures. I can't remember the last nontrivial patch
I wrote that did *not* include unrelated build fixes. Typically these failures 
aren't found until EWS results come back, reducing developer velocity.
And obviosuly it's super annoying to encounter completely unrelated build 
failures that must be nonetheless addressed.

Let's all do our part so that hacking on WebKit remains delightful.

Thanks,

Brian Burg (he/they)
 WebKit Developer Experience
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Transitioning commit-queue to new EWS and deprecating old EWS

2020-03-18 Thread Brian Burg
Awesome! Thanks for your hard work on WebKit CI and EWS!

-Brian

> On Mar 18, 2020, at 12:12 PM, Aakash Jain  wrote:
> 
> Hello Everyone,
> 
> I have transitioned commit-queue from old EWS to new EWS. This was the last 
> queue on old EWS. I will soon start deleting old EWS code from the repository.
> 
> While transitioning the commit-queue, I have also made several improvements:
> 
> - commit-queue now supports security bugs
> 
> - commit-queue now leaves only one comment on Bugzilla (instead of two 
> previously) after successfully landing the patch
> 
> - Less bugzilla comments on failures and more readable content (no more 
> detailed logs in comments like 
> https://bugs.webkit.org/show_bug.cgi?id=207727#c10 
> ).
> 
> Also commit-queue now runs mac-wk2 tests instead of mac-wk1 tests. Please let 
> me know if you notice any issue.
> 
> Thanks
> Aakash
> ___
> 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] Tools/TestWebKitAPI

2019-02-05 Thread Brian Burg
I am in favor of a top-level Tests directory which would contain the various 
*Tests/ directories within it. Any relative directory paths (i.e., 

Re: [webkit-dev] Don Olmstead and Ross Kirsling are now WebKit reviewers

2018-12-13 Thread Brian Burg
Congrats everyone!

> On Dec 13, 2018, at 1:46 PM, Fujii Hironori  wrote:
> 
> Hi everyone,
> 
> I would like to announce that Don Olmstead (dolmstead on #webkit) and
> Ross Kirsling (rkirsling) are now WebKit reviewers. They have worked
> on WinCairo port and PlayStation port, and Ross worked on Web
> Inspector Layers Tab, too.
> 
> Please join me in congratulating Don and Ross, and send them patches
> to review.
> 
> Don and Ross, congratulations. 
> 
> - Fujii Hironori, Sony Interactive Entertainment Inc.
> 
> ___
> 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] WebKit support in web-platform-tests

2018-02-12 Thread Brian Burg
Hi Zan!

> On Feb 12, 2018, at 7:06 AM, z...@falconsigh.net wrote:
> 
> Hi,
> 
> the web-platform-tests repository includes tooling that enables running those 
> tests against a supported browser product. I'd like to propose adding generic 
> WebKit support there.
> 
> 
> Current changes only assume usage of the WebDriver protocol, and the 
> WebDriver binary accepting the --port flag. Selenium executors are used for 
> test harness and reftests. Same WebDriver implementation can also be tested 
> against the WebDriver tests included in the web-platform-tests directory, 
> presuming the tests are enabled or explicitly specified.
> 
> Only port-specific bit is the specification of capabilities that are passed 
> to the WebDriver binary, idea being that these capabilities are the same as 
> those supported by the WebDriver implementation.

Yep, these capabilities already differ between safaridriver and 
webkit[gtk]driver.

> GTK is for now the only port that's supported, and it's leveraging the 
> WebDriver implementation under Source/WebDriver/ in WebKit. WPE will be doing 
> the same. Safari I suppose could use its own WebDriver implementation, or 
> perhaps even a separate product.

Whether it makes sense depends who is running the tests. If it's for public WPT 
CI, then it won't have access to trunk safaridriver bits, so it won't be very 
useful to detect new passes or failures. If it's me or another Apple engineer 
using it to find conformance problems, then it can run against trunk 
safaridriver and be quite useful. It might also be useful to run Safari 
Technology Preview safaridriver in public CI like wpt.fyi just to have an 
independent pass/fail metric that is a lot more current (every ~2 weeks) than 
/usr/bin/safaridriver (only updates when system Safari is updated).

Currently, safaridriver implements Selenium protocol, so this will be usable 
for running WPT tests in general (modulo bugs). However, the WebDriver tests in 
web-platform-tests repository only target W3C protocol and use a custom client 
library (not Selenium). I'm currently implementing W3C protocol; when it's 
ready for public testing via Safari Technology Preview, then I will make sure 
it's possible to target a 'safari' browser via wptrunner for WebDriver 
web-platform-tests. Until then it doesn't make much sense to add it upstream as 
a target for WebDriver tests.

> Here's the current set of changes:
> https://github.com/zdobersek/web-platform-tests/commit/c2ee920876ca6df7c4739feb8a6e03c77dffdb7f
> 
> 
> The web-platform-tests suite can then be run like this for the GTK port, 
> assuming a tip-of-trunk build:
> 
> $ /work/web-platform-tests/wpt run --webkit-port=gtk \
>--webdriver-binary=WebKitBuild/Release/bin/WebKitWebDriver \
>--binary=WebKitBuild/Release/bin/MiniBrowser \
>--binary-arg=--automation \
>--binary-arg=--javascript-can-open-windows-automatically=true \
>--binary-arg=--enable-xss-auditor=false \
>webkit /2dcontext
> 
> This can be further wrapped into a python script and run as part of the 
> continuous integration system. These changes add a run-web-platform-tests 
> script that invokes the web-platform-tests runner tool, also allowing each 
> port to specify what tests to enable and what the expected failures are:
> https://github.com/Igalia/webkit/commit/df1aeeb9476c6dd220067f4fc3c6ad69a8f948ba
> 
> Only a small subset of tests is enabled there, for prototype purposes. The 
> expected results system could also be improved to avoid each expected failure 
> having to be marked as such in separate .ini files.

Carlos has a JSON-based expectations system for WPT WebDriver tests. Should we 
use that? I'm not sure if it is flexible enough to capture multiple port 
expectations. We'd probably want expectations to vary depending on enabled 
features somehow. Also, I'm not sure if we want to combine multiple port 
expectations, as this is a maintenance nightmare in the current layout test 
TestExpectation files.

> But foremost, I'd like to have a consensus of sorts about how various WebKit 
> ports should be handled in the web-platform-tests repository, so that the 
> changes there can proceed -- whether it's fine to implement a generic WebKit 
> product, or whether Safari would like to be treated as a separate browser[1], 
> etc.

For WebDriver testing purposes, I would prefer that there be a generic WebKit 
driver (uses Source/WebDriver/ and MiniBrowser) and a Safari driver (uses 
safaridriver and Safari). They are two separate REST API implementations with 
different bugs and capabilities.

It might be worth the effort to make Source/WebDriver work with MiniBrowser.app 
on Mac just for the purpose of having the entire system under test be compiled 
from one repository. However, this is generally not reflective of how 
safaridriver will perform since only the WebKit parts of WebDriver are shared 
between safaridriver and webkit[gtk]driver. It would just make it easier to run 

Re: [webkit-dev] Formatting style for inline comments in Python code

2017-10-26 Thread Brian Burg


> 2017/10/26 午前9:21、Alexey Proskuryakov のメール:
> 
> 
> 
>> 25 окт. 2017 г., в 18:21, Michael Catanzaro > > написал(а):
>> 
>> On Wed, Oct 25, 2017 at 4:58 PM, Aakash Jain > > wrote:
>>> Does anyone else has any opinion/preference for this?
>> 
>> The number of spaces before a comment really does not matter, but my $0.02: 
>> PEP8 is an extremely common style for Python programs that all Python 
>> developers are familiar with. I would follow that, and forget about trying 
>> to adapt WebKit C++ style to an unrelated language. Trying to adapt the 
>> style checker to ignore particular PEP8 rules seems like wasted effort.
> 
> 
> There is definitely a number of PEP8 rules that we want to follow. But I 
> don't think that there is anything about the two space before comment rule 
> that makes it particularly fitting for Python.

This is entirely subjective, so: why differ from the vast majority of all other 
Python code in existence, just to be different? What's the point? PEP8 
adherence is nearly universal among projects on PyPi, at least among those that 
run style linters.

> I think that we should target WebKit developers with the coding style as much 
> as possible, not Python developers. As we all agree on the one space rule 
> elsewhere, why make a part of the code base uncomfortably different for most 
> WebKit developers?

I don't understand the distinction between WebKit developers and Python 
developers. Am I not a C++ developer and web developer as well?

If "WebKit developers" want to write Python code, perhaps they should learn the 
Pythonic idioms of the language, just as they would use idioms of Perl, 
JavaScript, and C++. For better or worse, PEP8 encodes many of these idioms.

If someone already knows Python, they will be tripped up by this divergence and 
waste some minutes trying to satisfy the style checker, or just ignore it. If 
they don't know Python well, then they are being conditioned to follow some 
variant that has no benefit and is different from what they would see in any 
other Python code.

I see no value in adding arbitrary barriers to new contributions in Python 
code. The code has enough problems as-is, we don't need to make up our own for 
some pretense of consistency. We import other Python projects into the tree, 
and they follow PEP8, so what was proposed is to make the Python code in the 
tree *less* internally consistent.

> - Alexey
> 
> ___
> 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] Formatting style for inline comments in Python code

2017-10-25 Thread Brian Burg
In this case, I always prefer the PEP8 rules, because check-webkit-style will 
complain if you don't do so.

Brian

> 2017/10/25 午後0:13、Aakash Jain のメール:
> 
> Hi All,
> 
> There is one case in which Webkit style guidelines and Python style 
> guidelines do not match. This is about spacing before inline comments.
> 
> WebKit style guidelines 
> (https://webkit.org/code-style-guidelines/#comments-eol 
> ) says: "Use only one 
> space before end of line comments and in between sentences in comments."
> 
> Python PEP8 style guidelines 
> (https://www.python.org/dev/peps/pep-0008/#inline-comments 
> ) says: "Inline 
> comments should be separated by at least two spaces from the statement."
> 
> Should we use "one space" or "two spaces" before the inline comments in 
> python code inside Webkit?
> 
> Thanks
> Aakash
> 
> Reference: https://bugs.webkit.org/show_bug.cgi?id=171506 
> ___
> 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] WEB_SOCKETS enabled on all ports - let's remove the flag

2017-08-02 Thread Brian Burg
Hi WebKittens,

In WebKit, the Web Sockets API is guarded by the ENABLE_WEB_SOCKETS feature 
flag.

It seems that ENABLE_WEB_SOCKETS is turned on for Xcode and CMake build systems 
by default for several years on all ports. I think it’s time to remove the 
feature flag. Are there any objections?

If I don’t hear anything, the flag’s removal will be tracked in 
 and happen shortly.

Happy hacking,
-Brian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

2017-07-24 Thread Brian Burg
Hi WebKittens,

In WebKit, the various web-exposed timing APIs–Resource Timing, User Timing, 
and Navigation Timing are guarded by the ENABLE_WEB_TIMING feature flag.

It seems that ENABLE_WEB_TIMING is turned on for Xcode and CMake build systems 
by default, and we have not experienced any fallout from shipping these 
features in Safari Technology Preview. I think it’s time to remove the feature 
flag. Are there any objections? Is there a port in-tree that’s compiling 
without this feature?

If I don’t hear anything, the flag’s removal will be tracked in 
.

Happy hacking,
-Brian
___
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-12 Thread Brian Burg

> On May 12, 2017, at 7:31 PM, Alexey Proskuryakov  wrote:
> 
>> 
>> 12 мая 2017 г., в 16:12, Sam Weinig > > написал(а):
>> 
>> 
>> 
>>> On May 12, 2017, at 2:49 PM, Alexey Proskuryakov >> > wrote:
>>> 
>>> 
 12 мая 2017 г., в 14:38, Sam Weinig > написал(а):
 
 I regret piling on here, as I think this thread has diverged from it’s 
 original purpose, but…I understand this frustration. That said, perhaps 
 this is something we can solve with some tooling. For instance, a 
 run-test-in-safari (as a parallel to run-safari) script could be made 
 which starts the server, and then loads the test with the right URL in 
 your built Safari (or MiniBrowser, or whatever).  
>>> 
>>> 
>>> That's still not good enough, as this means that I can't point someone else 
>>> to an instance of the test on trac.webkit.org  to 
>>> reproduce an issue. There is of course be another place to point to when/if 
>>> the test gets upstreamed, but even that doesn't support stable links like 
>>> trac does.
>>> 
>>> That's not to mention that learning the name of this proposed script is no 
>>> easier than learning about run-webkit-httpd.
>>> 
>>> - Alexey
>>> 
>> 
>> 
>> I’m not sure what you mean by “good enough”.  Good enough for what?  What 
>> are we debating here?
> 
> I think that I explained it very clearly, but let me try again.
> 
> When there is a test failure that I need to communicate to others, I say 
> something "please open 
>   
> >
>  in Safari to reproduce". That's very easy to do, and makes it very easy for 
> others to work on the issue.
> If your test requires complex setup, like WPT does, then I may not have the 
> time to write up complicated steps to reproduce, or the person who gets the 
> bug may not have the time to follow them. Those people don't have a WebKit 
> checkout, so scripts won't help. This makes the test less effective, as 
> problems that it finds are less likely to be addressed.

If the person works on WebKit, then it seems unreasonable that they would do 
work without a checkout.

If they don’t work on WebKit, then you could run wptserve on a machine 
somewhere and link to that copy. We have several servers that exist solely to 
host test content, it doesn’t seem like a big deal to make one of them update 
regularly and relaunch wptserve to pick up test harness changes.

> 
> - Alexey
> 
> ___
> 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] Another WPT bite

2017-05-12 Thread Brian Burg

> On May 12, 2017, at 2:10 PM, Simon Fraser  wrote:
> 
>> 
>> On May 12, 2017, at 12:04 PM, Alexey Proskuryakov > > wrote:
>> 
>> 
>>> 12 мая 2017 г., в 11:52, Ben Kelly >> > написал(а):
>>> 
>>> On Fri, May 12, 2017 at 2:26 PM, Rick Byers >> > wrote:
>>> On Fri, May 12, 2017 at 2:06 PM, Alexey Proskuryakov >> > wrote:
>>> Since imported WPT tests are very flaky, and are not necessarily written to 
>>> defend against important regressions, investigating issues with them is 
>>> relatively lower priority than investigating issues observed with WebKit 
>>> tests. So I would recommend not mixing tests for WebKit regressions with 
>>> WPT tests - if your test eventually ends up in LayoutTests/imported, it 
>>> will become a lot less effective.
>>> 
>>> FWIW this is absolutely NOT how we're treating this in chromium.  If this 
>>> is how things end up in practice then we will have failed massively in this 
>>> effort.
>>> 
>>> We figure if we want the web to behave consistently, we really have no 
>>> choice but to treat web-platform-tests as first class with all the 
>>> discipline we give to our own tests.  As such we are actively moving 
>>>  many of our LayoutTests to 
>>> web-platform-tests and depending entirely on the regression prevention they 
>>> provide us from there.  Obviously there will be hiccups, but because our 
>>> product quality will depend on web-platform-tests being an effective and 
>>> non-flaky testsuite (and because we're starting to require most new 
>>> features have web-platform-tests before they ship), I'm confident that 
>>> we've got the incentives in place to lead to constant ratcheting up the 
>>> engineering discipline and quality of the test suite.
>>> 
>>> FWIW, mozilla also treats WPT as first class tests.  We're not actively 
>>> moving old tests to WPT like google, but all new tests (at least in DOM) 
>>> are being written in WPT.  Of course, we do have exceptions for some tests 
>>> that require gecko-specific features (forcing GC, etc).
>> 
>> 
>> We don't have a concept of "first class", but I hope that when choosing 
>> between looking into a simple test that was added for a known important bug, 
>> and looking into an imported test whose importance is unclear, any WebKit 
>> engineer will pick the former. And since no one can fix all the things, such 
>> prioritization makes imported tests less effective.
> 
> I just ran into a classic example of how a WPT incurred more overhead. I made 
> a code change that broke 
> LayoutTests/imported/w3c/web-platform-tests/cssom-view/elementFromPoint.html. 
> I tried loading it in Safari and it doesn't run the test code because it 
> can't find /resources/testharness.js when loaded from a local file.
> 
> So then I have to figure out how to fire up the WPT server 
> (run-webkit-httpd), then figure out which host to use (localhost or 
> 128.0.0.1?) and which port, and finally to figure out the right path to the 
> test.

It sound like the pain point is just getting the http:// served test open in 
the browser. This workflow can and should be automated.
Maybe it could be an option passed to run-safari that does all the setup?

One thing I have considered authoring at some point is a catchall driver script 
for launching tests in a browser, attaching lldb to a layout test or API test, 
etc. I do all these things manually right now and it makes investigating test 
failures a drag. It would easiest to start a new script for these 
debug/triaging workflows than to than to try and tack it all onto 
./Tools/Scripts/run-safari.

> There's no reason this test should not work when loaded from file://.

If it’s easy to inspect a test served over http, then I am ambivalent. Loading 
over file:// protocol can have strange consequences, especially when CORS, 
caching, and resource loading are involved.

> 
> 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


Re: [webkit-dev] Proposal to limit the size of the captured exception stack

2017-03-16 Thread Brian Burg

> On Mar 16, 2017, at 10:09 PM, Mark Lam  wrote:
> 
> Hi folks,
> 
> Currently, if we have an exception stack that is incredibly deep (especially 
> for a StackOverflowError), JSC may end up thrashing memory just to capture 
> the large stack trace in memory.This is bad for many reasons:
> 
> 1. the captured stack will take a lot of memory.

How much? What would be the new footprint with your suggestion below?

> 2. capturing the stack may take a long time (due to memory thrashing) and 
> makes for a bad user experience.
> 3. if memory availability is low, capturing such a large stack may result in 
> an OutOfMemoryError being thrown in its place.
>The OutOfMemoryError thrown there will also have the same problem with 
> capturing such a large stack.
> 4. most of the time, no one will look at the captured Error.stack anyway.
> 
> Since there isn’t a standard on what we really need to capture for 
> Error.stack, I propose that we limit how much stack we capture to a practical 
> size.  How about an Error.stack that consists of (1) the top N frames, (2) an 
> ellipses, and (3) the bottom M frames?  If the number of frames on the stack 
> at the time of capture  is less or equal to than N + M frames, then 
> Error.stack will just show the whole stack with no ellipses.  For example, if 
> N is 4 and M is 2, the captured stack will look something like this:
> 
>  foo10001
>  foo1
>  foo
>  foo9998
>  …
>  foo1
>  foo0
> 
> If we pick a sufficient large number for N and M (I suggest 100 each), I 
> think this should provide sufficient context for debugging uses of 
> Error.stack, while keeping an upper bound on how much memory and time we 
> throw at capturing the exception stack.

Web Inspector’s interface wouldn’t look too good with such a large call stack 
anyway, so this doesn’t degrade the current experience IMO. Maybe even 50+50 
would be fine. I’ve never seen a call stack that large in JS code (but then 
again, I don’t use fancy frameworks).

> My plan for implementing this is:
> 1. change Exception::finishCreation() to only capture the N and M frames, 
> plus possibly 1 ellipses placeholder in the between them.
> 2. change all clients of Exception::stack() to be able to recognize and 
> render the ellipses.
> 
> Does anyone object to doing this or have a compelling reason why this should 
> not be done?
> 
> Thanks.
> 
> 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


Re: [webkit-dev] ReadMe.md on Github

2017-02-21 Thread Brian Burg

> On Feb 21, 2017, at 10:53 PM, Ryosuke Niwa  wrote:
> 
> Hi,
> 
> I recently added ReadMe.md file to WebKit's top-level directory for the 
> convenience of Github users: https://github.com/WebKit/webkit 
> 
> 
> I've added a very abridged instruction on how to checkout & build WebKit for 
> Mac/iOS ports for simplicity. It would be great if we can trim down the 
> amount of information further.
> 
> I feel like GTK+ port's instruction can be consolidated enough to fit there 
> but we might want to write some script that someone can run to do everything 
> you need like Tools/Scripts/configure-xcode-for-ios-development for iOS first.
> 
> Let me know what you think of it, and please feel free to post a patch to 
> improve it!

This is really great Ryosuke, thanks for your work! We may want to consider a 
similar consolidation of the Trac Wiki, which is sprawling, mostly outdated, 
hard to use, and hostile to new developers/passersby.

> 
> - 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


Re: [webkit-dev] On Mac and iOS ports, you may need to trigger clean rebuilds after r203337

2016-07-21 Thread Brian Burg
It was reproducible for me, but I nuked my build directory and moved on.

Looking at the Makefile, it seems we don't prefix the bindings files with 
$(WEBCORE) so it might not even be looking at the right files.

Let's continue investigation here:

https://bugs.webkit.org/show_bug.cgi?id=160031

> On Jul 21, 2016, at 10:05 AM, Darin Adler  wrote:
> 
>> On Jul 20, 2016, at 4:08 PM, Ryosuke Niwa  wrote:
>> 
>> It looks like the binding generator doesn't re-generate .cpp files when 
>> CodeGeneratorJS.pm is modified even though that dependency is explicitly 
>> expressed in DerivedSources.make.
> 
> Is that reproducible everywhere, or only on certain systems?
> 
> If reproducible, we should be able to track down and fix it using debug mode 
> in make.
> 
> — 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] RFC: stop using std::chrono, go back to using doubles for time

2016-05-23 Thread Brian Burg
+1 to Michael’s point. Naming of variables holding seconds/milliseconds is all 
over the place.
So, I would favor using Seconds/WallTime/MonotonicTime classes, since they will 
basically
guarantee that the variable name and/or type will describe the units near 
use-sites and avoid
ambiguity.

Not to belabor Fil’s original argument against std::chrono, but the sheer 
amount of templates
necessary to express something very simple has scared away myself and plenty of 
others
from converting code away from doubles. Not to mention, it will trip up anyone 
reading the
code who hasn’t invested time reading the documentation or doing their own 
conversion.
Some of the errors Fil mentions, such as overflow, are so obfuscated by the 
type gymnastics
that the easy-to-understand class of bugs std::chrono eliminates are replaced 
with more
subtle and harder to fix overflow errors.

Brian

> On May 23, 2016, at 8:04 AM, Michael Catanzaro  wrote:
> 
> On Mon, 2016-05-23 at 07:27 -0700, Filip Pizło wrote:
>> You guys are making a convincing case for
>> Seconds/WallTime/MonotonicTime!
>> 
>> -Filip
> 
> I will add: the convention "double means seconds" is very much not
> obvious. It's OK when we're careful to consistently use "seconds" in
> function and variable names, but in practice, that's not always or even
> usually the case in WebKit code.
> ___
> 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 project repo size

2016-03-31 Thread Brian Burg
Hi Marcus,

It’s unclear what your actual problem is.

If you have trouble downloading 7GB at once due to a slow or flaky connection, 
you can fetch earlier git commits to finish the initial repository checkout, 
and then fetch more commits in batches.
If you just want a subset of the repository, I recommend you use SVN instead of 
Git. (Maybe git supports sparse checkouts these days, i dunno).
If you simply don’t like the repository layout or size, I don’t know how to put 
it politely, but it’s unlikely to change due to the low payoff and huge amount 
of work involved.

-Brian

> On Mar 31, 2016, at 12:42 PM, Marcus Johnson  
> wrote:
> 
> I use the git mirror, so I'm not sure how large the main SVN repo is, but the 
> git one is huge at like 7 GB.
> 
> I think the best way to reduce that amount of space, is by splitting out the 
> websites into their own repos, and possibly even the unit tests into their 
> own repo as well.
> 
> Also, I've had pretty good luck reducing various repo's size running git gc 
> --aggressive (it's re-compacts the .pack file) making it 5GB, so obviously 
> some more work needs to be done.
> 
> I mean, it's just ridiculous trying to download a 7 GB project just to submit 
> a few patches for memory related issues.
> ___
> 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] Proposal: Use #pragma once instead of header guards

2016-03-09 Thread Brian Burg
Cool! It sounds like something good for new headers and drive-by cleanups, to 
start.
To clarify, it would always go after the license block? Is the pragma name 
stable and understandable enough to paste everywhere?

-Brian

> On Mar 9, 2016, at 17:27, Anders Carlsson  wrote:
> 
> Hi floks,
> 
> Currently we use 
> 
> #ifndef Header_h
> #define Header_h
> 
> … 
> 
> #endif
> 
> I propose that we instead start using
> 
> #pragma once
> 
> which does the same thing. It can be faster on some compilers, is less error 
> prone and is one line instead of three! All compilers we use support #pragma 
> once.
> 
> Thoughts?
> - Anders
> 
> ___
> 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] CC on reviewed bugs

2016-01-07 Thread Brian Burg
The only reason that normal commenting will CC you is that the [X] Add me to CC 
list is checked by default.
I agree it would be reasonable to duplicate that behavior when commenting via 
the review tool.

To do this, you’d have to modify “sub update()” in attachment.cgi, and pass in 
some new parameter.
I recommend filing a bug so we can deliberate how to implement it.

-Brian

> On Jan 7, 2016, at 12:48 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> I notice that when my only comment on a bug is the comment added using
> the WebKit review feature, I do not get CCed on the bug and so do not
> notice follow-up responses to my review.
> 
> It would be awesome if auto-CC could be implemented. I always want to
> be CCed on bugs with patches I have reviewed.
> 
> Please be careful to CC yourself manually in the meantime.
> 
> 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] Use the 'EasyFix' and 'GoodFirstBug' Bugzilla keywords to mentor WebKit newcomers!

2015-12-14 Thread Brian Burg
Hello WebKittens,

At the WebKit contributors meeting, we held a session to brainstorm ways to 
increase the size of the WebKit community.
(You can see our notes on the wiki: 
http://trac.webkit.org/wiki/November%202015%20Meeting 
)

One thing that we really liked about some other projects, particularly Mozilla 
projects such as Servo, Rust, and Firefox,
is that there are bugs explicitly marked as being “Easy” or a “Good First Bug” 
in Bugzilla. I think we should try this.

Here are some reasons why this works well (and what we should try to emulate):

- Bugs are flagged by experienced contributors who are familiar with the 
feature or component in question. Identifying
a good place to start is a big deal: in practice, most Bugzilla instances are 
chockfull of stale, misleading, or outright wrong
bug reports and tasks, and WebKit’s Bugzilla is no exception. Even if 
components and bugs were always current, there
are simply thousands of real, actionable tasks which are hard for new 
contributors to judge without domain expertise.
In WebKit’s Bugzilla instance, we are going to use the GoodFirstBug and EasyFix 
keywords to track such bugs.

Once some mentored bugs exist, we may want to think about setting up a gateway 
like Bugs Ahoy! to make searching easier.

- Every bug marked GoodFirstBug or EasyFix has a designated “bug mentor” who 
can help a new contributor get up to speed.
There is a lot of process to be learned to fix even a trivial bug: getting the 
code, building, making changes, writing tests,
creating and uploading a patch, going through review, and getting changes in 
the tree. In my experience, new folks are happy
to read and write code, but are easily discouraged from finishing a patch 
because of these barriers. A mentor helps coach
and encourage a new contributor through these parts of the process. Some 
Bugzilla instances have a field for this; for
now, just ensure a mentor (you or someone else) is CC’d and responsive to 
questions from the contributor on Bugzilla.

- A potential fix for a good first bug should be straightforward, described in 
Bugzilla, and be covered by new or existing tests.
This allows a new contributor to achieve a development feedback loop as to 
whether their changes have correct behavior without
requiring extra effort on the part of mentors. It also educates and instills 
good habits, like writing tests alongside (or even before!) making changes.

- Patches from new contributors are reviewed quickly and regularly. Getting 
quick feedback is essential to retaining interest
and momentum, especially for contributors without an economic motivation (i.e, 
a job) or long-term history with the project.
Feedback should be actionable and constructive. It’s much better to mark a 
patch as review- unless it’s ready to land, than to
let a patch linger with open questions and the review? flag set. This 
discourages new contributors since the next step is unclear.

Remember, good first bugs serve primarily as an introduction to the process of 
contributing code changes, so they may not
be particularly interesting to an experienced contributor. Ramping up new 
contributors takes time and effort, but it’s worth it.


Have any questions? Feel free to respond, find us on #webkit IRC, or contact 
myself or Jon Davis.

-Brian

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


Re: [webkit-dev] Preferred style for checking for undefined in our built-in JavaScript code?

2015-11-30 Thread Brian Burg
Web Inspector’s frontend code tends to use “x === undefined”, as we’ve found it 
the easiest to read.

> On Nov 30, 2015, at 11:57 AM, Geoffrey Garen  wrote:
> 
> For the time being, I like “x === undefined”.
> 
> Long term, I’d like us to switch to “x === @undefined”.
> 
> We use @ to indicate reserved words in built-ins. Currently, “@undefined" 
> does not exist, but the built-in compiler magically transforms “undefined” a 
> safe reserved word.
> 
> The typeof and void 0 code should be fast, but I find it obtuse.
> 
> Geoff
> 
>> On Nov 30, 2015, at 11:39 AM, Filip Pizlo  wrote:
>> 
>> I’ve also been guilty of:
>> 
>>  if (xxx === void 0)
>> 
>> This is slightly better than saying “undefined”, since that’s not actually a 
>> reserved word.
>> 
>> I believe that all of these should perform the same.  We should pick one 
>> based on what looks nicest and what has the most clear semantics.
>> 
>> -Filip
>> 
>> 
>> 
>>> On Nov 30, 2015, at 11:37 AM, Darin Adler  wrote:
>>> 
>>> I see the following in some code:
>>> 
>>>  if (xxx === undefined)
>>> 
>>> And I see the following in some other code:
>>> 
>>>  if (typeof xxx == “undefined”)
>>> 
>>>  or
>>> 
>>>  if (typeof xxx === “undefined”)
>>> 
>>> Is one preferred over the other, style-wise? Is one more efficient than the 
>>> other?
>>> 
>>> — 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


[webkit-dev] OUTAGE: Bugzilla not sending emails properly

2015-11-17 Thread Brian Burg
Hi all,

We’ve been getting reports that Bugzilla has not sent any mail out in the past 
24 hours. :-(
The server admins are investigating what’s up and will send out an email when 
it’s fixed.

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


Re: [webkit-dev] OUTAGE: Bugzilla not sending emails properly

2015-11-17 Thread Brian Burg
After some debugging and fixing, Bugzilla email seems to be working again. We 
apologize for the disruption!

> On Nov 17, 2015, at 10:07 AM, Brian Burg <bb...@apple.com> wrote:
> 
> Hi all,
> 
> We’ve been getting reports that Bugzilla has not sent any mail out in the 
> past 24 hours. :-(
> The server admins are investigating what’s up and will send out an email when 
> it’s fixed.
> 
>   -Brian
> ___
> 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] Youenn Fablet is now a WebKit reviewer

2015-10-26 Thread Brian Burg
Congrats Youenn!

> On Oct 26, 2015, at 19:15, Mark Lam  wrote:
> 
> Hello everyone,
> 
> I would like to announce that Youenn Fablet is now a WebKit reviewer.  Please 
> send him your congratulations, and some requests for patch reviews too. :-)
> 
> Youenn, congratulations.
> 
> 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


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

2015-10-02 Thread Brian Burg
If this reproduces on tip-of-tree WinCairo in the WebKit repository, then you 
should file a Web Inspector/WinCairo bug in Bugzilla and continue this 
discussion there.
I really have no way of knowing what’s going on just by reading these steps. 
You could also try reaching the relevant folks on IRC (#webkit or 
#webkit-inspector).

-Brian

> On Oct 2, 2015, at 1:29 PM, Vienneau, Christopher  wrote:
> 
> Hey Guys,
>  
> I’m redirecting Rupali’s enquiry about WebInspector’s Debugger and WinCairo 
> to a new audience.  I came across this again the other day, I think all the 
> debug information Rupali provided is still accurate for our current state.  
> In brief, when a breakpoint is hit in the debugger the pane that should show 
> the source gets stuck as a circular time spinner.  This blocks a lot of 
> functionality sine you can’t see what you’re debugging.  We would appreciate 
> any tips on how to resolve this in WinCairo since our port behaves the same 
> way.
>  
> Thanks
>  
> Chris
>  
> From: webkit-help-boun...@lists.webkit.org 
>  
> [mailto:webkit-help-boun...@lists.webkit.org 
> ] On Behalf Of Sharma, Rupali
> Sent: Monday, August 31, 2015 11:34 AM
> To: Sharma, Rupali >; 
> webkit-h...@lists.webkit.org 
> Subject: Re: [webkit-help] Issue with Web Inspector debugger breakpoint 
> handling (on Wincairo)
>  
> Hi folks,
>  
> Are you aware of this issue with web Inspector which we see on WinCairo?
>  
> Thanks,
> Rupali
>  
> From: webkit-help-boun...@lists.webkit.org 
>  
> [mailto:webkit-help-boun...@lists.webkit.org 
> ] On Behalf Of Sharma, Rupali
> Sent: Wednesday, August 26, 2015 11:16 AM
> To: webkit-h...@lists.webkit.org 
> Subject: [webkit-help] Issue with Web Inspector debugger breakpoint handling 
> (on Wincairo)
>  
> Hello,
>  
> We are seeing an issue with the Web Inspector debugger on latest WinCairo [ 
> using Webkit r188436]. In the wincairo webinpector, whenever a breakpoint is 
> set and then web page reload on a javascript source, the view goes on into 
> some indefinite waiting and never shows up, until we press 
> continue-script-execution or another page-refresh.
>  
> Here are the simple steps to reproduce it,
> 1.   Launch WinCairo and go to google.com 
> 2.   Open Web inspector and open the script source of any .js script
> 3.   Set a breakpoint anywhere
> 4.   Reload the web page
>  
> What we see is the spinner spinning and never the script source. However, if 
> one presses continue-script-execution from the debugger controls, we get the 
> view back.
>  
> Some points of debugging we did at our end,
> (i) We did some digging around the breakpoint setting, and do see the flow 
> correctly being going to handlepause() of the ScriptDebugServer. Though I see 
> the vmEntryGlobalObject is not updated with any value or callframe.
> I did not see any abnormality in the listener dispatching callback, with the 
> correct pause-reason to pass i.e. Breakpoint. However, I am not sure if its 
> sending the right pause-data to the frontend.
>  
> (ii)It gets stuck in the infinite eventloop which does look fine to me, as 
> long as it is paused.
>  
> (iii)Another observation I see is, the message “TimelineRecordingStopped” 
> being sent to the frontend. I believe, this is something newly added and not 
> sure, if at all it’ll effect the debugger scriptsource in any way. [reference 
> : doDispatchMessageOnFrontendPage]
>  
> (iv)Coming onto the Web inspector UI side of story, I did see one bug, that 
> even though  the method in DebuggerManager.js  “debuggerDidPause” got the 
> right pause-reason from the webkit, its not able to pass on correctly due to 
> an apparent bug in
> _pauseReasonFromPayload: function(payload)
> Here, the input payload does not match any of the  DebuggerAgent.PausedReason 
> and hence falls to the error of unknown reason. The correct string to match 
> would be “Breakpoint”. However, correcting the flow still doesn’t give us any 
> favorable behavior. Though, I believe it’s good to know.
>  
> Would you have a better insight as to what exactly is blocking the script 
> source to display in the paused-state of web inspector debugger?
>  
> The output log looks like:
> EAWebKit:Event kLETResourceResponseReceived : The server has responded to a 
> resource request URL - http://www.google.com/  with 
> status = 200
> EAWebKit:Event kLETLoadCompletedWithoutErrors : The load is completed without 
> errors
> Total Page Loaded : 1.139
> Total Page Lib Tick Update  : 
> 0.604  Slowest:: 0.521
> Total Page View Tick Update

Re: [webkit-dev] Bugzilla default assignees

2015-09-14 Thread Brian Burg
It should be possible for an administrator to set a component's default 
assignee and default cc: list. We use the default-cc approach for the Web 
Inspector component (though it often goes out of date).

However, the default assignee approach seems nice from a self-service POV, and 
we don’t seem to rely on the assignee field too much in the WebKit bugzilla. 
What do others think?

Brian

> On Sep 12, 2015, at 4:48 PM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> In WebKit Bugzilla the default assignee for all bugs is Nobody. This is
> problematic because it makes it really hard to notice when new bugs are
> filed against a particular component. For example, I want to be CCed on
> all new bugs in the WebKit Gtk component. If there was a fake default
> assignee, say webkit-gtk-ma...@webkit.bugs, then I could just add that
> email to the User Watching section under my Email Preferences, and I'd
> notice whenever a bug in that component is filed or changes state. This
> is what we do in GNOME Bugzilla and it works quite well.
> 
> Since we don't have that, what I've been doing is watching Carlos
> Garcia, which is a decent approximation since he tends to get CCed on a
> lot of bugs. :) But only regular contributors know to CC him, so if the
> bug isn't filed by a regular contributor, nobody ever sees it.
> 
> If a Bugzilla admin could set up default assignees for the various
> components (or at least the WebKit Gtk component, but it would be
> useful for all of them), that would be awesome.
> 
> 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] Fwd: *.webkit.org network issues

2015-05-18 Thread Brian Burg
Possibly related, bugs.webkit.org http://bugs.webkit.org/ was timing out and 
returning HTTP 500 internal server errors over the weekend (from Comcast). It 
works for me now, though.

 On May 18, 2015, at 10:00 AM, Ryosuke Niwa rn...@webkit.org wrote:
 
 On Mon, May 18, 2015 at 9:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu 
 mailto:o...@inf.u-szeged.hu wrote:
 *.webkit.org http://webkit.org/ sites (trac,bugs,build) are extremely slow
 from here (Europe/Hungary) and I didn't get any bugzilla
 mail 2 days ago, but I should have got many.
 
 Is it a known issue and/or is anybody working on the fix?
 
 FYI, I've been accessing webkit.org http://webkit.org/ via Comcast (U.S. 
 cable company) and I haven't observed any network issues like that.
 
 Yusuke, could you tell us whether you've been experiencing any issues with 
 webkit.org http://webkit.org/ in Japan?
 
 - 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


Re: [webkit-dev] Planning on Requiring Python 2.7 Soon

2014-09-11 Thread Brian Burg
IIRC, some GTK bots still run Python 2.6. (But not all of them?)
Here’s a relevant workaround I landed a while ago:

 http://trac.webkit.org/changeset/172686

On Sep 10, 2014, at 4:31 PM, Brent Fulgham bfulg...@apple.com wrote:

 Hi Everyone,
 
 Now that I’ve worked through the minor issues that prevented us from using 
 Python 2.7 on our Windows bots, I’d like to move the goalposts and require 
 Python 2.7 (or newer) for our build and test machines.
 
 Will this cause anyone any problems if this becomes the new law of the land?
 
 I plan on making this change on September 17th if I do not hear from anyone 
 on this topic.
 
 Thanks!
 
 -Brent
 ___
 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] Announcement: web replay support

2014-01-13 Thread Brian Burg
Hello all,

I’m excited to announce that I’ve begun work on upstreaming web replay support 
into WebKit. Web replay functionality allows developers to debug their web 
applications by exactly recording interactions with a web program, and then 
replaying the resulting execution at will. A prototype implementation has 
integration with the Web Inspector, and supports many important web features.

Most replay-related code will be behind the ENABLE(WEB_REPLAY) flag. It will be 
off by default until folks feel that the feature is ready for feedback through 
nightly builds.

A high-level technical description of the prototype is available in the 
following paper:
http://homes.cs.washington.edu/~mernst/pubs/record-replay-uist2013.pdf

There’s also short demo video from last year:
http://www.youtube.com/watch?v=ugHAzyQ6H00

Some accumulated details are on the prototype's wiki:
https://github.com/burg/timelapse/wiki


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


Re: [webkit-dev] Announcement: web replay support

2014-01-13 Thread Brian Burg
The timeline will certainly be important part of the UI (pretty much the only 
constant element in the various UI prototypes), but we haven’t figured out the 
specifics yet. The timeline views are under active development.

On Jan 13, 2014, at 4:15 PM, Benjamin Poulain benja...@webkit.org wrote:

 On 1/13/14, 4:03 PM, Brian Burg wrote:
 I’m excited to announce that I’ve begun work on upstreaming web replay
 support into WebKit. Web replay functionality allows developers to debug
 their web applications by exactly recording interactions with a web
 program, and then replaying the resulting execution at will. A prototype
 implementation has integration with the Web Inspector, and supports many
 important web features.
 
 Most replay-related code will be behind the ENABLE(WEB_REPLAY) flag. It
 will be off by default until folks feel that the feature is ready for
 feedback through nightly builds.
 
 That is great!
 
 Where will the tool be integrated in the Inspector? Will it be an extension 
 of the timeline or a new tab?
 
 Benjamin
 ___
 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