Re: [webkit-dev] Christophe Dumez is now a WebKit reviewer
Congratulations Christophe! On Fri, May 10, 2013 at 3:22 AM, Laszlo Gombos laszlo.gom...@gmail.com wrote: Hi, I'm happy to announce that Christophe Dumez is now a WebKit reviewer. Chris has done great work on WebKit2 (test infrastructure, support for new device APIs) and one of the driving forces behind the EFL port. Lately he has been doing work on the Soup and GStreamer backends and the binding generators. Please join me in congratulating Chris ! Thanks, Laszlo ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
On Thu, Apr 11, 2013 at 1:36 AM, Eric Seidel e...@webkit.org wrote: I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. Would be great if both projects could share the same generators. People writing device API bindings for web runtimes that are injected at runtime could also use it. Would be interesting if we could have the bindings generators as a separated/standalone project. Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
On Mon, Apr 8, 2013 at 4:27 AM, Benjamin Poulain benja...@webkit.orgwrote: On Sun, Apr 7, 2013 at 6:07 PM, Dirk Schulze dschu...@adobe.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. The question is still how you measure active reviewers/contributors? Is it enough to comment on bugs? Real reviews? Must there be at least one r+ in this time? Is an actual commit required? What do we gain from reverting reviewer ship/ committer ship? There is a problem of people not contributing for a while, not familiar with the current code base, who come and review things for their colleagues. There are bad ideas accepted by reviewers who are not very active on the project. I don't really see the big deal with revoking reviewer rights. If you come back to the project, make a few good patches and show a good understanding of the code base, you just get the rights back. The owner system with WebKit2 is avoiding this problem in an elegant way. It is effectively enforcing two reviews for most patches (one reviewer + one review from a owner). As a result, the quality of patches in WebKit2 has increased appreciably. Elegant is a bold claim (at least how it is implemented on WK2). There are examples of patches waiting for owners review/comments for months (even though the patch was already pre-reviewed by someone else). I suppose we also need another thread to discuss this issue... What are your concerns exactly? Benjamin PS: Maybe we should have this thread on the reviewer mailing list? Please, let's keep this at least to the committers list. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched
On Mon, Feb 25, 2013 at 5:24 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, We've replaced webkit-perf.appspot.com by perf.webkit.org. webkit-perf.appspot.com will be phased-out in the coming weeks. I'm going to check in the source code of perf.webkit.org into WebKit repository in coming months. The new version of the perf site is just awesome. Thanks a lot. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes to the WebKit2 development process
On Wed, Jan 9, 2013 at 11:32 AM, Simon Hausmann simon.hausm...@digia.com wrote: On Tuesday, January 08, 2013 02:57:53 PM Sam Weinig wrote: Hello webkit-dev, We are making some changes to the development process for WebKit2. These changes were announced to reviewers in advance, and I'd like to share them with you now. WebKit2 has a core set of functionality that is valuable to all ports, and then aspects that are only of limited/specialized interest. It is becoming increasingly difficult to improve and advance the core functionality while maintaining the more peripheral aspects. In addition, changes to the core often require significant expertise to evaluate, for instance to ensure that the security and responsiveness goals of WebKit2 are met. The changes are: 1) WebKit2 now has owners. Only owners should review WebKit2 patches. While we do not want to apply this concept across the whole WebKit project at this time, for WebKit2 it is appropriate. The list of owners is documented in the Owners file at the WebKit2 top level directory, and in committers.py. I think the fact that the regular WebKit review process stops at the boundary of WebKit2 should be documented in the WebKit Committers and Reviewer Policy. Agree. And please clarify on the policy if we are talking about everything inside the WebKit2/ directory or if we have exceptions. It is not clear to me if port specific code is covered by this rule and should by reviewed by the owners. And what about code shared by Qt, GTK and EFL (i.e. Platform/CoreIPC/unix/) but not used by Mac? - Thiago ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] how could I use std::cout in webkit?
On Mon, Nov 12, 2012 at 12:00 PM, Zhao, Halley halley.z...@intel.com wrote: Nothing shows in terminal when I added some std::cout in source code, any hints to print some log in webkit? My build command line: “./build-webkit --gtk --3d-rendering 21 | tee build.log” My run command line: “./run-launcher --gtk --enable-accelerated-compositing=1 http://localhost/test.html 21 | tee log.txt” run-launcher script might be eating the std output. Try invoking the browser binary directly. ___ 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?
On Mon, Nov 5, 2012 at 10:21 PM, Dirk Pranke dpra...@chromium.org wrote: 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. 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? 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. Cheers, -- Dirk I use it a lot. First stop when it is my gardening day. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Where is the Gtk+ DOM API?
On Fri, Oct 26, 2012 at 11:35 AM, Luka Napotnik luka.napot...@gmail.com wrote: Hello. I used Webkitgtk3 (webkit 1.8) on my Ubuntu 12.04 for a program I'm developing. I used the webkit_dom_html_element_click() function call to trigger click events on elements. But now, when I look into the newer code (webkit 1.10) there's no trace of these API calls. What happened? This list is for general WebKit development. For the WebKit GTK API, try the list bellow: http://lists.webkit.org/mailman/listinfo/webkit-gtk Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Replacing the JSC classic C++ interpreter with a llint generated C++ interpreter
On Thu, Sep 6, 2012 at 11:02 PM, Mark Lam mark@apple.com wrote:
As part of an effort to simplify future development, the JSC team is
deprecating the classic C++ interpreter (and will delete it shortly on Sept
24). In its place, we will use the LLINT (low level interpreter) with the
C++ back-end (see https://bugs.webkit.org/show_bug.cgi?id=91052) to generate
a llint C++ interpreter for new ports that do not support the JITs yet.
In order to deprecate the classic C++ interpreter, we will need your help to
convert your ports to use the llint (if you are using JSC for your port). I
will lay out some details below on how this conversion works:
Why deprecate the classic C++ interpreter?
=
The llint is where active development will take place as we add new JIT and
runtime enhancements. Having the classic C++ interpreter around only slows
down the development effort. The classic C++ interpreter is also prone to
experience bit-rot, and hence will easily get buggy over time.
How will you bring up a new platform without the classic C++ interpreter?
You will have to add the llint offline ASM build phase to generate the llint
C++ interpreter (see below for details on the llint offline build phase).
Alternatively, you can generate the llint C++ interpreter on a port that
already supports it, and use the generated LLIntAssembly.h from there to
bootstrap your port. It is preferred that every port supports the llint
natively because this will enable you to get the latest bug fixes and
performance enhancements.
What is the performance of the llint C++ interpreter?
The performance of the new llint C++ interpreter is currently slower than
the classic C++ interpreter, but within approximately 10% on average. The
goal of the llint C++ interpreter is not to achieve the highest performance,
but to provide a functional C++ interpreter to help bootstrap new ports. As
such, we don't plan to spend a lot of time on optimizing it.
sunspider results:
classic C++ interpreter llint C++ interpreter
arithmetic * 18.3123+-0.1593 !18.6551+-0.1095!
definitely 1.0187x slower
v8-real results:
classic C++ interpreter llint C++ interpreter
geometric * 15.31772+-0.22338!16.92580+-0.09735 !
definitely 1.1050x slower
How is the llint built?
Here's a summary of the steps:
Step 1: Generate LLIntDesiredOffsets.h
mkdir -p ${BUILT_PRODUCTS_DIR}/LLIntOffsets/
/usr/bin/env ruby ${SRCROOT}/offlineasm/generate_offset_extractor.rb
${SRCROOT}/llint/LowLevelInterpreter.asm
${BUILT_PRODUCTS_DIR}/LLIntOffsets/LLIntDesiredOffsets.h
Step 2: Build LLIntOffsetsExtractor from LLIntDesiredOffsets.h (from step 1)
and Source/JavaScriptCore/llint/LLIntOffsetsExtrator.cpp using the
cross-compiler for your target.
LLIntOffsetsExtractor is supposed to be an executable binary for your target
port. However, we will only be using it to extract offsets that we need for
the next step, and won't be running it.
Step 3: Generate LLIntAssembly.h
/usr/bin/env ruby JavaScriptCore/offlineasm/asm.rb
JavaScriptCore/llint/LowLevelInterpreter.asm
${BUILT_PRODUCTS_DIR}/JSCLLIntOffsetsExtractor LLIntAssembly.h || exit 1
LLIntAssembly.h provides the body of the interpreter, and will be #included
in Source/JavaScriptCore/llint/LowLevelInterpreter.cpp to be built into JSC.
How to get JSC to build with the llint C++ interpreter?
In Platform.h (or equivalent), set the following settings:
#define ENABLE_JIT 0
#define ENABLE_LLINT 1
#define ENABLE_CLASSIC_INTERPRETER 0
This combination of settings will ENABLE(LLINT_C_LOOP) which builds the
llint C++ interpreter. Eventually, ENABLE_CLASSIC_INTERPRETER won't be
needed when the classic C++ interpreter gets deprecated and deleted.
What do you need to do for your port?
=
The Mac port already works with the llint. I'm planning to fix the Windows
port to also work with the llint. On Sept 24, we plan to delete the classic
C++ interpreter. This means your port will cease to build if you are still
relying on the classic C++ interpreter then.
Please look into migrating your port to use the llint C++ interpreter (if
not the Assembly one) within the next few weeks. If you encounter issues
and need some help getting the llint to work for your port, please feel free
to contact me. I will do my best to help you out.
The work for CMake-based port is being done here:
https://bugs.webkit.org/show_bug.cgi?id=92682
Cheers,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] New feature: CSS Device Adaptation
Hi WebKit, I have been cooking an implementation of CSS Device Adaptation [1] for quite a while and I think it is now in a point that it can be proposed to WebKit upstream. The specification itself has matured and solved some controversial issues. Opera [2] and and IE10 [3] are implementing it. If you are not familiar with the standard, it is basically a CSS replacement for Viewport Meta Tag. [1] http://dev.w3.org/csswg/css-device-adapt/ [2] http://www.opera.com/docs/specs/presto28/css/viewportdeviceadaptation/ [3] http://samples.msdn.microsoft.com/ietestcenter/default.htm#css3deviceadaptation The Meta bug tracking this task: https://bugs.webkit.org/show_bug.cgi?id=95959 Thanks Kenneth for his support on viewport-related stuff. Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New WebKit reviewer: Gyuyoung Kim
On Tue, Aug 21, 2012 at 10:38 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I’m pleased to announce that Gyuyoung Kim is now a WebKit reviewer. Gyuyoung joined the WebKit team as part of an effort to port WebKit to the EFL platform. Since then he has taken leadership of the Samsung activities in WebKit trunk and helped integrating his team members in the community and community practices. Lately, Gyuyoung have been focused on adding device API's to WebKit, as well as refocusing the EFL efforts on WebKit2. Please join me in congratulating him in his new WebKit reviewer role. Congratulations! ___ 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?
On Tue, Aug 21, 2012 at 4:42 PM, William Siegrist wsiegr...@apple.com wrote: On Aug 21, 2012, at 6:33 AM, William Siegrist wsiegr...@apple.com wrote: On Aug 21, 2012, at 3:36 AM, Mark Rowe mr...@apple.com wrote: On 2012-08-21, at 02:25, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: and again ... I poked the server to work around the issue. I may have also tracked down the root cause of these issues too. I've sent Bill details of my theory, so hopefully we can come up with a permanent solution to it tomorrow! Mark is awesome. But we need to reboot the database server to implement the fix. Since its still early for a lot of webkit folks, I'm going to see if anyone minds in IRC and then just do it. The usual websites will go down for about 30 seconds. Fix is implemented. Looks like we have a problem with commit queue. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Commit queue is sick
Looks like the commit queue is sick. Can someone please check? Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 9:27 PM, Andreas Kling kl...@webkit.org wrote: On Thu, Jul 19, 2012 at 7:20 PM, Filip Pizlo fpi...@apple.com wrote: dataLog(foo %d bar %x baz %p\n, a, b, c); Reasoning and valid arguments aside, that actually looks totally beautiful. Do want. +1 from this shameless printfer. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature announcement: webkit-patch patches-to-review
Hi WebKit, webkit-patch patches-to-review was reworked [1] and now, instead of giving you the list of attachment ID of all the patches pending review, it will give you the list of bugs + description + age of patches pending review that has you on the CC list. The age here stands for how long in days the patch is waiting for review, not to the last time the bug was changed. Example: $ ./Tools/Scripts/webkit-patch patches-to-review Logging in as usern...@webkit.org... Bugs with attachments pending review that has usern...@webkit.org in the CC list: http://webkit.org/b/bugid Description (age in days) http://webkit.org/b/86310 [GStreamer] media/media-continues-playing-after-replace-source.html fails (14) http://webkit.org/b/86615 [EFL][DRT] EFL DRT needs deletebutton controller (17) http://webkit.org/b/82864 [EFL] LayoutTestController needs implementation of setTabKeyCyclesThroughElements (29) http://webkit.org/b/84589 [EFL][DRT] Implementation of showModalDialog needed (50) http://webkit.org/b/68511 [EFL] Script for running WebKit-EFL Unit Tests (276) http://webkit.org/b/54373 CSS '+' combinator with more than 2 combinations doesn't work (401) Total: 6 $ Try webkit-patch help patches-to-review for few more options. [1] https://bugs.webkit.org/show_bug.cgi?id=89470 Enjoy. ___ 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?
On Fri, Jun 8, 2012 at 2:47 AM, Dirk Pranke dpra...@chromium.org wrote: 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)? 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. The EFL port is gradually moving things from Skipped to TestExpectations. This process is taking time because we are using this opportunity to investigate each item and make an association to a bug for every line moved from Skipped to TestExpectations. I personally don't see a problem on moving our skip list to a new section on TestExpectations tagged as SKIP for the sake of reducing legacy on the testing infrastructure. Another option would be just migrate Skipped to TestExpectations syntax and let the ports move things to expectations file. Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
