Re: [webkit-dev] Windows Bots Are Green!

2015-02-23 Thread Adam Roben
 Over the past few weeks I’ve spent a considerable amount of time reviewing
 and correcting a number of problems with the Windows testing infrastructure.

 We were skipping thousands of tests, including Accessibility, http tests,
 and large sections of forms, css, and svg tests. Some tests were skipped
 because features were supposedly incomplete, but in the years since the skip
 entry was added to the file, the work had been completed and feature worked
 perfectly well. Some tests were skipped simply because feature flags had
 never been enabled on Windows.

 Happily, all of this is in the past. Now that this work is complete, we have
 much more test coverage of many areas of WebKit that had been previously
 ignored on this platform.

Nice work!

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


Re: [webkit-dev] When to use auto? (I usually consider it harmful)

2014-01-02 Thread Adam Roben
I found 
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
very persuasive in my thinking about when to use auto.

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


Re: [webkit-dev] About USE(CROSS_PLATFORM_CONTEXT_MENUS)

2013-02-25 Thread Adam Roben
 I was having a look at our Context Menu design when this USE flag got
 my attention. Can someone help me clarify the motivation for it?

The motivation is explained pretty well in the ChangeLog for r73802,
which introduced this flag. I'll try to give a little explanation here
too.

CROSS_PLATFORM_CONTEXT_MENUS changes WebCore::ContextMenu and
WebCore::ContextMenuItem from being thin wrappers around a
platform-specific context menu and context menu item, to being full
cross-platform representations of a menu and menu item. In this new
model, most code will only ever deal with the cross-platform types;
platform-specific menus and menu items should only be created as
needed (e.g., when actually showing the menu on screen, or when
passing a native menu up to the embedding application, as happens in
the Apple WebKit[2] APIs). Providing a true cross-platform
representation of menus and menu items makes many things simpler,
including being able to serialize menus and send them across process
boundaries.

This last point was the immediate motivation for
CROSS_PLATFORM_CONTEXT_MENUS: we needed to send context menus from the
web process to the UI process to support context menus in WebKit2 on
Windows. But the hope was that all ports would switch over to this
model eventually.

 It seems that only PLATFORM(WIN) is using it, but I'm not sure if for
 both WK1 and WK2...

WIN uses it for both WK1 and WK2.

 Also, is there any other port using it?

I don't believe so. But if you look at ContextMenu[Item].h, it looks
like CHROMIUM and EFL could very easily switch over to it; they've
already implemented something very similar by abusing the
PlatformMenuItemDescription typedef.

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


Re: [webkit-dev] Version control survey results

2013-02-18 Thread Adam Roben
 (For current svn users I assume using svn would become effectively 
 impossible; the only tool I could find to do this is server-side and 
 essentially maintains git and svn repositories in parallel.)

FYI, any Git repository on GitHub also functions as a Subversion repository:

$ svn checkout https://github.com/WebKit/webkit/trunk WebKit
AWebKit/.dir-locals.el
AWebKit/.gitattributes
AWebKit/.gitignore
AWebKit/.qmake.conf
AWebKit/CMakeLists.txt
AWebKit/ChangeLog
AWebKit/ChangeLog-2012-05-22
AWebKit/Examples
AWebKit/Examples/ChangeLog
AWebKit/Examples/NetscapeCocoaPlugin
AWebKit/Examples/NetscapeCocoaPlugin/English.lproj
AWebKit/Examples/NetscapeCocoaPlugin/English.lproj/InfoPlist.strings
AWebKit/Examples/NetscapeCocoaPlugin/Info.plist
AWebKit/Examples/NetscapeCocoaPlugin/MenuHandler.h
AWebKit/Examples/NetscapeCocoaPlugin/MenuHandler.m
…

You can even use Subversion branches to create pull requests on GitHub
(though I don't know what the performance would be like for a
repository as large as WebKit):
https://github.com/blog/1178-collaborating-on-github-with-subversion.
GitHub doesn't currently make the Subversion-Git bridge available
for non-GitHub repositories.

I don't say this to try to convince anyone to switch to Git or GitHub;
I just thought it seemed relevant.

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


Re: [webkit-dev] sln files with wrong line endings

2013-02-14 Thread Adam Roben
I'm pretty sure r142864 fixed this (perhaps unintentionally) by
changing all line endings in DumpRenderTree.sln from CRLF to LF.

On Thu, Feb 14, 2013 at 11:11 AM, Darin Adler da...@apple.com wrote:
 Typically in Subversion the fix for a problem like this is to set the 
 eol-style explicitly; presumably to CRLF for Windows project and solution 
 files and to LF or native for plain old source files. Once that property is 
 set, people changing file later on can’t cause problems with inconsistent 
 line endings, because Subversion will check the line endings at commit time.

 I have no idea how having git in the mix affects this.

WebKit's .gitattributes file contains the following:

*.vcproj eol=crlf
*.vsprops eol=crlf
*.sln eol=crlf

This tells git, When storing this file in the repository, convert all
line endings to LF. When checking out this file to disk, convert all
line endings to CRLF.

If the committed version of the file in the repository contains CRLF
line endings, git will show a diff that converts the CRLF line endings
to LF. eol=crlf means that the line endings *in the repository* should
be LF, so git is trying to fix it.

I think the thing to do is to set svn:eol-style to native for all
.vcproj, .vsprops, and .sln files. That way Subversion will commit the
files using LF line endings (like git wants), and check them out using
CRLF on Windows (like Visual Studio wants).

 In fact, I don’t know how to set a Subversion property using git-svn which 
 means I can’t easily just jump in and fix this like I would have in the past.

I don't think git-svn can set properties. When I've had to change
properties in the past I've checked out the appropriate subset of
WebKit using Subversion and made my changes there.

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


Re: [webkit-dev] EditBug permission

2012-05-04 Thread Adam Roben
 Could someone please add EditBug permission to my bugs.webkit.org 
 (http://bugs.webkit.org/) account?


Done.

-Adam


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


Re: [webkit-dev] github mirror

2012-04-24 Thread Adam Roben
On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann
simon.hausm...@nokia.com wrote:
 On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
 Hi WebKit,

 I've been using a fork of the following repo:
 https://github.com/WebKit/webkit

 However, yesterday there was discussion on #webkit that the SHA-1 checksums
 on this repo are different from repo at git.webkit.org, which means folks
 working on both need to have both versions checked out.

 I believe the reason for them being different is because in the github repo 
 the
 commit author fields are resolved.

That looks correct to me:


$ diff -u (GIT_DIR=WebKit/.git git cat-file -p
df242ce698c19b591e975d88c29f7411b2f2963d) (GIT_DIR=GitHubWebKit/.git
git cat-file -p 93f4255f7cb09996f0a9a354754c7902da87d1a3)
--- /dev/fd/63  2012-04-24 09:01:56.0 -0400
+++ /dev/fd/62  2012-04-24 09:01:56.0 -0400
@@ -1,7 +1,7 @@
 tree 492d5271473c516151a406aa02ebdbf1b494e758
-parent 1973d7515628dd8a4b3dd7559f0b0e2073096590
-author kl...@webkit.org
kl...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc 1335221533
+
-committer kl...@webkit.org
kl...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc 1335221533
+
+parent 9e00d90f6474a88108fe9d875d80ba2c04302733
+author Andreas Kling kl...@webkit.org 1335221533 +
+committer Andreas Kling kl...@webkit.org 1335221533 +

 [Mac] WebProcess should empty cache on a background thread/block.
 http://webkit.org/b/84619

You can see above that the tree and commit message are identical
between the two repositories. But the author and committer are
different, which causes the commit hash to be different (and since
this is true for older commits as well, the parent hash is different
too).

-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] github mirror

2012-04-24 Thread Adam Roben
Well that turned out ugly. Let's try again:

$ diff -u (GIT_DIR=WebKit/.git git cat-file -p
df242ce698c19b591e975d88c29f7411b2f2963d) (GIT_DIR=GitHubWebKit/.git git
cat-file -p 93f4255f7cb09996f0a9a354754c7902da87d1a3)
--- /dev/fd/63 2012-04-24 09:01:56.0 -0400
+++ /dev/fd/62 2012-04-24 09:01:56.0 -0400
@@ -1,7 +1,7 @@
 tree 492d5271473c516151a406aa02ebdbf1b494e758
-parent 1973d7515628dd8a4b3dd7559f0b0e2073096590
-author kl...@webkit.org
kl...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc
1335221533 +
-committer kl...@webkit.org
kl...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc
1335221533 +
+parent 9e00d90f6474a88108fe9d875d80ba2c04302733
+author Andreas Kling kl...@webkit.org 1335221533 +
+committer Andreas Kling kl...@webkit.org 1335221533 +

 [Mac] WebProcess should empty cache on a background thread/block.
 http://webkit.org/b/84619

-Adam

On Tue, Apr 24, 2012 at 9:03 AM, Adam Roben aro...@webkit.org wrote:
 On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann
 simon.hausm...@nokia.com wrote:
 On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
 Hi WebKit,

 I've been using a fork of the following repo:
 https://github.com/WebKit/webkit

 However, yesterday there was discussion on #webkit that the SHA-1
checksums
 on this repo are different from repo at git.webkit.org, which means
folks
 working on both need to have both versions checked out.

 I believe the reason for them being different is because in the github
repo the
 commit author fields are resolved.

 That looks correct to me:


 $ diff -u (GIT_DIR=WebKit/.git git cat-file -p
 df242ce698c19b591e975d88c29f7411b2f2963d) (GIT_DIR=GitHubWebKit/.git
 git cat-file -p 93f4255f7cb09996f0a9a354754c7902da87d1a3)
 --- /dev/fd/63  2012-04-24 09:01:56.0 -0400
 +++ /dev/fd/62  2012-04-24 09:01:56.0 -0400
 @@ -1,7 +1,7 @@
  tree 492d5271473c516151a406aa02ebdbf1b494e758
 -parent 1973d7515628dd8a4b3dd7559f0b0e2073096590
 -author kl...@webkit.org
 kl...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc 1335221533
 +
 -committer kl...@webkit.org
 kl...@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc 1335221533
 +
 +parent 9e00d90f6474a88108fe9d875d80ba2c04302733
 +author Andreas Kling kl...@webkit.org 1335221533 +
 +committer Andreas Kling kl...@webkit.org 1335221533 +

  [Mac] WebProcess should empty cache on a background thread/block.
  http://webkit.org/b/84619

 You can see above that the tree and commit message are identical
 between the two repositories. But the author and committer are
 different, which causes the commit hash to be different (and since
 this is true for older commits as well, the parent hash is different
 too).

 -Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] github mirror

2012-04-24 Thread Adam Roben
On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@webkit.org wrote:

 (from correct address)

 On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@sencha.comwrote:

 On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann 
 simon.hausm...@nokia.com wrote:

 On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:
  Hi WebKit,
 
  I've been using a fork of the following repo:
  https://github.com/WebKit/webkit
 
  However, yesterday there was discussion on #webkit that the SHA-1
 checksums
  on this repo are different from repo at git.webkit.org, which means
 folks
  working on both need to have both versions checked out.

 I believe the reason for them being different is because in the github
 repo the
 commit author fields are resolved.


 Yeah that's totally it.  So svn.webkit.org = git.webkit.org = github
 would need to be the mirroring strategy.  Sounds dicey :)


I don't see what would be dicey about it. The svn.webkit.org -
git.webkit.org step is the fragile one; after that it's just a simple git
push to get things over to GitHub. This sounds like a pretty good approach
to me, though of course it will cause some havoc for people who have
already been doing work using the current GitHub repository.

-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)

2012-04-24 Thread Adam Roben
On Fri, Mar 16, 2012 at 5:40 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Mar 16, 2012 at 2:32 PM, Ryosuke Niwa rn...@webkit.org wrote:
  Can we do some Bugzilla integration as Jarred suggested?

 If you're excited about using GitHub, you should feel free to do that work.

It sounds like there is already work going on on GitHub (e.g., the
iframe seamless support) even though this integration hasn't yet
been built. I echo Ariya and Ryosuke's concern that the reduced
visibility of that work makes it harder for WebKit contributors to
provide feedback, or even to realize that the work is going on. Is
there anyone working on improving the integration between GitHub and
our current tools so that work that occurs there can be as easily
discovered as work that goes on in bugs.webkit.org?

-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] github mirror

2012-04-24 Thread Adam Roben
On Tue, Apr 24, 2012 at 9:49 AM, Tor Arne Vestbø
tor.arne.ves...@nokia.com wrote:
 On 18.04.12 17:02, Simon Hausmann wrote:

 On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote:

 Hi WebKit,

 I've been using a fork of the following repo:
 https://github.com/WebKit/webkit

 However, yesterday there was discussion on #webkit that the SHA-1
 checksums
 on this repo are different from repo at git.webkit.org, which means folks
 working on both need to have both versions checked out.


 I believe the reason for them being different is because in the github
 repo the
 commit author fields are resolved.


 That's correct. I'm the one running that mirror (along with the one at
 gitorious.org/webkit), and the import is done using an author-script that
 resolves author names and emails for a nicer history. The commit objects
 will be different, hence the different sha1s, but the tree and blob objects
 are the same.

 In what situation does this cause issues?

Probably the biggest issue is for people who've been using
git.webkit.org and now want to try out GitHub. Since the commits are
distinct between the two repositories, they have to do a full clone to
make the switch.

-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Some doubt about PluginView in WebCore

2011-12-20 Thread Adam Roben
On Dec 20, 2011, at 7:23 AM, huangxueqing wrote:

 As guys know, there two implement of plug-in in webkit, the first is located 
 in WebKit/WebProcess/plugins and another in WebCore/plugins, safari5 use 
 former and Chromium implement plug-in in separate process in 
 webkit/support/glue/plugins.
 I want to know WebCore/plugins whether be maintained in future? Currently, it 
 seems windowless plug-in has some problem in WebCore/plugins, for instance, 
 PluginView::setNPWindowRect do nothing although m_npWindow.window is NULL, 
 but WebKit/WebProcess/plugins hook |TrackPopupMenu| and chromium call a GDI 
 api |CreateCompatableDC|. I have commit a bug about this  
 https://bugs.webkit.org/show_bug.cgi?id=74917.
 Actually, we hope WebCore/plugins be maintained since most base-on webkit 
 browser use it except chromium. Anyway, I found lots of bug about plug-in, I 
 will commit these in later.

I think Anders Carlsson (who wrote the original implementations of both 
WebCore's and WebKit2's plugins support) would like to see the WebKit2 code 
replace the WebCore code eventually. The WebKit2 code is well-suited to running 
either in-process or out-of-process. Perhaps Chromium could even adopt it 
eventually.

Any bugs you find should be filed at http://webkit.org/new-bug. Thanks!

-Adam

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


Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)

2011-12-05 Thread Adam Roben
On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote:

 The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still 
 !?!).

I suspect our Mac test bots could use a dose of RAM. Many of them only have 
3GB, since when you're running tests one by one you don't really need much more.

-Adam

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


Re: [webkit-dev] [GTK] Buildslave changes

2011-11-30 Thread Adam Roben
On Nov 30, 2011, at 4:34 PM, Philippe Normand wrote:

 Can we get new buildbot credentials for the new slave or can we reuse
 the 32-bits Debug ones? It'd be great if we can coordinate on this
 migration soon :)

Credentials are a slave name/password pair. If you're using the old slave name 
for the new machine then you should use the old password too.

If you're adding a new slave name, you should post a patch to bugs.webkit.org 
to do so and CC me. Once the patch lands I'll update the master and send you a 
password.

-Adam


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


Re: [webkit-dev] failed to upload a patch to bugs.webkit.org by webkit-patch!

2011-11-28 Thread Adam Roben
On Nov 28, 2011, at 10:13 AM, Hongbo Min wrote:

 Failed to assign bug to you (can't find assigned_to) control.
 Do you have EditBugs privileges at bugs.webkit.org?
 https://bugs.webkit.org/userprefs.cgi?tab=permissions
 
 If not, you should email webkit-committ...@lists.webkit.org or ask in #webkit
 for someone to add EditBugs to your bugs.webkit.org account.
 

This is the key. You don't have the EditBugs privilege. I've now given you this 
privilege.

-Adam

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


Re: [webkit-dev] Hanging builds

2011-11-28 Thread Adam Roben
On Nov 26, 2011, at 3:34 AM, Nikolas Zimmermann wrote:

 Good morning WebKit folks,
 
 I'm looking at build.webkit.org/waterfall, and see several bots which are 
 idle, but still report building  1min pretending they would do something.
 Does any of our build.webkit.org masters know the cause of this? They all 
 seem to hang in the upload step. Can we detect these errors, and avoid that?
 Maybe sth. like a 30min timeout timer for this step?
 
 Thanks in advance,
 Niko
 
 P.S. I'm aware that a master restart would fix this, but maybe we can try 
 better and avoid that completely.

More and more of these seemed to be piling up, so I restarted the master. I 
don't know what causes them, though I suspect it has something to do with 
slaves restarting during a download/upload step.

-Adam

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


Re: [webkit-dev] 8 Bit Strings Turned On in JavaScriptCore

2011-11-18 Thread Adam Roben
On Nov 18, 2011, at 2:14 PM, Michael Saboff wrote:

 Although the UChar* characters() method for the various string classes still 
 works, all new code should check what flavor a string is constructed by 
 using the new is8Bit() method on the various string classes.  After 
 determining the flavor, a call to either LChar* characters8() or UChar* 
 characters16() as appropriate should be done to access the raw characters of 
 a string.  The call to characters() on an 8 bit string will create a 16 bit 
 buffer and convert the native 8 bit string, keeping the conversion for future 
 use, before returning the 16bit result.  Obviously the expense of this 
 conversion grows with a string's length and it increases the memory footprint 
 beyond what was required by the original 16 bit string implementation.

I wonder what we could do to make it more obvious what the correct usage is. 
For example, we could rename characters() to make it clear that it might 
allocate a new buffer. And we could make it an error to call characters8() or 
characters16() on the wrong kind of string.

-Adam

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


[webkit-dev] Could use some help from SVG and Web Workers experts on leak hunting

2011-11-18 Thread Adam Roben
Hi all-

Darin Adler's been helping me sift through the leaks we're seeing on the Lion 
Intel Leaks bot. (You can see the results of a recent run here: 
http://build.webkit.org/LeaksViewer/?url=%2Fresults%2FLion%20Intel%20Leaks%2Fr100768%20%28193%29%2F.)
 We could use some expert advice for two of the leaks we're seeing:

https://bugs.webkit.org/show_bug.cgi?id=72741
Leaks beneath RenderSVGShadowTreeRootContainer::updateFromElement seen on Leaks 
bot

https://bugs.webkit.org/show_bug.cgi?id=72745
Leaks beneath SharedWorker::create seen on Leaks bot

Any comments from folks familiar with those parts of the code would be 
appreciated!

-Adam

P.S. Another interesting leak we're seeing is:

https://bugs.webkit.org/show_bug.cgi?id=56673
Leak of DocumentLoader seen on Leaks bot

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


Re: [webkit-dev] NRWT Migration Update

2011-10-21 Thread Adam Roben
On Oct 21, 2011, at 7:33 AM, Eric Seidel wrote:

 The WK2 bot looks stable (possibly more stable than before) after the
 NRWT switchover:
 http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r98091%20(15558)/results.html

Awesome!

 I'll work on switching the --leaks bot back to NRWT next week, and
 then the only remaining builder to switch is Apple's Windows.  (I
 likely won't be able to takle that one myself.)

I will hopefully be able to help get Windows switched over.

-Adam

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


Re: [webkit-dev] NRWT Migration Update

2011-10-21 Thread Adam Roben
On Oct 21, 2011, at 9:41 AM, SravanKumar Sandela wrote:

 Can you please inform us, what are the major difference between NRWT and 
 ORWT. I think it would of lot help for people like me who worked on ORWT long 
 back and now to catch up with NRWT.

This page gives a good explanation: 
http://trac.webkit.org/wiki/NewRunWebKitTests

-Adam

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


Re: [webkit-dev] Style guide should mention that we don't use anonymous namespace

2011-10-20 Thread Adam Roben
On Oct 19, 2011, at 9:56 PM, Ryosuke Niwa wrote:

 On Wed, Oct 19, 2011 at 6:32 PM, Adam Barth aba...@webkit.org wrote:
 On Wed, Oct 19, 2011 at 6:24 PM, Ryosuke Niwa rn...@webkit.org wrote:
  Also... VC++'s debugger happens to have some issues around unnamed
  namespaces:
  http://msdn.microsoft.com/en-us/library/0888kc6a%28VS.80%29.aspx
 
  Don't recall if this affected classes inside unnamed namespace though.
  I think VC++ 2005's support for unnamed namespace is better than nested
  classes (cl.exe has some serious bugs in resolving nested class names) so if
  our only alternative to unnamed namespace is nested classes, then I'd much
  prefer unnamed namespace.
  Adam, do you recall any compiler/debugger issues with classes inside unnamed
  namespace on VC++ 2005?
 
 Nope, but I haven't used VC 2005 in many years.
 
 Oops, sorry I meant to cc A. Roben. Adam (R), do you remember any issues with 
 unnamed namespace?

I don't, but that's mostly because we don't use them much so I don't have much 
experience with them!

-Adam


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


Re: [webkit-dev] Reg: Build break on latest Trunk!

2011-10-12 Thread Adam Roben
On Oct 12, 2011, at 3:15 AM, just2 contribute wrote:

 Has anybody tried building the latest webkit-trunk for Safari on windows?
  
 I am getting some build errors while building WebCore :)
  
 Can anybody share the latest working SVN Revision Number that I can try?

http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 says that the 
last revision the bots built was r97252. http://trac.webkit.org/ says that 
that's the latest checked-in revision.

In general you can assume that any recent revision builds on Windows. You can 
double-check with the bots if you'd like.

-Adam

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


Re: [webkit-dev] Features defines: Platform.h vs build system

2011-10-03 Thread Adam Roben
On Oct 3, 2011, at 10:51 AM, Darin Adler wrote:

 But a while back, Maciej outlined a concept for where to put these platform 
 base include files; I don’t remember when that was or what the details were.

I think the plan is outlined here: 
http://trac.webkit.org/wiki/Porting%20Macros%20plan.

-Adam

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


Re: [webkit-dev] Making top-level style changes through window.internals

2011-09-29 Thread Adam Roben
On Sep 29, 2011, at 11:37 AM, Fady Samuel wrote:

 pageScaleFactor is a document level CSS scaling style. Often times, we'd like 
 to be able to apply style at the document level when writing layout tests. As 
 far as I'm aware, there's no way to do this in javascript in a layout test? 
 Is this correct? If so, would anyone object to exposing document-level styles 
 to window.internals? If not there, is there anywhere else where this can be 
 exposed for testing purposes?

In the particular case of pageScaleFactor I believe we already have 
eventSender.scalePageBy. (I think it's on eventSender rather than 
layoutTestController because it was first used to simulate Safari's 
pinch-to-zoom feature.)

Moving this feature to window.internals and adding other similar features seems 
fine to me.

-Adam

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


Re: [webkit-dev] Help with a possible Webkit bug

2011-09-26 Thread Adam Roben
This isn't the right mailing list for a question like this. 
http://www.webkit.org/contact.html explains the different mailing lists.

But probably the best thing to do in a case like this is to file a bug at 
http://webkit.org/new-bug.

-Adam

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


Re: [webkit-dev] Not able to play flash with windows webkit

2011-09-23 Thread Adam Roben
On Sep 23, 2011, at 9:36 AM, vswap 65 wrote:

 After little more investigation I found that the issue is with the mimetype 
 not with the flash plugin.
 When the NP flash plugini.e., npswf.dll is installed, webkit is loading the 
 dll and playing the flash with if the mimetype is changed to 
 application/x-shockwave-flash. This is valid mime-type for *.swf content.
 
 But in the testcase attached for the bugid: 21649, mimetype is 
 application/octet-stream.
 And firefox is able to play even if the mimetype is 
 application/octet-stream.
 So I wanted to know if this is a valid bug on webkit or its a content 
 issue(invalid HTML content).
 Can some please suggest us if we can raise a bug on webkit?

It sounds worth filing a bug and mentioning the difference from Firefox. It 
would also be good to test other browsers.

-Adam

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


Re: [webkit-dev] Do you maintain OS(WINCE)?

2011-09-13 Thread Adam Roben
On Sep 13, 2011, at 12:07 PM, Leandro Pereira wrote:

 Antonio,
 
 On 09/13/2011 04:00 PM, Antonio Gomes wrote:
 
 I believe it was maintained by Torch Mobile, and, according to George
 Staikos, it is not part of the plans any more (Torch was acquired by RIM).
 
 
 AFAIR, Patrick Gansterer (paroga) is still working on the WinCE port. He 
 usually informally reviews CMake-related changes.

I believe this is correct. He also maintains a buildbot: 
http://build.webkit.org/builders/WinCE%20Release%20%28Build%29

-Adam


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


Re: [webkit-dev] run-bindings-tests

2011-09-09 Thread Adam Roben
On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote:

 On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote:
 On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote:
 
 I'm happy to write a run-all-tests script which runs all known tests that 
 platform can handle. :)
 
 I think run-webkit-tests should be this. We can come up with a new name for 
 the “just run the tests in the LayoutTests directory” tool.
 
 I would like that too.  But there are going to be stages to get here.
 If we did this today, bots would break if nothing else.
 
 I'll see about adding a run-all-tests script soon and we can work to
 have it replace run-webkit-tests.  (new-new-run-webkit-tests anyone?)

