Re: [webkit-dev] Windows Bots Are Green!
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)
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)
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
(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
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
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
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
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
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)
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
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
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)
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
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!
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
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
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
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
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
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
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!
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
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
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
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
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)?
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
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
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
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
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
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)
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
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
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] Switching to new-run-webkit-tests
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
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)
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
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
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
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?
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?
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
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
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
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
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
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
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
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
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] New feature - MHTML support
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
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
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
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
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
[webkit-dev] All webkit.org services seem to be down
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
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?)
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
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
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?
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
-Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progress
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
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
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
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
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] SnowLeopard debug buildbot not there
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
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
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Ϟ\xB4kO\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\xDB x\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
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?
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
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
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
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
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
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
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] Leopard Debug
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)
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
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
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
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
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
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?
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
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
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
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
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
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
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
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]
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
Re: [webkit-dev] trouble installing tools
On Oct 28, 2010, at 4:16 PM, software visualization wrote: My issue is, no such path 9or similar) exists on my machine, that is C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\mfc does not exist and C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include does not exist and C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\ does not exist and C:\Program Files\ *any similarly named or likely path involving Microsoft anything* \ Include Have you tried looking in C:\Program Files (x86) instead? If that works we should consider updating the website. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitAuxiliaryLibrary and WebKitSupportLibrary have been updated
Hi all- WebKitAuxiliaryLibrary and WebKitSupportLibrary (two of the prerequisites for building Apple's Windows port of WebKit) have been updated recently. The former will be downloaded automatically when you run update-webkit, but the latter will need to be downloaded manually. You'll see instructions for doing so when you run build-webkit. I just wanted to give a heads-up. Please let me know if you run into any trouble. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitAuxiliaryLibrary and WebKitSupportLibrary have been updated
On 10/20/2010 3:22 AM, Thomas Brodt wrote: Hi all the build bot for the wincairo build also fails because of the library. (WebKitSupportLibrary.zip is out-of-date.) As I don't know how to update that, maybe somebody else can do that? Whoops, I didn't realize that that bot would be affected. Hopefully Brent Fulgham can update it soon. -Adam Am 20.10.2010 10:34, schrieb Adam Roben: Hi all- WebKitAuxiliaryLibrary and WebKitSupportLibrary (two of the prerequisites for building Apple's Windows port of WebKit) have been updated recently. The former will be downloaded automatically when you run update-webkit, but the latter will need to be downloaded manually. You'll see instructions for doing so when you run build-webkit. I just wanted to give a heads-up. Please let me know if you run into any trouble. -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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Safari for Windows symbol server updated
The Safari for Windows symbol server has been updated with symbols for all releases through Safari 5.0.2. You can find instructions for using the symbol server at http://developer.apple.com/internet/safari/windows_symbols_agree.html. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review tool changes
On Sep 20, 2010, at 2:34 PM, Oliver Hunt wrote: I really would like to be able to select some text and add a comment that uses the selection as context, a single line of context is frequently insufficient, this is about the only thing that still makes the new review tool less effective than the old review mechanism (for me at least). This already works. Just click-and-drag on the line numbers of the lines you want to include in the context. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
