Re: [webkit-dev] EWS commenting about ancient patches
Hi, EWS picks up all patches with r? flag. Mac WK2 EWS is a brand new EWS bot, that's why it tested ancient patches and commented their bugs. It finished processing ancient patches, so it won't be problem in the future. br, Ossy Alexey Proskuryakov írta: On several occasions over the last few days, I noticed EWS commenting in bugs that didn't have any recent activity, e.g. https://bugs.webkit.org/show_bug.cgi?id=87527. Is EWS picking ancient patches, or is it posting comments to wrong bugs? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
Hi, Shouldn't we restrict modifying the wiki for contributors in commmiters.py only? Or what if adding a captcha and mail verification for registering to trac? br, Ossy Andras Becsi írta: Hi, On 15 December 2012 20:56, William Siegrist wsiegr...@apple.com mailto:wsiegr...@apple.com wrote: There was a typo in the trac config that prevented the plugin from loading. Should be fixed now. Not sure how, but although mousew...@yahoo.com mailto:mousew...@yahoo.com is listed in the bad content list, spamming[1] is still regular from this e-mail address. [1] https://trac.webkit.org/wiki/WebInspector?action=history /Andras -Bill On Dec 15, 2012, at 6:59 AM, Andras Becsi abe...@webkit.org mailto:abe...@webkit.org wrote: Hi, I think the spam filter plugin might not be enabled again since there is spamming going on [1] on the wiki from at least one e-mail address that is already listed on the bad content list. Could someone check this please? [1] http://trac.webkit.org/wiki/WebInspector?version=60 /Andras On 18 September 2012 18:06, William Siegrist wsiegr...@apple.com mailto:wsiegr...@apple.com wrote: The spam filter plugin had not been installed on the new hardware, but I just installed it, so the spamming should be better now. You can add new addresses or patterns to the BadContent wiki page for any new spam. Previously I had kept all of the Mac OS Forge BadContent lists in sync, but with the new hardware the project can manage its own BadContent page now. https://trac.webkit.org/wiki/BadContent -Bill On Sep 18, 2012, at 4:52 AM, Andras Becsi abe...@webkit.org mailto:abe...@webkit.org wrote: Hi, On 18 September 2012 13:47, Osztrogonac Csaba o...@inf.u-szeged.hu mailto:o...@inf.u-szeged.hu wrote: Hi, Can't we add a captcha to the registration form of the trac to block SPAM bots? Would be good because spamming seems to escalate lately. Some more addresses that regularly submitted spam links in recent months: sussane_...@hotmail.com mailto:sussane_...@hotmail.com toybaby...@gmail.com mailto:toybaby...@gmail.com janeparker...@gmail.com mailto:janeparker...@gmail.com ra...@mailinator.com mailto:ra...@mailinator.com dasta...@o2.pl mailto:dasta...@o2.pl doris.gr...@gmail.com mailto:doris.gr...@gmail.com w...@marrant.org mailto:w...@marrant.org dietas...@hotmail.com mailto:dietas...@hotmail.com cont...@freemobileactu.com mailto:cont...@freemobileactu.com uuo...@gmail.com mailto:uuo...@gmail.com /Andras br, Ossy Andras Becsi írta: Hi, Could someone who has the needed credentials ban willetta...@yahoo.com mailto:willetta...@yahoo.com carstrow...@yahoo.com mailto:carstrow...@yahoo.com tonygua...@gmail.com mailto:tonygua...@gmail.com mtjohnwo...@gmail.com mailto:mtjohnwo...@gmail.com lindahom...@gmail.com mailto:lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] commit-queue offline for the rest of the day
Hi, Is it possible if http://git.chromium.org/external/Webkit is broken? Or somebody pushed non fast forward commits? Maybe a manual kick can help: git reset --hard HEAD~1000 git clean -dxf git pull These lines always helped me if something went wrong on my git repository. Ossy Eric Seidel írta: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is UseV8.cmake still used?
Hi, We were interested in it, but not now. All Qt-V8 related codepaths were removed from tree after WebKit2 with V8 was rejected by the community: http://lists.webkit.org/pipermail/webkit-dev/2012-April/thread.html#20407 http://lists.webkit.org/pipermail/webkit-dev/2012-May/thread.html#20869 http://lists.webkit.org/pipermail/webkit-dev/2012-June/thread.html#20903 Otherwise QtWebKit doesn't use cmake, but qmake. ;-) br, Ossy Ryosuke Niwa írta: The last time I checked, Qt folks were interested in being able to use V8 as well as JSC. I'm not sure if their needs have changed since then. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Does anyone still use the TestFailures app?
Hi, We use it and http://build.webkit.sed.hu/TestFailures/ for gardening, it is the first step we usually do if determining who broke what about the waterfall isn't trivial. On http://build.webkit.sed.hu/TestFailures/ we use a very old copy of test failures and it still works fine. Dirk Pranke írta: http://build.webkit.org/TestFailures/ I think Adam Roben was working on this a year or so ago. It appears to be broken at the moment (it's likely that I broke it, in fact), but before I spend much time fixing it I thought I'd check. It works for me more or less, but I got strange link names: http/tests/security/cross-origin-plugin-private-browsing-toggled.html: [object DocumentFragment] Maybe one of the garden-o-matic patches broke it somehow. I've never actually used it myself, so I'm not sure what all it was supposed to do; it looks like it overlaps in functionality some with the flakiness dashboard, but was probably written before the flakiness dashboard worked with the build.webkit.org bots and everyone was converted to using NRWT. If anyone is still using it (or would if it was actually working) in preference to the flakiness dashboard, can you let me know why? We still use it, because it is very simple, it works almost always, it isn't hakced day by day and its output is very very simple. We get the result - which revision broke a given test, which are the related bug reports - with _one_ click on the name of the slave. It is more complicated to do same thing on flakiness dashboard: - select webkit.org from group - select a given slave - select tests with wrong expectations - (unselect flaky) - find manually the last good revision for test by test but it is _impossible_ if the breakage is too old Ideally I'd like to get rid of it and roll any good features it had into the flakiness dashboard, but I'm happy to fix it and/or keep it around if it does other things I'm not aware of or if people are still using it. Please don't remove this good and simple tool, we use it day by day. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] commit queue is stucked
Hi, It seems CQ is stucked 2 days ago: http://queues.webkit.org/queue-status/commit-queue Is there anyone here to be able to kick it/them? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Idle build bots?
It seems, the buildbot master needs a restart. Bill or Lucas, could you check it, please? Raphael Kubo da Costa írta: Hey there, Looking at build.webkit.org I see many white bubbles in all bots, and the most recent commits have been pending in them for a few hours. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] wiki spammers
Hi, Can't we add a captcha to the registration form of the trac to block SPAM bots? br, Ossy Andras Becsi írta: Hi, Could someone who has the needed credentials ban willetta...@yahoo.com carstrow...@yahoo.com tonygua...@gmail.com mtjohnwo...@gmail.com lindahom...@gmail.com from trac because the wiki receives regular spam updates from these addresses. /Andras ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to diagnose a failing early-warning failure that passes on my machine?
I can't remember if it was disabled, and the result uploader code is still here: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/tool/commands/earlywarningsystem.py#L90 Ossy Adam Barth írta: I think we disabled that because we didn't want to spam the bugs.webkit.org database with tons of zip files. Adam On Tue, Sep 11, 2012 at 3:25 PM, Eric Seidel e...@webkit.org wrote: The cr-linux bots used to upload the results to the bug itself. Maybe that changed? On Tue, Sep 11, 2012 at 3:20 PM, Adam Barth aba...@webkit.org wrote: Currently, there's no way to get results from the bots. You might need to land your patch and see what the bots on build.webkit.org tell you. Adam On Tue, Sep 11, 2012 at 2:45 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Bug 96040 (https://bugs.webkit.org/show_bug.cgi?id=96040) I posted a patch. The little oval thingys are all green except cr-linux. Clicking the failing oval gives a long file including these lines: Regressions: Unexpected text failures : (1) inspector/extensions/extensions-panel.html = TEXT This is a file I changed so I would like to know what failed in that test. It passes on my linux box. Any hints? jjb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi All, I'd like to inquire about the future of MIPS and SH4 assemblers. A long time ago we had buildbots for MIPS and SH4 platforms (hosted by Holger). But their last builds were at 29th June, machine were stopped, bots were removed from build.webkit.org (2 months before!). Is there anyone interested in maintaining MIPS and SH4 buildbots (and probably EWS bots) to catch build failures early? Gábor is working on fixing https://bugs.webkit.org/show_bug.cgi?id=79040 and it seems the fix will affect all assemblers. But I don't think if it is a good idea to try to fix MIPS and SH4 assemblers blindly without EWS and buildbots. And who knows if MIPS and SH4 builds work now or not? br, Ossy Filip Pizlo írta: Hi all, We are actively trying to improve the WebKit JavaScript engine (JavaScriptCore), with new debugging, profiling, memory efficiency, and performance features. Because JavaScriptCore is a JIT-based engine, this inevitably means doing JIT work, which in turn includes adding new instructions to the JIT assemblers and changing the API between the assemblers and the JIT. Currently, the maintenance situation in the assembler layer is not great. We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then we have three assemblers that appear to be on life support: legacy (non-THUMB2, pre-v7) ARM, SH4, and MIPS. It is increasingly painful to maintain these three barely-supported assemblers. None of these assemblers has been updated to support the new JIT or interpreter infrastructure, and there appears to be no ongoing effort to do so. That means that for progress to be made on X86 and ARMv7, we need to increasingly scatter #if ENABLE(...) noise throughout the system to keep those other assemblers building. Neither the active JavaScriptCore contributors, nor those running the bots for those hardware platforms, appear to have much interest in maintaining those assemblers, other than the occasional build fix. This is not a good situation to be in. So, I am curious: is anyone shipping with the legacy ARM assembler, the MIPS assembler, or the SH4 assembler? As a secondary question, if you are shipping the legacy ARM assembler, are you doing so because you have legacy ARM hardware or because you have not had the chance to switch to the new ARM assembler in your codebase? -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
You can mark the failing tests as failing tests or skip them in TestExpectations/Skipped with the change. And then you can rebase and unskip them without disturbing the bot. Dominik Röttsches írta: Hi Dirk, On 08/22/2012 10:49 PM, Dirk Pranke wrote: The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts. Can the failure limit be increased to 1 for example? Levi/Emil were saying the rebaseline touches about 8000 cases. Otherwise we'd have to go through a more complicated process like Zan explains. Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
and again ... Osztrogonac Csaba írta: Hi, ... and again and again ... Bill, Mark or Lucas, could you check it, please? Have you got any idea why does it happen regularly? br, Ossy Osztrogonac Csaba írta: bugs.webkit.org and trac.webkit.org is unavailable again. :( ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
Hi, ... and again and again ... Bill, Mark or Lucas, could you check it, please? Have you got any idea why does it happen regularly? br, Ossy Osztrogonac Csaba írta: bugs.webkit.org and trac.webkit.org is unavailable again. :( ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?
Hi, bugs.webkit.org and trac.webkit.org is unavailable again. :( Could you check it, please? br, Ossy Osztrogonac Csaba írta: It seems bugs.webkit.org and trac.webkit.org is unavailable now. (at least from Hungary) Have you got any idea what happened? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] broken build.webkit.org?
Hi, It seems something happened with build.webkit.org. The latest build was http://trac.webkit.org/changeset/124728 on slaves. And now there are 7-10 pending builds on each slaves, but nothing happens. I think a master restart would solve this problem. Bill or Lucas, could you check what happened, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] broken build.webkit.org?
It works again after http://build.webkit.org/changes/5632 Osztrogonac Csaba írta: Hi, It seems something happened with build.webkit.org. The latest build was http://trac.webkit.org/changeset/124728 on slaves. And now there are 7-10 pending builds on each slaves, but nothing happens. I think a master restart would solve this problem. Bill or Lucas, could you check what happened, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] broken build.webkit.org?
Hi, Your patch is unrelated to build.webkit.org breakage. Your patch only revealed a bug near watchlist. I filed a new bug for it: https://bugs.webkit.org/show_bug.cgi?id=93250 br, Ossy Gyuyoung Kim írta: Hello Ossy, I'm sorry. It looks my commit made this problem. I just rolled out my r124728 in r124738. But, it is not adjust to buildbot first. Does anyone how to solve this problem? I'm sorry again. Gyuyoung. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Osztrogonac Csaba Sent: Monday, August 06, 2012 4:17 PM To: WebKit Development Subject: [webkit-dev] broken build.webkit.org? Hi, It seems something happened with build.webkit.org. The latest build was http://trac.webkit.org/changeset/124728 on slaves. And now there are 7-10 pending builds on each slaves, but nothing happens. I think a master restart would solve this problem. Bill or Lucas, could you check what happened, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT
Hi, With the new Trac I noticed two little bit annoying thing: language: -- trac.webkit.org uses my browsers default language. Hungarian translation of Trac is terrible. :( Of course I could change my browsers default language, but it would affect all other websites too ... Can't we make Trac to use english always? I don't think if any developer really wants to use Trac in his/her native language. Author name: - https://trac.webkit.org/browser/trunk As far as I remember before the update we could see the full email addresses of the authors. Now we can see only the email addresses before @. It makes harder to identify the author. Can we get the full mail address (and/or IRC nick, full name) somehow? (It seems we still get full mail addresses for wiki: https://trac.webkit.org/wiki/WikiStart?action=history ) br, Ossy William Siegrist írta: All done. -Bill On Jul 26, 2012, at 12:32 PM, William Siegrist wsiegr...@apple.com wrote: The Trac and subversion servers are being migrated to the new hardware Friday (tomorrow) morning at 7am PDT. The whole process should take 1-2 hours. Trac and svn will be unavailable for most of that time. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT
Many thanks, it works for me. ( similar to timezone settings :) ) Yuta Kitamura írta: As a workaround, try this: log in to trac, and visit https://trac.webkit.org/prefs/language to change the UI language. Apparently this preference page is hidden, but seems to work. Thanks, Yuta On Mon, Aug 6, 2012 at 8:16 PM, Osztrogonac Csaba o...@inf.u-szeged.hu mailto:o...@inf.u-szeged.hu wrote: Hi, With the new Trac I noticed two little bit annoying thing: language: -- trac.webkit.org http://trac.webkit.org uses my browsers default language. Hungarian translation of Trac is terrible. :( Of course I could change my browsers default language, but it would affect all other websites too ... Can't we make Trac to use english always? I don't think if any developer really wants to use Trac in his/her native language. Author name: - https://trac.webkit.org/__browser/trunk https://trac.webkit.org/browser/trunk As far as I remember before the update we could see the full email addresses of the authors. Now we can see only the email addresses before @. It makes harder to identify the author. Can we get the full mail address (and/or IRC nick, full name) somehow? (It seems we still get full mail addresses for wiki: https://trac.webkit.org/wiki/__WikiStart?action=history https://trac.webkit.org/wiki/WikiStart?action=history ) br, Ossy William Siegrist írta: All done. -Bill On Jul 26, 2012, at 12:32 PM, William Siegrist wsiegr...@apple.com mailto:wsiegr...@apple.com wrote: The Trac and subversion servers are being migrated to the new hardware Friday (tomorrow) morning at 7am PDT. The whole process should take 1-2 hours. Trac and svn will be unavailable for most of that time. -Bill _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Trac/Svn Migration - Friday the 27th, 7-9am PDT
Hi, Could you kick git.webkit.org please? It is stucked on r123874, but svn.webkit.org is on r123878 Ossy William Siegrist írta: All done. -Bill On Jul 26, 2012, at 12:32 PM, William Siegrist wsiegr...@apple.com wrote: The Trac and subversion servers are being migrated to the new hardware Friday (tomorrow) morning at 7am PDT. The whole process should take 1-2 hours. Trac and svn will be unavailable for most of that time. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org down?
Hi, In this case we could have avoided the breakage with running this unittest. Can we make the master somehow run this unittest before restarting itself? br, Ossy Eric Seidel írta: One can run: http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/mastercfg_unittest.py to test the master locally, but that's all I know of. On Thu, Jun 21, 2012 at 11:15 AM, Sergio Villar Senin svil...@igalia.com wrote: En 21/06/12 19:54, William Siegrist escribiu: On Jun 21, 2012, at 10:43 AM, Jon Lee jon...@apple.com wrote: Is something being upgraded right now? No, the config file has a problem in it which is unrelated to our upgrade as far as I can tell. I'm trying to track down what happened. $ buildbot checkconfig Do we have any tool that allows to check locally changes in the slaves configuration? BR ___ 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
Re: [webkit-dev] Proposal to add 'compile-tools' step to the build bots
Hi, The idea is good, we should catching build errors as soon as possible. But why don't you make the Apple's part of build-webkit to build DRT/WTR/ImageDiff/testbrowser/... too? I checked the bot logs and it seems that all port (Qt,GTK,Chromium,EFL) except Apple ports build everything in the compile-webkit step. As far as I remember, the tools components build separately, because only developers (who would like to run tests) and buildbots need DRT and friends. What if adding --developer-build / --build-tools / ... or any similar option to build-webkit instead of master.cfg hacking? br, Ossy Eric Seidel írta: Sounds like a good idea to me. Many ports already build DumpRenderTree, etc. as part of build-webkit. (Gtk/Qt come to mind.) http://trac.webkit.org/browser/trunk/Tools/Scripts/build-dumprendertree#L74 On Tue, Jun 19, 2012 at 1:33 PM, Lucas Forschler lforsch...@apple.com wrote: Hello all, Currently our build bots have a compile-webkit step. This step does NOT build any of the tools used by the testers. Instead, the testers are building the tools at execution time. I would like to add a compile-tools step to run directly after the compile-webkit step. The tools components would be packaged up into the archive, and then downloaded by the test bots for execution. This will allow us to catch any breaks in the tools in the compile phase rather than the test phase. I plan to add this to build.webkit.org and will send a patch out for review. Please let me know if you have any interest or concerns in the implementation. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org down for upgrade
Hi, Sorry for the late response, I didn't have to much time last week. But fortunately I managed to fix it today, and uploaded the proposed patches: - Unhide login form on the build.webkit.org - https://bugs.webkit.org/show_bug.cgi?id=88981 - Update buildbot master in autoinstaller to match build.webkit.org - https://bugs.webkit.org/show_bug.cgi?id=88992 - Add ForceScheduler to build.webkit.org - https://bugs.webkit.org/show_bug.cgi?id=88982 - master.cfg cleanup, remove unnecessary workaround - https://bugs.webkit.org/show_bug.cgi?id=88994 br, Ossy Lucas Forschler írta: Hi Ossy, Can you send me the bugzilla link for the ForceScheduler work? Thanks, Lucas On May 31, 2012, at 9:22 AM, Lucas Forschler wrote: HI Ossy, I did notice the display order change as well. I think I am going to open a bug to rename all of the Apple bots to prefix them with 'Apple'. We (at Apple) would like to get our bots into a more conforming naming convention. I realize that won't solve the problem with having a specific order for your bots, but it will at least get everything grouped together. I'm slightly opposed to rolling out the natural sorting as you suggest below... I think that will be short-lived and when buildbot 0.9.x is available, we may not have this option. I think we should be forward thinking here and try not to work around this. I can be convinced to make the change if there is additional support for rolling out the natural sorting. Thanks for looking into the ForceScheduler. Hopefully we can get that up and running quickly. So far it appears we don't have any bots stuck in trigger mode. Please let me know if you see any. I am hoping that issue is now solved for good. Thanks, Lucas On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote: Lucas Forschler írta: to 0.8.6p1 Will be back online when complete. Lucas Hi All, Unfortunately there are too annoying bugs introduced with upgrading build master to 0.8.6p1 : Problem 1 -- Builders are alphabetically ordered on http://build.webkit.org/waterfall instead of the given order in our config.json. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Builders are no longer displayed in the order they were configured. This was never intended behavior, and will become impossible in the distributed architecture planned for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, but with numeric segments sorted numerically. I think the new alphabetical order is so confusing. For example Apple's Lion bots are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know that we can see category=AppleMac, category=Qt, ... , but the order of the bots in a given category is important for us too. I don't think that an artifical renaming would be a good solution to get the order what we want. (Because we would have to rename bots in all scripts, we would have loose the history, ...) What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this bug/feature? Here is a simple patch to do it: diff --git a/buildbot-0.8.6p1/buildbot/status/master.py b/buildbot-0.8.6p1/buildbot/status/master.py index e803133..e60ab06 100644 --- a/buildbot-0.8.6p1/buildbot/status/master.py +++ b/buildbot-0.8.6p1/buildbot/status/master.py @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): def getBuilderNames(self, categories=None): if categories == None: -return util.naturalSort(self.botmaster.builderNames) # don't let them break it +return self.botmaster.builderNames # don't let them break it l = [] # respect addition order @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): bldr = self.botmaster.builders[name] if bldr.config.category in categories: l.append(name) -return util.naturalSort(l) +return l def getBuilder(self, name): Problem 2 -- There isn't force build possibility anymore. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Forced builds now require that a ForceScheduler be defined in the Buildbot configuration. It can be solved simple with adding ForceScheduler. I'm going to file a bug report and prepare a patch to fix it soon. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] can we stop using Skipped files?
Hi, Dirk Pranke írta: I believe most if not all of the ports have started using either TestExpectations files or a combination of TestExpectations files (except for the Apple Win port). Can we explicitly switch to the TestExpectations files at this point and drop support for Skipped files on the other ports (and perhaps disable old-run-webkit-tests for all but apple win)? Until NRWT can't handle cascaded TestExpectations - https://bugs.webkit.org/show_bug.cgi?id=65834, Qt port can't drop supporting Skipped files. We have many tests skipped in qt-5.0, qt-5.0-wk1, qt-5.0-wk2, wk2 Skipped lists. We can't migrate all of them to the only one TestExpectations. And I disagree with disabling ORWT at all. Qt port still support using ORWT locally. It is better for gardening than NRWT. NRWT regularly has problems with generating new results for a given platform dir (qt,qt-5.0,qt-5.0-wk1,...), it doesn't support the good --skipped=only option . If folks don't want to use it, just not use, but disabling for everyone by fiat isn't a friendly thing. If not, what needs to happen so that we can do that? Do we need to land more of the discussed changes to the syntax of the TestExpectations file? Anything else? It would be nice to get rid of the complexity (both in the code and in our heads) if we can. -- Dirk br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org down for upgrade
Lucas Forschler írta: to 0.8.6p1 Will be back online when complete. Lucas Hi All, Unfortunately there are too annoying bugs introduced with upgrading build master to 0.8.6p1 : Problem 1 -- Builders are alphabetically ordered on http://build.webkit.org/waterfall instead of the given order in our config.json. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Builders are no longer displayed in the order they were configured. This was never intended behavior, and will become impossible in the distributed architecture planned for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, but with numeric segments sorted numerically. I think the new alphabetical order is so confusing. For example Apple's Lion bots are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know that we can see category=AppleMac, category=Qt, ... , but the order of the bots in a given category is important for us too. I don't think that an artifical renaming would be a good solution to get the order what we want. (Because we would have to rename bots in all scripts, we would have loose the history, ...) What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this bug/feature? Here is a simple patch to do it: diff --git a/buildbot-0.8.6p1/buildbot/status/master.py b/buildbot-0.8.6p1/buildbot/status/master.py index e803133..e60ab06 100644 --- a/buildbot-0.8.6p1/buildbot/status/master.py +++ b/buildbot-0.8.6p1/buildbot/status/master.py @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): def getBuilderNames(self, categories=None): if categories == None: -return util.naturalSort(self.botmaster.builderNames) # don't let them break it +return self.botmaster.builderNames # don't let them break it l = [] # respect addition order @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): bldr = self.botmaster.builders[name] if bldr.config.category in categories: l.append(name) -return util.naturalSort(l) +return l def getBuilder(self, name): Problem 2 -- There isn't force build possibility anymore. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Forced builds now require that a ForceScheduler be defined in the Buildbot configuration. It can be solved simple with adding ForceScheduler. I'm going to file a bug report and prepare a patch to fix it soon. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] AppleWin Bot is sick?
Hi, I think the Windows tester bot is bigger problem if you would like to unskip/rebase tests, because it exits early long long time ago because of too many failing tests. http://build.webkit.org/builders/Windows%207%20Release%20%28Tests%29/builds/24196 fast/repaint/moving-shadow-on-path.html was the latest test ran, and then exited after 11254 tests. So the test coverage equals to zero after fast/repaint/ tests. PS: At least the builder bot works again. ;-) br, Ossy Eric Seidel írta: http://build.webkit.org/builders/Windows%20Release%20%28Build%29 Looks like it's 60 hours behind? I was looking into unskipping some tests on windows to get the results from the bots, but that seems infeasible. :) More generally it seems that bot may be borked? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SVN mirrors (ex*.webkit.org is down)
Hi All, Nowadays there were too many svn.webkit.org downtime which made folks and buildbots many times so sad (and rm -rf and new checkout). I have a constructive proposal how can we make the world better. I started to experiment how can we setup read-only SVN mirror(s) and how can we make buildbots use them instead of the master svn.webkit.org server. Now we have an internal SVN mirror for our 14 buildslaves on build.webkit.sed.hu. They work quite stable 2 weeks ago. And we are going to make our 7 buildslaves on build.webkit.org too to use our SVN mirror. I created a patch for the master.cfg of build.webkit.org to make it possible to add more and more SVN mirrors to make buildslaves much more faster and unburden the regularly overloaded svn.webkit.org server. Here is the bug report and the first WIP (but working stable) patch: [Bug 85887] Add SVN mirror handling feature to build.webkit.org https://bugs.webkit.org/show_bug.cgi?id=85887 Feedbacks are welcome. PS. Now a new checkout is 3-5 minutes for us instead of 2-3-4 hours. ;-) br, Ossy William Siegrist írta: All services have been restored. -Bill On May 8, 2012, at 5:52 AM, Balazs Kelemen wrote: On 05/08/2012 01:40 PM, Alexis Menard wrote: Hi, Many contributors in #webkit have problems to connect to bugs.webkit.org. Wiliam could you look at it? Thanks. Problems here at Szeged as well. Trac, svn, bugzilla is dumb, however I have no problem with #webkit. On Thu, Jan 19, 2012 at 7:51 PM, Jesus Sanchez-Palencia je...@webkit.org wrote: It's back! :) cheers, jesus On Thu, Jan 19, 2012 at 7:26 PM, William Siegristwsiegr...@apple.com wrote: I think you have the same problem as Gustavo. His email to webkit-dev seems to imply a problem in between Brazil and webkit.org. -Bill On Jan 19, 2012, at 2:00 PM, Alexis Menard wrote: Hi, I can't also access from home : IP - 186.215.1.122 Thanks. On Thu, Jan 19, 2012 at 6:05 PM, William Siegristwsiegr...@apple.com wrote: If you are still having trouble access the site, send me your IP address and I will see if its anything on the server. -Bill On Jan 19, 2012, at 12:34 PM, Jesus Sanchez-Palencia wrote: I'm also in Brazil and I can confirm it doesn't work for me as well. I guess kov is also in Brazil and I just saw him mentioning on IRC that both bugs.webkit.org and git.webkit.org are timing out... Cheers, Jesus On Thu, Jan 19, 2012 at 5:24 PM, Philip Rogersp...@google.com wrote: http://www.downforeveryoneorjustme.com/ (It's up for me too). On Thu, Jan 19, 2012 at 3:22 PM, Jarred Nichollsjar...@webkit.org wrote: On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.org wrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, ...). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Qt Mac buildbot got crazy
Hi All, it seems Qt Mac bot got crazy and signals false build fails regularly: ../../../../Source/WebCore/bridge/qt/qt_runtime.cpp: In function 'bool JSC::Bindings::isJSUint8ClampedArray(JSC::JSValue)': ../../../../Source/WebCore/bridge/qt/qt_runtime.cpp:142: error: 'JSUint8ClampedArray' is not a class or namespace Please ignore this message. Alexis, could you stop your bot not to confuse folks with false alarms until proper fix? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Handling failing reftests
Hi All, I ran into a failing reftest and I didn't find a proper way for handling it. fast/multicol/cell-shrinkback.html is a new reftest introduced in http://trac.webkit.org/changeset/113738 . But unfortunately it fails almost everywhere (Chromium, GTK, Qt). Chromium guys added platform specific png files into platform/chromium-linux and platform/chromium-win directories - http://trac.webkit.org/changeset/113790 I tried to do same thing for Qt port, but the test still fails - http://trac.webkit.org/changeset/113869 It seems NRWT ignores expected png and txt files for reftests at all. And now I found that it is added to the test_expectations.txt for Chromium: http://trac.webkit.org/changeset/113797/trunk/LayoutTests/platform/chromium/test_expectations.txt So what is the proper way for handling failing reftests? In this case isn't possible if the reftest is incorrect, because it fails almost on all platform, but Mac? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org seems down?
Take it easy, Eric! No trac, no SVN server, no commit, no regression, no problem. ;-) Eric Seidel írta: http://trac.webkit.org/ is failing to load for me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New Qt-WK2 EWS
Hi WebKittens, Today morning we started a new EWS to help your WebKit2 development. It is a build only EWS, which builds QtWebKit (WK1 and WK2 too) with the latest stable Qt5 hash which is used by all QtWebKit developer. The new EWS can be found here: http://queues.webkit.org/ and you will see its results on bugzilla's qt-wk2 status bubble. (After it finished testing the long initial r? queue) If you would like to reproduce its result locally, you need the latest stable Qt5. You can find its hash and the script I used to build Qt5 here: - https://github.com/ossy-szeged/qt5-tools/blob/master/build-qt5-env - https://github.com/ossy-szeged/qt5-tools/blob/master/build-qt5.sh br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] svn.webkit.org
Hi, It seems Qt bots and developers are banned from svn.webkit.org. :((( Could you remove 160.114.0.0/16 network from the ban list, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org
Hi All, To avoid overloading svn.webkit.org again and again with zillion svn checkout after rm -rf-ed working copies on the bots, I stopped all of our clobbered buildbot. After unbanning our network, I'll copy a locally tar-ed WebKit-svn copy to all bots and then restart them one by one not to overload svn.webkit.org. And I'm thinking about how can we make buildbots more robust in the future. My first idea is that we should setup git mirrors for all WebKit port, and then make buildbots use these mirrors instead of svn.webkit.org. To do it, we need to modify the master.cfg a little bit. - class Factory(factory.BuildFactory): def __init__(self, platform, configuration, architectures, buildOnly, features=None, **kwargs): factory.BuildFactory.__init__(self) self.addStep(ConfigureBuild, platform=platform, configuration=configuration, architecture= .join(architectures), buildOnly=buildOnly, features=features) self.addStep(CheckOutSource) self.addStep(KillOldProcesses) ... - To migrate the bots simple from svn to git isn't a good solution, because in this case we'll loose the svn revision number on the waterfall. My idea is that replace the self.addStep(CheckOutSource) to calling a shell/perl/python script which updates the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the following way: - git fetch - git reset --hard `git svn find-rev rsvn-revision-number-got-from-the-master` I'm going to implement this initial git updater script this week and try to migrate our bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can make build.webkit.org slaves to use it too. How does it sound? Any better idea? br, Ossy Osztrogonac Csaba írta: It seems Qt bots and developers are banned from svn.webkit.org. :((( Could you remove 160.114.0.0/16 network from the ban list, please? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org
Mark Rowe írta: On 2012-03-01, at 03:37, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: After unbanning our network, I'll copy a locally tar-ed WebKit-svn copy to all bots and then restart them one by one not to overload svn.webkit.org. You can get a relatively up to date working copy from http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2. We always have relatively up-to-date working copy. It is faster then downloading from you. ;) (I tried to download this nightly and the ETA is ~3 hours ...) Additionally we use svn 1.7 (to make our bots faster, and less IO intensive) which has different working copy than svn 1.6 . And I'm thinking about how can we make buildbots more robust in the future. My first idea is that we should setup git mirrors for all WebKit port, and then make buildbots use these mirrors instead of svn.webkit.org. To do it, we need to modify the master.cfg a little bit. There are two different options that we're investigating to address this thundering herd problem that tends to kill SVN after buildbot downtime: 1) Teach build slaves to fetch and unpack http://nightly.webkit.org/files/WebKit-SVN-source.tar.bz2 rather than using svn checkout. To do it, all slave must use same svn version. 2) Add additional hardware and load-balance svn.webkit.org across several machines so that the spike in load is distributed. It is a good idea. ;) To migrate the bots simple from svn to git isn't a good solution, because in this case we'll loose the svn revision number on the waterfall. My idea is that replace the self.addStep(CheckOutSource) to calling a shell/perl/python script which updates the local copy from the Qt/GTK/Apple/Chromium/... git mirror with the following way: - git fetch - git reset --hard `git svn find-rev rsvn-revision-number-got-from-the-master` I'm going to implement this initial git updater script this week and try to migrate our bots on build.webkit.sed.hu to use it. If we manage to make it stable, we can make build.webkit.org slaves to use it too. How does it sound? Any better idea? Pulling from git instead of SVN is certainly worth considering, but I wouldn't be surprised if this simply shifted the performance issue from svn.webkit.org to git.webkit.org. No, I don't want to shift the load from svn.webkit.org to git.webkit.org. But make all port maintainer to use their own git mirror for the bots instead of the root svn/git.webkit.org. Mirroring git.webkit.org locally is the simplest thing in the world. :) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Hi, Marc-Antoine Ruel írta: Here are some things that may help; *#1 svn server overloading when all the slaves bootstrap at the same time* The only good work around is to keep an internal read-only svn-mirror that the slaves use instead of the real svn server. This means that builds must be triggered on the svn-mirror, which may incurs a delay of a few seconds, due to svnsync polling. My hypothesis is that svn has repo-wide locks while committing, so when there are a lot of readers, they are all starved whenever some action is happening. Doing the svn-mirror trick helped us to scale in the range past /several hundreds of simultaneous active connections/. As a guidance, gclient sync does 8 svn connections per slave by default. Scale that to hundreds of slaves waking up at the same time... Also, serving the read-only svn server from a set of apache frontends helps. We do that with src.chromium.org http://src.chromium.org. To be clear, above I was talking about a DMZ-only mirror. It is a different one from the apache frontends. Implementing both has the biggest benefit. We like the idea to setup svn mirrors, and we are ready to setup an svn mirror for Qt buildslaves hosted in Szeged. (6 slaves connected to build.webkit.org master and 13 slaves connected to build.webkit.sed.hu master) I think this mirror would help to reduce the load of svn.webkit.org and avoid rm -rf because of slow and not so stable trans-atlantic network connection. If there isn't any objection against adding an svn.webkit.sed.hu mirror, we will start to setup the server and prepare the master.cfg change to make slaves to be able to use svn mirrors, and add new scheduler to trigger slaves depends on their svn mirror used. And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
Hi, William Siegrist írta: On Mar 1, 2012, at 7:56 AM, Osztrogonac Csaba wrote: And one more technical question. Could you add an svn post-commit hook to do svnsync on the mirror svn server if we finished setting up the server? How would you want svn.webkit.org to signal the mirror? I think having svn.webkit.org request a specific HTTP URL would work. My first idea was that I gives you ssh or something else access to the svn mirror and the following post-commit hook will do the synchronization: /usr/local/bin/svnsync synchronize --username svnsync svn+ssh://svnsync@remote/home/svnsync/svn But your suggestion is reasonable and more safe than mine, when svn.webkit.org does a specific HTTP request and then our svn mirror will start the synchronization. Let's talk about it in private mail after we finished setting up the server. PS. So could you unban our subnet in the near future, please? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
William Siegrist írta: The Szeged slaves are unblocked. -Bill Many thanks, I copied up-to-date svn working copy to them and then started. I have only one more little request. Could you kick git.webkit.org too? It seems it is still stay on r109303. Our EWS would be happy if it works again. PS. Tomorrow we are going to setup the Szeged svn mirror. ;) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] git.webkit.org problem
Hi, git.webkit.org is behind svn.webkit.org again. :( r109205 is the latest svn commit, but r109202 in git. Unfortunately I can't commit to svn because this problem. Is it any trick to update my git-svn repo from svn? I set up my git svn repo about $http://trac.webkit.org/wiki/UsingGitWithWebKit : - git clone git://git.webkit.org/WebKit.git WebKit - git svn init --prefix=origin/ -T trunk http://svn.webkit.org/repository/webkit - git config --replace svn-remote.svn.fetch trunk:refs/remotes/origin/master br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
Hi, I uploaded the necessary buildfix for Qt to the bugzilla: https://bugs.webkit.org/show_bug.cgi?id=79783 . Please be careful with moving JavaScriptCore/wtf to WTF, because we need zillion trivial fixes for case sensitive file systems. (~4000 files!!!) I made it locally to be able prepare the Qt buildfix and I had to replace all wtf to WTF includes everywhere. (*.cpp, *.h, *.y, *.py, *.pl, *.pm, ...) The patch is huge, ~2Mb and ~4000 files are affected. I suggest landing the following patches separately: - Moving Sources/JavaScriptCore/wtf -- Sources/WTF - s/wtf/WTF/g patch :) - platform buildfixes Please let me know if you have the new date for landing these patches. I would be happier with a more CET timezone friendly timing. - 08:00-00:00 in CET. br, Ossy Eric Seidel írta: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] wiki spammer
Hi, Please ban demetgelin...@gmail.com user from trac, because it started to SPAM the wiki: 01:07 UsingGitWithWebKit edited by demetgelin...@gmail.com (diff) 01:02 WikiStart edited by demetgelin...@gmail.com (diff) I removed these SPAMs. PS. We should add captcha for the registration to avoid spamming in the future. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org problem
Hi, Sure, I filed a bug for the sick(dying) build.webkit.org: https://bugs.webkit.org/show_bug.cgi?id=79474 I hope it will be recovered once from this long and serious sickness. ;) br, Ossy On 02/22/2012 11:12 PM, Lucas Forschler wrote: Can you open a bugzilla bug, and we can use that to keep any investigations documented? Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] build.webkit.org is very sick
Hi, it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org is very sick
Hi again, Now the things are going from bad to worse: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. :(( Are you planning to fix http://build.webkit.org in the near future? br, Ossy Osztrogonac Csaba írta: it seems build.webkit.org is very very sick. Almost all builds are broken with a strange exception and there are zillion strange stucked builds: building 1 min 1 min 1 min 1 min 1 min 1 min 1 min Could you check what happened? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] style queue
Hi All, Style queue dead long time ago: Style Queue 5 days, 16 hours ago Status: Stopping Queue, reason: User terminated queue. 799 pending Eric or Adam or anyone has access, could you kick it? Thanks in advance. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SnowLeopard WebKit2
Hi all, Somebody committed a regression between r107432 and r107442 11 days ago. This change made more than 20 test crash on the SL WK2 bot and it made the bot exiting early: 2012-02-10 19:33:44,040 13500 printing.py:462 INFO Testing (35%): 9993 ran as expected, 55 didn't, 18246 left 2012-02-10 19:33:44,040 13500 manager.py:801 WARNING Exiting early after 20 crashes and 0 timeouts. 10048 tests run. We are going to unskip tests in general wk2 Skipped list which pass on qt-wk2 platform, but it's hard to maintain the general wk2 and mac-wk2 Skipped list if Apple doesn't have a working WK2 buildbot. Is there any volunteer on Apple side who is interested in making the SL-WK2 bot work and maybe green again? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org problem
Hi, Unfortunately it is still so slow nowadays. :-/ For example I'm waiting for build.webkit.org now. I regularly press the refresh button, but nothing happens. And Qt Linux 64-bit Release (Perf) finished its compile step 8 minutes ago and it is still waiting for build.webkit.org to get the next build step. br, Ossy William Siegrist írta: The server should be a little better now. Are your slaves still waiting a long time for new steps? -Bill On Feb 16, 2012, at 12:23 PM, William Siegrist wsiegr...@apple.com wrote: I'm still working on the web server. It'll be slow for a while. I'll send an email when things are all moved. The git server should be much better already though. -Bill On Feb 16, 2012, at 11:40 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, It seems build.webkit.org is very very slow now. I manage to load its webpage rarely and our bots (Qt) regularly wait for 10-20 minutes to get new build step from the master. Could you check what happened? I think it is still related to the disk array problem occured yesterday. Thanks for your help in advance. br, Ossy ___ 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] build.webkit.org problem
Hi, It seems build.webkit.org is very very slow now. I manage to load its webpage rarely and our bots (Qt) regularly wait for 10-20 minutes to get new build step from the master. Could you check what happened? I think it is still related to the disk array problem occured yesterday. Thanks for your help in advance. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] git.webkit.org is offline
Hi, It seems git.webkit.org is offline. Could you check what happened? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Snow Leopard WebKit2 tester bot
Hi WebKit Developers, Unfortunately Snow Leopard WebKit2 tester bot doesn't work long time ago, exactly from 12/02/2011 - http://trac.webkit.org/changeset/101853 . After enabling parallel testing, it exits early because of too many crashes. Shouldn't we disable parallel test running on SL-WK2? It seems it doesn't work at all. Or is anyone interested in a working SL-WK2 tester bot? It's strange for me that wasn't a problem for anyone in 2 months. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Mac and Chromium Mac EWS
Hi, Adam Barth írta: On Sat, Jan 21, 2012 at 9:32 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Something happened with Mac EWS again and now there are 375 stucked patch. Could anyone from Apple check and fix it? Lucas and I have been working to enable running the tests on the mac-ews. Unfortunately, there are too many failures on the Mac port at the moment (more than 30, at least on those machines). That prevents the bots from processing patches. I'm not sure what the current plan is. In this case I think we should stop running layout tests on Mac EWS. A working builder EWS is always better than a non-working builder ans tester EWS. Now the 7-day Pass counter of this bot is zero, so this bot doesn't work at least a week ago. :( br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Mac and Chromium Mac EWS
Hi all, Something happened with Mac EWS again and now there are 375 stucked patch. Could anyone from Apple check and fix it? And I noticed that Chromium Mac EWS is offline 1 month, 3 weeks ago. Is there any reason for it? If Chromium Mac platform is still supported, could you fix it? Or shouldn't we remove it from the list if it isn't supported anymore? ( http://queues.webkit.org/ ) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Mac EWS is dead :(
Hi WebKit Developers, Unfortunately nowadays there are many build failures on Mac platforms, because Mac EWS bots were dead minimum 3 weeks ago. It would be helpful if we got a working Mac EWS. Is there any volunteer from Apple to fix apple-mac-1 and apple-mac-2 EWS bots? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tools/Scripts/build-webkit --gtk --debug --makeargs=-j1 taking up to 80% of memory
Hi All, 32 bit debug build is impossible long time ago, because linker runs out of 4Gb address space. Maybe cross compiling on a 64 bit machine can solve this problem. Is there anyone interested in 32 bit build? br, Ossy Zeno Albisser írta: Hi Sachin, We had the same/a similar problem with QtWebKit. Ranlib ran out of memory on a 32bit system when building debug, because the library got bigger than 4GB. I dont think there is a proper solution for this problem. The only thing that would help would be to reduce the size of WebCore. For now we just disabled debug builds on 32bit systems. I heard some people managed to build debug by disabling SVG. - never tried it myself though. Best Regards -- Zeno On Dec 27, 2011, at 6:45 AM, sachin nikam skni...@gmail.com wrote: I synced up the latest webkit code base and am trying to build webkit gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs I tried with --makeargs=-j2 but still got ld process terminated signal[9] error which indicates that it ran out of memory. I suspect i will still the get the same error with --makeargs=-j1. Is there any other flag where we can restrict the memory usage? Regards Sachin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] svn.webkit.org problems
Hi, it seems something happened with svn.webkit.org, because many bots fail with svn error again and again. Unfortunately buildbot tries to solve svn errors with rm -rf and a new checkout. But a new checkout takes min. 4-5 hours. :( Have you got any idea what happened with svn.webkit.org? If it is stabilized, I can do a trick on the Qt bots. I'll stopp them, copy an up-to-date svn working copy to theirs storage and then restart. I think we should find an automatic and better way in the future to avoid similar problems. For example: - hack buildbot source not to do rm -rf - migrate buildslaves to git.webkit.org somehow (It needs many hack to save svn revision number on the bots) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Source/ThirdParty/ChangeLog? Really???
Hi All, I didn't break the tradition, 7 was the culprit revision: http://trac.webkit.org/changeset/10 - trunk/Source/ThirdParty/ChangeLog http://trac.webkit.org/changeset/9 - absolutely wrong patch http://trac.webkit.org/changeset/8 - absolutely wrong patch http://trac.webkit.org/changeset/7 - trunk/ChangeLog http://trac.webkit.org/changeset/6 - trunk/WebCore/ChangeLog http://trac.webkit.org/changeset/5 - trunk/WebCore/ChangeLog http://trac.webkit.org/changeset/4 - trunk/WebCore/ChangeLog http://trac.webkit.org/changeset/3 - trunk/WebCore/ChangeLog http://trac.webkit.org/changeset/2 - trunk/WebCore/ChangeLog http://trac.webkit.org/changeset/1 - absolutely wrong patch Now we shouldn't be sad, but let's celebrate this great number! ;) Brady Eidson írta: Bad form! X0,000 announcements have historically always been in WebCore/ChangeLog. A sad and unfortunate break in tradition just to avoid resolving the conflict to land. :( But seriously WebKit, congrats! ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Removing mac-leopard platform
Hi All, Mac Leopard buildslaves were removed by r97496: http://trac.webkit.org/changeset/97496/trunk/Tools/BuildSlaveSupport/build.webkit.org-config Shouldn't we remove the LayoutTests/platform/mac-leopard directory? ( ~150Mb, ~4800 files) br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Help with QT port
Hi, You should add the new file to WebCore.pro to make Qt port happy. ;) br, Ossy Mo, Zhenyao írta: My patch added a few new files in WebCore. Somehow I couldn't get the QT port to link. From the linking error, it seems the source files are not compiled. So besides adding the files in WebCore.gypi for chromium port and WebCore.xcodeproj for Mac port, are there other things I need to do to add the new files to QT port? This is the bugL: https://bugs.webkit.org/show_bug.cgi?id=70077 ___ 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] ping-pong with fast/files/create-blob-url-crash-expected.txt
Hi, It seems you guys are playing ping-pong with this platform independent expected file. Could you decide which one is the correct? br, Ossy http://trac.webkit.org/changeset/93713 http://trac.webkit.org/changeset/93713/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt -PASS: Not enough arguments +PASS: Type error http://trac.webkit.org/changeset/94023 http://trac.webkit.org/changeset/94023/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt -PASS: Type error +PASS: Not enough arguments http://trac.webkit.org/changeset/94168 http://trac.webkit.org/changeset/94168/trunk/LayoutTests/fast/files/create-blob-url-crash-expected.txt -PASS: Not enough arguments +PASS: Type error ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Are roll-outs getting a little out of hand?
Hi, Darin Adler wrote: I noticed these three roll-outs: http://trac.webkit.org/changeset/89190 It broke all non-V8 build as you mentioned later because of stricter gcc treats warnings as errors. I checked the bug today , and suggested a fix for the build fail: https://bugs.webkit.org/show_bug.cgi?id=62904 http://trac.webkit.org/changeset/89191 The original change was committed by a Qt developer. I think the minimum requirment is that a developer should build his/her patch at least on his/her platform before landing. (Fixed patch was already landed.) http://trac.webkit.org/changeset/89192 It broke 22 tests on all platform, and the author, Oliver Hunt confirmed this rollout was fine. (Fixed patch was already landed.) Were all of these necessary? Was there a way to fix the problem instead of rolling out in any of these cases? It might be. Fix for the 1st and the 2nd build break was quite simple. But I don't have time to fix them on saturday morning. I think rolling out was better than leaving the build broken for 2 days and let the authors to fix their bugs themselves. Broken build is the worst thing, because buildbot can't catch new layout regressions if the build is broken. In my opinion WebKit developers should take contributing rules seriously to make the lives of other developers easier. http://www.webkit.org/coding/contributing.html Regression tests Once you have made your changes, you need to run the regression tests, which is done via the run-webkit-tests script. All tests must pass. Patches will not be landed in the tree if they break existing layout tests. Keeping the tree green Your change must at least compile on all platforms. Rolling out is the last thing what I do with a wrong patch. First I try to contact the author and/or the reviewer on #webkit. If he/she doesn't answer, I try to fix the bug myself (if I have time and enough knowledge to do it.) After a roll-out I usually help the author to fix the Qt part of the patch. br, Csaba Osztrogonác (Ossy) University of Szeged ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Qt build slaves are offline
Dear WebKit developers, unfortunately we had network problems and it made Qt buildbots offline for half a day. And some of them are still broken. Sorry for the inconvenience, and please be patient until fix. After network fixed three of our slaves can't reconnect to the master. We tried to stop and start slaves again and again, but it didn't help. Estabilishing of the TCP connection works, but we always get the following strange twisted exception from the master: twisted.spread.pb.CopyableFailure traceback Traceback unavailable Calling Stale Broker unsafeTracebacks twisted.spread.pb.ProtocolError exceptions.Exception exceptions.BaseException __builtin__.object$.twisted.spread.pb.DeadReferenceError type$.twisted.spread.pb.DeadReferenceError Adam, Bill, could you check it, please? Is it possible that restarting the buildbot master will help us? Thanks in advance, Ossy University of Szeged ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to enable WebGL on WebKit QT port?
Hi, Sorry for the inconvenience, I fixed it: http://trac.webkit.org/changeset/85526 Unfortunately this code path isn't guarded by buildbot now. br, Ossy Won J Jeon írta: I tried to build a WebKit QT port with WebGL support by enabling '--3d-canvas' and '--3d-rendering' (--no-accelerated-2d-canvas by default) but it has the following error on GraphicsContext3DQt.cpp: ../../../Source/WebCore/platform/graphics/qt/GraphicsContext3DQt.cpp: In constructor 'WebCore::GraphicsContext3D::GraphicsContext3D(WebCore::GraphicsContext3D::Attributes, WebCore::HostWindow*, bool)': ../../../Source/WebCore/platform/graphics/qt/GraphicsContext3DQt.cpp:617: error: no matching function for call to 'WTF::OwnPtrWebCore::GraphicsContext3DInternal::OwnPtr(WebCore::GraphicsContext3DInternal*)' ../../../Source/JavaScriptCore/wtf/OwnPtr.h:57: note: candidates are: WTF::OwnPtrT::OwnPtr(const WTF::OwnPtrtypename WTF::RemovePointerT::Type) [with T = WebCore::GraphicsContext3DInternal] ../../../Source/JavaScriptCore/wtf/OwnPtr.h:48: note: WTF::OwnPtrT::OwnPtr() [with T = WebCore::GraphicsContext3DInternal] make[1]: *** [obj/release/GraphicsContext3DQt.o] Error 1 Is there any other steps that I need to follow in order to make WebGL working? Regards, Won ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding pixel result checksum in the png
Hi, The idea is awesome. ;) Getting rid of ~32k checksum files would speedup svn operations. I support you're works, please cc me to the bug report. br, Ossy Tony Chang írta: Yes, reading the checksum is the same speed as before. We write the png comment at the beginning of the file and only scan the first 2k of the file for the checksum. I also tried converting about 200 tests to use embedded checksums and found no speed difference. I've already updated new-run-webkit-tests, but plan on updating old-run-webkit-tests as well since it's a small amount of code (only about 20 lines of python, I imagine the amount of perl will be similar). ___ 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?
Ryosuke Niwa írta: 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). old-run-webkit-tests always generates results.html even if DRT crashes. br, Ossy ___ 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?
Hi Adam, I think it is a good idea. I always check results.html too, so I'd would be great if we had to click only once. ;) It is a very simple patch to fix the url: (master.cfg) -url = self.build.getProperties().render(self.resultDirectory).replace(public_html/, /) +url = self.build.getProperties().render(self.resultDirectory).replace(public_html/, /) + /results.html I never checked Apache logs: error_log.txt and access_log.txt, but they can be useful. If we modify the URL of view result, we should add URL's to results.html referencing these files. If there isn't any objection against it, I'm going to upload a patch into bugzilla. br, Ossy Adam Barth írta: Hi Bill, 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. I don't have any sense for whether those things are easy or hard, but they'd make my life a little bit easier. If you point me in the right direction, I can attempt to make the changes myself (but you should also feel free to do them yourself if that's easier for you). Thanks! 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?
Adam Barth írta: Cool. Looks like Ossy is going to write a patch. Yes sir, I filed a bug report, and uploaded the proposed patch: https://bugs.webkit.org/show_bug.cgi?id=57671 br, Ossy ___ 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
+1 vote for pre-commit hook. Ossy Adam Roben írta: 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] About 165 Editing Tests Require Rebaselines per Bug 51389
I'm in CET, but I'm flexible. I will have time between 08:00-02:00 in CET, 17:00-11:00 in PST and 0:00-18:00 in JST. Please tell me the exact time and I will be online at the time. Ossy Ryosuke Niwa írta: *When is the best time to land a massive patch that requires rebaselines of about 165 tests?* I'm going to land my patch https://bugs.webkit.org/attachment.cgi?id=84363action=review for the bug 51389 https://bugs.webkit.org/show_bug.cgi?id=51389 within the next 24 hours but the patch is 688KB and rebaselines 186 tests, of which 165 are Mac specific. And it's likely that we need to do a similar number of rebaselines (approx. 165) on other platforms as well. Since I'm in JST now, I can land it either in the late evening or early morning. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About 165 Editing Tests Require Rebaselines per Bug 51389
Ooops, I miscalculated. :) (All times are in 24h format.) The following interval is good for me everyday. 08:00 - 02:00 in CET 23:00 - 17:00 in PST 16:00 - 10:00 in JST Osztrogonac Csaba írta: I'm in CET, but I'm flexible. I will have time between 08:00-02:00 in CET, 17:00-11:00 in PST and 0:00-18:00 in JST. Please tell me the exact time and I will be online at the time. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is the minimal version of Python for webkit-patch?
Hi, We have Debian Lenny on Qt buildbots and Qt EWS with python 2.5.2. Upgrading to Debian Squeeze is in progress, I think we can finish it in this week. If you can wait a little bit, it would be great. br, Ossy Benjamin írta: I would like to update webkit-patch to support Python 3 because that is what I use by default. I think that would not be too much problem to support Python = 2.6. If we have to support as low as Python 2.4, that could be a problem because of some new syntax elements introduced in 2.6. Should I wait before patching for Python 3? Anyone needs webkit-patch for Python 2.6? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-help] Need help in running build webkit with GTK in ubuntu
Hi, Ubuntu 10.10 has libglib2.0-dev version 2.26.0, but you need version = 2.27.90 for building WebKitGTK+ . Ubuntu 11.04 has 2.28 libglib2.0. Or you have to build a newer version from source. Probably you have to install newer libsoup too. Check https://trac.webkit.org/wiki/BuildingGtk for details. br, Ossy Shruti írta: I am trying to run /Tools/Scripts/build-webkit --gtk in ubuntu I am getting this error: checking for GLIB - version = 2.27.90... no *** Could not run GLIB test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GLIB is incorrectly installed. configure: error: You need the GLib dev tools in your path Failed to setup build environment using 'autotools'! I have done: sudo apt-get install libglib2.0-dev And I have set the following path: export LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH export PKG_CONFIG_PATH=/usr/lib/pkgconfig export C_INCLUDE_PATH=/usr/include/glib-2.0/ export CPLUS_INCLUDE_PATH=/usr/include/glib-2.0/ I am a beginner...Thanks a lot in advance. Regards. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-dev mailing list reply-to
Hi, I suggest we should set the reply to list config for webkit-dev and other mailing lists in mailman config. Now we have to rewrite manually the to field if we would like to answer to the list. I think we answer more often to the list than in private. Any other pros or contras? ps. Sorry for my last mail to webkit-dev instead of webkit-help. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Leopard Bot has been broken for 5 days.
I ran into similar problem several times, it might be a DumpRenderTree bug. One DumpRenderTree instance execute 1000 tests without restarting by default. Sometimes it occurs that a test leaves behind some mess in the DRT and it breaks one of the following tests. If the test passes with run-webkit-tests _the_failing_test_, it must be a DRT bug. br, Ossy Adam Barth írta: I investigated this issue for a while. Disabling the test just causes the next test to fail. I'm not very familiar with this code. I can spend more time investigating, but having someone familiar with ideographs would likely be more efficient. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] proposal: pass --exit-after-n-failures 500 to old-run-webkit-tests on the bots
Hi WebKit developers, Yesterday http://trac.webkit.org/changeset/75682 made all layout tests fail and buildbots sick, because of an accidentally committed debug puts(). The size of results for ~22000 failing layout tests is more than 100Mb. This very big filesize is absolutely unnecessary, storage and network killer. I propose to pass --exit-after-n-failures 500 option to the old-run-webkit-tests on the buildbots to make buildbot master and slaves happier. 500 should be more than enough for online rebaselining and avoid 100Mb sized result files. I filed a bug for it: https://bugs.webkit.org/show_bug.cgi?id=52364 Any objections or seconder for this change? br, Ossy ___ 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
Hi, Eric Seidel írta: So that means at least the following people will need to perform restarts: - Whoever runs the Qt ews I will be online on Dec 17 at 4PM PST and will restart the Qt EWS. Additionally the master buildbot of University of Szeged ( http://webkit.sed.hu/buildbot/waterfall ) will need to be restarted too. I will do it after the patch landed. On Fri, Dec 10, 2010 at 2:10 PM, Dan Bernstein m...@apple.com wrote: How about next week, Dec 17 at around 4PM PST? And Dirk mentioned in the bug, that some Chromium wrapper scripts will need to be updated. Will this update affect the Chromium master? ( http://build.chromium.org/p/chromium/console ) Who will take care of the Chromium scripts/master update? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style of #include statements
Hi, Now the second one is correct, because you should use angle brackets ... for system headers, and quote marks ... for non system headers. I think you should use wtf/HashSet.h. It is important, because searches order is different with ... and ...: http://gcc.gnu.org/onlinedocs/gcc-4.3.2//cpp/Include-Syntax.html#Include-Syntax #include file: 1.) -I ... directories 2.) -isystem .. directories 3.) standard system directories #include file: 1.) in the directory containing the current file 2.) -iquote 2.) -I 3.) -isystem 4.) standard system directories br, Ossy Patrick Roland Gansterer írta: Currently, the style guidelines specify Includes of system headers must come after includes of other headers. But what about WebKit headers in arrow brackets? What is the correct style: #include ArgumentEncoder.h #include WorkItem.h #include wtf/HashSet.h #include wtf/OwnPtr.h #include QApplication #include QLocalServer or #include ArgumentEncoder.h #include WorkItem.h #include QApplication #include QLocalServer #include wtf/HashSet.h #include wtf/OwnPtr.h I prefere the first one because wtf/*.h aren't real system headers. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Clobber builds in windows bots needed?
Hi,
Touching header is a general fix for problems like this.
It will fix the build for all developer, but forcing a
clean build solve the build break only on the bots.
br
Ossy
Antonio Gomes írta:
Hi.
After http://trac.webkit.org/changeset/70975, Windows Debug bot
started failing to build:
http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 . The
build error shown is:
()
### COMPILING 1 FILES USING AT MOST 8 PARALLEL INSTANCES OF cl.exe
###
LayoutTestControllerWin.cpp
.\LayoutTestControllerWin.cpp(1389) : error C2065:
'WebKitEditingUnixBehavior' : undeclared identifier
()
however this enum value is clearly declared in
WebKit/win/Interfaces/IWebPreferences.idl as
50 typedef enum WebKitEditingBehavior {
51 WebKitEditingMacBehavior = 0,
52 WebKitEditingWinBehavior,
53 WebKitEditingUnixBehavior
54 } WebKitEditingBehavior;
Could someone with access to this bot force a complete build? Maybe
this is needed for this .idl to properly generate the corresponding
header.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Report errors from Qt/Win EWS bots
Hi Daniel, Qt EWS should always report the stdout (and stderr) when the build fails. If you see red Qt status bubble and empty result, please write an e-mail with bug number to webkit-ews at sed.inf.u-szeged.hu , and we will try to find what the problem is. I agree with you in MSVC issue, contets of BuilLog.htm is very important for developers on buildbots and on EWS too. There is a bug to do it for Windows build: https://bugs.webkit.org/show_bug.cgi?id=39199 br, Ossy Daniel Cheng írta: Is it possible to make the Qt/Windows EWS bots report what the build errors actually were? Qt doesn't seem to provide any stdio output. MSVC does, but it logs the output into BuildLog.htm files--would it be possible to scrape the text information out of these files and make them available? I ask because one of my patches didn't build on the Windows EWS bot, and so far, I still haven't managed to get the Windows port of WebKit to successfully compile. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why are we running Sputnik?
Eric Seidel írta: Chromium skips it (and if I remember correctly, they commissioned it?) Why do we want to be running these 6000 tests and slowing down our builds. I was talking with jamesr, and he seemed to think it adds little value to run it every time? (It was supposedly written as more of a development tool for V8?) But maybe I'm missing something? Sputnik tests are very fast. All test cases (15642) run in 394s, and 5468 Sputnik tests run in 41s on Qt buildbot, it takes only 10% of the testing time. Alexey Proskuryakov írta: One possible way to speed up Sputnik tests would be to run them as part of run-javascriptcore-tests, avoiding web page overhead. Someone proficient in scripting languages just needs to improve run-javascriptcore-tests to the point when it can do that. 1127 JavaScriptCore tests (run-javasriptcore-tests) run in 11s, 5468 Sputnik tests run in 41s on Qt buildbot. I don't think we can speed up Sputnik tests significantly. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Snow Leopard bot
One of the bot SnowLeopard Intel Release (Tests) bots itself is sick, apple-xserve-6 is the culprit. I think it needs a kick to make commit queue happier. br, Ossy Adam Barth írta: The snow leopard bot is having some trouble. For roughly half the runs, all the tests time out: (Jun 19 00:35) rev=[61470] failure #11969: failed Exiting early after 20 failures. 20 tests run. 20 test cases (100%) timed out The only plausible change in near the regression window is http://trac.webkit.org/changeset/61447, but that seems unlikely. Maybe the bot itself is sick? Can someone (wms?) take a look? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore export symbols
Hi, Kenneth surely thought about this bug: https://bugs.webkit.org/show_bug.cgi?id=27551 br, Ossy Kenneth Christiansen wrote: Hi Kevin, They export privately using some files listing the symbols to be exported (mac supports that as so does visual studio, I believe). We cannot do this for Qt, so if you search bugzilla you will find that we have some old patches adding export declarations to the classes being exported (or the individual symbols, if that made more sense) Cheers, Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] spammy edit of wiki
Thanks, I removed both of them. br, Ossy Peter Speck írta: I think this change should be rolled back: ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qt is now a core builder
We can simple add two URLs to build.webkit.org to show only core builders and other builders waterfalls on a separate webpage: Core builders: http://build.webkit.org/waterfall?show=Tiger%20Intel%20Releaseshow=Leopard%20Intel%20Release%20(Build)show=Leopard%20Intel%20Release%20(Tests)show=Leopard%20Intel%20Debug%20(Build)show=Leopard%20Intel%20Debug%20(Tests)show=SnowLeopard%20Intel%20Release%20(Build)show=SnowLeopard%20Intel%20Release%20(Tests)show=Windows%20Release%20(Build)show=Windows%20Debug%20(Build)show=Qt%20Linux%20Releaseshow=Qt%20Linux%20Release%20minimalshow=Qt%20Linux%20ARMv5%20Releaseshow=Qt%20Linux%20ARMv7%20Releaseshow=Qt%20Windows%2032-bit%20Releaseshow=Qt%20Windows%2032-bit%20Debugshow=Chromium%20Win%20Releaseshow=Chromium%20Mac%20Releaseshow=Chromium%20Linux%20Release Other builders: http://build.webkit.org/waterfall?show=SnowLeopard%20Intel%20Leaksshow=Windows%20Release%20(Tests)show=Windows%20Debug%20(Tests)show=GTK%20Linux%2032-bit%20Releaseshow=GTK%20Linux%2032-bit%20Debugshow=GTK%20Linux%2064-bit%20Debugshow=GTK%20Linux%2064-bit%20Releaseshow=New%20run-webkit-tests Yes, the buildbot configuration is in WebKit trunk, and Bill updates the config from svn manually. br, Ossy Maciej Stachowiak írta: Per my previous comments, I'd really like it if the core builders list appeared on a separate Web page of buildbot output than the other builders. Is that a practical thing to do? Is our buildbot configuration in SVN? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Qt buildbots
Hi, Of course we would like to add only very stable bots to build.webkit.org . The bots in question are two Windows builders (release and debug), one Linux builder (release with --minimal option, which guards the #ifded guards) and two ARM-Linux builders (ARMv5, ARMv7). The URL that Gábor showed wasn't the best one, because you could also see our experimental (maybe red) layout bots. Here you can check our stable bots: http://alturl.com/jtc9 These bots have a history of several months, they are stable enough, and green almost all the time. Flakey tests are irrelevant, because they are only builder bots and don't run layout test. Furthermore we agree that a multi-page setup would be more useful, and things like console view is more scalable than waterfall. br, Ossy Eric Seidel írta: I'm strongly in favor of more builders. However, it would be nice if the builders on build.webkit.org's front-page were all builders we were actually supposed to keep green. Right now Windows, Qt and Gtk builders at build.webkit.org are red and mostly ignored by the project. Would these new builders be green, or mostly ignored like the existing Qt builders? Perhaps build.webkit.org should have a multi-page setup like how build.chromium.org does where the main page is builders that are expected to be green, and other pages are FYI were builders may or may not always be green. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore
Hi, Alexey Proskuryakov írta: FIXME! is different from FIXME: in that Xcode doesn't recognize it. I'm surprised that style guide doesn't say anything about FIXME vs. TODO. I wasn't aware of this, thanks for your advice, I will use FIXME: next time. + // [Qt]r57240 broke Qt build (might be a gcc bug) + // FIXME! See: https://bugs.webkit.org/show_bug.cgi?id=37253 But I'm not sure if a comment was even needed here - the ugliness of nested #ifs shouts the same. This patch is only a workaround for buggy gcc. I added this comments, because I want to avoid that somebody would like to optimize Qt port and remove these guards. Ugliness of nested #ifs is another question, I hate them as you. It would be great if we can define it in Coding Style Guidelines. We can found different styles for nested #ifdefs in trunk (for example in JavaScriptCore/wtf/Platform.h( style-I.) #if xxx #if yyy ... #else ... #endif #endif style-II.) #if xxx #if yyy ... #else ... #endif // yyy #endif // xxx style-III.) #if xxx #if yyy ... #else ... #endif // yyy #endif // xxx style-IV.) #if xxx # if yyy ... # else ... # endif #endif As for me, I prefer style-III, but all reviewer ask me to modify my patches into style-I or style-II. I think we should make consensus which of them is the preferred coding style. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [52980] trunk/LayoutTests
Hi, The r52976 revealed this strange sideeffect bug, we filed some bug on it. We skipped these tests, because commit-queue doesn't work if one of the core builder is red. I don't think it is a good idea to land different, platform dependent expected files with false data. On the one hand layout tests protect against regression (verification) and on the other hand they test a correctness of specific feature (validation). What is the more important? I think both of them. I hope fixing the bug ASAP is much more important than paper over the problem with rolling out a good and working patch which only revealed the bug. Alexey, what do you think, if we use this new feature on the basis of our original idea until fix? I mean it can be disabled by default, but we can use it with --http-as-last option and/or enverionment variable. br, Ossy Alexey Proskuryakov wrote: * platform/mac/Skipped: Add http/tests/uri/escaped-entity.html to Skipped list since it affects later tests. I think that having this particular test enabled is much more important than having the patch it was affecting landed. Also, looks like this didn't even help, see http://trac.webkit.org/changeset/52990. * platform/mac-snowleopard/Skipped: platform/mac/editing/input/devanagari-ligature.html skipped. Same for this test. How will we notice regressions in text input support if we disable tests? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QWebElement not found in Qt 4.5.2
Hi, I am using WebKit rev 46156 with Qt 4.5.2 and it works correctly. Here qwebelement.h and cpp can be found in Webkit's webkit/qt/Api directory not in Qt. br, Ossy Ashok N N írta: Hi, I am compiling QtWebKit for the first time with Qt 4.5.2. At the very end of compilation, I see linking errors for QWebElement (among others). And searching around I did not find the header file qwebelement.h included in Qt4.5.2. And searching online I found that QWebElement is released in Qt 4.6 (http://chaos.troll.no/~tavestbo/webkit/domapi/qwebelement.html http://chaos.troll.no/%7Etavestbo/webkit/domapi/qwebelement.html). I was wondering how the current code is compilable in this situation? Is there a flag that can be set to disable this part of the code? The actual changes to WebKit were done in rev 42238. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QWebElement not found in Qt 4.5.2
Hi, qwebelement.cpp build into WebCore library: libQtWebKit.so , because in WebCore/WebCore.pro SOURCES contains qwebelement.cpp. br, Ossy Ashok N N wrote: Thanks Ossy. Can you tell me what library is created from that? My problem could be a linking issue with the required library not being linked to. ashok *From:* Osztrogonac Csaba o...@inf.u-szeged.hu *Cc:* webkit-dev@lists.webkit.org *Sent:* Wednesday, July 22, 2009 1:00:38 PM *Subject:* Re: [webkit-dev] QWebElement not found in Qt 4.5.2 Hi, I am using WebKit rev 46156 with Qt 4.5.2 and it works correctly. Here qwebelement.h and cpp can be found in Webkit's webkit/qt/Api directory not in Qt. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QWebElement not found in Qt 4.5.2
Hi, I am working on Linux, and now I see you are working on Windows with MinGw. I will try to build with your config, and then answer you approximately in an hour. br, Ossy Ashok N N wrote: In WebCore.pro, the library apparently being created is libQtWebKit.lib: TEMPLATE = lib TARGET = QtWebKit But when linking the library is QtWebKit4. And in fact I can find libQtWebKit4.a but not QtWebKit.lib or QtWebKit.a. g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-s -mthreads -Wl -Wl,-subsystem,windows -o ..\..\..\bin\QtLauncher.exe release/main.o -Ldefaultbuild\Release\lib -Lc:\Qt\4.5.2\lib -lmingw32 -lqtmain -lQtWebKit4 -lQtUiTools -lQtXml4 -lQtGui4 -lQtCore4 release/main.o(.text+0xdf3):main.cpp: undefined reference to `_imp___ZN8QWebView18guessUrlFromStringERK7QString' And is the command above trying to find libQtWebKit4.lib instead of libQtWebKit4.a? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announce the ARM port of JIT (Gabor Loki)
Hi, There isn't any barrier why not porting WREC. We are going to port WREC, the development is ongoing, and the results will be available too. br, Ossy haithem rahmani írta: why the JavaScriptCore/wrec/WRECGenerator.cpp file was not ported to use ARM instructions? regards. haithem ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] command line JSC vs. JSC in libQtWebKit
Hi all, We are working on speedup jsc, and found a strange thing. Command line JSC and JSC in libQtWebkit build with different gcc options: - jsc.pro build command line jsc with: -O3 - WebCore.pro build libQtWebKit with: -O2 -fPIC -fno-strict-aliasing (The latter is slower by 12%.) If you implement an optimization, you measure speedup with command line jsc on SunSpider. The results can be different if you measure with a web browser such as QtLauncher. User usually not run command line jsc, but a browser. Accordingly I suggest we should measure performance users' point of view. Is neccesary building faster, but different jsc? If no, possible solution can be: Build JavaScriptCore library with JavaScriptCore.pro and link it with jsc command line interface (jsc.o). Or make possibility in build system to build two different jsc. One of them is faster for using in real life. The other is slower, but same as running in browsers for testing and performance measuring. br, Csaba Osztrogonac (Ossy) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unsupported platform, can't determine built library locations
Have you Qt (and QTDIR env set) or GTK installed on your system? br, Ossy nguyen hai írta: I tried to build webkit on unbuntu 8.04 but failed. The message is below: long...@ubuntu:~/WebKit/WebKitTools/Scripts$ ./build-webkit Unsupported platform, can't determine built library locations. at /home/longhai/WebKit/WebKitTools/Scripts/webkitdirs.pm line 405. Can someone help me? thanks in advance ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] architecture specific optimizations
Hi all, We are interested in SFX speed optimizations, and we have experimented with some architecture specific optimizaton. If enable gcc to generate SSE2 instructions with -msse2 option, SunSpider has 4.8% progression with JIT, and 2.4% progression with interpreter. (result attached) (-msse2 is default option on MAC platform, but it isn't on qt-linux platform) Nowadays the rate of sse2 capability CPU is increasing. (e.g. all of the x86-64 architecture have sse2.) I think we should take advantage of different architectures. Have you got any idea? e.g. different build for architectures - determine the platform capabilities at buid time, etc br, Ossy TEST COMPARISONFROM TO DETAILS = ** TOTAL **: 1.024x as fast2396.1ms +/- 0.3% 2341.0ms +/- 0.5% significant = 3d: 1.060x as fast 381.9ms +/- 0.7%360.3ms +/- 0.7% significant cube: 1.081x as fast 125.7ms +/- 1.5%116.3ms +/- 1.6% significant morph: 1.069x as fast 144.1ms +/- 0.8%134.8ms +/- 0.7% significant raytrace: 1.027x as fast 112.1ms +/- 0.6%109.2ms +/- 0.9% significant access: ?? 341.8ms +/- 0.3%342.8ms +/- 1.0% not conclusive: might be *1.003x as slow* binary-trees: *1.041x as slow*29.4ms +/- 1.3% 30.6ms +/- 2.3% significant fannkuch: *1.015x as slow* 130.4ms +/- 0.4%132.3ms +/- 0.3% significant nbody: 1.027x as fast 146.5ms +/- 0.3%142.7ms +/- 2.3% significant nsieve:*1.048x as slow*35.5ms +/- 1.1% 37.2ms +/- 0.8% significant bitops: 1.016x as fast 222.0ms +/- 0.3%218.5ms +/- 0.3% significant 3bit-bits-in-byte: - 38.5ms +/- 1.0% 38.2ms +/- 0.8% bits-in-byte: - 50.9ms +/- 0.4% 50.7ms +/- 1.0% bitwise-and: - 46.0ms +/- 0.0% 46.0ms +/- 1.0% nsieve-bits: 1.036x as fast 86.6ms +/- 0.4% 83.6ms +/- 0.6% significant controlflow: ?? 25.5ms +/- 1.5% 25.8ms +/- 1.8% not conclusive: might be *1.012x as slow* recursive: ?? 25.5ms +/- 1.5% 25.8ms +/- 1.8% not conclusive: might be *1.012x as slow* crypto: 1.043x as fast 158.0ms +/- 0.6%151.5ms +/- 0.4% significant aes: 1.016x as fast 57.5ms +/- 1.2% 56.6ms +/- 0.9% significant md5: 1.060x as fast 51.0ms +/- 0.7% 48.1ms +/- 0.5% significant sha1: 1.058x as fast 49.5ms +/- 0.8% 46.8ms +/- 0.6% significant date:- 168.0ms +/- 1.6%166.7ms +/- 1.5% format-tofte: 1.026x as fast 67.8ms +/- 1.1% 66.1ms +/- 1.3% significant format-xparb: ?? 100.2ms +/- 2.1%100.6ms +/- 2.2% not conclusive: might be *1.004x as slow* math:1.072x as fast 304.9ms +/- 0.3%284.3ms +/- 0.7% significant cordic:1.112x as fast 111.6ms +/- 0.6%100.4ms +/- 1.2% significant partial-sums: 1.048x as fast 128.1ms +/- 0.3%122.2ms +/- 0.7% significant spectral-norm: 1.057x as fast 65.2ms +/- 0.5% 61.7ms +/- 0.8% significant regexp: - 300.3ms +/- 0.4%299.6ms +/- 0.3% dna: - 300.3ms +/- 0.4%299.6ms +/- 0.3% string: - 493.7ms +/- 0.9%491.5ms +/- 1.0% base64:1.029x as fast 52.6ms +/- 2.0% 51.1ms +/- 1.5% significant fasta: 1.031x as fast 83.7ms +/- 1.7% 81.2ms +/- 1.5% significant tagcloud: ?? 154.7ms +/- 1.1%156.0ms +/- 0.9% not conclusive: might be *1.008x as slow* unpack-code: ?? 124.2ms +/- 1.7%125.7ms +/- 1.7% not conclusive: might be *1.012x as slow* validate-input:- 78.5ms +/- 1.9% 77.5ms +/- 1.1% TEST COMPARISONFROM TO DETAILS = ** TOTAL **: 1.048x as fast1391.0ms +/- 0.4% 1327.4ms +/- 0.4% significant = 3d: 1.081x as fast 273.3ms +/- 0.5%252.8ms +/- 0.5% significant cube: 1.093x as fast 94.9ms +/- 1.0% 86.8ms +/- 1.0% significant morph:
