[webkit-dev] Do we need subpixel layout (Was: Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?)
I think first we should clarify some more basic questions about subpixel layout. 1. Is it actually mantained? 2. Do any port really need it? Please correct me if these questions are too obvious or have been resolved before. Note that I am not a fan of subpixel layout, neither an enemy of it - in fact I do not know or care much about it. But from what I know it seems like this is a feature that makes an essential difference on the engine and I don't understand how can we allow such huge divergence across WebKit ports. Isn't it a maintenance burden? Doesn't it result in that test results across ports will diverge a lot more? Br, Balazs On 07/31/2013 10:40 PM, Ryosuke Niwa wrote: Can't we encounter the same bug if we you multiplied the same height by 64 even if the sub pixel layout is not turned off? Or is there some parser and other component that prevents such an overflow to happen? - R. Niwa On Wed, Jul 31, 2013 at 1:35 PM, Benjamin Poulain benja...@webkit.org mailto:benja...@webkit.org wrote: On Wed, Jul 31, 2013 at 4:34 AM, Javier Fernandez jfernan...@igalia.com mailto:jfernan...@igalia.com wrote: While looking into the bug #118595 I've found out that the root cause was an arithmetic overflow during the layout process, at least in the case of the WebKitGtk+ port, but I guess other ports have similar root cause. Notice that webkitgtk+ port enables the SUBPIXEL-LAYOUT by default. Later, I've concluded that the bug is not related to Regions at all, but something generic happening when the max-height CSS property value is set to a huge number. I've filled a new bug #119273 for this. The arithmetic overflow is gone when enabling the SATURATED_ARITHMETIC_LAYOUT flag, which actually, as far as I could understand, it's the purpose of such experimental feature. However, I've provided a patch for the #119273 facing the specific case of the max-height. I don't think that's the right approach, because I think other CSS property might have the same problem, but I thought it was useful to understand the issue. I think the right solution would be to enable the SATURATED_ARITHMETIC_LAYOUT whenever the SUBPIXEL_LAYOUT flag is enabled. Perhaps, eventually, both flags will become part of the same feature; that's one of the points to be discussed here. I'm sending this email to this list in order to get an agreement between all the ports using the SUBPIXEL_LAYOUT feature, but perhaps this should be debated independently on each port's mailing list. It looks to me like it is a good idea on the long term to have saturated arithmetic enabled when you have subpixel layout. I believe only GTK and EFL enable subpixel layout at the moment(?). You can probably lead the way and mature the feature and others will follow. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing names of new WebGL extensions
On 07/05/2013 10:54 AM, Karol Swiniarski wrote: Ok that's great! Patch is ready. Who can review it and merge it into webkit? http://www.webkit.org/coding/contributing.html If you want your work find it's way to trunk, you should upload your patch to the bugzilla and find a reviewer. Please don't use the mailing list for that. You should cc a reviewer with appropriate knowledge. You can ask people on IRC. The mailing list is not for that: it would be unusable if everybody would ask for reviews here. Br, Balazs -Original Message- From: Kenneth Russell [mailto:k...@google.com] Sent: Tuesday, July 02, 2013 1:40 PM To: Karol Swiniarski Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Changing names of new WebGL extensions I suggest to remove the prefixes. These WebGL extensions graduated to community approved status about six months ago, and there are very few hits on searches for e.g. WEBKIT_WEBGL_depth_texture, so I doubt many, if any, applications will break. -Ken On Tue, Jul 2, 2013 at 11:09 AM, Karol Swiniarski k.swiniar...@samsung.com wrote: Hi all, First of all I would like to say hi to everyone - it's my first post in this list ;-) There has been recently approved WebGL extensions by Khronos: WEBGL_depth_texture, WEBGL_compressed_texture_s3tc, WEBGL_lose_context. I created a patch which changes old prefixes from WEBKIT_WEBGL_ to WEBGL_ https://bugs.webkit.org/show_bug.cgi?id=117786 It has been reviewed, and so far, not accepted. This change complies with latest WebGL standard and may break some backward-compatibility. What's the process of pushing such changes to Webkit? Who is responsible for changing names? Can this change be applied any soon? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing names of new WebGL extensions
Ah, sure, sorry, I was misguided by the term merge into webkit and I was thinking the patch only available in some external repository. On 07/05/2013 11:40 AM, Noam Rosenthal wrote: It was suggested on the bug that this is a discussion for the mailing list... On Fri, Jul 5, 2013 at 11:37 AM, Balazs Kelemen kbal...@webkit.org mailto:kbal...@webkit.org wrote: On 07/05/2013 10:54 AM, Karol Swiniarski wrote: Ok that's great! Patch is ready. Who can review it and merge it into webkit? http://www.webkit.org/coding/contributing.html If you want your work find it's way to trunk, you should upload your patch to the bugzilla and find a reviewer. Please don't use the mailing list for that. You should cc a reviewer with appropriate knowledge. You can ask people on IRC. The mailing list is not for that: it would be unusable if everybody would ask for reviews here. Br, Balazs -Original Message- From: Kenneth Russell [mailto:k...@google.com] Sent: Tuesday, July 02, 2013 1:40 PM To: Karol Swiniarski Cc:webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Changing names of new WebGL extensions I suggest to remove the prefixes. These WebGL extensions graduated to community approved status about six months ago, and there are very few hits on searches for e.g. WEBKIT_WEBGL_depth_texture, so I doubt many, if any, applications will break. -Ken On Tue, Jul 2, 2013 at 11:09 AM, Karol Swiniarski k.swiniar...@samsung.com mailto:k.swiniar...@samsung.com wrote: Hi all, First of all I would like to say hi to everyone - it's my first post in this list ;-) There has been recently approved WebGL extensions by Khronos: WEBGL_depth_texture, WEBGL_compressed_texture_s3tc, WEBGL_lose_context. I created a patch which changes old prefixes from WEBKIT_WEBGL_ to WEBGL_ https://bugs.webkit.org/show_bug.cgi?id=117786 It has been reviewed, and so far, not accepted. This change complies with latest WebGL standard and may break some backward-compatibility. What's the process of pushing such changes to Webkit? Who is responsible for changing names? Can this change be applied any soon? ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto: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] Fuzzinator, a mutation based web fuzzer
On 06/27/2013 10:21 AM, Renáta Hodován wrote: Hi Dave, This is a good idea! What's more it seems it's not so hard to add MathML support to the fuzzer. Maybe in a few days (or in worst case next week) I can put it into it. I think the question was about whether your system is modularized well enough that it is easy for other people to extend it. Long term this is a very valid goal. Br, Balazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementation of Qt platform specific code in Plugin Process module
On 06/26/2013 06:36 PM, Harsh Sarin wrote: Hi, I have been analyzing the Plugin Process infrastructure for some time now, and came across some platform specific initialization. However, these are not implemented for the Qt platform. Please could you shed some light on development plans for this. Thanks for your time. Plugins are implemented per OS (or rather windowing system). They are implemented for Windows, Mac and X11, and ports can share these implementations. Balazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo
For me optional seems very misleading and generally different prefixes suggests that those objects are not the same. Maybe IfExists does not sound nicely but at least it's clear. I would choose to have a pointer version with IfExists and a reference version which is a noun, like: StyleResolver* styleResolverIfExists() StyleResolver styleResolver() Br, -Balazs On 06/19/2013 10:28 AM, Maciej Stachowiak wrote: On Jun 18, 2013, at 10:16 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Tue, Jun 18, 2013 at 7:20 PM, Simon Fraser simon.fra...@apple.com mailto:simon.fra...@apple.com wrote: On Jun 18, 2013, at 7:11 PM, Darin Adler da...@apple.com mailto:da...@apple.com wrote: On Jun 18, 2013, at 7:05 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: Why don't we call it requireStyleResolver() instead? I'm warming to this idea. Maybe we can use require as a term of art, analogous to the way we use create, to mean create if not already created. Since the fact that it returns a reference implies that it must create something if necessary, the required part of the name seems redundant. Why not just StyleResolver styleResolver() requireStyleResolver() sounds like it would return a bool. True. But it's important to differentiate a simple inline accessor and a lazily-create function because it's very easy to write code like: if (styleResolver().x()) styleResolver().y(); and incur two function calls when we could have done StyleResolver resolver = styleResolver(); if (resolver.x()) resolver.y(); instead. On the other hand, I've started to think that maybe we can simply forbid the former style altogether in the style guide so that we'll never have to think about whether a given function is inline or not. I don't think possible lazy creation is a good reason to decorate the name. Functions should be named for what they do, not their presumed efficiency. I am also not sure we need a style guideline about putting things into variables. If it makes a difference in a hot code path, then sure, but most of the time, the more concise code is better. - Maciej - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing new port: Nix
Excellent! I'm looking forward to see WebKitNix in trunk. -kbalazs On 05/17/2013 02:41 PM, Luciano Wolf wrote: The openBossa team at INdT Brazil is proud to announce “Nix” - a new WebKit2 port based on POSIX and OpenGL. Nix stands for “WebKit for unix-like platforms” and, if you consider the German meaning of the word nix, it can be taken as “WebKit plus nothing”. We are looking forward to upstreaming and maintaining this port. Below you will find a brief history about Nix, besides its main goals and motivation. :: A little bit of history :: The first of Nix basic ideas arose from a conversation between Kenneth Rohde Christiansen and Noam Rosenthal, who were wondering about the idea of having a “platform/glib” or platform/posix”. Other ports such as EFL, GTK and Qt would then be able to develop themselves on top of it, having a common source core. While QtWebKit’s QQuickWebView is great for embedding web content into QtQuick, a few people felt they needed more freedom to implement a different WebView behavior than the one being provided by Qt. Behavior more suitable for tricky use cases like embedding web content in a 3D world, for example. A private API called QRawWebView was implemented to fulfil this gap. Motivated by the 2 aforementioned concepts and by the idea of having a “lightweight” GL based port for developing some prototypes on a RaspberryPi, in August 2012 Caio Oliveira and Jesus Sanchez-Palencia, long term WebKit developers and former INdT employees, kick-started what they called WebKitNix. They started from the EFL port, took out every EFL-specific piece of code, implemented a “raw” GL-based WebView, provided a C API in the WK2 fashion and a set of platform/device APIs based on the former Chromium’s Source/Platform. We can summarize its evolutionary process as: 1. Initial idea: platform/posix or platform/glib (share code); 2. Evolved problem: we wanted to have different behaviors for QQuickWebView - Qt Raw WebView 3. Network: QtWebKit + Soup experiment 4. Efl Raw WebView experiment 5. Efl Without Efl :) 6. Nix was born. :: What is inside it? :: Most of Nix’s building pieces are shared with other existing ports: CMake build system, GLib, libsoup and Cairo. Also, it uses Coordinated Graphics, Tiled Backing Store and existing WebKit2 C APIs. Having such a tiny WebKit API means that Nix has the smallest possible footprint on the rest of the WebKit project. We take seriously the notion that the WebKit project is for a web rendering engine and nothing else, and try to develop as much of the auxiliary features as possible outside the WebKit project, on top of the API or in the injected bundle. Nix is already covered by Layout Tests, API Tests (TestWebKitAPI) and Ref Tests which are run by our buildbot[1]. Perf tests are supported but we don’t have a buildbot ready for them at this time. Pixel Tests are on the way. Today we have around 75% of layout tests coverage. We have been merging Nix with webkit.org three times per week so it is kept up-to-date. There is a public repository[2] with the original git history and we are looking forward to upstreaming it. (Yes, we fulfill all the “requirements” defined by the “Successful Port How To” document[3]) :: Who should use it? :: It targets whoever wants to have a hardware accelerated WebKit2 port on UNIX based devices, with a minimum effort. Nix is now running on x86 and ARM (Raspberry Pi[4] is a supported platform). Flexibility and freedom is guaranteed: you can define your WebView behavior and there’s no toolkit attached, so it may be used with EFL, GTK, Qt or even no toolkit at all. :: Who’s working on it now? :: This port was made in openBossa - an open source research group in Brazil. Nowadays, the team comprehends 5 WebKit committers and 4 more developers. In January, several contributors from the university of Szeged have joined the project as well, and are responsible for many valuable contributions like the current work to switch to libcurl. :: Past and Future :: - 2012 - - August/September: Lab phase, lots of experiments; - October/November: Branching; - late November: test infrastructure running; - 2013 - - January: public repository[2]; - May: comments/discussions/objections - upstreaming; -June beyond: maintenance, expand test coverage, focus on the web platform (contributing to WebCore). :: Where can you find it? :: website: webkitnix.openbossa.org buildbots: webkitnix.openbossa.org/build/ code: https://github.com/WebKitNix/webkitnix contact: n...@openbossa.org IRC: #webkitnix at freenode Best regards, Nix/openBossa team [1] http://webkitnix.openbossa.org/build/ [2] https://github.com/WebKitNix/webkitnix [3] http://trac.webkit.org/wiki/SuccessfulPortHowTo [4] https://github.com/WebKitNix/nix-rpi-sdk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev
Re: [webkit-dev] Reorganization of animation starting
On 04/17/2013 10:27 AM, Nándor Huszka wrote: Hi All, There is an optimization problem related to animations. If we have one out of the visible viewport, it is still animated. (Try to scroll down on http://philbit.com/animatedgiftest.html) In this case it would be good to stop, then continue animations when it is required. Now a BitmapImage's animation is started (continued) when it is drawed, and animation does not stop until it is destroyed. If animation starting would be handled separately from drawing, we could start and stop it when it is needed. Under https://bugs.webkit.org/show_bug.cgi?id=112327 there is a preliminary patch for it. The main idea in a nutshell: remember every animation in FrameView (instead of painting it),then only resume ones are on the visible viewport. For more details please check the bug. Reorganizing animation starting raises an important question. I plan to modify every ports' code where startAnimation is called, because after this patch it would be FrameView's role. If we would rename startAnimation to continueAnimation it could help with finding code points where startAnimation are called and should be removed by investigating EWS build logs. On the one hand it would be a more expressive name for that the method does. What do you think about the conception and about the method renaming? IMHO grep is a better tool to find call sites than ews, you should not rename just for that. If the change in behaviour implies the renaming than still it's probably better to do it in a follow-up patch. br, Nándor ___ 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] Adding __FILE__ and __LINE__ to CRASH() macro
On 04/16/2013 10:27 AM, Arunprasad Rajkumar wrote: Hi Darin, Any other concerns? May I file a bug provide the patch? BR For me this change doesn't seems to be too big or controversial, so I would say let's go for it ;) On 15 April 2013 16:41, Arunprasad Rajkumar ararunpra...@gmail.com mailto:ararunpra...@gmail.com wrote: Forwarded conversation Subject: *Adding __FILE__ and __LINE__ to CRASH() macro* From: *Arunprasad Rajkumar* ararunpra...@gmail.com mailto:ararunpra...@gmail.com Date: 12 April 2013 15:29 To: webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Cc: arunpras...@nds.com mailto:arunpras...@nds.com (Hope this is the proper mailing list to ask, Sorry in-case of not) Hello Folks, In embedded platforms(mostly debugger is missing) it very difficult(for us) to debug the issues without proper prints in CRASH macro. Though it has WTFReportBacktrace(); due to some constraints we are not getting proper call stack information(debug build with -g is costlier for us) . So we are thinking to extend the functionality of WTFInvokeCrashHook by passing __FILE__ __LINE__ and printing it. Any suggestion? If you all agreed then I will create bug and submit a patch. Thanks BR -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- From: *Darin Adler* da...@apple.com mailto:da...@apple.com Date: 12 April 2013 20:17 To: Arunprasad Rajkumar ararunpra...@gmail.com mailto:ararunpra...@gmail.com, arunpras...@nds.com mailto:arunpras...@nds.com Cc: WebKit Development webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Is this for debug builds or for production builds? If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. If it is for production builds, then how do you debug other crashes? -- Darin -- From: *Arunprasad Rajkumar* ararunpra...@gmail.com mailto:ararunpra...@gmail.com Date: 13 April 2013 11:36 To: Darin Adler da...@apple.com mailto:da...@apple.com Cc: arunpras...@nds.com mailto:arunpras...@nds.com, WebKit Development webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org Hi Darin, Is this for debug builds or for production builds? It is for production build. If it is for debug builds, then adding file and line seems fine; we should do it in a way that shares code with assertion macros. So in-case of calling CRASH from ASSERT then it shouldn't print __FILE__ and __LINE__ right(because ASSERT prints all these)? If it is for production builds, then how do you debug other crashes? printf :( -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad -- *Arunprasad Rajkumar* http://in.linkedin.com/in/ararunprasad ___ 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] Cleaning House
On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote: Hey, On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Do you mean adopting cmake for the whole project, or just for Gtk? Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
On 03/01/2013 06:03 PM, Arunprasad Rajkumar wrote:
Hi,
Please ignore if it is really out of context.
It would be nice to define a Class by Class
roles/responsibilities/expectations from Platform layer before
starting implementation. May be it is a kind of Class/Function
standardization process :). I agree that currently we have
standardized platform specific interface classes like GraphicsContext,
ResourceHandle, ImageFrame,.. but the issue is each port has its own
extensions to those classes to make the process easier, PSB
If I got it correctly than exactly these are the classes that should
leave in Platform (among others). The fact that their feature set is not
equivalent is orthogonal to this. It's a fact that each platform has
it's own extra capabilities and we should be able to utilize them.
Guarding them with preprocessor directives and relying on the convention
that only platform code will actually use them is one way to do this,
probably not the best.
class GraphicsContext {
...
#if PLATFORM(QT)
ShadowBlur* shadowBlur();
#endif
...
#if USE(CAIRO)
GraphicsContext(cairo_t*);
#endif
..
#if USE(CG)
void applyStrokePattern();
void applyFillPattern();
void drawPath(const Path);
void drawNativeImage(NativeImagePtr, const FloatSize
selfSize, ColorSpace styleColorSpace, const FloatRect destRect, const
FloatRect srcRect, CompositeOperator = CompositeSourceOver, BlendMode
= BlendModeNormal, ImageOrientation = DefaultImageOrientation);
// Allow font smoothing (LCD antialiasing). Not part of the
graphics state.
void setAllowsFontSmoothing(bool);
void setIsCALayerContext(bool);
bool isCALayerContext() const;
void setIsAcceleratedContext(bool);
#endif
};
How we are going to address these?. After this work whether we have
all these defines?
Kind Regards,
Arun
On 1 March 2013 21:50, Z(an Dobers(ek zandober...@gmail.com
mailto:zandober...@gmail.com wrote:
On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia
je...@webkit.org mailto:je...@webkit.org wrote:
Hi,
2013/2/28 Darin Adler da...@apple.com mailto:da...@apple.com:
To do this, we need to eliminate dependencies from the
platform directory to the rest of WebCore.
At this time, we are far from that. Many dependencies on the
DOM and other such things have crept into the platform directory.
I would be happy to help fixing this, Darin. Are the bugs blocking
https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to
start
list or is there something more urgent?
Violations reported by those bugs are most likely still valid.
There are of course probably other existing violations that
haven't been reported yet.
-Z
Cheers,
jesus
___
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
--
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
___
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] NetworkProcess / NetworkThread in the UIProcess
On 02/12/2013 04:51 PM, Zeno Albisser wrote: Hi, I have been looking into the NetworkProcess code that has recently been added to WebKit2. For Qt we are considering moving all the networking into a separate thread within the UIProcess. Do you guys think that the NetworkProcess code could be designed in a way to allow running in a separate thread of the UIProcess instead of in a separate process? We are convinced that this design would be a very good fit for our needs. Also in the light of the currently ongoing effort of cleaning up our Qt-bits and pieces in WebKit2. After a quick look it seems to me that this could be achieved with fairly minor modifications: * Instead of relying on RunLoop::main() within NetworkProcess, a different function would need to be introduced to retrieve a networking RunLoop. This would allow to process networking related events in the network thread. Depending on the platform, this could of course return a pointer to the main-RunLoop, for the cases where networking is indeed executed in a separate process. * Splitting the NetworkProcess class in two pieces. The child process and IPC setup remaining in NetworkProcess, and the actual networking code in a separate class (e.g. called NetworkThread). Provided the IPC (between threads in our case) would be setup upfront this would allow running the code provided by NetworkThread in a separate thread. You also need IPC because the NetworkProcess serves the needs of the web process. Could you describe why a network thread in the UI process fit your needs bettter? Is it to support API's related to networking or does it have other advantages? -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Should LChar really being unsigned char? (was Re: SerializedScriptValue: signed vs unsigned char)
On 02/07/2013 01:48 AM, Maciej Stachowiak wrote: I think we should continue to use uint8_t instead of char as the primary way to represent a raw byte in WebKit. First, it's good to distinguish raw data from C strings at the type system level, and second, the unpredictable signedness of char is actively bad for byte-oriented processing. Another library making a different choice doesn't overcome these reasons. I agree with that, but I still don't see why should LChar be unsigned since it is a character and not a raw byte. It would be somewhat more convenient when dealing with string literals or traditional C libraries. I you agree I could investigate in the refactoring work. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
I think one important aspect of build systems was not considered yet int this conversation: speed. The time an incremental build takes has a great effect on developer productivity. I don't think any of the meta-build systems we use does a great job here - although I only have experiences with qmake, cmake and autotools (and I don't have an SSD that could help somewhat). The technic I found useful here is to avoid calling build-webkit always and instead just rebuild the subproject you have edited, so I think it is important to have a build system that supports it. Let me share my experiences here. With qmake nowadays this work perfectly. The developer build is producing a shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2), which means you only need to call make in the specific subdirectory (i.e. if I only touched WebKit2 files I do make -C WebKitBuild/Release/Source/WebKit2 which is pretty quick). Still WebCore is so big that make is quite slowly find out the files you actually edited and need to be rebuilt. What could help here is to devide WebCore into smaller parts, like the ongoing work of extracting Platform. Maybe the next logical candidate could be svg (I don't have real knowledge about how feasible it is). Note that I don't come up with qmake because I would like to recommend it as the one and only build system (in fact it has a ridiculously inconvenient syntax, and a lot of bugs), just as an example. With Cmake fast incremental rebuilds are also possible, maybe in a bit more complicated way. When working with the EFL port I found a quick rule for WebKit2 in the generated makefile. Although the makefiles are usually call back to Cmake, and make is not faster than build-webkit, if you use the special fast target, which is something like eflWebKit/fast (i.e. make -C WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check dependencies but just rebuild the files that have changed. I did not find a similar thing for WebCore, I guess because it is not built as a shared library. What I dislike in Cmake is that I am disappointed by how slow a normal incremental build with it (i.e. build-webkit). qmake is not faster at all, but it generate plain makefiles that typically no call back to qmake if not specified explicitly to do so, and directly calling make is faster, yet it can handle most of the non-trivial changes, for example editing a generator file. I don't know gyp, so I wonder about how would it do in this comparison (but I guess it generates simple makefiles as well, so it's similar than qmake in this manner.) I hope I added something to this conversation that is worth to consider with my late nightly brain dump. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
On 02/01/2013 02:28 AM, Darin Fisher wrote: It would be nice if, in the shared library build of chromium, webcore and perhaps the modules and platform were separate DLLs. The shared library build is kind of a developer build, right? In this case I believe you can solve this by setting the default visibility to public at compiler/linker level, no need for exports. -kbalazs ___ 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
IMHO, recently, contributors as well as WK2 owners are a bit suffering from it. I think we can go to a better direction: making all developers happy as well as resolving WK2 owners' concerns. I think the straightforward way to achieve this is to let somebody be an owner from every port. He/she should could be restricted to approve only platform specific changes. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On 01/23/2013 01:43 AM, Allan Sandfeld Jensen wrote: On Wednesday 23 January 2013, Balazs Kelemen wrote: On 01/22/2013 05:14 PM, Zoltan Herczeg wrote: Where in WebKit do you experience problems with color conversion? As for me WebKit2 transmits BGRA images, which needs to be converted to RGBA before it is uploaded to a texture on GLES 2.0. These conversions seems computation heavy for certain animations, and I was wondered whether do we really need to use BGRA here. It would be nice to invent something to avoid that. You explained the symptom but not the source of the problem. So, do you know _why_ do we have BGRA before the texture upload? If this is a software rendered image buffer, why can't we just use the appropriate format when doing the software rendering? Anybody? Because it is a 32bit buffer of ARGB values. On a little endian CPU like i386, 32bit ARGB is stored bytewise as BGRA. In Qt we always have 32bit ARGB values because that is the internal color format of the Qt renderer (QRgb). In the grand scheme of things it is probably easier up to upload BGRA textures than trying to double the rendering paths of QPainter to support RGBA. A quick little overview of what I am talking about: ARGB format aka RGBA32 (32bit ordered) As 32bit math 8bit big endian 8bit little endian 24-31bit: A 1.byte: A 1.byte B 16-23bit: R 2.byte. R 2.byte G 8-15bit: G3.byte. G 3.byte R 0-7bit: B4.byte. B 4.byte A RGBA format aka RGBA8 (byte-ordered) As byte format32bit big endian 32bit little endian 1.byte: R 24-31bit: R 24-31bit: A 2.byte: G 16-23bit: G 16-23bit: B 3.byte: B 8-15bit: B 8-15bit: G 4.byte: A0-7bit: A0-7bit: R Ofcourse the confusion can be avoided if RGBA8 is only accesed bytewise, and ARGB only 32bit wise, but when uploading to textures or otherwise serializing it we need to deal with the mess. Thanks, that was useful to me. I did not know that the internal format is byte order agnostic. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RGBA8 and BGRA8 formats in WebKit
On 01/22/2013 05:14 PM, Zoltan Herczeg wrote: Where in WebKit do you experience problems with color conversion? As for me WebKit2 transmits BGRA images, which needs to be converted to RGBA before it is uploaded to a texture on GLES 2.0. These conversions seems computation heavy for certain animations, and I was wondered whether do we really need to use BGRA here. It would be nice to invent something to avoid that. You explained the symptom but not the source of the problem. So, do you know _why_ do we have BGRA before the texture upload? If this is a software rendered image buffer, why can't we just use the appropriate format when doing the software rendering? Anybody? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The --test-list option behavior in NRWT
On 11/08/2012 02:51 AM, Ojan Vafai wrote: On Wed, Nov 7, 2012 at 12:41 PM, Dirk Pranke dpra...@chromium.org mailto:dpra...@chromium.org wrote: On Tue, Nov 6, 2012 at 11:58 PM, Z(an Dobers(ek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi WebKitties, I'd like to see in what scale the --test-list option in NRWT is used and whether anyone would object a change in how its usage behaves. Currently the test gathering takes into account any paths that were passed in through the command line and any paths listed in the file to which a possible --test-file option points[1]. These paths are then expanded if necessary (due to platform-specific tests and virtual test suites) and all the tests to which these paths apply are gathered[2]. All the gathered tests are then either sorted into a natural order or randomized (if the --randomize-order option is used)[3]. I'd like to propose a change in the behavior when using the --test-list option. When used, the tests would be gathered only from the paths listed in the file to which the option points. Also, the gathered tests would be sorted to follow the order of the paths in the test list file. For instance, consider the following two entries being placed in the test list file: c/d/e.html a/b/ The current behavior would gather all the tests to which these two paths apply and sort them in this order (on the premise that no other paths are passed through the command line arguments): a/b/1.html a/b/2.html c/d/e.html The new behavior would place the c/d/e.html test at the top of the list but sort the other two tests in order, like this: c/d/e.html a/b/1.html a/b/2.html The idea behind this is to be able to specify the exact order in which the tests should be run. I'm currently playing around with a tool that randomly chooses a certain number of tests, runs them and bisects down the first regression that occurs (if any) to the smallest possible ordered list of tests that reproduces that regression. The proposed change makes this a simple task from the test listing perspective and I'd argue that exact test ordering is the main point of an option such as --test-list. Currently I'm using an untested workaround of adding a new option that specifies the tests should be reordered back to the original order that the test list file provided, but I'd like to move on with implementing the change in behavior if everyone feels it's OK and won't tamper with his/her workflow. -Z [1] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/layout_test_finder.py#L46 [2] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/base.py#L576 [3] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py#L309 Hi, I have used the option from time to time, and I have also wanted from time to time the ability to run tests in a specific order. This change would be fine by me. If people want to ensure that tests run in the old order, they can always sort the test list. I have used this in the past to identify which test caused test flakiness (e.g. I have 100 tests and I know the last test depends on one of the other 99 to run first in order to pass). The problem with this last sentence is that it's hard to know what order run-webkit-tests would choose, so it's hard to replicate it. It would make that use-case a little harder if we made this change. Otherwise, I don't care either way. Exactly for the reason Ojan mentioned I think the best would be to add an option for defining the desired ordering behavior. Paths on command line and in --test-list should imply to use the ordering as it is passed but it would be possible to force the current method. I hope it would not add too much complexity. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On 10/28/2012 08:25 PM, Ami Fischman wrote: We can live in one of two worlds: 1) LayoutTests that concern themselves with specific network/loading concerns need to use unique URLs to refer to static data; or 2) DRT clears JS-visible state between tests. The pros/cons seem clear to me: Pro#1: loading/caching code is coincidentally tested by (unknown) tests that reuse URLs among themselves. Con#1: requires additional cognitive load for all webkit developers; the only way to write a test that won't be affected by future addition of unrelated tests is to use unique URLs Pro#2: principle of least-surprise is maintained; understanding DRT reading a test (and not every other test) is enough to understand its behavior Con#2: loading/caching code needs to be tested explicitly. IMO (Pro#2 + -Con#1) (Pro#1 + -Con#2). Are you saying you believe the inequality goes a different way, or am I missing some other feature of your thesis? Yes, this is a fair description. I'm going to assume you mean that yes, you believe the inequality goes the other way: (Pro#2 + -Con#1) (Pro#1 + -Con#2) This accidental testing is not something to be neglected I'm not neglecting it, I'm evaluating its benefit to be less than its cost. To make concrete the cost/benefit tradeoff, would you add a random sleep() into DRT execution to detect timing-related bugs? It seems like a crazy thing to do, to me, but it would certainly catch timing-related bugs quite effectively. If you don't think we should do that, can you describe how you're evaluating cost/benefit in each of the cases and why you arrive at different conclusions? (of course, adding such random sleeps under default-disabled flag control for bug investigation could make a lot of sense; but here I'm talking about what we do on the bots by default) It's not humanly possible to have tests for everything in advance. Of course. But we should at least make it humanly possible to understand our tests as written :) Making understanding our tests not humanly possible isn't the way to make up for the not-humanly-possible nature of testing everything in every way. It just means we push off not knowing how much coverage we really have, and derive a false sense of security from the fact that bugs have been found in the past. I completely agree with Maciej's idea that we should think about ways to make non-deterministic failures easier to work with, so that they would lead to discovering the root cause more directly, and without the costs currently associated with it. I have no problem with that, but I'm not sure how it relates to this thread unless one takes an XOR approach, in which case I guess I have low faith that the bigger problem Maciej highlights will be solved in a reasonable timeframe (weeks/months). Memory allocator state. Computer's real time clock. Hard drive's head position if you have a spinning hard drive, or SSD controller state if you have an SSD. HTTP cookies. Should I continue the list? These things are all outside of webkit. Yes, they are outside WebKit, but not outside WebKit control, if needed. Did you intend that to be an objection? I imagine Balazs was pointing out that you included items that are not JS-visible in an answer to my question about things that are JS-visible. But that was part of an earlier fork of this thread that went nowhere, so let's let it go. I was just meaning that it is not feasible to force every external dependency to reset it's state, neither we want it. We just trust in them. But the cache is in WebKit, and we can reset it's state. So either resetting the cache is a good or a bad idea, I think it has nothing to do with the fact that we cannot reset the OS and the hardware (and external libs of course). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Some stderr output missing when using run-webkit-tests
On 10/29/2012 12:29 AM, Terry Anderson wrote: Hi webkit-dev, When I include fprintf(stderr, ...) statements in WebKit code that I expect to be executed when running a set of layout tests, the summary page of run-webkit-tests will sometimes only show a subset of these statements. However, when I add a CRASH() somewhere in the code, the missing stderr output will appear on the summary page. Has anyone else experienced this issue? Is there a way to force run-webkit-tests to display all stderr output without needing to force a crash at a particular point in the code? Terry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev The summary page only shows the stderr output of the failed tests. I also annoyed me sometimes, probably this should be changed. kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Mac build issue (appearing only locally)
Hi!
I did build the Apple Mac port two times in the past few days to try
something and both times I faced with a strange build issue that does
not appear on the bots. I had to apply this patch, which just move some
functions before their use in WKView.mm to be able to finish my build:
https://gist.github.com/3913811 https://gist.github.com/3913811 I am
using Lion with clang 3.0 (tags/Apple/clang-211.10.1) and I passed
--makeargs=-j12 to build-webkit. Do you have an idea what can be the
problem?
Thanks!
kbalazs
P.S.: here is the build error:
Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1875:5:{1875:5-1875:80}:
error: instance method '-_wk_windowDidBecomeKey:' not found (return type
defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidBecomeKey,
NSWindowDidBecomeKeyNotification, nil);
^~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1876:5:{1876:5-1876:109}:
error: instance method '-_wk_windowDidChangeBackingProperties:' not
found (return type defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidChangeBackingProperties,
windowDidChangeBackingPropertiesNotification, window);
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1877:5:{1877:5-1877:89}:
error: instance method '-_wk_windowDidChangeScreen:' not found (return
type defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidChangeScreen,
NSWindowDidChangeScreenNotification, window);
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1878:5:{1878:5-1878:91}:
error: instance method '-_wk_windowDidDeminiaturize:' not found (return
type defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidDeminiaturize,
NSWindowDidDeminiaturizeNotification, window);
^~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1879:5:{1879:5-1879:87}:
error: instance method '-_wk_windowDidMiniaturize:' not found (return
type defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidMiniaturize,
NSWindowDidMiniaturizeNotification, window);
^~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1880:5:{1880:5-1880:73}:
error: instance method '-_wk_windowDidMove:' not found (return type
defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidMove, NSWindowDidMoveNotification, window);
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1881:5:{1881:5-1881:91}:
error: instance method '-_wk_windowDidOrderOffScreen:' not found (return
type defaults to 'id') [-Werror,3]
ADD_OBSERVER(_wk_windowDidOrderOffScreen,
windowDidOrderOffScreenNotification, window);
^~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1872:57:
note: instantiated from:
usingBlock:^(NSNotification *notification){ [self
selectorName:notification]; }] \
^~~~
/Users/balazs/WebKitGit/Source/WebKit2/UIProcess/API/mac/WKView.mm:1882:5:{1882:5-1882:89}:
error: instance method '-_wk_windowDidOrderOnScreen:' not found (return
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
Actually Qt and EFL DRT's already does that. On 08/08/2012 07:47 PM, Ojan Vafai wrote: See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Ojan ___ 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] Removing --pixel-tests from DRT/WTR
Hi webkittens! I am going to upload a patch to https://bugs.webkit.org/show_bug.cgi?id=92398 https://bugs.webkit.org/show_bug.cgi?id=92398 that will remove the --pixel-tests option from test drivers. Don't worry, I don't want to kill pixel testing, I want to be able to control it per test so we can filter what tests to run as pixel tests. I already implemented it in http://trac.webkit.org/changeset/123729 for WebKitTestRunner and Qt DRT, so now those drivers accept an optional '--pixel-test' arg after the test name so the test harness can specify whether to dump pixels for each test separately. (Note that the hash is not enough because there are cases when we may want to run pixel tests but we don't pass the hash, like with --reset-results or when the expected image is missing.) Now I'm going to make it work for every DRT, and after that there will be no need for the --pixel-tests command line option. But there is a question that I should ask first: is there anybody relying on running DRT manually, and passing --pixel-tests on the command line? Do you think it can be useful? (Maybe for debugging?) There is no technical problem of keeping it for this use case but I think it's better to remove if there is no strong need for it. Cheers, kbalazs https://bugs.webkit.org/show_bug.cgi?id=92398 ___ 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 07/19/2012 11:27 PM, Maciej Stachowiak wrote:
On Jul 10, 2012, at 8:52 AM, Brady Eidsonbeid...@apple.com wrote:
On Jul 10, 2012, at 5:25 AM, Alexis Menardalexis.men...@openbossa.org wrote:
On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidsonbeid...@apple.com wrote:
On Jul 9, 2012, at 2:43 PM, Alexis Menardalexis.men...@openbossa.org wrote:
Hi,
For those who secretly use printf debugging :). I know the
recommended way is to use a debugger and it's not the point of this
discussion.
A lot of us do this, and sometimes it's necessary. I agree with the gripe and
support adding something easier.
So I propose wtf() and its stream operator.
Usage :
wtf()HelloWorld34.53322323; will output : Hello World 3 4.53322
There is no reason to bring in stream operators - that are willfully absent
from WebCore - just for debugging.
But it's really nice for that purpose, and somehow match std::cout
And we quite purposefully don't use std::cout in the project.
Overloading functions works just as well.
I'm not sure to understand what you mean here…
I mean relying on C++'s overloading of functions for the different types you'd
like to printf debug.
void debug(WebCore::String);
void debug(WebCore::Frame*);
void debug(WebCore::Node*);
etc etc etc.
debug(someFrame);
debug(someNode);
debug(someString);
Especially that last one would help me from remembering how to type printf(%s,
someString.utf8().data()) which is all I've ever really wanted.
In principle, we could also have this support multiple arguments, so you could
write:
debug(frame: , someFrame, node: , someNode, string, someString);
This would be no more verbose than the style, but could compile to a single
function call at the call site and therefore could be relatively compact. I would
find this easier to deal with than a unary function or a printf-style format string.
The way you'd do this is by defining template functions which call a unary overloaded
function for each argument:
templatetypename A, typename B debug(A a, B b)
{
debug(a);
debug(b);
}
templatetypename A, typename B, typename C debug(A a, B b, C c)
{
debug(a);
debug(b);
debug(c);
}
templatetypename A, typename B, typename C, typename D debug(A a, B b, C c,
D d)
{
debug(a);
debug(b);
debug(c);
debug(d);
}
... and so on up to some reasonable number of arguments.
But neither these compile to a single function call. Or we could define
simple inline debug() overrides but we could also do that with the
stream operator. And anyway, if the actual calls are not supposed to
land than it doesn't matter how compact it is. For me the stream
operator is a bit nicer.
-kbalazs
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] bugs.webkit.org is extermely slow
Hi! We experience a serious slowdown of bugzilla currently, here in Szeged (CET time, UTC+1). Do you know the reason? -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] bugs.webkit.org is extermely slow
On 07/16/2012 02:33 PM, Balazs Kelemen wrote: Hi! We experience a serious slowdown of bugzilla currently, here in Szeged (CET time, UTC+1). Do you know the reason? -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Ok, there is no problem now. Probably it just needed a cache clear, in which case so sorry for the noise. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Time out issue (30s) of WebKit layout test [Mac OS]
On 06/29/2012 05:40 PM, Brady Eidson wrote: On Jun 28, 2012, at 11:57 PM, Horky Chen ho...@sina.com mailto:ho...@sina.com wrote: Hi, On Mac OS, if one time-out larger than 30s would be used, --time-out-ms cannot work well. According to the run-webkit-tests script, custom Time-Out can be assigned for each test case. But, unfortunately, below line in LayoutTestControllerMac.mm blocked the setting if it is larger than 30s (waitUntilDone notifyDone are used): static const CFTimeInterval waitToDumpWatchdogInterval = 30.0; I think this is just the default, WebKitTestRunner has a --timeout that should control this if given. If that's not the case than it seems like a bug for me. On the other hand, I don't think run-webkit-tests supports setting custom timeout for a particular test. That is hard code, and no parameter can be accepted to adjust it. There are two time-out settings for one test case, is it possible to use common time-out setting? The two timeouts have slightly different purpose. The interval of the watchdog timer in the driver (in WebKitTestRunner) can detect if the test is slow (the web process don't finish in the interval). In this case we can rely on the driver and there is no need to restart it (because it is still responsive, just the test takes too much time). The timeout of the test harness (run-webkit-tests) take into action when the driver become unresponsive, and in this case it is necessary to restart it. Would you please help to double check about it? Historically there has been absolutely no excuse to *expect* a single test take longer than 30 seconds. Such a test needs to be redesigned or broken up in to smaller tests. Thanks, ~Brady Best Regards! Horky ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto: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] can we stop using Skipped files?
So the unit tests are superfluous. In particular, if I had to pick between only having unit tests or only having regression tests, I might pick unit tests. But if I already have regression tests then I'm unlikely to want to incur technical debt to build unit tests, particularly since unit tests requiring changing the infrastructure to make the code more testable, which then leads to the problems listed above. There are many code paths are used rarely. In practice, we were having regressions frequently when people modified the code. Since the codebase has been unittested, the rate of regressions has gone down considerably. The time you spend dealing with tests is considerably less than the time you spend rolling patches in an out as you encounter different edge cases that different configurations/flags hit. A quick note to unittests. I think it's easy to define a hard limit for unittests, which is that: if I want to add a feature, or some customizing option for a particular port, it should be less effort to write the unittest than to write the actual code. I heard from my colleges a few times that it's not always the case with nrwt. I can imagine that it's not trivial to setup the unittest system for a module that has not been unittested so far but I think it should rather be the job of those who are actively working on the test harness, not of those who just need some work to be done for their port. ___ 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 06/08/2012 09:46 AM, Osztrogonac Csaba wrote: 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. 1. These are real weaknesses of nrwt, we should fix them. If gardening is better with orwt (i doubt that is the case, but I don't do gardening regularly), we should improve nrwt, i.e. reimplement features from orwt. 2. I believe basically everybody agrees that we should drop orwt, except you Ossy. Maybe I'm wrong. So, is there anybody still want to have support for orwt? If so, why? -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF_Please_use_ASCIICType_... and system header includes (on QNX)
Sources/WTF/config.h already disables it:
// this breaks compilation of QFontDatabase, at least, so turn it off
for now
// Also generates errors on wx on Windows and QNX, because these functions
// are used from wx and QNX headers.
#if !PLATFORM(QT) !PLATFORM(WX) !OS(QNX)
#include wtf/DisallowCType.h
#endif
I don't think there is a better solution than disabling it for all
modules. Your compile error seems to be the result of not having it
disabled in Sources/WebKit2/config.h. Hope that helps.
On 06/08/2012 01:05 PM, Milian Wolff wrote:
Hey all,
I'm currently trying to patch (Qt-)WebKit in order to build it for QNX. Now
I'm running into an issue which I wonder how to address properly. Most *.cpp
files start with the following lines in WebKit:
// file foo.cpp:
#include config.h
#include foo.h
Now, this might trigger the inclusion of system headers from QNX eventually.
If these contain stuff like e.g.:
// FUNCTION _Tolower
inline int _Tolower(int _Byte, const _Ctypevec *)
{ // perform locale-specific tolower
return (_CSTD tolower(_Byte 0xff));
}
you get a compile time error:
'tolower_WTF_Please_use_ASCIICType_instead_of_ctype_see_comment_in_ASCIICType_h'
is not a member of 'std'
I see how this is useful for WebKit code, but it should not be triggered for
system includes or third-party includes, should it? Does anyone have an idea
on how I could solve this?
For now I'll work-around this issue by disabling DisallowCType.h on QNX, but I
whether anyone has a better idea.
Cheers
PS: Here's a full error trace that shows how we end up at the function
_Tolower I quoted above:
In file included from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/xlocale:12,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/xiosbase:7,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/streambuf:7,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/xlocnum:10,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/ios:7,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/ostream:7,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/istream:7,
from
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/string:7,
from /home/milian/projects/qt5/install-
playbook/include/QtCore/qstring.h:50,
from /home/milian/projects/qt5/install-
playbook/include/QtCore/qobject.h:48,
from /home/milian/projects/qt5/install-
playbook/include/QtCore/qiodevice.h:46,
from /home/milian/projects/qt5/install-
playbook/include/QtCore/qdatastream.h:46,
from /home/milian/projects/qt5/install-
playbook/include/QtCore/QDataStream:1,
from
/home/milian/projects/qt5/qtwebkit/Source/WTF/wtf/Vector.h:35,
from
/home/milian/projects/qt5/qtwebkit/Source/WTF/wtf/Deque.h:37,
from
/home/milian/projects/qt5/qtwebkit/Source/WebKit2/Platform/CoreIPC/ArgumentDecoder.h:31,
from
/home/milian/projects/qt5/qtwebkit/Source/WebKit2/Platform/CoreIPC/Attachment.cpp:29:
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/xlocinfo: In function
'int std::_Tolower(int, const std::_Ctypevec*)':
/home/milian/bbndk-2.0.1/target/qnx6/usr/include/cpp/xlocinfo:173: error:
'tolower_WTF_Please_use_ASCIICType_instead_of_ctype_see_comment_in_ASCIICType_h'
is not a member of 'std'
___
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] can we stop using Skipped files?
On 06/08/2012 05:21 PM, Filip Pizlo wrote: On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote: On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote: 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. 1. These are real weaknesses of nrwt, we should fix them. If gardening is better with orwt (i doubt that is the case, but I don't do gardening regularly), we should improve nrwt, i.e. reimplement features from orwt. I applaud your enthusiasm. 2. I believe basically everybody agrees that we should drop orwt, except you Ossy. Maybe I'm wrong. So, is there anybody still want to have support for orwt? If so, why? I'm with Ossy on this. Getting rid of ORWT would be a show stopper for me. This talk of fixing bugs in NRWT is really great but until such time as those bugs are fixed, let's keep ORWT. Understandable. Let me make it clear: I don't prefer one over the other. I believe it's contra-productive that some people/bots use this, and others use that. It adds overhead to bot maintainance, it's bad for developer experience, and it blocks the evolution of the one and only tool - because some people still make efforts on fixing/improving the other instead. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming DumpRenderTree to WebKitTestRunner or merging those two
On 06/04/2012 03:10 AM, Ryosuke Niwa wrote: On Sun, Jun 3, 2012 at 6:01 PM, Adam Barth aba...@webkit.org mailto:aba...@webkit.org wrote: On Sun, Jun 3, 2012 at 5:54 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Sun, Jun 3, 2012 at 5:33 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: On Jun 3, 2012, at 8:05 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Sun, Jun 3, 2012 at 3:55 PM, Maciej Stachowiak m...@apple.com mailto:m...@apple.com wrote: I am on vacation so I won't be able to review your patch in detail, but from your description it sounds less appealing to me than the WKTR approach. It seems like bad layering to me to define the IDL interface in WebCore for something actually implemented completely outside of WebCore. While you're right that it's somewhat of a layer violation to define the IDL for layoutTestController, WebCoreTestSupport appears to be the most logical place to share files between DumpRenderTree and WebKitTestRunner at the moment unless we're going to create another project/library in Tools. The downside is that they would be using internal WebCore interfaces instead of the public interface as originally intended. I do not think that is a good change, nor does it seem required just to share more code. Are you referring to things like JSValueRef? If JS* functions are supposed to be tested in DumpRenderTree, then that's a good argument against this approach. JavaScriptCore has a bunch of tests for its API independent of DumpRenderTree. I suspect Maciej's point is more about having DumpRenderTree use public rather than private interfaces so that it's easier for JavaScriptCore to change its private interfaces. Have you looked at adding a V8 backend to the code generator that WebKitTestRunner is using currently? My guess is that it will be much simpler than CodeGeneratorV8.pm because WebKitTestRunner doesn't have deal with all the exciting variety was have in the web platform. http://trac.webkit.org/browser/trunk/Tools/WebKitTestRunner/InjectedBundle/Bindings/CodeGeneratorTestRunner.pm hasn't changed in 17 months, so I wouldn't expect an ongoing maintenance issue. Yes. But there was a recent discussion about supporting V8 in WebKitTestRunner where Sam objected to it citing that doing so will clutter the WTR's codebase. I have no problem with creating a V8 backend if Sam doesn't mind introducing V8 equivalent there. However, the real difficulty is in sharing files between WebKitTestRunner and DumpRenderTree, and modifying 11? build configurations we have for DumpRenderTree. - Ryosuke I think you refer to the discussion started by me. To make it clear, it was about whether can we support v8 in WebKit2, not (just) WebKitTestRunner. The solution of mine - wrapping v8 with the jsc api for WTR - would make it unnecessary to change anything on WTR. On the other hand, using generated bindings in WTR and WebKit2 could also be a way to keep the mantainance overhead of supporting v8 low. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit2 with v8
On 05/31/2012 07:06 PM, Alexey Proskuryakov wrote: What I'm seeing is that parts of v8 support are already leaking into cross-platform WebKit2 code. WebKitTestRunner cannot just use WebCoreTestSupport, it needs an ifdef for Qt: #if PLATFORM(QT) DumpRenderTreeSupportQt::injectInternalsObject(context); #else WebCoreTestSupport::injectInternalsObject(context); #endif This is of course something non-Qt developers have to worry about, see e.g. https://bugs.webkit.org/show_bug.cgi?id=87783#c14. This one could be avoided with the shim (in https://bugs.webkit.org/show_bug.cgi?id=87872). We could introduce a file called WebKitTestSupportQt.cpp that implements injectInternalsObject(JSContextRef). It would unbox the v8 context from the wrapper and call the v8 version of WebCoreTestSupport::injectInternalsObject. So it's a bit complicated but at least there would be no ifdef needed in WebKitTestRunner. - WBR, Alexey Proskuryakov 31.05.2012, ? 9:38, Balazs Kelemen ???(?): I continued to work on this, more complete patches have been sent in https://bugs.webkit.org/show_bug.cgi?id=87872 and https://bugs.webkit.org/show_bug.cgi?id=84457. It's not because I don't understand your points, but it's better to debate on an actual patch that just theoretically :) I think most of what is needed in WebKit2 to support v8 is really just boilerplate code that should not change regularly. On 04/24/2012 12:23 AM, Sam Weinig wrote: Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemenkbal...@webkit.org wrote: On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached tohttps://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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 mailto: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] webkit2 with v8
I continued to work on this, more complete patches have been sent in https://bugs.webkit.org/show_bug.cgi?id=87872 and https://bugs.webkit.org/show_bug.cgi?id=84457. It's not because I don't understand your points, but it's better to debate on an actual patch that just theoretically :) I think most of what is needed in WebKit2 to support v8 is really just boilerplate code that should not change regularly. On 04/24/2012 12:23 AM, Sam Weinig wrote: Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemenkbal...@webkit.org wrote: On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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] *.webkit.org is down
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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit2 with v8
Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit2 with v8
On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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] Removing support for the RVCT compiler
On 12/11/2011 05:56 AM, Benjamin Poulain wrote: On Sat, Dec 10, 2011 at 8:47 PM, Eric Seidele...@webkit.org wrote: I'm curious what the practical implications of this are? Are there 500 #ifdefs for RVCT or 5? I think a dozen of #ifdef, plus a dozen of workarounds for compiler bugs. I know about a lot of ifdefs for the JIT at least. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turn on the PARALLEL_JOBS feature by default
On 10/18/2011 06:42 PM, Darin Adler wrote: I think it’s worth going further — when can we remove this #if altogether? -- Darin Sure we can, sounds great. I will do that in the next patch. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Turn on the PARALLEL_JOBS feature by default
Hi Webkittens! I am planning to turn on the ENABLE_PARALLEL_JOBS feature by default. It is tracked in https://bugs.webkit.org/show_bug.cgi?id=70032. This feature has proved to be an efficient optimization for some SVG filters where it has been applied. Naturally it could be used in other areas as well in the future. It supports a fork-and-join threading scheme thus it can be used for computations where the task can be divided to independent sub-tasks. It plays well with the platform: for Mac it has a libdispatch based implementation. For other platforms it has a generic and an openmp based one - the latter is used only in -fopenmp builds. With the Methanol benchmark - https://gitorious.org/methanol - our measurements showed a 60% speedup for SVG filters on a 6 core MacPro (libdispatch implementation) and 40% gain on my 4 core i5 desktop (generic implementation). The cost of enabling the feature is a few extra thread creation with the generic backend. The maximum of thread creations is the number of cores in the system since the implementation using a basic thread-pool for the parallel threads. With libdispatch it's cheaper because the system handles the thread allocation for us. In the case of openmp the cost is implementation specific but normally it should also has an internal thread pool. Finally, for !ENABLE(FILTERS) builds there is no cost at all currently. Please tell me if you have any concerns about enabling the feature. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Features defines: Platform.h vs build system
Hi all! I think we lack a consistent way for setting up the set of feature defines. Some of them are handled via Platform.h and some of them via the build systems. Don't you think all should be handled the same way? This has came up in my mind in connection with the newly introduced CSS_FILTERS define. (https://bugs.webkit.org/show_bug.cgi?id=68652) The logic to set the define has only been added to the Mac build system because the feature is Mac-only currently. I don't think it is a good solution. As more platforms would use the feature they also need to add the logic to their build system that is somewhat more difficult than just adding one more ifdef branch to Platform.h. Note that it is not totally avoidable to have some overhead per platform because we need to handle the --css-filters build-webkit switch. However build-webkit already knows how to set up a -D flag on each platform so it's not a big deal. I wonder about your opinion on this. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
On 07/06/2011 07:24 PM, Eric Seidel wrote: On Wed, Jul 6, 2011 at 10:18 AM, Xan Lopezx...@gnome.org wrote: On Wed, Jul 6, 2011 at 6:29 PM, Eric Seidele...@webkit.org wrote: NRWT uses both! It will read in all the port's Skipped files, covert them to SKIP text_expectations, and add them to your test_expectations file. http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/webkit.py#L309 For better or worse, NRWT will error out, if you have duplicates in your test_expectations file, including duplicates between your test_expectations file and your Skipped lists. Right, this is what I meant in another email when I said you are not supposed to use both. Cannot really see a sane use case for this to be honest. When I transitioned I basically converted Skipped locally to the new format, got tons of duplicated errors, figured out what was going on and deleted then deleted Skipped. Maybe this is done so that you can leave Skipped as it is and start gradually adding stuff to the new file? This was done to make it possible to bring up NRWT on Mac over a year ago. :) I'm happy to look at moving to a different configuration now that the project has (mostly) moved to NRWT. So long term the best is to move from Skipped to text_expectations. But I worry about the lack of the cascading logic. At some point we decided that we need it in the old system. Why do we think that we won't need it with NRWT? I think the cascading reduce the cost of maintaining the skipped lists. WebKit2 is the best example. We have a common skip list that lists all the tests that are failing due to a common WebKit2 specific reason. In that way, I can skip tests that appearing when I work and Apple folks are sleeping and they don't need to worry about that and the same is true in the reverse direction. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Todo List for WebKit2
On 04/14/2011 02:34 PM, naren.me...@gmail.com wrote: Hi Everybody, I have recently started understanding webkit2 and am interested in participating and contributing in this project. So far I have gone through the available webkit2 code through GIT repository and studied the available documents. I tried to find a ToDo list so that I can pick up some work from there but couldnt find it. Can any of you pls point me towards it, if its there ?? First of all, what platform are you targeting and what are your goals? As per my current understanding, I have made a small list which cover the broad topics/functionalities that is currently missing in WebKit2 pls feel free to correct me if I am wrong 1) Shared Secondary Thread (Full implementation) 2) Secondary process (Full implementation) It has been sad that first we concentrate on the shared secondary process model i.e. make it feature complete and stable before start playing with other models. I don't want to discourage you about working on these but currently the trunk does not go on this direction. Further discussion about process models: https://lists.webkit.org/pipermail/webkit-dev/2010-August/014129.html, and https://bugs.webkit.org/show_bug.cgi?id=53597 3) Plugin process support (Full implementation) 4) GTK port implementation for not implemented functionalities. (Partial implementation) 5) Plugin stream like flash or other media players (Full implementation) 6) Web process crash management/ recovery (Full implementation) What do you mean about full implementation? Work is going on all these topics. You are free to join and start contributing on these. and also pls add more topics to this list to make it more comprehensive. It will be very helpful for newcomers like me. Looking forward to the support and guidance of fellow community members. Thanks and Regards, Naren ___ 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] Todo List for WebKit2
Is there any particular work being done on sandboxing like chrome ?? Yes, it is, but currently it is restricted to the Mac port as I know. I believe porting it is a goal for both the Qt and Gtk port. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WebKit's GTK+ back-end using distcc timing
As far as I know, distcc master process pre-processes the code before sending it to the slaves. Having more (or bigger) files in the tree could be the cause of your master machine having to do more work before offloading the compilation to the slaves. Last, but not least, more code means more work when linking libraries and programs, and this step is also done by the distcc build master. There could me some other additional reasons why it is taking so much time now, but I would point to pre-processing and linking as possible causes for the distcc master now doing more work. Especially when you do not have enough memory and the system start swapping. Have you checked that? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git history and the moving to Source
That works, thank you guys! By the way, don't you think the -M switch for git diff should be used by webkit-patch? It's much easier to review a patch with rename and changes with the rename detection. On 01/04/2011 07:26 AM, Evan Martin wrote: Adam is correct. To elaborate, there are two rename-related flags of interest: 1) When you git log -- foo/bar.cc, you're saying only show me logs that apply to the path foo/bar.cc. This excludes renames implicitly. The --follow flag indicates that the filename filter should be broadened to include renames. 2) If you are viewing diffs (like with -p), you must pass -M etc. just as you would to git diff for it to find renames. Here's an interesting thread from Linus on the subject: http://kerneltrap.org/mailarchive/git/2009/1/30/4856404/thread As usual, his opinions on renames are ...interesting. On Mon, Jan 3, 2011 at 5:56 PM, Adam Barthaba...@webkit.org wrote: There's a git option to follow renames. I think it's --follow, but some git experts might know better. Adam On Mon, Jan 3, 2011 at 5:53 PM, Balazs Kelemenkbal...@webkit.org wrote: I have just realized that git log -- filename does not output the history before the file had been moved to Source. It seems like the whole git history will be lost after the move. Did we take this into consideration when we decided to switch to the new directory structure? Can we do something to save the history? Or should I just do something locally to fix this? Balazs ___ 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] Why is ResourceHandle.cpp in WebKit/chromium/src
I have no strong opinion about which pattern should we use but I think we should decide which is the preferred in a given type of WebKit - WebCore interaction. Currently we have introduced a new pattern with the NetworkingContext. Shouldn't we rework that and implement in the form of a strategy? Maybe it could be a good way of testing the usability of the strategy pattern. Currently I would like to remove the frame dependency in the qt version of PluginData (because it is crashing with WebKit2) and I am wondering about should I use the strategy pattern or should I introduce a PluginContext abstraction. On 09/12/2010 08:39 AM, Maciej Stachowiak wrote: On Sep 11, 2010, at 9:42 PM, Darin Fisher wrote: On Sat, Sep 11, 2010 at 2:49 AM, Adam Barth aba...@webkit.org mailto:aba...@webkit.org wrote: If we like pattern (3), maybe we should replace PlatformBridge with (3)? Yes, perhaps we should do that. In concert with that, it would be good to create a subdirectory in WebKit/chromium/src for these WebCore class implementations. I'm concerned that the PlatformStrategies approach adds too much maintenance overhead given the number of interfaces we'd need to add to it. Is it really more maintenance than PlatformBridge? That class includes effectively a bunch of interfaces, they are just demarcated with comments instead of actually being separate classes. Modularity is good. Large interfaces that are a grab-bag of different things are not good for maintainability in the long run. At least that is what we learned from WebCoreBridge back in the day. Furthermore, the PlatformBridge solution is one we cannot use for WebKit2. It uses static methods exclusively and so forces the binding to be compile-time. But we'd like to be able to use the same copy of WebCore with an in-process implementation and an out-of-process one, for many things. Thus, we will need the PlatformStrategies approach for a number of things. For the same reason, header-in-WebCore-implementation-in-WebKit won't work. Chromium could choose to handle the delegation of those things in a completely different way, but that won't lower complexity for the project as a whole. Can you give a bit more detail on why the PlatformStrategies approach seems like too much maintenance overhead to you? I would prefer as much as possible to have an approach that works for all ports. In particular, I hope that with WebKit2 having many of the same specialized requirements as Chromium, we can reduce the amount of Chromium-specific pieces of architecture and find more general solutions to these problems. Regards, Maciej ___ 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] WebKit2 SharedSecondaryProcess model
Right? This means there would be only one WebProcess, which would work as a server for UI client processes which connect to it. I see the benefits of this in an embedded environment where widgets share one common WebProcess and thus this model would use less memory, for example if the WebProcess is used by multiple widgets. Exactly, that is my idea. Is there a future plan to support this model too? At least in my mind it is :) . It would increase the complexity of the framework of course, so it would be important to know other's opinion from the community. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A proposal for Platform Mechanisms
On 06/17/2010 02:30 AM, Anders Carlsson wrote:
Hi everyone,
We've now reached the point in WebKit2 development where we need to be able
to override some global calls in WebCore so that we can funnel them through
to another process, in a similar way to what Chromium does. We also need to
be able to override the calls at run-time, so that we can use the same
WebCore framework with both current WebKit and WebKit2.
Here's a proposal for something I call Platform mechanisms that I hope can
be used by other ports as well as replacing the Chromium bridge long term:
The design pattern we use in WebCore for when a port wants to override
functionality is the abstract client class pattern. We have a
FrameLoaderClient per frame, a ChromeClient per Page etc. Some functionality
is global, and doesn't really belong to a specific object, for example:
* Clipboard handling
* File access
* Plug-ins.
I propose that we create an abstract class, PlatformMechanism which acts as
the starting point for accessing such functionality, something like:
class PlatformMechanism {
virtual ClipboardMechanism* clipboardMechanism() = 0;
virtual FileAccessMechanism* fileAccessMechanism() = 0;
virtual PluginMechanism* pluginMechanism() = 0;
};
class PluginMechanism {
virtual void refreshPlugins() = 0;
virtual void getPluginInfo(VectorPluginInfo) = 0;
};
The various ports would subclass PlatformMechanism, implement the various
mechanism classes and then call into WebCore to set the PlatformMechanism.
This approach gives a natural separation of the functionality. (There's of
course nothing stopping you from having a single class inherit from all of
the mechanism classes). We could also consider adding some functions to
PlatformMechanism directly, for example if a mechanism class would end up
with just a single function.
Hi everyone!
I want to share you my toughts about WebKit2 and the PlatformStrategies
abstraction.
I am working on the Qt port of WebKit2. Currently I have a crash in
PluginData::initPlugins in PluginDataQt.cpp where we want to downcast
the ChromeClient to it's Qt derivate (ChromeClientQt) and access to the
Qt API specific page class (QWebPage):
|QWebPage* webPage = static_cast(m_page-chrome()-client())-m_webPage;|
Of course the ChromeClient is not a ChromeClientQt so we are crashing
there. I am thinking about using the platform strategies to solve this
but my problem is that plugin handling in Qt is bounded to the page. The
Qt API-s has a QWebPage::setPluginFactory method so the initPlugins
should take care about the page specific settings. This is in contrast
with the idea behind the PluginStrategy abstraction.
There are other similar situations where we want to access the port
specific client object. One is in ResourceHandleQt.cpp:
|getInternal()-m_frame =
static_cast(frame-loader()-client())-webFrame();|
This one is also crashing in WebKit2. Hopefully this one can be fixed by
the work tracked in https://bugs.webkit.org/show_bug.cgi?id=42292.
https://bugs.webkit.org/show_bug.cgi?id=42292
I do not want to implement this features in the WebKit2 port for now but
I need a way to disable them in runtime. I am afraid that neither the
abstract client class shame nor the strategy provides an elegant way to
achieve this.
One idea came to my mind is to extend the concrete port specific
Strategy classes with methods like isPluginFactorySupported and ask it
in WebCore. In this case we would downcast the Strategy object to it's
concrete type in WebCore what is not an elegant thing. Do you think it
is acceptable?
I am absolutely open for your suggestions.
Cheers!
Balazs Kelemen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit2 build system
On 07/07/2010 07:27 PM, Sam Weinig wrote: Hi. On Wed, Jul 7, 2010 at 7:02 AM, Balazs Kelemen k...@inf.u-szeged.hu mailto:k...@inf.u-szeged.hu wrote: Hi folks! While I worked on the Qt port of WebKit2, I faced with some build issues. To solve these problems it seems like common parts of WebKit2 should change, that is why I thought that discussing them in the list would be useful. There are two main problem I see: * Usage of precompiled header. Without using WebKitPrefix.h as a precompiled header it seems like includes are broken. The reason why I dislike precompiled header is that distcc does not support it. It should not be necessary to use WebKitPrefix.h as a precompiled header, it is only necessary for it to be used a prefix header. Does discc also not support prefix headers? The config.h in JavaScriptCore and WebCore is there for similar purposes as this prefix header. Why don't we use this one in the same way? This would solve our problems with distcc and icecc. * Include paths. The common files in WebKit2 includes headers in the form #include WebKit2/xyz.h while the real place of the file is for example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by copying headers into the build dir and set the includepath to contain it, but I do not think it is a good practice. We should probably change the mac to have forwarding headers (as we do with WebCore for JavaScriptCore) to avoid this. That would be great. I have started to create them. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit2 build system
Hi folks! While I worked on the Qt port of WebKit2, I faced with some build issues. To solve these problems it seems like common parts of WebKit2 should change, that is why I thought that discussing them in the list would be useful. There are two main problem I see: * Usage of precompiled header. Without using WebKitPrefix.h as a precompiled header it seems like includes are broken. The reason why I dislike precompiled header is that distcc does not support it. * Include paths. The common files in WebKit2 includes headers in the form #include WebKit2/xyz.h while the real place of the file is for example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by copying headers into the build dir and set the includepath to contain it, but I do not think it is a good practice. I think WebKit2 would be more portable if we could solve these problems. Please share your thoughts with me! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Disabling the JIT
If you want to set the flags manually, you should write CXXFLAGS+=... instead of CXXFLAGS=. However, the first method what you tried is right, so if it is crashing then smg wrong with the JIT. What platform (Architecture, OS, qt-version) do you use? On 04/27/2010 05:41 PM, Nyx wrote: I am trying to disable the JIT when building the QT version of webkit so that I can instrument the interpreter for profiling purposes. I have been googling around and found a few suggestions, which so far have all not worked: If I run the following build command: WebKit/WebKitTools/Scripts/build-webkit --qt JAVASCRIPTCORE_JIT=no WebKit builds, but when I try to run it: WebKit/WebKitTools/Scripts/run-launcher --qt It crashes as soon as I try to load a page that uses JavaScript (eg: google). Someone also suggested building WebKit as follows: WebKit/WebKitTools/Scripts/build-webkit --qt --makeargs='CXXFLAGS=-DENABLE_JIT=0' This works *once*, but if I try to run build-webkit a second time, I get lots of nonsensical compilation errors, which I can't seem to get rid of, even if I try to build without -DENABLE_JIT=0... Any help would be appreciated, - Max ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where are bench-alloc-reatained.js and ~-nonretaned.js?
Thanks for the commit, Geoffrey! :-) On 04/19/2010 02:44 PM, Balazs Kelemen wrote: Hi folks! I am doing some hacking around the GC, and want to test and benchmark it. In GC related changes I see results of these two benchmarks, but I do not find them in the tree. Are those living in the tree? If not, I think it would be useful to check-in them. Balazs Kelemen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Where are bench-alloc-reatained.js and ~-nonretaned.js?
We investigating in multithreading possibilities. In connection with the GC I try to organize the mark phase into a parallel thread. The idea is to have 2 heap, serve allocations from the active one, while marking the other. When the active is full, swap them. Currently, it is in a non stable and non complete state, and it is not 100% that it will be ever complete. On 04/19/2010 11:08 PM, Geoffrey Garen wrote: Hi Balazs. I just checked in those two tests to JavaScriptCore/tests/perf. What kind of GC hacking are you doing? Geoff On Apr 19, 2010, at 5:44 AM, Balazs Kelemen wrote: Hi folks! I am doing some hacking around the GC, and want to test and benchmark it. In GC related changes I see results of these two benchmarks, but I do not find them in the tree. Are those living in the tree? If not, I think it would be useful to check-in them. Balazs Kelemen ___ 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] Where are bench-alloc-reatained.js and ~-nonretaned.js?
Hi folks! I am doing some hacking around the GC, and want to test and benchmark it. In GC related changes I see results of these two benchmarks, but I do not find them in the tree. Are those living in the tree? If not, I think it would be useful to check-in them. Balazs Kelemen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