An alternate path to success would be:

1) Decide what to call the script that just runs tests from LayoutTests
2) Rename run-webkit-tests to that new name and add a new script called 
run-webkit-tests that just calls the renamed script
3) Slowly make run-webkit-tests call out to other test-running scripts

-Adam

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


Re: [webkit-dev] run-bindings-tests

2011-09-09 Thread Adam Roben
On Sep 9, 2011, at 10:59 AM, Adam Roben wrote:

 On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote:
 
 On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote:
 On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote:
 
 I'm happy to write a run-all-tests script which runs all known tests that 
 platform can handle. :)
 
 I think run-webkit-tests should be this. We can come up with a new name for 
 the “just run the tests in the LayoutTests directory” tool.
 
 I would like that too.  But there are going to be stages to get here.
 If we did this today, bots would break if nothing else.
 
 I'll see about adding a run-all-tests script soon and we can work to
 have it replace run-webkit-tests.  (new-new-run-webkit-tests anyone?)
 
 An alternate path to success would be:
 
 1) Decide what to call the script that just runs tests from LayoutTests
 2) Rename run-webkit-tests to that new name and add a new script called 
 run-webkit-tests that just calls the renamed script
 3) Slowly make run-webkit-tests call out to other test-running scripts

I of course forgot:

2.5) Change the bots to call the renamed script

-Adam

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


Re: [webkit-dev] make-script-test-wrappers not being maintained

2011-09-08 Thread Adam Roben
On Sep 8, 2011, at 10:58 AM, Eric Seidel wrote:

 We could also teach DumpRenderTree to lie about what / is, so we
 could include the scripts like this:
 
 script href=/fast/js/resources/js-test-pre.js

By the time DRT sees that URL it will already have been resolved against the 
base URL of the page.

-Adam

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


Re: [webkit-dev] Code Search for webkit.org

2011-09-08 Thread Adam Roben
On Sep 8, 2011, at 5:52 PM, Eric Seidel wrote:

 I'm curious how other developers search the WebKit code?
 
 I use http://codesearch.google.com/#search/q=package:webkit from time
 to time.  If others do too, we should make it a redirect from
 cs.webkit.org (like we do for cia.webkit.org).
 
 Or maybe folks have better code search solutions?  grep -r?

I use git grep or Xcode/Visual Studio's find functionality. But I trust git 
grep more for code that might run on other platforms.

-Adam

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


Re: [webkit-dev] PSA: Removing support for Apache 1.3 in WebKit

2011-07-12 Thread Adam Roben
On Jul 11, 2011, at 9:33 PM, Eric Seidel wrote:

 Eventually we might transition the cygwin port to Apache2

https://bugs.webkit.org/show_bug.cgi?id=22517 discusses this a little bit.

-Adam

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


[webkit-dev] Update on commit messages (was: Re: Proposal: Commit messages should start with a one-line summary of the change)

2011-07-08 Thread Adam Roben
On Jul 1, 2011, at 10:38 AM, Adam Roben wrote:

 On Jun 30, 2011, at 7:52 PM, Darin Adler wrote:
 
 I do think that given the tools behavior you described, we should move the 
 reviewer text after the bug title and patch description paragraph, even 
 though you explicitly said that’s not what you are proposing.
 
 I think that would be a good first step. It would definitely be better than 
 what we have now from a tools perspective. And in a lot of cases these days, 
 the bug title really is a short description of the change. [1]
 
 I think these two bugs will get us started:
 http://webkit.org/b/26755 webkit-patch's commit messages are less readable 
 than commit-log-editor's
 http://webkit.org/b/63804 commit-log-editor reorders ChangeLog entries in 
 unexpected ways

These two bugs have now been fixed. (There was a little fallout from bug 26755, 
but hopefully that has been taken care of, too.)

prepare-ChangeLog now puts the bug title and URL first, then the Reviewed by 
line. commit-log-editor no longer reorders the ChangeLog contents (other than 
extracting common lines to the top of the commit message). webkit-patch now 
uses commit-log-editor to create its commit messages.

I think this has made some of our tools a lot more useful. (See, e.g., 
http://trac.webkit.org/log/trunk?rev=90579stop_rev=90540. The switch from 
the old commit messages to the new ones is quite obvious.) I think it's also a 
slight improvement in readability of ChangeLogs, as in many cases the bug title 
is a description of the change.

I'm going to drop the put a one-line summary at the top of your commit 
message suggestion for now. I think I've caused enough change for one email 
thread. :-)

-Adam

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


Re: [webkit-dev] New page for viewing test failures on build.webkit.org

2011-07-08 Thread Adam Roben
I've been working a bit more on TestFailures over the last few weeks, and it's 
grown a few new features [1]. I encourage you to check it out if you haven't, 
and even if you have!

http://build.webkit.org/TestFailures/

-Adam

1. Including:
 * Basic support for detecting flaky tests
 * Basic support for NRWT bots
 * LocalStorage caching for sped!
 * Lists of existing bugs related to the failing tests
 * Parsing of commit messages to try to guess better which revision is guilty
 * Loading of builds that have been moved to the old-results directory
 * Crashing function names shown right on the page
 * Links to regression ranges in Trac
 * A link right on the page to file a bug about TestFailures itself

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


Re: [webkit-dev] Switching to new-run-webkit-tests

2011-07-07 Thread Adam Roben
On Jul 7, 2011, at 2:55 AM, Eric Seidel wrote:

 One of the Leopard Debug slaves (apple-mac-pro-6) is still wedged
 after the transition:
 http://build.webkit.org/builders/Leopard%20Intel%20Debug%20%28Tests%29/builds/32142/steps/layout-test/logs/stdio
 
 If someone could run killall httpd, or just restart the machine,
 that'd be wonderful. :)

It looks like apple-xserve-3, apple-macpro-5, and apple-macpro-6 were all 
having trouble. I rebooted all of them.

-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Is there special setup needed to run the WebKit2 tests?

2011-07-07 Thread Adam Roben

On Jul 7, 2011, at 12:01 AM, Eric Seidel wrote:

 old-run-webkit-tests -2 --debug produces:
 
 107 test cases (1%) had incorrect layout
 1 test case (1%) crashed
 8 test cases (1%) Web process crashed
 24 test cases (1%) had stderr output
 
 new-run-webkit-tests -2 --debug (which is what I'm trying to make
 work better) produces:
 
 Regressions: Unexpected text diff mismatch : (96)
 Regressions: Unexpected DumpRenderTree crashes : (7)
 
 (NRWT doesn't understand the difference between
 WebKitTestRunner/WebProcess and DumpRenderTree yet.)
 
 So at least NRWT fails the same as ORWT on my machine.  But I was
 hoping to get closer to the 5 failures the the bots see.  Any
 suggestions?
 
 http://trac.webkit.org/wiki/WebKit2 doesn't mention any special setup.

I don't know of any special setup. Maybe if you post your results directory 
somewhere we can have a look and try to figure out what's going on?

-Adam

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


Re: [webkit-dev] Switching to new-run-webkit-tests

2011-07-06 Thread Adam Roben
Now that more and more ports are switching to NRWT, it would be great for 
someone to explain what the best practices are for dealing with failing and 
flaky tests.

-Adam

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


Re: [webkit-dev] Switching to new-run-webkit-tests

2011-07-06 Thread Adam Roben
On Jul 6, 2011, at 11:53 AM, Adam Roben wrote:

 Now that more and more ports are switching to NRWT, it would be great for 
 someone to explain what the best practices are for dealing with failing and 
 flaky tests.

Two specific questions I have:

1) Are the ports that have switched to NRWT no longer using Skipped files?
2) Are the ports that have switched to NRWT now using test_expectations.txt 
files?

But I'm interested in a more general overview, too.

-Adam

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


Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)

2011-07-06 Thread Adam Roben
On Jul 6, 2011, at 11:58 AM, Adam Barth wrote:

 I'm not sure we've quite figured that out yet.  NRWT supports both
 Skipped lists and test_expectations.txt, which is a more expressive
 (but also more complex) version of Skipped lists.  IMHO, we should
 wait for the dust to settle on the transition before changing our
 practices.

OK. Then I have another question:

What should I do to make the Leopard and SnowLeopard bots green, now that they 
have switched to NRWT?

-Adam

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


Re: [webkit-dev] Fixing the Platform fields in Bugzilla

2011-07-05 Thread Adam Roben
On Jul 5, 2011, at 12:41 PM, Simon Fraser wrote:

 Can we clean this up?

Definitely! It's easy to change the options for these two fields. I don't know 
what would be involved with replacing these two fields with something else 
entirely.

Do you have a proposal?

-Adam

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


Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

2011-07-01 Thread Adam Roben
On Jun 30, 2011, at 7:52 PM, Darin Adler wrote:

 I don’t think it’s a good idea to add yet another thing to every change log 
 entry.

I wouldn't consider this something being added. Most ChangeLog entries (the 
good ones, anyway) already contain a description of the fix in addition to the 
bug title, URL and reviewer. http://trac.webkit.org/changeset/90086 is a good 
example. All I'm proposing is that part of the explanation of the fix be 
extracted out into a one-line summary at the top of the ChangeLog. So it's not 
so much adding something as rearranging the information that is (or should) 
already be present.

 I do think that given the tools behavior you described, we should move the 
 reviewer text after the bug title and patch description paragraph, even 
 though you explicitly said that’s not what you are proposing.

I think that would be a good first step. It would definitely be better than 
what we have now from a tools perspective. And in a lot of cases these days, 
the bug title really is a short description of the change. [1]

I think these two bugs will get us started:
http://webkit.org/b/26755 webkit-patch's commit messages are less readable 
than commit-log-editor's
http://webkit.org/b/63804 commit-log-editor reorders ChangeLog entries in 
unexpected ways

-Adam

1. I don't think this is necessarily a good thing; it would be better in my 
opinion if bug titles described user-visible symptoms or missing features. The 
typical webkit-patch-based workflow of writing a patch first and then uploading 
it to a new bug encourages these kinds of solution-based rather than 
issue-based bug titles. But webkit-patch makes so many things so much easier 
that it's hard to fault it!

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


Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

2011-07-01 Thread Adam Roben
On Jul 1, 2011, at 11:57 AM, Julien Chaffraix wrote:

 I don’t think it’s a good idea to add yet another thing to every change log 
 entry.
 
 I wouldn't consider this something being added. Most ChangeLog entries (the 
 good ones, anyway) already contain a description of the fix in addition to 
 the bug title, URL and reviewer.
 
 While I sympathize with the idea of the one line explanations, I think
 this adds unneeded complexity to our workflow and the added value you
 mentioned does not seem to overcome it (namely making a couple of
 tools work better).

I wasn't trying to add any complexity. My hope is that people are already 
adding descriptions of their changes to their ChangeLog entries, like you do. I 
was just trying to suggest a better way to organize that description.

In my original email I noted two benefits of making this change:

 1) It would make it much easier to understand at a glance what the change 
 actually does.
 
 2) It would make many of our tools work better

I see (1) as the primary benefit, and (2) as a nice side-benefit.

 Also you are implicitly constraining people to explain their change
 with one-liners which IMHO is not a good constraint. I would rather
 see good explanations than explanations that need to match a format.

I'm not trying to constrain descriptions to one line. I think that would be 
horrible in a lot of cases! I'm just suggesting that there be a one-line 
summary at the top followed by a more detailed description below. (Note that 
our current ChangeLog template doesn't say that you should include *any* 
description of the change.)

-Adam

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


[webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?

2011-07-01 Thread Adam Roben
When a test starts failing on a bot that uses old-run-webkit-tests, we 
typically check in expected failure results for that test (e.g., 
http://trac.webkit.org/changeset/90235). That way we can find out if the 
test's behavior changes in the future even though the test is still failing. 
This is particularly useful for tests that are actually testing multiple things 
at once. (Maybe they should be broken up into multiple tests, but that's a 
different discussion.)

Is there a way to achieve this with new-run-webkit-tests? I know that you can 
mark a test as an expected failure (either a text diff, or an image diff, or 
both). Does it let you specify that the test should fail in a particular way?

-Adam

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


[webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?

2011-07-01 Thread Adam Roben
When a test starts failing on a bot that uses old-run-webkit-tests, we 
typically check in expected failure results for that test (e.g., 
http://trac.webkit.org/changeset/90235). That way we can find out if the 
test's behavior changes in the future even though the test is still failing. 
This is particularly useful for tests that are actually testing multiple things 
at once. (Maybe they should be broken up into multiple tests, but that's a 
different discussion.)

Is there a way to achieve this with new-run-webkit-tests? I know that you can 
mark a test as an expected failure (either a text diff, or an image diff, or 
both). Does it let you specify that the test should fail in a particular way?

-Adam

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


[webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

2011-06-30 Thread Adam Roben
I'd like to propose that WebKit commit messages start with a one-line summary 
of the change.

This change would have two benefits:

1) It would make it much easier to understand at a glance what the change 
actually does.

Our commit logs usually include a bug title, but the bug title only tells you 
about the problem, not about the solution.

2) It would make many of our tools work better.

For instance, http://trac.webkit.org/log/trunk shows the first 75 characters 
or so of the commit message. Right now it's just a wall of dates and author 
names, which are already shown in other parts of the UI. It would show much 
more useful information if we had a one-line summary at the top of the commit 
message. As another example, pretty much all git-based tools assume the commit 
message starts with a one-line summary (e.g., git log --pretty=oneline, gitk, 
webkit-patch post-commits, etc.), and work much better when that is the case.

Since our commit messages are almost always just a copy of our ChangeLog 
entries, this should apply to ChangeLog entries too. Specifically, I suggest 
one line be added to our ChangeLog template, yielding the following:


2011-06-30  Adam Roben  aro...@apple.com

Need a one-line summary of your change (OOPS!)

Reviewed by NOBODY (OOPS!).

Need a short description and bug URL (OOPS!)

* FileIModified.cpp:



Given this format, commit-log-editor will put the summary right at the top of 
the commit log. webkit-patch will require modifications to do this correctly, 
as represented by https://bugs.webkit.org/show_bug.cgi?id=26755.

Thoughts?

-Adam

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


Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

2011-06-30 Thread Adam Roben
On Jun 30, 2011, at 5:10 PM, Mark Rowe wrote:

 Most ChangeLog entries already have a one-line summary immediately after the 
 Reviewed by line.  I'm not sure that there's any benefit to reordering 
 these parts of the ChangeLog.

Most ChangeLog entries have the bug title after the Reviewed by line, like 
this one: http://trac.webkit.org/changeset/90156/trunk/LayoutTests/ChangeLog. 
As I said in my email:

 Our commit logs usually include a bug title, but the bug title only tells 
 you about the problem, not about the solution.

I don't consider the bug title and the one-line summary I'm proposing to be 
equivalent. I'm also not proposing moving the bug title above the Reviewed by 
line.

 Given this format, commit-log-editor will put the summary right at the top 
 of the commit log. webkit-patch will require modifications to do this 
 correctly, as represented by https://bugs.webkit.org/show_bug.cgi?id=26755.
 
 commit-log-editor already does the right thing given our current format.  
 It's just that many people have switched to using webkit-patch, and it was 
 never taught the correct format for commit messages.

commit-log-editor will do some wacky things that sometimes end up with the bug 
title and URL lines first, followed by the Reviewed by line. 
https://bugs.webkit.org/show_bug.cgi?id=27754 seems to be the source of the 
wackiness. This was added in an attempt to make our commit messages work better 
with our tools, but doesn't help people who are browsing through ChangeLogs. I 
also think it's confusing that our commit messages and ChangeLogs don't follow 
the same order (as Adam Treat mentioned in 
https://bugs.webkit.org/show_bug.cgi?id=27754#c6).

Having the bug title on the first line (as commit-log-editor currently tries to 
do) is better than having the date/author line first from a tools perspective. 
But I think having a one-line summary first would be even better. And I think 
it would be nice to have the ordering of our ChangeLog entries and commit 
messages match.

-Adam

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


Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

2011-06-30 Thread Adam Roben
On Jun 30, 2011, at 5:00 PM, Dirk Pranke wrote:

 Sounds good to me, except I wonder how often you'd get Fixed bug
 where  where XXX is the bug summary.

I think this is something that reviewers would have to encourage authors not to 
do, just like reviewers should be encouraging authors to fill out the 
file/function boilerplate that prepare-ChangeLog gives you with actual comments.

-Adam

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


Re: [webkit-dev] Proposed Windows Drawing Change (WebNodeHighlight) Logic

2011-06-27 Thread Adam Roben
On Jun 27, 2011, at 1:55 AM, Simon Fraser wrote:

 This should go into a bug.

Agreed.

 On Jun 26, 2011, at 4:12 PM, Brent Fulgham wrote:
 
 While investigating a separate issue, I noticed that I was hitting an 
 assertion in the Cairo drawing layer because it was attempting to use an 
 invalid HBITMAP created in the WebNodeHighlight::update method.  The 
 underlying issue was that the CreateDIBSection function was failing, because 
 it was being requested to create a section of zero height.
 
 I think the following change would be safe for the CoreGraphics and Cairo 
 ports, but wanted to see if anyone knew of a reason why it would be bad to 
 exit early in the case of a zero height (or zero width) paint region.
 
 $ svn diff
 Index: win/WebNodeHighlight.cpp
 ===
 --- win/WebNodeHighlight.cpp(revision 89759)
 +++ win/WebNodeHighlight.cpp(working copy)
 @@ -145,10 +145,14 @@
size.cx = webViewRect.right - webViewRect.left;
size.cy = webViewRect.bottom - webViewRect.top;
 
 +if (!size.cx || !size.cy)
 +return;
 +
BitmapInfo bitmapInfo = BitmapInfo::createBottomUp(IntSize(size));
 
void* pixels = 0;
OwnPtrHBITMAP hbmp = adoptPtr(::CreateDIBSection(hdc, bitmapInfo, 
 DIB_RG
 B_COLORS, pixels, 0, 0));
 +ASSERT_WITH_MESSAGE(hbmp.get(), ::CreateDIBSection failed with error 
 %lu,
 ::GetLastError());
 
::SelectObject(hdc, hbmp.get());

I don't see any reason why this would be bad.

-Adam

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


Re: [webkit-dev] New page for viewing test failures on build.webkit.org

2011-06-20 Thread Adam Roben
On Jun 1, 2011, at 4:41 PM, Adam Barth wrote:

 Looks like a good start.

Thanks!

 Have you considered a test-centric view
 (instead of a bot-centric view)?  That might make it easier to see
 what's going on globally across the project.

I have considered it, and I agree. That's basically what 
http://webkit.org/b/61059 is about.

-Adam

 On Wed, Jun 1, 2011 at 12:22 PM, Adam Roben aro...@apple.com wrote:
 Hi all-
 
 Before I go on vacation for 2.5 weeks, I wanted to let you know about a new
 page I've been working on on build.webkit.org. You can see it here:
 
 http://build.webkit.org/TestFailures/
 
 The idea of the page is to provide a single place to go to find out what
 tests are failing on the bots and when they started failing. It also tries
 to make it easy to file bugs about the failures.
 
 It is pretty ugly, and has some glaring bugs (search Bugzilla for
 TestFailures). But I've found it useful already. I hope you will, too!
 
 Please file bugs and feature requests in the Tools / Tests component of
 Bugzilla, include the word TestFailures in the bug, and CC me. The code
 lives in
 Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures.
 
 Let me know what you think!
 
 -Adam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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


Re: [webkit-dev] Different Versions of WebkitSupportLibrary.zip

2011-06-20 Thread Adam Roben
On Jun 1, 2011, at 8:38 PM, Brian Stuart wrote:

 Hi All,
 I am trying to build a fork of WebKit on windows that requires a version of 
 WebKitSupportLibrary.zip different than the one currently available from 
 http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html
  
 In the script “WebKitTools/Scripts/update-webkit-support-libs” it’s looking 
 for a version of WebKitSupportLibrary.zip with a checksum of 
 a1341aadbcce1ef26dad2b2895457314
  
 Does anyone know where I can download the correct version of 
 WebKitSupportLibrary.zip?

Are you trying to build an old version of WebKit? update-webkit-support-libs no 
longer uses a checksum to verify the version of the zip file.

-Adam

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


Re: [webkit-dev] Different Versions of WebkitSupportLibrary.zip

2011-06-20 Thread Adam Roben
On Jun 20, 2011, at 11:21 PM, Brian Stuart wrote:

 Thanks for your reply, 
 Yes I need to build an older version of webkit that was forked and has some 
 custom changes. 
 
 Any idea where I might find the correct version of WebkitSupportLibrary.zip?

Old versions of WebKitSupportLibrary.zip aren't made available anywhere. (And 
even if you did have an old WebKitSupportLibrary.zip lying around, you'd also 
need the matching old version of Safari in order for the WebKit you built with 
it to actually be usable.)

You could try using the latest version of update-webkit-support-libs and 
WebKitSupportLibrary.zip. Hopefully it will work with your old version of 
WebKit without requiring too many changes.

-Adam

 On Jun 20, 2011, at 8:00 PM, Adam Roben wrote:
 
 On Jun 1, 2011, at 8:38 PM, Brian Stuart wrote:
 
 Hi All,
 I am trying to build a fork of WebKit on windows that requires a version of 
 WebKitSupportLibrary.zip different than the one currently available from 
 http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html
  
 In the script “WebKitTools/Scripts/update-webkit-support-libs” it’s looking 
 for a version of WebKitSupportLibrary.zip with a checksum of 
 a1341aadbcce1ef26dad2b2895457314
  
 Does anyone know where I can download the correct version of 
 WebKitSupportLibrary.zip?
 
 Are you trying to build an old version of WebKit? update-webkit-support-libs 
 no longer uses a checksum to verify the version of the zip file.
 
 -Adam
 
 

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


[webkit-dev] New page for viewing test failures on build.webkit.org

2011-06-01 Thread Adam Roben

Hi all-

Before I go on vacation for 2.5 weeks, I wanted to let you know about  
a new page I've been working on on build.webkit.org. You can see it  
here:


http://build.webkit.org/TestFailures/

The idea of the page is to provide a single place to go to find out  
what tests are failing on the bots and when they started failing. It  
also tries to make it easy to file bugs about the failures.


It is pretty ugly, and has some glaring bugs (search Bugzilla for  
TestFailures). But I've found it useful already. I hope you will, too!


Please file bugs and feature requests in the Tools / Tests component  
of Bugzilla, include the word TestFailures in the bug, and CC me.  
The code lives in Tools/BuildSlaveSupport/build.webkit.org-config/ 
public_html/TestFailures.


Let me know what you think!

-Adam

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


Re: [webkit-dev] Verifying changes to build.webkit.org-config/master.cfg locally

2011-05-23 Thread Adam Roben
On May 20, 2011, at 8:22 PM, Dmitry Lomov wrote:

 I am trying to make run-api-tests run at build time.
 I wonder what is the right way to verify my changes locally (aka what do I 
 run to simulate build on bots locally?)

Here are instructions I was given by Bill Siegrist (_wms) a while back:

 The basic steps to making a test version of build.webkit.org are:
 
 
 1. Install stuff on a Mac  (I use MacPorts for this, but using the built-in 
 easy_install for Python 2.6 on SnowLeopard should work too)
   a) buildbot   (port name: buildbot)
   b) simplejson (port name: py26-simplejson)
 
 2. Create a master by doing: buildbot create-master 
 /path/to/an/empty/directory
 
 3. Get the files from the webkit svn repo (master.cfg and config.json). Put 
 them in your buildbot master directory from when you did `buildbot 
 create-master` in step 2.
 
 4. create a passwords.json in the master directory with a dictionary of 
 slavename-password keys like:  { apple-test-slave: thepassword, }
 
 5. Follow normal buildbot documents to start the master (run `buildbot start` 
 in the master directory). The master website should be visible on port 8710.
 
 6. Send changes using the buildbot tool. The following uses a lot of bogus 
 data. All that should matter for testing scheduling/filtering is the branch 
 value given to the -b option. 
 
 $ buildbot sendchange -b branches/foo -r 12345 -u someuser 
 --master=localhost:17000 -m commit message -R therepo somefiles
 
 Note that builds will not start until there have been no changes for 45 
 seconds (this is set in config.json via treeStableTimer). 
 
 
 See also:   http://buildbot.net/buildbot/docs/current/

-Adam

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


Re: [webkit-dev] New feature - MHTML support

2011-05-12 Thread Adam Roben
On May 2, 2011, at 6:03 PM, Eric Seidel wrote:

 MHTML support was definitely discussed at length back in the early
 days of Safari Windows development in webkit.org.  Maybe that desire
 has gone away since then.  I feel very out-of-touch with current
 Safari-on-Windows needs.

We've had requests for MHTML support on Windows and on Mac. I don't think the 
requests have been terribly frequent.

-Adam

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


Re: [webkit-dev] Correct relative URL behavior

2011-05-04 Thread Adam Roben
On May 4, 2011, at 2:42 PM, Adam Barth wrote:

 I wish I could make script tests that didn't output PASS/FAIL

What's stopping you?

-Adam

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


Re: [webkit-dev] new-run-webkit-tests new results.html format

2011-05-03 Thread Adam Roben
On May 3, 2011, at 4:01 PM, Ojan Vafai wrote:

 The results load considerably faster now. For runs where many tests fail, the 
 filesize is considerably smaller than the old-run-webkit-tests filesize. 
 Also, I've added in the image toggling behavior of old-run-webkit-tests and 
 made the aesthetics a bit closer to the old-run-webkit-test format.
 
 Some rough file sizes if you care about the details.
 
 old-run-webkit-tests 5 failures: 5k
 old-run-webkit-tests 500 failures: 250k
 new-run-webkit-tests 5 failures: 1k json + 25k htmljs
 new-run-webkit-tests 500 failures: 60k json + 25k html/js

Thanks for all the work you've put into this, Ojan! Is there a link we can use 
to look at the latest and greatest?

-Adam

 On Fri, Apr 22, 2011 at 11:04 AM, Ojan Vafai o...@chromium.org wrote:
 On Thu, Apr 21, 2011 at 10:05 PM, Maciej Stachowiak m...@apple.com wrote:
 On Apr 21, 2011, at 4:47 PM, Ojan Vafai wrote:
 On Thu, Apr 21, 2011 at 4:21 PM, Maciej Stachowiak m...@apple.com wrote:
 
 (2) Slow to load (apparently it loads a 3 meg JSON file before displaying 
 anything?)
 
 Loading it locally is very fast for me. I guess I should try it on a laptop 
 though.
 
 I'm on a laptop. On my home WiFi, it takes 5-15 seconds.
 
 Yikes.
 For context, we reuse the JSON file that's used for the test runtime 
 treemaps, which means we need an entry for each test. That json will will 
 get .5 meg smaller shortly. There are a number of approaches to make this 
 smaller if needed. Some options would be to generate a separate JSON file, 
 or to make the data format in the existing json file more compact.
 It seems to me that only data on unexpected failures should be needed for 
 initial display. Making the page load fast seems more important than 
 convenience of reusing an existing JSON file. I hope you will agree that 5-15 
 second load time is not acceptable. I'm sure it would be even worse in poor 
 network conditions, where even the old-style pages can be a challenge to 
 load. I would also like to be able to look at results pages on my iPhone or 
 iPad without invoking the OOM killer.
 
 This should be relatively straightforward to fix. I'll ping again in a day or 
 two when it's done. I expect we should be able to get comparable, if not 
 smaller size than the old style pages.
 (3) I like PrettyPatch format better than wdiff format.
 
 This is orthogonal. new-run-webkit-tests will use whichever one is available 
 on the system. The results.html file will display whichever one was used.
 What would the bots display if this is deployed?
 
 I'm not 100% sure. Dirk can confirm, but I believe it will use whichever one 
 is on the system. So, if the bot has pretty-patch, but not wdiff, it would 
 only show the pretty-patch link. The Chromium bot I linked to has wdiff, but 
 not pretty-patch, hence the wdiff links.
 
 Ojan 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Some compile time data

2011-04-26 Thread Adam Roben
On Apr 26, 2011, at 1:30 PM, David Kilzer wrote:

 On Apr 25, 2011, at 4:59 PM, Stephanie Lewis wrote:
 
 One point brought up during the compile time discussion today was that if 
 you pulled once a day, you were likely to have rebuild the world.  I thought 
 it would be interesting to see which files were contributing to rebuilding 
 the world the most often.
 
 Using the data provided by Mihai at 
 http://persistent.info/webkit/tools/buildbot/ I wrote a script to find all 
 of the revisions that took ~2x the average time to compile.  Then I matched 
 that up with the file list from svn log to get an idea of which files are 
 triggering world builds the most often (or at least recently).
 
 Of the 500 revisions 152 spiked compile time.
 
 Here are the most common changed files, full data attached.  
 
 12   /trunk/Source/WebCore/bindings/scripts/CodeGeneratorJS.pm
 12   /trunk/Source/WebCore/bindings/js/JSDOMBinding.h
 10   /trunk/Source/WebCore/WebCore.exp.in
 
 Changing WebCore.exp.in should only require relinking WebCore, not 
 recompiling it, although linking WebCore takes a non-trivial amount of time.  
 (The WebCoreExportGenerator project will get recompiled, but that's generally 
 negligible compared to WebCore itself.)

It seems likely that WebCore.exp.in is changing in conjunction with other 
files, in particular header files which are #included by WebKit.

-Adam

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


Re: [webkit-dev] Platform LayoutTests are out of control

2011-04-21 Thread Adam Roben
On Apr 21, 2011, at 2:41 AM, Brent Fulgham wrote:

 I think it's just been especially bad the last few days.

I believe this is because Tony Chang has been working on converting existing 
pixel results to have embedded checksums, rather than out-of-line .checksum 
files. This is a one-time conversion, and when it's completed it should reduce 
the total number of files (though not file size) considerably.

-Adam

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


Re: [webkit-dev] [webkit-changes] [83955] trunk

2011-04-15 Thread Adam Roben
On Apr 15, 2011, at 1:19 PM, Oliver Hunt wrote:

 Don't roll out patches that don't break any core builders, without making 
 some attempt to diagnose the problem or providing information that will make 
 it possible to fix the problem.

The GTK bots are core builders.

-Adam

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


[webkit-dev] All webkit.org services seem to be down

2011-04-06 Thread Adam Roben
Hi Bill-

bugs.webkit.org, svn.webkit.org, www.webkit.org, trac.webkit.org all seem to be 
down. Is this expected? Any idea when they might return? Thanks!

-Adam

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


Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows

2011-04-06 Thread Adam Roben
On Apr 6, 2011, at 12:25 PM, Pere Martir wrote:

 On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben aro...@apple.com wrote:
 The best way to report a bug like this is to file a new bug at 
 http://webkit.org/new-bug. In this case, this is a known issue 
 (http://webkit.org/b/52913), so you don't need to do anything. There isn't 
 a workaround at this time, other than to skip those tests or use a Release 
 build.
 
 That's why there is no Windows 7 Debug (Tests) in BuildBot ?

No. That's mostly a historical accident. At first we weren't able to capture 
crash logs on Windows 7 bots, and it seemed important to have crash logs for 
assertion failures, so the Debug bots all ran Windows XP. Now we can capture 
crash logs on Windows 7, but we haven't had a need to change things.

I'd say that the lack of a Windows 7 Debug (Tests) bot is part of the reason 
why that assertion hasn't been fixed yet, though.

-Adam

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


Re: [webkit-dev] LayoutTest failures on Windows due to fonts/metric (yet again, any update?)

2011-04-06 Thread Adam Roben
On Apr 6, 2011, at 7:43 AM, Pere Martir wrote:

 I am working on Windows and I am planning to submit some patches
 (plugin loading) but I have problem make all regression tests
 (run-webkit-tests) pass without unmodified code.
 
 I followed all the instructions:
 
   http://trac.webkit.org/wiki/BuildingOnWindows#Font-metric-relatedfailures
 
 but as it warned, I saw metric-related failures.
 
 And recently aroben just told me on IRC that I may still have
 difference in the metrics so that I suppose that this problem has not
 be resolved.
 
 The most related posts that I could find in this list is kinda old.
 * Eric Seidel, Oct 2008 - http://markmail.org/message/ihjhh4dre2ztu6v4
 * Darin Adler, Apr 2009 - http://markmail.org/message/wsnz67kqm7l7mtk6
 
 However, on WebKit BuildBot I saw that Windows release and debug build
 are both green. I don't see the option --tolerance specified.
 There must be some tricks of setting up the machine. Any clue please ?
 
 @@ -1,15 +1,15 @@
 layer at (0,0) size 800x600
   RenderView at (0,0) size 800x600
 -layer at (0,0) size 800x70
 -  RenderBlock {HTML} at (0,0) size 800x70
 -RenderBody {BODY} at (8,8) size 784x54
 -  RenderText {#text} at (0,0) size 770x36
 +layer at (0,0) size 800x79
 +  RenderBlock {HTML} at (0,0) size 800x79
 +RenderBody {BODY} at (8,8) size 784x63
 +  RenderText {#text} at (0,0) size 770x41
 
 (full result of 2 failures attached)
 
 One thing may make he difference. In my MacBook, I found *almost all*
 fonts listed in:
 
 https://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/win/DumpRenderTree.cpp#L319
 
 except Times *.ttf. I did find Times New Roman8.ttf so that I
 renamed the later.
 layout-test-results.tar.gz

It's possible that you need the fonts from a specific version of Mac OS X. I 
don't know what version that would be, though.

It is a known issue that it's so hard to get correct test results on Windows. I 
don't think we have a bug filed about it.

-Adam

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


Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows

2011-04-05 Thread Adam Roben
On Apr 5, 2011, at 1:02 PM, Pere Martir wrote:

 64-bit Window 7.
 
 run-webkit-tests reported that many tests crashed, in addition to many
 other failures due to the metric difference.
 
 Command line:
 
  Tools/Scripts/run-webkit-tests compositing/iframes
 
 Tests that caused DumpRenderTree tool to crash:
  compositing/iframes/connect-compositing-iframe3.html
 
 stderr of connect-compositing-iframe3.html:
 ASSERTION FAILED: !isAcceleratedCompositing()
 ..\WebView.cpp(1083) : WebView::paintIntoBackingStore
 
 The result and crash log have been attached in this message.
 layout-test-results.tar.gz

The best way to report a bug like this is to file a new bug at 
http://webkit.org/new-bug. In this case, this is a known issue 
(http://webkit.org/b/52913), so you don't need to do anything. There isn't a 
workaround at this time, other than to skip those tests or use a Release build.

-Adam

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


Re: [webkit-dev] Many crashs of regresion tests in 64-bit Windows

2011-04-05 Thread Adam Roben
On Apr 5, 2011, at 1:17 PM, Pere Martir wrote:

 On Tue, Apr 5, 2011 at 7:10 PM, Adam Roben aro...@apple.com wrote:
 The best way to report a bug like this is to file a new bug at 
 http://webkit.org/new-bug. In this case, this is a known issue 
 (http://webkit.org/b/52913), so you don't need to do anything. There isn't 
 a workaround at this time, other than to skip those tests or use a Release 
 build.
 
 Thanks. I didn't know that this is a bugI thought that it might be due
 to the configuration of my Windows 7. Should I always report this kind
 of issue directly to Bugzilla instead of posting them here first ?

Yes, please. Bugzilla is our best tool for keeping track of bugs, even if they 
turn out to eventually be specific to some misconfiguration on the developer's 
system.

-Adam

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


Re: [webkit-dev] Can we show failing test list on waterfall?

2011-04-02 Thread Adam Roben
On Apr 2, 2011, at 4:59 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Fri, Apr 1, 2011 at 2:54 PM, Adam Barth aba...@webkit.org wrote:
 Can we show the list of failing layout tests in buildbot's waterfall
 display so we don't have to click through to the results.html file?
 
 Also, can we change the [view results] link so that it goes directly
 to results.html instead of the directory listing?  Personally, I
 always click through to results.html because it's so much prettier
 than the directory listing.
 
 What if DRT was killed and there was no result.html? (e.g. if more than 20+ 
 tests crash, we bail out early and there won't be result.html).

We should write out results.html in that case, too. There's no reason not to.

-Adam

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


[webkit-dev] Progress

2011-04-01 Thread Adam Roben
-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Progress

2011-04-01 Thread Adam Roben
On Apr 1, 2011, at 10:03 AM, Dimitri Glazkov wrote:

 I know that Adam Barth was the driving force behind this, since it was his 
 turn at gardening WebKit (that's a Chromium thing 
 http://www.chromium.org/developers/how-tos/webkit-merge-1). I wonder if we as 
 a community would benefit from a cross-organizational rotation like this?

Jessie Berlin and I have been trying to pitch in as well over the course of the 
week. (We have a rotation similar to Chromium's gardeners inside Apple, but 
it's fairly new.) I think it is definitely helpful to have more eyes on the 
bots.

Hopefully we can come up with some ideas for how to make gardeners less 
important by making the bots keep themselves green.

-Adam

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


Re: [webkit-dev] Progress

2011-04-01 Thread Adam Roben
Major kudos to Adam (Barth) for all his gardening efforts this week! (Somehow 
this slipped out of my previous message.)

-Adam

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


Re: [webkit-dev] UA string changes blog draft

2011-03-25 Thread Adam Roben
On Mar 25, 2011, at 1:53 PM, Peter Kasting wrote:

 UA String Changes On WebKit Trunk
 Posted by Peter Kasting on Friday, March 25th, 2011 at 10:44 am
 Recently some changes to the UA string (tracked by 
 https://bugs.webkit.org/show_bug.cgi?id=54556) have landed.  These changes 
 are designed to add UA string detail, remove redundancy, and increase 
 compatibility with Internet Explorer, and are happening in conjunction with 
 similar changes in Firefox 4 (which you can read about at 
 http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/).
 
I find textual links, rather than bare URLs, more user-friendly. bug 54556 
could be used as the text for the first link, at least.
 Here’s a few sample pre-change UA strings:
  Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, 
 like Gecko) Version/5.0.3 Safari/533.19.4
  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ 
 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
 
 Here’s some sample post-change UA strings:
  Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) 
 Version/5.0.3 Safari/534.24
  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 
 (KHTML, like Gecko) Version/5.0.3 Safari/534.24
 

Here's should probably be Here are in both cases above.

 The “U” SSL encryption strength token has been removed.
 
It is still present in the Mac UA strings you showed above.

Thanks for writing the post!

-Adam

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


[webkit-dev] New tool: Leaks Viewer

2011-03-18 Thread Adam Roben


  
  
Hi all-

Over the last two weeks I've been working on a new tool for viewing
leaks output from the SnowLeopard Intel Leaks bot. You can see it
here: http://build.webkit.org/LeaksViewer/ (screenshot
below). It uses the Inspector's Profiles panel code to present leak
stacks in an outline view. I've found it pretty useful for finding
leaks in our code.

Please give it a whirl, and maybe plug some leaks! There are a
number of known issues (particularly with the Heavy view), which can
be found in Bugzilla by searching for "leaks viewer". If you file
any new bugs please include that string in the title and CC me.

I hope you find it useful!

-Adam


  

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


Re: [webkit-dev] cairo build fails on r81169

2011-03-17 Thread Adam Roben

On 3/16/2011 11:36 PM, Brent Fulgham wrote:

Can build-bot be trained to grab that file from another directory?


Yes. Set the WEBKITSUPPORTLIBRARIESZIPDIR environment variable to a 
Windows-style absolute path pointing to the directory that contains 
WebKitSupportLibrary.zip.


-Adam

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


Re: [webkit-dev] cairo build fails on r81169

2011-03-16 Thread Adam Roben

On 3/16/2011 4:18 PM, Adam Barth wrote:

Please file a bug: https://bugs.webkit.org/enter_bug.cgi?product=WebKit

I don't believe the cairo port has a buildbot (please correct me if
I'm wrong).  That means developers have no way of knowing if they
breaking the port and will have trouble keeping the port building.


It does have a buildslave. But it has been failing for months due to 
some configuration issue on the slave. 
http://build.webkit.org/builders/WinCairo%20Debug%20%28Build%29


-Adam

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


Re: [webkit-dev] SnowLeopard debug buildbot not there

2011-03-10 Thread Adam Roben


On Mar 10, 2011, at 3:40 PM, Adam Barth wrote:


On Thu, Mar 10, 2011 at 12:33 PM, Mark Rowe mr...@apple.com wrote:

On 2011-03-10, at 12:27, Adam Barth wrote:

On Thu, Mar 10, 2011 at 12:11 PM, Mark Rowe mr...@apple.com wrote:

On 2011-03-10, at 12:08, David Levin wrote:
tL;dr Why isn't there a SnowLeopard debug buildbot? Related:  
Why does the commit queue (appear) to only run release builds  
through tests?


Details:
Yesterday, I did a build of WebKit on SnowLeopard and hit ~12  
crashes (mostly in inspector tests).


Then I realized that we don't have such a bot, so perhaps that's  
why these crashes aren't getting noticed by people. It also  
looks like the commit queue only runs release builds. I have a  
concern that not having this allows the code to become less  
stable than it should be.


The SnowLeopard Leaks bot builds and tests the debug configuration.


The problem with the leaks bot is that it's always red.  At the  
moment

it has 10792 leaks.


Fixing the leaks would help address this, and is obviously  
beneficial in itself.  It certainly didn't have anywhere near this  
number of leaks last week.


What's the best way to tack down when that regression occurred?  I
scrolled to the end of the waterfall for that builder

http://build.webkit.org/waterfall?last_time=1299183958show=SnowLeopard%20Intel%20Leaks

and the earliest build I could find had 10344 leaks.


You can look at a page like: 
http://build.webkit.org/builders/SnowLeopard%20Intel%20Leaks?numbuilds=500

And then you can start manually decreasing the build number on pages  
like: http://build.webkit.org/builders/SnowLeopard%20Intel%20Leaks/builds/15273


-Adam

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


Re: [webkit-dev] SnowLeopard debug buildbot not there

2011-03-10 Thread Adam Roben

On Mar 10, 2011, at 3:51 PM, Adam Roben wrote:

I'm also planning to file a bug about CoreText-related leaks beneath  
GlyphPage::fill.


http://webkit.org/b/56136 CoreText-related leaks seen beneath  
GlyphPage::fill


-Adam

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


[webkit-dev] A tip for committers

2011-03-03 Thread Adam Roben
All committers are encouraged to follow the instructions I just added to 
http://trac.webkit.org/wiki/CommitterTips#Walkingyouthroughyourfirstcommit:

 Subversion has a handy feature called auto-props that will ensure that new 
 binary files you add to the repository are given the correct MIME type. To 
 set this up, find the following two lines in ~/.subversion/config and 
 uncomment them:
 
 enable-auto-props = yes
 
 *.png = svn:mime-type=image/png
 
 Note that this will work even if you use git-svn to commit changes to WebKit.

This will prevent your webkit-changes emails from being filled with 
gobbledy-gook like this:

 +\x89PNG
 +
 +
 +IHDR X'bKGD\xFF\xFF\xFF\xA0\xBD\xA7\x93 
 IDATx\x9C\xED\xDD{\x90\x95\xE5}\xC0\xF1\xF7\xC8\xCBeq\x97\x8B\x90%q) 
 \xC2RASk:8\x89\xB9\xD0L\xB5Tt'\xEB0:\xA3i
 +4b\xA3S#SsA\x89Q[\xB0x 
 jiA#7\x89\xB2Fv\xB9(7Yݷ\x9C\x99\x9D\xCD^\xEF.?\xF4\xF3\xF9\xEBx\xF6}\xDF\xE7y\xDEs\x8E\xFB\x9D\xF7\xCE\xE6\xD24M\x88sډ\x9E\xC0g\x8D\xC0\xB0\x82
,\x80` \x98\xC0\xB0\x82,\x80` 
 \x98\xC0Vt,;\xEF޽\xFB\xE0\xC1\x83EEE\xBD{\xF7nx\xBBUy\xF7\xDDw\xB7o\xDFlذ\xAE]\xBB6\xFDiuuummmII\xC9駟ު\xC3VUU%Iҽ{\xF7Ν;\xB7j\xC7cת\xA1\xDB|\xDEZ\xA5ͧ\xB1\x91\x96f\xBBgϞ\xB4k׮O\x9FY\xB6\xCF\xE2\xFD\xF7\xDF?t\xE8P\xA7N\x9Dz\xF4\xE8\xD1\xDA}[\x9Aϧ\xE0x\xA0Q\x9F\x9ALW\xB0\xDE{\xEF\xBD\xFA\xA7z\xE6\x99gݿ}\xFB\xF6\xDBn\xBB\xED\xE2\x8B/nt;\xBB|\xF0_\xFE\xE5_fϞ\xFD\xEC\xB3\xCF6\xBB\xC1\xBAu뮸⊟\xFC\xE4'\xAD:l\x92$/\xBF\xFC\xF2\xC0\x81\xFB\xDB߶v\xC7cת\xA1\xDBv\xDEZ\xABͧ\xB1\x91\x96f\xFB\xCE;\xEF\xFC\xE8G?|x\xC6\xED\xB3ضm\xDB5\xD7\\xF3\xDD\xEF~\xB7\xF0f\xCF?\xFF\xFC\xFC\xC7d\x9COk5{\xF0Ž\xC7Z\xE0\xE1k\xC3
 \xF8d
 +\xAC_\xFF\xFA\xD7s\xE7\xCE\xFD\xE7\xFE\xE7F\xF7\x8F1\xE2K_\xFAR\xD3\xDBx\xF0\x8E;\xEE\x98:u\xEA\xBD\xF7\xDE;dȐF?\xCD\xFF\xEA\xB1cǞu\xD6Y\xAD:l\xDE\xF8\xF1㋋\x8B۰\xE3\xB1k\xD5\xD0m8om\xD0\xE6\xD3\xD8HK\xB3\xBD\xF0\xC2/\xBD\xF4\xD2\xEC\xDBg1r\xE4ȁu\xB3G}\xF4\xDF\xFF\xFD\xDF3\xCE'\xA3\xFA\xBF\x80\xDE\xEC\xC1+\xBC\xE4\xD6\xFEm\xF5\xA3\xBE
 +\xDA0C\x99\xEB\x99g\x9E\xB9\xFB\xEE\xBB_}\xF5\xD5\xD7_=p\xEC\xED۷\xF8\xE1\x87%%%\xA5\xA5\xA5\x8D~\x95\xF9\xE4\x933g\xCE\xF6!N;\xED\x84}\xC8\xEC\xFD\xB9\xF2\x8B_\xFCbݺu\x81l\xF8܋=xk\x9F\xD5Y\xB6_!\x8E\xFE\xACu\xEB\xD6UTT\{\x{DD77}\xDCr˜9s~\xFAӟ\xB6a\x98Ç?\xF5\xD4Suuu\xDF\xFAַ:u\xEA\x94$ɞ={\xF2o\xF9䓝;w\xBE\xFA\xEA\xABs\xB9\~\xE3-[\xB6\xDCy\xE7\x9DÆ
 +{\xEC\xB1\xC7ƍ\x97$I\xBBv\xED֮]\xFB\xEC\xB3\xCFv\xEC\xD8qҤIݺu\xCBo\xB9{\xF7\xEEy\xF3\xE6%Ir\xDDuםq\xC6M\xC7ݷo\xDF̙3kkk'L\x98PVVV`\xAF\xBE\xFA\xEA\xE6͛\x93$\xE9ٳ\xE7\xF0\xE1ß{\xEE\xB9$I*++\xCF?\xFF\xFCfڱc\xC7c\x8F=\xF6\xC1\x9Cs\xCE9\xD7_}\xFE
  
 Y\x86ꜛ\xCE\x{DDFF}\xFDm]]]\x92$\x83\xBE\xE0\x82\xEA\xB7|\xF7\xDDwW\xAE\\x99$\xC9СC

(My hat is off to those brave souls who keep the bots green by rebaselining 
tests. My hat will be even more off to you if you follow this tip!)

-Adam

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


Re: [webkit-dev] A tip for committers

2011-03-03 Thread Adam Roben
On Mar 3, 2011, at 11:40 AM, Oliver Hunt wrote:

 Can the style bot be made aware of .png at least and complain if you don't 
 set the right flags?

Subversion properties aren't captured in patches, so the style bot is too early 
in the process. We could add a pre-commit hook to check for the right 
properties, though.

-Adam

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


Re: [webkit-dev] What is Alias on Bugzilla?

2011-03-02 Thread Adam Roben
On Mar 2, 2011, at 2:33 AM, Ryosuke Niwa wrote:

 I just realized that there's a new field labelled Alias on 
 https://bugs.webkit.org/enter_bug.cgi?product=WebKit
 
 Why is this field added and what should I put in this field?

The Alias field allows a bug to be referred to by something other than its 
numeric ID. For instance, if you put BestBugEver in the Alias field for a 
hypothetical bug 9, you can refer to the bug as either 
https://bugs.webkit.org/show_bug.cgi?id=9 or 
https://bugs.webkit.org/show_bug.cgi?id=BestBugEver.

The Alias field was added to allow easier tracking of security bugs that have 
identifiers in other security bug databases.

You don't need to add anything to the Alias field for most bugs.

-Adam

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


[webkit-dev] All Apple Mac and Windows testers now upload crash logs

2011-03-02 Thread Adam Roben
Hi all-

All of Apple's Mac and Windows test bots should now be uploading crash logs to 
build.webkit.org [1]. The crash logs are linked to from results.html (e.g., 
http://build.webkit.org/results/Windows%20XP%20Debug%20(Tests)/r80125%20(25890)/results.html).

If you see a crash on one of Apple's testers and a crash log is not uploaded, 
please file a bug and CC me.

I hope you find this helpful!

-Adam

1. Until recently, crash logs were not uploaded for Windows 7 testers, or for 
crashes in the web process when running WebKit2 tests.

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


[webkit-dev] Criteria for becoming a core builder

2011-03-02 Thread Adam Roben
Hi all-

I'd like to understand better what the criteria are for a builder to become a 
core builder.

We've been putting lot of effort into keeping the Windows testers green lately 
(especially the Windows 7 Release (Tests) builder), and it seems like it would 
be good for them to eventually join the core group so they can reap the 
benefits of sheriffbot, an increased number of people looking at them, etc. 
Most of the failures that happen on the Windows bots these days are either due 
to:

1) a new test being added which needs results on Windows
2) an existing test with Windows-specific results being modified without the 
Windows results being updated
3) test flakiness

Being in the core group seems like it would help with (1) and (2) because the 
people who are making these changes would notice that they forgot Windows. It 
wouldn't help with (3), of course. (We're obviously trying to track down all 
causes of flakiness we can.)

So what does it take for a builder to be a core builder? Once we know this, 
we can hopefully focus our Windows efforts toward satisfying the criteria.

Thanks!

-Adam

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


Re: [webkit-dev] All Apple Mac and Windows testers now upload crash logs

2011-03-02 Thread Adam Roben
On Mar 2, 2011, at 1:41 PM, Eric Seidel wrote:

 Does this require special configuration on the bots, or should
 run-webkit-tests be copying crash logs into layout-test-results for
 all Snow Leopard machines?

run-webkit-tests should be copying crash logs into layout-test-results for all 
Snow Leopard machines if isAppleMacWebKit() is true.

 I ask, because the EWS and commit-queue snow leopard machines do not
 seem to be copying crash logs into layout-test-results like I would
 expect:
 https://bugs.webkit.org/show_bug.cgi?id=51138
 (each of those zips are made from /tmp/layout-test-results after the test 
 run).

We should first look to see if the crash logs are in 
~/Library/Logs/CrashReporter.

-Adam

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


Re: [webkit-dev] Criteria for becoming a core builder

2011-03-02 Thread Adam Roben
On Mar 2, 2011, at 1:38 PM, Eric Seidel wrote:

 So if you believe the windows bots are regularly green, you should
 make them Core.

Well, they are regularly green except for the cases I mentioned. The biggest 
problem is people making changes that cause tests to fail on Windows and not 
noticing that this has happened, so I think making them core will help keep 
them quite a bit greener.

So it sounds to me like we should go ahead and do this. I'll wait a day or two 
to allow other opinions to be heard.

 Along the same logic, we should move bots like Leopard to non-core,
 since they haven't been green in weeks (even though I'm sure we wish
 it would be green).

The Leopard Debug bots are non-core now. The Release ones are still core for 
the moment.

-Adam

 On Wed, Mar 2, 2011 at 9:51 AM, Adam Roben aro...@apple.com wrote:
 Hi all-
 
 I'd like to understand better what the criteria are for a builder to become 
 a core builder.
 
 We've been putting lot of effort into keeping the Windows testers green 
 lately (especially the Windows 7 Release (Tests) builder), and it seems like 
 it would be good for them to eventually join the core group so they can 
 reap the benefits of sheriffbot, an increased number of people looking at 
 them, etc. Most of the failures that happen on the Windows bots these days 
 are either due to:
 
 1) a new test being added which needs results on Windows
 2) an existing test with Windows-specific results being modified without the 
 Windows results being updated
 3) test flakiness
 
 Being in the core group seems like it would help with (1) and (2) because 
 the people who are making these changes would notice that they forgot 
 Windows. It wouldn't help with (3), of course. (We're obviously trying to 
 track down all causes of flakiness we can.)
 
 So what does it take for a builder to be a core builder? Once we know 
 this, we can hopefully focus our Windows efforts toward satisfying the 
 criteria.
 
 Thanks!
 
 -Adam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 

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


Re: [webkit-dev] All Apple Mac and Windows testers now upload crash logs

2011-03-02 Thread Adam Roben
On Mar 2, 2011, at 1:41 PM, Eric Seidel wrote:

 the EWS and commit-queue snow leopard machines do not
 seem to be copying crash logs into layout-test-results like I would
 expect:
 https://bugs.webkit.org/show_bug.cgi?id=51138
 (each of those zips are made from /tmp/layout-test-results after the test 
 run).

For those playing at home, this turned into http://webkit.org/b/55607, and 
should now be fixed.

-Adam

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


Re: [webkit-dev] Towards a unified build system

2011-03-01 Thread Adam Roben
Reducing the number of build systems is a face-meltingly worthy goal. I have 
one small question:

On Mar 1, 2011, at 4:21 AM, Adam Barth wrote:

 3) Remove the xcodeproj files from svn.webkit.org and integrate the
 generation of xcodeproj files with the WebKit build / update scripts.
 At this point, contributors will notice that something has changed
 because there'll be one less build system to worry about keeping up to
 date!

Won't contributors who don't use update-webkit/build-webkit also notice 
something has changed, because they will no longer have any project files? (I 
ask this as a contributor who doesn't use update-webkit/build-webkit.)

-Adam

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


Re: [webkit-dev] when will pages group into different PageGroup

2011-02-24 Thread Adam Roben
On Feb 24, 2011, at 1:44 AM, tomorrow chen wrote:

 I'm reading source about Page class.I found there's related class named 
 PageGroup,which seems to group different pages into different group by name.
 Different PageGroup has different user script and GroupSetting.
  
 I wonder when will the page group into different PageGroup. If there's two 
 apps based on webcore(one is browser,maybe),does this means there's two 
 PageGroup?
 In my option,GroupSetting and user script is same for all the pages in 
 browser.

Pages are assigned into a PageGroup by calling the Page::setGroupName function. 
All pages initially start in a unique PageGroup (i.e., each Page is in its own 
PageGroup). If you pass the same string to setGroupName for multiple Pages, 
those pages will then be put into the same group.

PageGroups only exist within a single process, so PageGroups in one application 
will not affect or interact with PageGroups in another application.

 Another question,shouldTrackVisitedLinks is a class member.If there's two 
 apps,and one want to disable visistedTrack(call 
 setShouldTrackVisitedLinks(false),it will influence the behavior of another 
 app?

No. This state is only stored in the current process. It does not affect other 
processes.

-Adam

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


Re: [webkit-dev] Leopard Debug

2011-02-24 Thread Adam Roben

On Feb 24, 2011, at 12:59 AM, Adam Barth wrote:

 As far I as I can tell, Leopard Debug is not consistently green:
 
 http://build.webkit.org/waterfall?show=Leopard%20Intel%20Debug%20(Build)
 
 In fact, it's been failing to build much more often than not for an
 extended period of time (i.e., several weeks).  Based on these
 observations, it should not be a core builder.  We can add it back to
 the set of core builders when it's consistently green again.  To be
 concrete, shall we say building cleanly for a week?

Sure, that sounds fine. When I added it back to the core list I expected it to 
stay green indefinitely, but clearly that was incorrect. Apparently WebCore 
just keeps growing! Sorry for the trouble.

-Adam

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


Re: [webkit-dev] Slave lost on SnowLeopard Intel Release (Build)

2011-02-24 Thread Adam Roben
On Feb 24, 2011, at 4:11 AM, Ryosuke Niwa wrote:

 I realized that the build was 13 hours behind and wasn't making any progress 
 in compiling r79464 so I force stopped the build but then the slave got lost 
 along the way.  In the retrospect, I should have been more careful.  I 
 apologize for any inconveniences caused by this but could someone please 
 restart the bot?

Looks like it's back online now. 
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Build%29

-Adam

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


Re: [webkit-dev] More information for crashing tests now available on build.webkit.org

2011-02-07 Thread Adam Roben
On Feb 7, 2011, at 7:20 AM, Alejandro Garcia Castro wrote:

 On Fri, Feb 04, 2011 at 02:25:10PM -0500, Adam Roben wrote:
 Hi all-
 
 [...]
 
 Please file any bugs you find with this feature on bugs.webkit.org,
 and CC me. Please also file bugs for any ideas you have for making
 this more useful!
 
 
 Nice, we have been running this crash service for the two gtk+ debug
 bots for some time now, it has stacks and core files, maybe it is a
 good idea if we could also integrate it the same way, if possible:
 
 http://webkit-bots.igalia.com/

You can see how the Mac/Windows ports do it by looking at 
captureSavedCrashLog($) in old-run-webkit-tests.

-Adam

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


[webkit-dev] More information for crashing tests now available on build.webkit.org

2011-02-04 Thread Adam Roben
Hi all-

The results.html pages on build.webkit.org now make it much easier to triage 
crashing tests on Mac and Windows XP (Windows Vista/7 are blocked by 
http://webkit.org/b/44135). When a test crashes, you'll see something like 
this on Mac:

 fast/events/tabindex-focus-blur-all.html  stderr  crash log 
 (com.apple.WebCore: 
 JSC::Bindings::Instance::willDestroyRuntimeObject(JSC::Bindings::RuntimeObject*)
  + 156)

…and like this on Windows:

 fast/events/tabindex-focus-blur-all.html  stderr  crash log 
 (WebKit!JSC::Bindings::Instance::willDestroyRuntimeObject+95)

The new crash log link will take you to a textual crash log for that test. 
The function name you see is our best guess at the crashing module, function, 
and offset (in decimal on Mac, hexadecimal on Windows), based on the crash log.

Please file any bugs you find with this feature on bugs.webkit.org, and CC me. 
Please also file bugs for any ideas you have for making this more useful!

-Adam

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


Re: [webkit-dev] More information for crashing tests now available on build.webkit.org

2011-02-04 Thread Adam Roben

On Feb 4, 2011, at 2:25 PM, Adam Roben wrote:

 The new crash log link will take you to a textual crash log for that test.

And on Windows, the crashing line of code is even included in the log, like 
this:

 FAULTING_SOURCE_CODE:  
105: 
106: void Instance::willDestroyRuntimeObject(RuntimeObject* object)
107: {
108: ASSERT(m_rootObject);
   109: ASSERT(m_rootObject-isValid());
110: m_rootObject-removeRuntimeObject(object);
111: m_runtimeObject.clear(object);
112: }
113: 
114: void Instance::willInvalidateRuntimeObject(RuntimeObject* object)

-Adam

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


Re: [webkit-dev] More information for crashing tests now available on build.webkit.org

2011-02-04 Thread Adam Roben
On Feb 4, 2011, at 3:29 PM, Jerome Duval wrote:

 Seems like a nice feature. Why the different bases for the offsets between 
 Mac and Windows?

That's just how the offsets are represented by default in each platform's crash 
logs. It shouldn't be hard to convert to a common base, though. Feel free to 
file a bug!

-Adam

 On 11-02-04 02:25 PM, Adam Roben wrote:
 
 Hi all-
 
 The results.html pages on build.webkit.org now make it much easier to triage 
 crashing tests on Mac and Windows XP (Windows Vista/7 are blocked by 
 http://webkit.org/b/44135). When a test crashes, you'll see something like 
 this on Mac:
 
 fast/events/tabindex-focus-blur-all.htmlstderr  crash log 
 (com.apple.WebCore: 
 JSC::Bindings::Instance::willDestroyRuntimeObject(JSC::Bindings::RuntimeObject*)
  + 156)
 
 …and like this on Windows:
 
 fast/events/tabindex-focus-blur-all.htmlstderr  crash log 
 (WebKit!JSC::Bindings::Instance::willDestroyRuntimeObject+95)
 
 The new crash log link will take you to a textual crash log for that test. 
 The function name you see is our best guess at the crashing module, 
 function, and offset (in decimal on Mac, hexadecimal on Windows), based on 
 the crash log.
 
 Please file any bugs you find with this feature on bugs.webkit.org, and CC 
 me. Please also file bugs for any ideas you have for making this more useful!
 
 -Adam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] safari extension script loading within injected file

2011-02-02 Thread Adam Roben
This list is for discussion of the development of the WebKit project itself, 
not questions about how to use WebKit (or a browser that uses WebKit, such as 
Safari). See http://webkit.org/contact.html for details. You'll have better 
luck asking in a Safari-specific venue, such as 
https://devforums.apple.com/community/safari.

-Adam

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


[webkit-dev] svn.webkit.org and nightly.webkit.org down ahead of schedule?

2011-02-02 Thread Adam Roben
Hi Bill-

svn.webkit.org is responding to pings, but svn up just hangs. And 
nightly.webkit.org responds to pings, but never finishes loading when navigated 
to in a browser. Is this expected? Do you know when they'll be available again? 
Thanks!

-Adam

On Feb 1, 2011, at 8:52 PM, William Siegrist wrote:

 We are upgrading another server tomorrow morning at 7am PST. Downtime should 
 be about an hour and I will make announcements in #webkit as usual. Mail 
 delivery to @webkit addresses and mailing lists will not happen during the 
 downtime, but mail should catch up once we come back up. Affected services 
 are:
 
 build.webkit.org
 git.webkit.org
 lists.webkit.org
 nightly.webkit.org
 
 
 Thanks
 -Bill
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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


Re: [webkit-dev] Using Visual Studio 2010 for Apple's Windows WebKit port

2011-02-01 Thread Adam Roben
On Jan 31, 2011, at 9:04 PM, Jeremy Orlow wrote:

 How hard will the transition be?  If it's going to take a lot of time and 
 cause a lot of churn anyway, would this be a good time to try and make that 
 port use GYP or CMake?  (I assume the answer is probably no, but figured it 
 was worth asking anyway. :-)

VS2010 includes a project conversion wizard that can convert projects from 
VS2005 (and presumably VS2008) format to VS2010. We've tried it previously on 
WebKit and it seemed to work just fine with only minor issues.

The goal of having fewer project files is a worthy one, however. Patrick 
Gansterer offered to code up a patch to build Apple's Windows port using the 
existing CMake build system, which will be very interesting to see!

-Adam

 On Mon, Jan 31, 2011 at 12:46 PM, Adam Roben aro...@apple.com wrote:
 On Jan 31, 2011, at 3:41 PM, Peter Kasting wrote:
 
 On Mon, Jan 31, 2011 at 12:30 PM, Adam Roben aro...@apple.com wrote:
 Please let me (and the list) know if this change will cause you trouble, and 
 if there's something we can do to make the transition easier.
 
 This may make life hard on Chromium as right now we don't support building 
 with VS2010.  We are working on adding support (I think 
 http://crbug.com/25628 may be the closest bug).  I'm not sure what time 
 frame that will happen in.
 
 I don't think we have any plans to drop VS2005 support.  If WebKit drops 
 support it may force us to do so as well.
 
 In both cases above we're not so much impacted by vcproj/sln changes (since 
 we use GYP to construct our vcproj and sln files) as we are by code changes, 
 e.g. code that requires VS2010 to build correctly.
 
 I doubt that maintaining compatibility with VS2005's compiler would be an 
 issue. As long as there's an EWS and/or buildbot to catch problems, we should 
 be able to work around any compiler differences. I didn't mean to imply that 
 we'd intentionally break compilation with VS2005's compiler; all I meant was 
 that using VS2005 to build Apple's port would no longer be supported.
 
 -Adam
 
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
 
 

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


[webkit-dev] Using Visual Studio 2010 for Apple's Windows WebKit port

2011-01-31 Thread Adam Roben
Hi all-

We'd like to switch Apple's Windows WebKit port to build with Visual Studio 
2010 sometime in the next 6-8 months, and to drop support for building with 
Visual Studio 2005 at the same time.

The biggest consequence of this will be that anyone wishing to build Apple's 
Windows port will have to switch from VS2005/VC++ Express 2005 to VS2010 or 
VC++ Express 2010. This change should not affect applications that use WebKit, 
as we don't pass memory ownership across the WebKit API boundary (i.e., 
mallocing memory inside WebKit for the application to free later, or 
vice-versa).

I wanted to send this email as a heads-up for Windows developers. People 
working on the Cairo/libcurl/CFLite port, which shares project files with 
Apple's port, need to be especially aware of this change, since it will require 
converting our .vcproj/.vsprops files to the VS2010 format.

Please let me (and the list) know if this change will cause you trouble, and if 
there's something we can do to make the transition easier. You can also comment 
in http://webkit.org/b/53445, which tracks this effort. Thanks!

-Adam

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


Re: [webkit-dev] Using Visual Studio 2010 for Apple's Windows WebKit port

2011-01-31 Thread Adam Roben
On Jan 31, 2011, at 3:41 PM, Peter Kasting wrote:

 On Mon, Jan 31, 2011 at 12:30 PM, Adam Roben aro...@apple.com wrote:
 Please let me (and the list) know if this change will cause you trouble, and 
 if there's something we can do to make the transition easier.
 
 This may make life hard on Chromium as right now we don't support building 
 with VS2010.  We are working on adding support (I think 
 http://crbug.com/25628 may be the closest bug).  I'm not sure what time frame 
 that will happen in.
 
 I don't think we have any plans to drop VS2005 support.  If WebKit drops 
 support it may force us to do so as well.
 
 In both cases above we're not so much impacted by vcproj/sln changes (since 
 we use GYP to construct our vcproj and sln files) as we are by code changes, 
 e.g. code that requires VS2010 to build correctly.

I doubt that maintaining compatibility with VS2005's compiler would be an 
issue. As long as there's an EWS and/or buildbot to catch problems, we should 
be able to work around any compiler differences. I didn't mean to imply that 
we'd intentionally break compilation with VS2005's compiler; all I meant was 
that using VS2005 to build Apple's port would no longer be supported.

-Adam

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


Re: [webkit-dev] Potential patch for building webkit on Visual Studio 2010

2010-12-15 Thread Adam Roben

On Dec 14, 2010, at 8:24 PM, Jake wrote:

 Hello,
 
 I've made some changes to the webkit trunk that allows me to build webkit 
 (more specifically QtWebkit) with Visual Studio 2010. I had to make several 
 changes to handle the ambiguous operator = error from NullPtr.h.
 
 To get the build to work I made two primary changes:
 
 First, NullPtr.h
 
 #ifndef NullPtr_h
 #define NullPtr_h
 
 // For compilers and standard libraries that do not yet include it, this adds 
 the
 // nullptr_t type and nullptr object. They are defined in the same namespaces 
 they
 // would be in compiler and library that had the support.
 
 #if !defined(_MSC_VER)
 #ifndef __has_feature
 #define __has_feature(feature) 0
 #endif
 
 #if !__has_feature(cxx_nullptr)
 
 namespace std {
 class nullptr_t { };
 }
 
 extern std::nullptr_t nullptr;
 
 #endif
 
 #elseif  _MSC_VER  1600
 
 //to maintain compatibility with previous versions of msvc
 #ifndef nullptr
 #define nullptr 0
 #endif
 
 #endif //_MSC_VER
 
 #endif
 
 
 And secondly I changed all = 0 errors to = nullptr (approximately 450 
 instances).
 
 My question is, does this look like a sound approach? If so, I'll submit a 
 patch.

It would be great to move this discussion to bugs.webkit.org, even if you 
aren't sure of the exact correct approach yet. Please file a bug there and 
attach your patch so that contributors can discuss it.

-Adam

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


Re: [webkit-dev] JSRetainPtr and JSStringRef

2010-12-15 Thread Adam Roben
On Dec 15, 2010, at 9:13 AM, John Knottenbelt wrote:

 I'm looking at adding a method on the LayoutTestController in DumpRenderTree 
 that will return a string. I see that some methods there return 
 JSRetainPtrJSStringRef and some just return JSStringRef. 
 
 Can anybody comment on when it is appropriate to return JSRetainPtr vs plain 
 JSStringRef?

JSRetainPtrJSStringRef should be used any time it is the responsibility of 
the caller to release the JSStringRef. Otherwise it is fine to use a plain 
JSStringRef.

-Adam

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


Re: [webkit-dev] WebKitTools is changing to Tools

2010-12-10 Thread Adam Roben
On Dec 10, 2010, at 5:21 PM, Eric Seidel wrote:

 Could we add a symlink before then?

That seems unlikely to work on Windows, though if the only processes that rely 
on the symlink are Cygwin-based, maaybe it will.

-Adam

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


Re: [webkit-dev] GTK+ release bots are missing results

2010-12-01 Thread Adam Roben
On Dec 1, 2010, at 11:54 AM, Martin Robinson wrote:

 For some weeks now the GTK+ release bots have been missing results.
 When you try to click on any result in results.html, there's an error
 page. I'm not sure what the issue is, but the results upload output
 looks quite sane:
 
 http://build.webkit.org/builders/GTK Linux 32-bit
 Release/builds/8174/steps/MasterShellCommand/logs/stdio
 
 It's pretty tough to debug failures on the release bot at the moment.

Perhaps the umask change that Bill Siegrist requested a month or so ago [1] was 
never made on those bots?

-Adam

1. http://article.gmane.org/gmane.os.opendarwin.webkit.devel/14798___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] wincairo buildbot failing, cannot install WebKitSupportLibrary, errors in JavaScriptCore[Generated]

2010-11-16 Thread Adam Roben

On 11/16/2010 6:42 AM, Thomas Brodt wrote:
The buildbot for the wincairo port is running again, thanks to whoever 
did repair it (Brent?).


But the build fails again, as before when it went offline.

There are errors installing the new WebKitSupportLibrary:
cp: cannot create regular file 
`D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win/Software 
License Agreement for WebKit Support Libraries.rtf': No such file or 
directory


and some file name concatenation seems to go wrong:

in JavaScriptCoreGenerated

1 xcopy /y/d/e/i ..\..\..\WebKitLibraries\win\tools 
D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win\tools

1Invalid number of parameters

and later on
in JavaScriptCore

2cat: 
D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win/tools/scripts/VERSION: 
No such file or directory
2cat: 
D:/Projects/BuildSlave/win-cairo-debug/build/WebKitLibraries/win/tools/scripts/COPYRIGHT-END-YEAR: 
No such file or directory

2Compiling resources...
2.\JavaScriptCore.rc(17) : error RC2127 : version WORDs separated by 
commas expected
2.\JavaScriptCore.rc(18) : error RC2127 : version WORDs separated by 
commas expected
2.\JavaScriptCore.rc(37) : error RC2104 : undefined keyword or key 
name: __COPYRIGHT_YEAR_END_TEXT__


As I am not familiar with that, can anyone please look at it?


All of these problems seem to have the same cause: the value of the 
WEBKITLIBRARIESDIR environment variable is quoted, but should not be.


-Adam

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


  1   2   3   4   >