[webkit-dev] Vector iteration
Hi all, I just landed a patch that replaces VectorT::iterator and VectorT::const_iterator with a non-pointer object that is actually memory safe. Everything _should_ work the same as before, with a few exciting changes: * begin() and end() can no longer be used transparently as pointers. Happily WTF::getPtr() will do the right thing. * The iterators them selves are larger - they have to track the current location and the source vector. It would be nice if we could avoid this within the enumeration syntax but that would require language changes. * Iteration is bounds checked! Woo! As everyone has been switching to C++ enumeration syntax we lost all the bounds checking we were doing previously, but happily that hole is now plugged again. * Huge and happy advantage: Vector iteration is now safe against mutation!!! Previously mutating a vector during enumeration was not memory safe, bounds safe, or in fact any kind of safe (but you weren’t doing that right?), and now it is!!! Happily there is no performance hit from this. —Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?
On a related note I’ve also got a patch up for review that adds bounds checking to Vector::iterator, and that vigorously performs bounds and overflow checking. —Oliver On Nov 19, 2014, at 2:04 PM, Chris Dumez cdu...@apple.com wrote: Hi, I believe the Vector class is already checking for overflows. I looked quickly and it seems that when trying to allocate / reallocate the Vector buffer, we will call CRASH() if: (newCapacity std::numeric_limitsunsigned::max() / sizeof(T)) Kr, -- Chris Dumez - Apple Inc. Cupertino, CA On Nov 19, 2014, at 1:57 PM, Geoffrey Garen gga...@apple.com mailto:gga...@apple.com wrote: I don’t haver a specific opinion on size_t vs unsigned, but I have a related point: If Vector uses unsigned, then it must RELEASE_ASSERT that it does not overflow unsigned when growing. Even if most normal content allocates 4GB, exploit content surely will try to allocate 4GB. Chris, maybe you can make this change in trunk, since trunk uses unsigned? Geoff On Nov 19, 2014, at 1:50 PM, Alexey Proskuryakov a...@webkit.org mailto:a...@webkit.org wrote: That makes good sense for internal implementation, do you think that class API should also use a custom type, or should it use size_t? With Vector though, I don't know how we would differentiate code paths that need large allocations from ones that don't. Nearly anything that is exposed as a JS API or deals with external world can hit sizes over 4Gb. That's not out of reach in most scenarios, not even for resources loaded from network. - Alexey 19 нояб. 2014 г., в 13:19, Filip Pizlo fpi...@apple.com mailto:fpi...@apple.com написал(а): ArrayBuffers are very special because they are part of ECMAScript. We use unsigned for the length, because once upon a time, that would have been the right type; these days the right type would be a 53-bit integer. So, size_t would be wrong. I believe that ArrayBuffers should be changed to use a very special size type; probably it wouldn't even be a primitive type but a class that carefully checked that you never overflowed 53 bits. -Filip On Nov 19, 2014, at 12:54 PM, Alexey Proskuryakov a...@webkit.org mailto:a...@webkit.org wrote: This is not exactly about Vector, but if one uses FileReader.prototype.readAsArrayBuffer() on a large file, I think that it overflows ArrayBuffer. WebKit actually crashes when uploading multi-gigabyte files to YouTube, Google Drive and other similar services, although I haven't checked whether it's because of ArrayBuffers, or because of a use of int/unsigned in another code path. I think that we should use size_t everywhere except for perhaps a few key places where memory impact is critical (and of course we need explicit checks when casting down to an unsigned). Or perhaps the rule can be even simpler, and unsigned may never be used for indices and sizes, period. - Alexey 19 нояб. 2014 г., в 12:32, Filip Pizlo fpi...@apple.com mailto:fpi...@apple.com написал(а): Whatever we do, the clients of Vector should be consistent about what type they use. I'm actually fine with Vector internally using unsigned even if the API uses size_t, but right now we have lots of code that uses a mix of size_t and unsigned when indexing into Vectors. That's confusing. If I picked one type to use for all Vector indices, it would be unsigned rather than size_t. Vector being limited to unsigned doesn't imply 4GB unless you do Vectorchar. Usually we have Vectors of pointer-width things, which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)). Even in a world where we had more than 32GB of memory to use within a single web process, I would hope that we wouldn't use it all on a single Vector and that if we did, we would treat that one specially for a bunch of other sensible reasons (among them being that allocating a contiguous slab of virtual memory of that size is rather taxing). So, size_t would buy us almost nothing since if we had a vector grow large enough to need it, we would be having a bad time already. I wonder: are there cases that anyone remembers where we have tried to use Vector to store more than UINT_MAX things? Another interesting question is: What's the largest number of things that we store into any Vector? We could use such a metric to project how big Vectors might get in the future. -Filip On Nov 19, 2014, at 12:20 PM, Chris Dumez cdu...@apple.com mailto:cdu...@apple.com wrote: Hi all, I recently started updating the WTF::Vector API to use unsigned types instead of size_t [1][2], because: - WTF::Vector is already using unsigned type for size/capacity internally to save memory on 64-bit, causing a mismatch between the API and the internal representation [3] - Some reviewers have asked me to use unsigned for loop counters iterating over vectors (which looks unsafe as the
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On May 7, 2014, at 2:41 PM, Rik Cabanier caban...@gmail.com wrote: When would I as a user, not want a page or web application to be as fast as possible? Has a user ever complained about a desktop app that uses too many of his CPU's? I think Oliver's point was that other processes might fight for the same CPU resources but that is not unexpected for users. What happen if i go to your website while i'm doing something else in the background? What if i'm playing a game while waiting for my machine to do something else? What if your page is in the background? Or my battery is running low. You need to stop thinking in terms of a user wanting only one thing to happen at a time. --Oliver ___ 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] support for navigator.cores or navigator.hardwareConcurrency
On May 7, 2014, at 3:15 PM, Rik Cabanier caban...@gmail.com wrote: On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt oli...@apple.com wrote: On May 7, 2014, at 2:41 PM, Rik Cabanier caban...@gmail.com wrote: When would I as a user, not want a page or web application to be as fast as possible? Has a user ever complained about a desktop app that uses too many of his CPU's? I think Oliver's point was that other processes might fight for the same CPU resources but that is not unexpected for users. What happen if i go to your website while i'm doing something else in the background? What if i'm playing a game while waiting for my machine to do something else? What if your page is in the background? Or my battery is running low. Sure. However, a page can already do this today. This will just give the author a way to make a semi-informed decision. Without this, he might just spin up too many threads and starve the rest of the system. You need to stop thinking in terms of a user wanting only one thing to happen at a time. I'm not sure if I follow. How would this be any different from a regular desktop application? The argument is that this is not behaviour that users want - the fact that desktop applications do this is a bug in the programming model. APIs like GCD were specifically created to allow a developer to make an application than can automatically scale (or descale) to match the behaviour that is best for the user. That’s the model we want to encourage on the web. —Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency
On May 5, 2014, at 6:13 PM, Rik Cabanier caban...@gmail.com wrote: Do you really want a page to know that you have a fancy-pants 24-core Mac Pro rather than a little Mac mini? Yes! If I have 24 cores ready to do work and the page can put them to use, I would like it to do so. At the same time, if I just have a old mac mini, I don't want the page to launch 24 workers as that will exhaust my memory and cause contention. But I don't have 24 cores available, i have 24 cores installed. You have no idea what the actual workload of the system is, you don't know whether any other tabs are also using workers, you only have one piece of information, and that is nowhere near sufficient to make a reasonable choice. A better solution would be to have a WorkerSet API where the browser is able to make a sensible choice given the current system, system load, power source, etc, etc Generating workloads on the basis of # of installed cores has be attempted on every environment and it almost always leads to incorrect choices being made. --Oliver On May 5, 2014, at 4:58 PM, Filip Pizlo fpi...@apple.com wrote: I like this. Personally, I don't see any downside. Is there a bug (on bugs.webkit.org), and if not, can you create one? :-) -Phil On May 5, 2014 at 4:49:35 PM, Rik Cabanier (caban...@gmail.com) wrote: All, there's a thread on blink-dev [1] and whatwg [2] to create a new parameter on the navigator object that returns the maximum number of tasks that can run in parallel. [3] Is this something that WebKit would support? 1: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4 2: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html 3: http://wiki.whatwg.org/wiki/NavigatorCores ___ 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] EFL EWS Bot output
Could whoever is responsible for the EFL EWS bot please make the bot set the correct mimetype on the build output. I've requested this before, but i'm trying again. It is really annoying that it triggers a download rather than just opening in the browser like the output from every other bot. Cheers, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [JavaScriptCore] When to JSValueProtect?
On Dec 7, 2013, at 12:15 PM, Alexei Sholik alcosho...@gmail.com wrote: The garbage collector scans the C stack. Hm, let me make sure I understand this correctly. ... I'm asking because I've never previously dealt with a library that scans the host application's stack. So it sounds pretty incredible to me. Every JSC vm will do a full conservative scan of the in use portion of the stack for every thread in your application whenever it needs to GC. Anything that looks like it could be a pointer to a gc value is treated as though it is _definitely_ a GC value and marked accordingly. Thanks! On Sat, Dec 7, 2013 at 9:37 PM, Geoffrey Garen gga...@apple.com wrote: At this point, the code is not inside the JS stack, so is it possible for an object to be collected between the calls to JSObjectMake and JSObjectCallAsFunction? The garbage collector scans the C stack. Geoff -- Best regards Alexei Sholik ___ 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] Changes in QtWebKit development
On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Monday 30 September 2013, Oliver Hunt wrote: On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: Some of this is exactly the reason we want to keep Qt WebKit alive. It may never be possible to fully replace Qt WebKit with anything Blink/Chromium based. I really don’t understand this, there are only two options: 1. Qt Webkit is critical to you and you want to support and maintain it, and do all the work necessary for that; or 2. Qt WebKit is not critical, and so you could simply branch and have a permanent stable release platform similar to what the S60 port did years ago. Currently you seem to be arguing for a third option, wherein all of the WebKit developers need to deal with your port, and be hamstrung by the numerous invasive Qt-isms scattered throughout the codebase, for a port that isn’t considered critical to its own platform. Actually I am arguing we should get rid of most of the invasive Qt'ism unless they are really required for Qt WebKit to even work. Many of them were only necessary due to having to support so many platforms. With a more narrow focus we can hopefully get rid of 90% of the burden. If it turns out not to be possible in the end, we can always leave after having helped as far as we could. But why should webkit have _any_ burden when Qt itself cares so little about QtWebKit that it is happy to have qtisms that were ostensibly necessary for performance, etc removed? My reading of that is that you are more willing to have the quality of QtWebKit deteriorate than to simply fork off a final high quality stable branch. I don’t believe WebKit should be taking _any_ burden for a port that is primarily focused on a completely separate fork in an unrelated tree. So could you please say whether the QtWebKit plan going forward is option 1 or option 2. —Oliver Best regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF::fastMalloc
On Oct 1, 2013, at 11:56 AM, Martin Robinson mrobin...@webkit.org wrote: On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen gga...@apple.com wrote: A 5% regression in page load performance seems pretty serious. I’m assuming you’re considering the GTK port here, and not the end-of-life Qt port. Are you up for some engineering work to adopt a better malloc for GTK? I appreciate your offer! Here’s a rough task list: (1) Define a canonical GTK platform we’ll use for performance measurement. Perhaps the University of Szeged team has some insight into what platforms they used for comparing allocator performance. (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by global operator new/delete in WebCore+JavaScriptCore. (1a) Either build the API layer as a separate library from WebCore+JavaScriptCore, (1b) or specifically annotate each object at the API library with a per-class operator new / operator delete. I don't think this should be a problem. Currently all allocations of API-level objects happen with the GLib slab allocator (or system malloc/free, given the right environment arguments). (2) Find a fast secure random number API on the canonical GTK platform. I can look into this. WTF has a custom implementation of arc4random(), i suspect most current Gtk host environments have a native one as well (s_rand on windows is terribly slow, but like i said, WTF has its own secure generator that will seed appropriately) (3) Find a fast thread-specific data API on the canonical GTK platform. Threading for GTK+ on non-Mac/non-Windows platforms is essentially pthreads. It probably wouldn't be a lot of work to defer to Windows and Mac implementations on those platforms. I recall linux having fast thread locals, as does windows. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changes in QtWebKit development
On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: Some of this is exactly the reason we want to keep Qt WebKit alive. It may never be possible to fully replace Qt WebKit with anything Blink/Chromium based. I really don’t understand this, there are only two options: 1. Qt Webkit is critical to you and you want to support and maintain it, and do all the work necessary for that; or 2. Qt WebKit is not critical, and so you could simply branch and have a permanent stable release platform similar to what the S60 port did years ago. Currently you seem to be arguing for a third option, wherein all of the WebKit developers need to deal with your port, and be hamstrung by the numerous invasive Qt-isms scattered throughout the codebase, for a port that isn’t considered critical to its own platform. —Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] LLInt alignment problem on ARM
I believe that there’s a mnemonic that forces alignment that we could (arguably should?) be using before these labels. IIRC it’s something like .align N — if we aren’t doing this already we could make the lint assembler backend emit a .align 16 prior to each global symbol. —Oliver On Sep 26, 2013, at 1:09 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote: Hello! I'm fighting with a strange LLInt alignment problem on ARM. As I see we put the LLInt code into .rodata section instead of .text. Is there a specific reason why we are doing this? If there is not I would put them to the .text section. Here is the objdump: ./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: file format elf32-littlearm Disassembly of section .rodata: _ZStL19piecewise_construct: 0: andeq r0, r0, r0 0004 _ZStL13allocator_arg: 4: andeq r0, r0, r0 0008 _ZStL6ignore: ... 0009 llint_begin: 9: e30b3eefmovwr3, #48879 ; 0xbeef d: e34b3badmovtr3, #48045 ; 0xbbad 11: e583str r0, [r3] 15: e3a0mov r0, #0 19: e12fff30blx r0 001d llint_program_prologue: 1d: e1a0200emov r2, lr 21: e5852010str r2, [r5, #16] 25: e5951008ldr r1, [r5, #8] ... The problem is that these traditional instructions are lying on odd adresses in the .rodata section. Regards, Gabor ___ 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] Can we disable control reaches end of non-void function warning on Qt?
We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() and clobber those with RELEASE_ASSERT_NOT_REACHED() as well. I wonder if it would be easier to have DEFAULT_NOT_REACHED() and DEFAULT_OKAY() macros, and convince the style bot to require ether a default: block or one of these two macros at the end of every switch? --Oliver On Sep 13, 2013, at 10:29 AM, Darin Adler da...@apple.com wrote: On Sep 13, 2013, at 10:28 AM, Alexey Proskuryakov a...@apple.com wrote: 13 сент. 2013 г., в 10:13, Darin Adler da...@apple.com написал(а): Since there’s no runtime guarantee that the enum will have a valid value, I think there needs to be a return statement outside the switch, even if we have ASSERT_NOT_REACHED before it. Should it be a RELEASE_ASSERT? If we have a bad value in an enum, it's likely a memory smasher, so it's best to crash before it's exploited. Sure, that’d be OK with me. -- Darin ___ 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] Can we disable control reaches end of non-void function warning on Qt?
Hurk :-/ I guess there's no nice automate-able to handle everything magically. Still it would probably be good to replace the default:ASSERT_NOT_REACHED() cases at least. --Oliver On Sep 13, 2013, at 10:33 AM, Darin Adler da...@apple.com wrote: On Sep 13, 2013, at 10:31 AM, Oliver Hunt oli...@apple.com wrote: We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() and clobber those with RELEASE_ASSERT_NOT_REACHED() as well. I wonder if it would be easier to have DEFAULT_NOT_REACHED() and DEFAULT_OKAY() macros, and convince the style bot to require ether a default: block or one of these two macros at the end of every switch? Maybe. The advantage of doing the not-reached assertion after the switch is that we get the compile time warning if we don’t enumerate one of the enum values. Having a default case turns that warning off. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing new port: Nix
On Sep 12, 2013, at 6:38 AM, Thomas Fletcher tho...@cranksoftware.com wrote: TDLR: Crank Software Supports a NIX port This is a question of maintenance burden. As Geoff said every port adds a cost to developing and maintaining webkit. You've said you support a NIX port, but a quick search doesn't show any contributions from you or crank software (very quick so feel free to correct me if i'm wrong) so it's hard to see what this support entails. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposed feature: Network Service Discovery
On Sep 6, 2013, at 9:44 AM, youenn fablet youe...@gmail.com wrote: Hi Ryosuke, The two points you are mentioning make sense to me. For starters, most of users wouldn't even know what a local network is; let alone what discovering media sources, etc... mean. Most users may not be able to understand what means “discover local network DACP servers”. But if a user is requested to grant/deny access to “Bob music library” service (the service being a DACP server), the situation seems getting better. The spec is a work in progress and may be improved. For the sake of argument let's say this discovery is allowed to occur. How do you talk to Bob music library without the web page sending raw data to/from the DACP server? --Oliver___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposed feature: Network Service Discovery
On Aug 30, 2013, at 9:15 AM, Brendan Long s...@brendanlong.com wrote: On 08/29/2013 05:45 PM, Benjamin Poulain wrote: Can you explain a bit what it is for? What are the common use cases? This would be useful for certain kinds of web apps. For example,a music website like Pandora or Spotify could allow users to include music on their local network. Or a service like Netflix could include local network movies (on networked hard drives, or DVR's) in their search results, and play them from the same interface. Here's my concern - if you say a service like x might want to search for something, that is better described as a random website. That may be something the user wants, alternatively it could be something evil. It could also be something evil embedded in an ad on the site a user trusts. My concern here is that as a web spec this essentially acts as a way for arbitrary web content from any source to perform a network scan of your local machine and get data about your internal network topology and services from inside your firewall. That's a really scary concept to me. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposed feature: Network Service Discovery
On Aug 30, 2013, at 12:44 PM, Dirk Pranke dpra...@chromium.org wrote: On Fri, Aug 30, 2013 at 10:06 AM, Oliver Hunt oli...@apple.com wrote: On Aug 30, 2013, at 9:15 AM, Brendan Long s...@brendanlong.com wrote: On 08/29/2013 05:45 PM, Benjamin Poulain wrote: Can you explain a bit what it is for? What are the common use cases? This would be useful for certain kinds of web apps. For example,a music website like Pandora or Spotify could allow users to include music on their local network. Or a service like Netflix could include local network movies (on networked hard drives, or DVR's) in their search results, and play them from the same interface. Here's my concern - if you say a service like x might want to search for something, that is better described as a random website. That may be something the user wants, alternatively it could be something evil. It could also be something evil embedded in an ad on the site a user trusts. My concern here is that as a web spec this essentially acts as a way for arbitrary web content from any source to perform a network scan of your local machine and get data about your internal network topology and services from inside your firewall. That's a really scary concept to me. While there are certainly security concerns that need to be clearly thought through and addressed, the spec isn't as broad as you make it sound. It picks up services that are advertising themselves, after all; you can't probe. (Unless you've noticed something in the spec I haven't; I've scanned the spec, but not read it super-carefully). Define advertise? Bonjour like? UPnP? The draft does contain the sentence Web pages should not be able to communicate with Local-networked Services that have not been authorized by the user thereby maintaining the user's privacy in the use cases section; this should definite be emphasized and fleshed out, in a security section. How does the user know what they're doing? If there's an ad/unescaped comment containing something malicious should a remote site be able to know what services you have in your internal network? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ports not building as C++11?
So wait, is everyone using C++11 now? I dream of using auto… :-D On Jul 28, 2013, at 12:47 PM, Gergely Kis gerg...@homejinni.com wrote: Hi, On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: became required in WebKit2. The only fallout will likely be the loss of the Qt MIPS bot which is maintained by a third party and is too old. The MIPS bot was updated to Debian Wheezy and GCC 4.7.2 a few weeks ago, I just forgot to update the buildbot slave info file, did it now. Best Regards, Gergely the 3rd party maintaining the MIPS bot :) ___ 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] FTL merge (and subsequent mayhem)
(I meant to send this last night, so many apologies for the delay) Last night I merged over the FTL branch to trunk, currently the FTL itself is guarded by ENABLE_FTL_JIT and HAVE_LLVM guards, however the branch does bring in a lot of general improvements to JSC's existing execution engines. Unfortunately this has hosed all the non-Mac builds, and my initial attempt to fix the CMake based build systems had so little effect that I felt I needed assistance from engineers on those specific platforms, unfortunately none were around by the time I headed to bed. I would like to apologise to the maintainers of those platforms that I destroyed, and offer my heart felt thanks to those who have already started getting the builds running. I will be available all day today if help is needed, but to my knowledge this should primarily require updating project files *crosses fingers*. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebGL validations
On Jul 15, 2013, at 4:04 AM, SzymanskiPrzemyslaw p.szymans...@samsung.com
wrote:
Hello.
Valgrind shows that WebGL performance is lowered by WebGL validation methods
like: WebGLRenderingContext::validateRenderingState,
WebGLRenderingContext::validateUniformMatrixParameters or validations in
drawElements/drawArrays. Those validations are done in the OpenGL driver.
WebKit use those validations mostly for console output.
The validation routines that you're talking are not simple logging functions:
they are critical for WebGL to have any semblance of safety.
All of these validation routines have the following basic logic:
bool Thing::validateFoo() {
if (fooState is valid)
return true;
log(foo error)
return false;
}
all WebGL functions call the relevant validation functions and then abort if
the validation returns false.
This validation is _not_ optional, even the WebGL spec talks about what is
necessary.
I propose to make some setting bool variable like: webgl_validations_enabled
= true/false and use it in WebGLRenderingContext.
So if webgl_validations_enabled = false then WebKit should not validate WebGL
and performance will be increased. Typically user doesn’t need those
validations. It is helpful only for developers. So they can enable WebGL
validations by check webgl_validations_enabled = true.
In WebKit it is a variable indicating to print messages to console so for
WebGL validations this solutions should also works.
Having an option to remove validation simply is not viable - if you wanted you
could try to speed up the validation logic, but the validation cannot be
dropped.
The validation is needed to achieve a semblance of safety in WebGL and the
WebGL spec even specifies what validation must occur, so removing the
validation would also result in incorrect behavior (relative to that specified
by the spec. Crashing the browser is also incorrect behavior :D )
Regards,
Przemyslaw Szymanski
--Oliver
___
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] All development moved private?
Webkit development occurs on trunk and most communication is on IRC and in bugs.webkit.org. If you rely on email to see signs of activity I recommend subscribing to webkit-commits (or whatever that list is called). All it would have taken is the briefest look at webkit's svn or git repositories to see that. Discussion on webkit-dev is usually about substantial changes, or in recent years bike shedding discussions that carry on with no apparent end. --Oliver On Jul 12, 2013, at 10:55 AM, Randall Bennett randall.benn...@gmail.com wrote: I've noticed this list has basically gone silent. I'm wondering if there's another place where I can find out about what's being developed with Webkit, or if Webkit's public development has essentially ceased now that Google has forked Blink. rb ___ 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] Pepper and NaCl supporting (prototype)
Neither NaCl nor Pepper are trivial pieces of code, they would require maintenance if they were in trunk. If they're not in trunk then the entire discussion on webkit-dev is moot as they would (by definition) not be present in WebKit. You also haven't said _why_ they're a cool and useful technology, which was my point. What do they provide that is not already provided by the standardized_ web platform? Taking a large pile of code, to support a platform with no obvious signs of standardization reeks of the science experiment concept we don't want in the tree. I have not seen any evidence of a specification document anywhere, and without a spec document how can anyone else write their own implementation? --Oliver On Jul 11, 2013, at 5:46 AM, Jake j...@jakeonthenet.com wrote: I would suggest you re-read the original post - Halton's work adds no maintenance burden to the webkit project whatsoever. It does, however, make some very cool and useful technology available to those who choose to use webkit2. I believe that would qualify as obvious benefit. On Tue, Jul 9, 2013 at 12:49 PM, Oliver Hunt oli...@apple.com wrote: Aside from any other issues, my recollection was that there had not been any work to formally specify NaCl or Pepper, has that changed? I'm also concerned as this adds a significant maintenance burden to the project for no obvious benefit. --Oliver On Jun 30, 2013, at 11:41 PM, halton huo halton@gmail.com wrote: Dear WebKit developers and users, I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2] support for WebKit2. The home page is located at https://github.com/nacl-webkit/native_client/wiki. The initial code include supporting of: * Partial pepper api supporting includes: 2d, scripting, url_loader, file chooser, audio, mouse and keyboard events, websockets. * Basic NaCl support with post message api (HelloWorld from nacl_sdk) There are some sceenshots on https://github.com/nacl-webkit/native_client/wiki/Screenshots QA === Q: Why this project? A: We enjoy working with the WebKit projects. We also enjoy technologies like NaCl, and wanted to lower the barrier to letting people integrate NaCl into their WebKit2 based projects. We prototyped this work and now want to make it available for others to use if they want. Q: Can I modify and re-use the project? A: Yes. The code is inherited from the Chromium, WebKit2 and native_client projects. As such, this project follows the same licenses. Q: Why not upstream? A: There are two main reasons. First, the current code is only a prototype to support NaCl in the Linux EFL port of WebKit2. There still remains work to be done before the patches would be appropriate to try and take upstream. Second, the WebKit community has stated in the past that they did not want NaCl upstream. Q: How to contribute? A: Fork the repo on github and submit the pull request, committers will review the patches. For the time being, the initial contributors are committers, we're welcome to anyone who can show his ability to be as committer. Follow the https://github.com/nacl-webkit/native_client/wiki/Code to get code and build. Q: Any next plan? A: We don't have any formal plans for the project moving forward; it is being developed as a part-time effort by a few engineers. As such, there is no guarantee for future work. Again, anyone is welcome to contribute! Or fork the project and run with it. [1] http://code.google.com/p/ppapi/ [2] http://code.google.com/p/nativeclient/ ___ 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] Pepper and NaCl supporting (prototype)
Aside from any other issues, my recollection was that there had not been any work to formally specify NaCl or Pepper, has that changed? I'm also concerned as this adds a significant maintenance burden to the project for no obvious benefit. --Oliver On Jun 30, 2013, at 11:41 PM, halton huo halton@gmail.com wrote: Dear WebKit developers and users, I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2] support for WebKit2. The home page is located at https://github.com/nacl-webkit/native_client/wiki. The initial code include supporting of: * Partial pepper api supporting includes: 2d, scripting, url_loader, file chooser, audio, mouse and keyboard events, websockets. * Basic NaCl support with post message api (HelloWorld from nacl_sdk) There are some sceenshots on https://github.com/nacl-webkit/native_client/wiki/Screenshots QA === Q: Why this project? A: We enjoy working with the WebKit projects. We also enjoy technologies like NaCl, and wanted to lower the barrier to letting people integrate NaCl into their WebKit2 based projects. We prototyped this work and now want to make it available for others to use if they want. Q: Can I modify and re-use the project? A: Yes. The code is inherited from the Chromium, WebKit2 and native_client projects. As such, this project follows the same licenses. Q: Why not upstream? A: There are two main reasons. First, the current code is only a prototype to support NaCl in the Linux EFL port of WebKit2. There still remains work to be done before the patches would be appropriate to try and take upstream. Second, the WebKit community has stated in the past that they did not want NaCl upstream. Q: How to contribute? A: Fork the repo on github and submit the pull request, committers will review the patches. For the time being, the initial contributors are committers, we're welcome to anyone who can show his ability to be as committer. Follow the https://github.com/nacl-webkit/native_client/wiki/Code to get code and build. Q: Any next plan? A: We don't have any formal plans for the project moving forward; it is being developed as a part-time effort by a few engineers. As such, there is no guarantee for future work. Again, anyone is welcome to contribute! Or fork the project and run with it. [1] http://code.google.com/p/ppapi/ [2] http://code.google.com/p/nativeclient/ ___ 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] Feature announcement: WebCL
On May 1, 2013, at 5:29 PM, Antonio Gomes toniki...@webkit.org wrote: - 4.2 Cross-Origin Information Leakage WebCL's position is that this be handled by the same mechanism as used for WebGL, ie https://www.khronos.org/registry/webgl/specs/latest/#4.2 . A bug will be filed to request update of wording in the working draft. Thanks - 4.3 Out-of-Range Memory Access The validator will perform static analysis on WebCL kernels to determine violations of WebCL kernel behavior and language restrictions. The results from the analysis will also be used to determine any necessary instrumentation to bring the WebCL kernels in compliance with security and syntactic requirements of the WebCL API. The RFQ for the WebCL Validator located at https://cvs.khronos.org/wiki/index.php/WebCL_Validator provides information on the approach recommended by the WebCL working group. How do you statically verify the all memory accesses are within bounds without limiting a WebCL kernel to the functionality already offered by shaders in WebGL? - 4.6 Prevention of potential denial of service (DoS) from long running kernels: This is addressed by the OpenCL CL_CONTEXT_TERMINATE extension. In http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf , please refer to section 9.16 Terminating OpenCL contexts. I haven't seen any real evidence of widespread support for responsive termination in WebGL shaders yet, and given that the same hardware is involved when you want GPU backed WebCL I don't see how much this will help. It is chicken-egg problem: without Browser vendors commitment to WebCL, the motivation for hardware vendors to implement, for example, OpenCL 1.2 Memory Initialization and Context termination extensions, required by WebCL, is not as strong. The extensions mentioned above are required by WebGL shaders, and WebGL has been around for a lot longer (and has even more stringent requirements than WebCL) - are there any GPUs that support the WebGL restrictions natively? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: WebCL
Before i saw any patches landed i would expect the specification to state exactly what kernel features are allowed and required. Additionally the specification language of the security section is fairly weak - 4.2 doesn't say how CORS will be used to achieve security. Presumably WebCL just wants the WebGL security resource semantics, but the language needs to be explicit. How is 4.3 enforced? The only way to reliably enforce 4.4 is to either restrict the valid kernel constructs (see my first point - you aren't defining the kernel semantics sufficiently well), or to avoid ever pushing the kernels onto a gpu. On the plus side not pushing the kernel to the GPU means executing on the CPU, and so having the benefit of sane interruption and memory access behavior, which neatly solves 4.6. I'd rather not support the half-float format anywhere, as that simply means at some point in the communication paths we end up having to do a software double or single to half conversion, and back again later, all in order to support older GPUs that don't support single, assuming we even let the kernel get anywhere near the gpu. In general I don't like the design of the API, I believe it over-exposes system information and doesn't sufficiently define edge case behavior. --Oliver On Apr 30, 2013, at 5:10 PM, Antonio Gomes toniki...@webkit.org wrote: Hello. As discussed before, Khronos has been working on a specification for WebCL, a JavaScript API that exposes GPUs and multi-core processors for intensive compute tasks. The latest version of the working draft is available here: [1]. Over the past weeks, some discussion involving WebCL took place in this mailing list ([2]), when some concerns were raised, and to which I later on tried to address in [3]. At this time, I would like to contribute our WebCL prototype implementation [4] to WebKit.org. Feature would be defined behind a ENABLE(WEBCL) feature flag, and work will be tracked onhttps://bugs.webkit.org/show_bug.cgi?id=115457. Let me know if you have any comments or concerns. Cheers, [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html [2] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024546.html [3] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024747.html [4] https://github.com/SRA-SiliconValley/webkit-webcl -- --Antonio Gomes ___ 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] Is there a plan for supporting multi-process and WebCL in webkit
On Apr 10, 2013, at 9:44 AM, Jarred Nicholls jar...@webkit.org wrote: On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes toniki...@webkit.org wrote: Hi On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert timb...@adobe.com wrote: Yes, leveraging multicore and the power of GPUs for general computations is great and very powerful but first, securing such kernels is hard, and authoring these would be pretty brutal to most web developers, I think this is what Benjamin was referring to. With WebCL, you are basically writing C style kernels that you load and run to drive the computations, initiatives like RiverTrail are more restrictive but way more approachable and closer to the web, exposing higher level primitives on top of WebCL (ParallelArray for example) and integrated at the language level, which makes a lot of sense. Security is a primary goal of WebCL, and both WebCL and OpenCL working groups are working together to ensure a safe parallel programming environment to the Web, as you can see in [1]. If you have specific concerns, please raise it in the Khronos working group mailing list ([2]) or file a bug ([3]) against the draft spec. Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL. Introducing OpenGL (i.e. WebGL) to the web had similar security concerns, and yet… OpenCL is fundamentally less safe than OpenGL+GLSL, so it not correct to say that the security concerns are similar. There is no part of GLSL that is overtly operating on raw memory with arbitrary pointer access, whereas in OpenCL such functionality is a core primitive. I am not saying that it will be impossible to make WebCL safe (after all OpenCL can trivially be kept on the cpu, which already has the assumption that it is running untrusted code), but whether you can keep it safe without completely compromising the programming and performance model remains to be seen. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of functions
like map, etc where if you restrict your list of language features to a
specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a specific
operation to perform on each element of an array, parallelise it if possible,
and what's possible is arbitrarily limited, and require a distinct type that
isn't an array.
--Oliver
On Apr 10, 2013, at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo fpi...@apple.com wrote:
On Apr 10, 2013, at 2:29 AM, Pozdnyakov, Mikhail
mikhail.pozdnya...@intel.com wrote:
Why not infer ParallelArrays automatically?
Sorry, did not get it. Could you please elaborate?
Normal JS arrays. You use them with pure computation. Profiler notices this.
And then the same things that you have in the ParallelArrays proposal now
work except you don't need a new type.
Compiler writers have been chasing this problem for 50 years, with (AFAIK)
very limited success for languages that don't give you compile-time
annotations to help you along. I'm not aware of any work on JIT compilers
doing this. Why do you think we could do better? (Honest question, I'm not
trying to be snarky, nor am I an expert).
___
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] Is there a plan for supporting multi-process and WebCL in webkit
I'm not sure what you mean here: a parallel array is simply an array of
numbers; there is nothing magic about it.
If we _really_ wanted to be blunt about it, we could simply say (in Array.map)
if (length = giant function.isEasyPeasy() everything in the array is a
number)
return doHardcoreMap();
// carry on doing regular map
...
Understand that the parallel APIs have to do all of this as well, the only
thing they lose is the is everything a number check
--Oliver
On Apr 10, 2013, at 12:50 PM, Dirk Pranke dpra...@chromium.org wrote:
Right, I get how ParallelArrays would work. I was asking Filip how you might
infer that an array could be a ParallelArray.
-- Dirk
On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt oli...@apple.com wrote:
The parallel arrays apis aren't a magic make my code parallel wand.
They don't make general code parallel, they simply provide a bunch of
functions like map, etc where if you restrict your list of language features
to a specific subset, they'll vectorise it.
For instance
ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
would be vectorised
ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
wouldn't be.
This isn't solve autovectorisation, this is we've been given a specific
operation to perform on each element of an array, parallelise it if
possible, and what's possible is arbitrarily limited, and require a distinct
type that isn't an array.
--Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Deleting V8 bindings (was Cleaning House)
There are plenty of other bindings - Gtk has a set of dom bindings i believe, there used to be COM (shudder) bindings as well, but those aren't the problem. We could have as many binding languages as we want, there's no major architectural reason not to. But supporting javascript isn't simply a matter of another binding. The complexity comes from javascript being the internal scripting language used by webcore for script tags, etc. It's that complexity that creates the need for massive abstraction when supporting multiple distinct JS engines. There is simply no way to support multiple JS engines without retaining the current abstraction - the fact that it's currently only present in order to support the existence of V8 isn't relevant - the same machinery would be necessary to support _any_ other JS engine in addition to JSC. There is strictly no advantage to WebKit in keeping that machinery, it is purely performance and opportunity cost. You need an _extremely_ compelling argument to outweigh those costs. --Oliver On Apr 4, 2013, at 11:15 PM, Per Bothner per.both...@oracle.com wrote: On 04/04/2013 09:14 PM, Ryosuke Niwa wrote: On the other hand, I don't think optimizing WebCore for JSC doesn't necessarily mean it'll become impossible for you to have a custom build of WebKit that uses some other binding code. For example, Mac has Objective-C bindings and that's not going anywhere in the foreseeable future. True, but Objective-C bindings are *in addition* to JSC. Our use of Nashorn *replaces* JSC. Still, we can certainly have local changes in the code-base, like we currently do. My worry is about the places the code hard-wires in an assumption on JSC - if those proliferate it will complicate us keeping updated with WebKit. I can see the logic for simplifying, and I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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] SerializedScriptValue: signed vs unsigned char
On Feb 6, 2013, at 4:59 PM, Alec Flett alecfl...@chromium.org wrote: On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak m...@apple.com 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. To be fair, there hasn't been a convention in WebKit at all. uint8_t was chosen for SerializedScriptValue roughly two months ago, with specific IndexedDB support in mind: https://bugs.webkit.org/show_bug.cgi?id=104354 - this usage is not widespread, and in fact the only consumer of this type is IndexedDB. I don't know where you get this idea from -- SerializedScriptValue has always used uint8 buffers. That IndexedDB used Strings and that _it_ changed to uint8 buffers is entirely irrelevant here. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
I take your word for it that it's not possible on Windows. Given that Chromium has many users on Windows (and other non-Mac platforms), you should now understand why this design does not fit well with Chromium's design constraints. But chromium doesn't use webkit or webkit2, so i'm not entirely sure why webkit2 design decisions should consider chromium's (pre-wk2) design decisions. One thing that I'm unclear on is how having a distinct network process can possibly be less secure than a single thread in _any_ circumstance. Fundamentally any sandbox model that allows a single thread to be sandboxed, can just sandbox the main appropriate threads in the separate networking process, vice versa is not true however. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
How will we ensure thread safety? Even at just the tokenizing level don't we use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this seems like it sould add a world of hurt. I realise it's been a long time since I've worked on this so it's completely possible that I'm not aware of the current behaviour. That aside I question what the benefit of this will be. All those cases where we've started parsing html are intrinsically tied to the web's general single thread of execution model, which implies that even if we do push parsing into a separate thread we'll just end up with the ui thread blocked on the parsing thread which doesn't seem hugely superior. What is the objective here? To improve performance, add parallelism, or reduce latency? --Oliver On Jan 9, 2013, at 6:10 PM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel e...@webkit.org wrote: We're planning to move parts of the HTML Parser off of the main thread: https://bugs.webkit.org/show_bug.cgi?id=106127 This is driven by our testing showing that HTML parsing on mobile is be slow, and long (causing user-visible delays averaging 10 frames / 150ms). https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002 Complete data can be found at [1]. In case it's not clear from that link, the ParseHTML column is the total amount of time the web inspector attributes to HTML parsing when loading those URLs on a Nexus 7 using a top-of-tree build of Chromium's content_shell (similar to WebKitTestRunner). The HTML parser parses data a chunk at a time, which means the total time doesn't tell the whole story. The ParseHTML_max column shows the largest single block of time spent in the HTML parser, which is more of a measure of the main thread jank caused by the parser. Antti has pointed out that the inspector isn't the best source of data. He measured total time using instruments, and got numbers that are consistent (within a factor of 2) of the inspector measurements. (We were using different data sets, so we wouldn't expect perfect agreement even if we were measuring precisely the same thing.) Adam Mozilla moved their parser onto a separate thread during their HTML5 parser re-write: https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading We plan to take a slightly simpler approach, moving only Tokenizing off of the main thread: https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit The left is our current design, the middle is a tokenizer-only design, and the right is more like mozilla's threaded-parser design. Profiling shows Tokenizing accounts for about 10x the number of samples as TreeBuilding. Including Antti's recent testing (.5% vs. 3%): https://bugs.webkit.org/show_bug.cgi?id=106127#c10 If after we do this we measure and find ourselves still spending a lot of main-thread time parsing, we'll move the TreeBuilder too. :) (This work is a nicely separable sub-set of larger work needed to move the TreeBuilder.) We welcome your thoughts and comments. 1. https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0 (Epic thanks to Nat Duca for helping us collect that data.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to
I don't understand why anyone is _speculatively_ rolling out patches. You should only be rolling it out if you _know_ the patch is bad. That said if you do rollout a random unrelated patch it is obviously your job to roll it back in. You can't say i thought this broke something, but i was wrong. Here you can have that bug again. There is no case where the original author needs to be involved as we've already determined that they did nothing wrong - the original breakage (of whatever form) was not caused by the patch you selected randomly, and they were not the author responsible for landing anything (eg. the rollout). --Oliver On Dec 11, 2012, at 1:21 PM, Peter Kasting pkast...@chromium.org wrote: On Tue, Dec 11, 2012 at 1:19 PM, Emil A Eklund e...@chromium.org wrote: I don't understand your logic. A patch landed, the sheriff thinks maybe it was bad and rolls it out, then it turns out it was a red herring. Why is it not now the sheriff's responsibility to re-land? After all, the patch was landed originally by people who understood it and hasn't been seen to cause any problems. There might very well have been other changes that conflicts with it. If it applies cleanly then I agree with you that whoever rolled it out should reland it. If there are conflicts or if it requires merging in any way though I'd argue that the original author needs to get involved. There are certainly cases where the original author needs to be involved, but I'd be happy just saying this is a judgment call. Usually rollouts happen not long after a patch lands, and roll-ins happen not long after that. In those cases, most merge failures are trivial and mechanical and can easily be handled by a conscientious sheriff who reads the relevant changes involved in the conflicts. Sometimes, of course, that's not true. But sheriffs should be biased towards try to leave working patches in the tree. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to
On Dec 11, 2012, at 2:17 PM, Peter Kasting pkast...@chromium.org wrote: On Tue, Dec 11, 2012 at 2:14 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why anyone is _speculatively_ rolling out patches. You should only be rolling it out if you _know_ the patch is bad. Sometimes something bad happens to the tree, the sheriff doesn't know which patch is responsible, and the change authors are not present to ask for help. In a case like this the sheriff has to either do speculative rollouts or leave the tree broken. Ideally, of course, change authors are around when something like this happens. But maybe the bustage doesn't happen until much later, due to some subtle/latent issue, or maybe the change author is in fact irresponsible. Or the sheriff could actually see if rolling out a patch locally fixes the problem. I'm not sure why they're considering not testing to be a valid behaviour for someone who is ostensibly meant to be keeping things going in the face of people who aren't testing. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderArena: Teaching an old dog new tricks
Since a common theme people are bringing up is vtable overrides, I do recall reading about vtable masking being available in some compilers. I'm wondering if we should push for support for such in compilers we use - I'm not sure what the vcall perf hit is in such cases, but it would knock kill off vtable overwrites as an attack vector. We can also trivially add vtable poisoning to dealloc if we felt it necessary - i'm not sure here if the problem is specifically use-after-free, use-after-free-and-overwritten-with-evil-data, or use-after-free-and-overwritten-with-another-object-with-a-different-type. --Oliver On Nov 15, 2012, at 2:08 AM, Chris Evans cev...@chromium.org wrote: On Thu, Nov 15, 2012 at 12:34 AM, Elliott Sprehn espr...@chromium.org wrote: On Thu, Nov 15, 2012 at 3:22 AM, Chris Evans cev...@chromium.org wrote: ... My read on the Arena is that it's fragmentation resistant (i.e. it will not repurpose a larger free chunk to satisfy a smaller allocation.) However, memory usage at any given time is defined by peak usage since it cannot release pages back to the system without ruining its security guarantee. Interestingly, it can't be super bad: we already bite this bullet for RenderArena as used by RenderObjects. The RenderArena lifetime is the same as the document / DOM and I was surprised to recently be told that we don't throw away the RenderArena on a full layout. My understanding is that the render tree is rather small compared to the DOM in terms of memory usage on most pages This does not seem to necessarily be the case. Loading Gmail to the inbox view, sizes in bytes for all live allocations: - 541k in the DOM arena - At least a 918k plus a 49k render arena. May have failed to count a few smaller ones that are still live. Would you like similar measurements for a simpler page? Or some other complicated page you think might be instructive? Cheers Chris so not releasing it may not be so bad, but never releasing the memory used from DOM nodes seems like it'd be bad for large web apps. - E ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?
On Oct 1, 2012, at 8:47 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Oct 1, 2012 at 7:07 AM, Dirk Schulze k...@webkit.org wrote:
On Monday, October 1, 2012, Gyuyoung Kim wrote:
Hello WebKit folks,
There were build warning related to unused parameter nowadays. I think there
are three solutions. One is to remove parameter,
another is to use UNUSED_PARAM macro and the other is to use /* */ in
parameters.
I like to use UNUSED_PARAM macro except for primitive parameters personally,
for example
void foo(RenderObject* object, int /*width*/, int /*height*/) {
UNUSED_PARAM(object);
}
I'd like to know what webkittens think about this.
If it is crystal clear what the parameters stand for, omit them. If not, you
find them commented out. UNUSED_PARAM is used when just some platforms of
flagged features use parameters, others not.
or only used in ASSERTs.
That's what the ASSERT_UNUSED(variable, assertion) macro is for :D
--Oliver
- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
It isn't, it's never been a concern as our serialisation format is simple enough to be hard to break. That said tests would be fine, i'm just not sure how you would do them nicely. --Oliver On Sep 19, 2012, at 1:50 PM, Alec Flett alecfl...@chromium.org wrote: So this thread kinda died. Anyone have any suggestions? Where is JSC's SerializedScriptValue consistency tested? Alec On Tue, Sep 18, 2012 at 1:22 PM, Alec Flett alecfl...@chromium.org wrote: Sorry I totally left out the I expose this through Internals - and adam has explained the rationale On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt oli...@apple.com wrote: What exactly are you trying to test here? The internal serialisation format isn't exposed anywhere (nor should it be). By definition newer formats won't be backwards compatible, or are you trying to ensure that newer deserialisers will be able to continue to deserialise old content? exactly. Where does JSC test this? I'm happy to follow whatever pattern is already established. Alec ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt
My preference would simply be to improve the Clang static analyser - it's free, open source, etc. I periodically run that analyzer on JSC, but apparently their ToT code has many improvements over stable. --Oliver On Sep 17, 2012, at 9:20 PM, Brent Fulgham wrote: Hi Gang, On Sep 17, 2012, at 4:11 PM, James Hawkins jhawk...@chromium.org wrote: TL;DR - If you have opinions one way or another about having a Coverity instance available for WebKit developers, please respond to this message. I have used Coverity at on a couple of occasions, without modifying source code to help the static analyzer. While its rather high cost has prevented me from using it recently, I did think that it provided enough signal-to-noise that I really wish I still had it. I think one of its main advantages is the ability to have it run over the entire source tree periodically to do larger-scale analysis than we can do looking at individual changesets. Many of the bugs it found were of the 'uninitialized variable' type, but I did find that it could dredge up some very clever edge cases that were definitely worth fixing. Since the cost to the project is effectively zero, I think we would be very foolish not to take advantage of this very generous offer. Thanks, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
JSC's SerializedScriptValue has always been versioned (having learned the
horror of no versioning with localStorage :( )
Newer formats (obviously) can't be read by older clients, but the serialisation
is intentionally forwards compatible.
--Oliver
On Sep 18, 2012, at 12:36 PM, Adam Barth aba...@webkit.org wrote:
This is an interesting case because it's important for the
serialization format to be consistent across time (so that an
IndexedDB created at one point in time can work at another point in
time), but it's not important to be consistent across embedders
(because IndexedDB created by Safari don't need to be readable by
Chrome and vice versa).
Perhaps we shouldn't use LayoutTests to test this functionality.
Instead, it might make more sense to use API-level tests that check
that a particular embedder API is stable and working as expected.
Adam
On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] platform-specific differences in test case inputs
What exactly are you trying to test here? The internal serialisation format
isn't exposed anywhere (nor should it be).
By definition newer formats won't be backwards compatible, or are you trying to
ensure that newer deserialisers will be able to continue to deserialise old
content?
--Oliver
On Sep 18, 2012, at 12:19 PM, Alec Flett alecfl...@chromium.org wrote:
Background: some of the storage systems use SerializedScriptValue to persist
structured-clonable objects
(http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
- most of this is implemented in a V8 or JSC-specific implementation of
SerializedScriptValue.
I'm adding tests for the actual values stored with SerializedScriptValue so
that we can move forward with serialization changes without breaking
backwards compatibility.
So many of my js tests boil down to:
testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
Which makes sure that these two representations are equivalent by going in
both directions.
The issue I'm hitting is that JSC has a different implementation with a
different storage format, and the serialization/deserialization between the
two storage formats is not compatible - the above code works great on V8 but
JSC uses different bytes.
I can't address this with just expectations files (i.e. only check that {}
serializes to some byte array, and have different expectations depending on
the port) because I need to check that specific inputs (such as old V8-based
formats) can also deserialize back into the right native objects.
What I kind of want is something like:
#ifdef JSC
script src=serialized_script_tests_jsc.js /script
#endif
#ifdef V8
script src=serialized_script_tests_v8.js /script
#endif
Thoughts?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] unsigned vs unsigned int
Does the style bot pick up unsigned int etc? --Oliver On Sep 13, 2012, at 1:19 PM, Ryosuke Niwa rn...@webkit.org wrote: Landed in http://trac.webkit.org/changeset/128499 (Thanks ggaren!) On Thu, Sep 13, 2012 at 12:29 PM, Ryosuke Niwa rn...@webkit.org wrote: Uploaded a patch on https://bugs.webkit.org/show_bug.cgi?id=96682. - Ryosuke On Thu, Sep 13, 2012 at 8:11 AM, Dan Bernstein m...@apple.com wrote: On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: Hi there, I was telling people to use unsigned instead of unsigned int, as I have been told that was the preferred style before, but apparently that is not in the style guide. The question is, should it be? Yes. A few greps in the code: unsigned - 18406 occurrences. unsigned int - 1721 unsigned i = - 1548 It does in fact seem to be the preferred style. Cheers Kenneth -- Kenneth Rohde Christiansen Senior Engineer, WebKit, Qt, EFL Phone +45 4093 0598 / E-mail kenneth at webkit.org ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Non JS Function call.
op_call_NotJSFunction is only referenced during the final linking phase. Actual compilation requires two distinct operations: 1) planting the call instruction and 2) linking the call target after the code has been relocated. Here is the (64-bit) version of the call + link logic: ... preserveReturnAddressAfterCall(regT3); emitPutToCallFrameHeader(regT3, RegisterFile::ReturnPC); emitPutImmediateToCallFrameHeader(0, RegisterFile::CodeBlock); storePtr(callFrameRegister, m_globalData-topCallFrame); restoreArgumentReference(); Call callCallNotJSFunction = call(); -- here is the call emitGetFromCallFrameHeaderPtr(RegisterFile::CallerFrame, callFrameRegister); restoreReturnAddressBeforeReturn(regT3); ret(); ... patchBuffer.link(callCallNotJSFunction, FunctionPtr(cti_op_call_NotJSFunction)); -- here is us linking the call --Oliver On Jul 24, 2012, at 1:45 PM, vahe vardanyan wrote: Grep gives nothing, there is only one mention of op_call_NotJSFunction in privateCompileCTIMachineTrampolines(JITOpcodes.cpp), but I don't see any call instruction there. Still can't understand how calls orgonized in SXF. On 24 July 2012 20:07, Filip Pizlo fpi...@apple.com wrote: On Jul 24, 2012, at 5:51 AM, vahe vardanyan vahag...@gmail.com wrote: Hi all. As I understand in SFX all non JS functions calls go trough JITStubs:op_call_NotJSFunction function. But in which point, where, the op_call_NotJSFunction function is called? It's called from code generated by the JIT. I would start by running a command called grep on the code in the jit directory to search for mentions of NotJSFunction. Can anyone please explain how function calls are implemented in SFX(simple jit). Thanks for attention ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
The problem is that as we make changes we end up breaking the SH4, MIPS, ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend significant amounts of time trying to ensure that the builds don't break/start failing horribly, and then having committed the patch[es] we have to spend multiple build bot cycles discovering all the cases that we missed. This consumes a lot of time that would be better spent working on the higher level portions of the JIT, that benefit all platforms. --Oliver On Jun 21, 2012, at 11:44 PM, Zoltan Herczeg wrote: Hi Filip, we (Gabor Loki and me) are the maintainers of the traditional ARM port, and we are willing to fix all issues. Just let us know what we need to do. You can assign the necessary bug reports to us and we are available in the #squirrelfish (or #webkit) channel as well. Regards, Zoltan Hi all, We are actively trying to improve the WebKit JavaScript engine (JavaScriptCore), with new debugging, profiling, memory efficiency, and performance features. Because JavaScriptCore is a JIT-based engine, this inevitably means doing JIT work, which in turn includes adding new instructions to the JIT assemblers and changing the API between the assemblers and the JIT. Currently, the maintenance situation in the assembler layer is not great. We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then we have three assemblers that appear to be on life support: legacy (non-THUMB2, pre-v7) ARM, SH4, and MIPS. It is increasingly painful to maintain these three barely-supported assemblers. None of these assemblers has been updated to support the new JIT or interpreter infrastructure, and there appears to be no ongoing effort to do so. That means that for progress to be made on X86 and ARMv7, we need to increasingly scatter #if ENABLE(...) noise throughout the system to keep those other assemblers building. Neither the active JavaScriptCore contributors, nor those running the bots for those hardware platforms, appear to have much interest in maintaining those assemblers, other than the occasional build fix. This is not a good situation to be in. So, I am curious: is anyone shipping with the legacy ARM assembler, the MIPS assembler, or the SH4 assembler? As a secondary question, if you are shipping the legacy ARM assembler, are you doing so because you have legacy ARM hardware or because you have not had the chance to switch to the new ARM assembler in your codebase? -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.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] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
That would be the ifdef hell we currently deal with. One option (that would keep everything building till appropriate people have fixed whatever needs to be fixed) would simply be to disable the JIT for effected platforms everytime something changes that is too difficult for us to blindly fix. Then people with appropriate hardware and toolchains could make the (probably trivial) changes required to bring them up again. --Oliver On Jun 22, 2012, at 11:20 AM, Maciej Stachowiak wrote: Is there a way to reduce these costs other than deleting the slower-maintained JITs? For example, could we temporarily freeze the JIT (perhaps the whole JSC engine somehow) at old versions somehow for architectures that may take time to catch up? Regards, Maciej On Jun 22, 2012, at 10:52 AM, Oliver Hunt oli...@apple.com wrote: The problem is that as we make changes we end up breaking the SH4, MIPS, ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend significant amounts of time trying to ensure that the builds don't break/start failing horribly, and then having committed the patch[es] we have to spend multiple build bot cycles discovering all the cases that we missed. This consumes a lot of time that would be better spent working on the higher level portions of the JIT, that benefit all platforms. --Oliver On Jun 21, 2012, at 11:44 PM, Zoltan Herczeg wrote: Hi Filip, we (Gabor Loki and me) are the maintainers of the traditional ARM port, and we are willing to fix all issues. Just let us know what we need to do. You can assign the necessary bug reports to us and we are available in the #squirrelfish (or #webkit) channel as well. Regards, Zoltan Hi all, We are actively trying to improve the WebKit JavaScript engine (JavaScriptCore), with new debugging, profiling, memory efficiency, and performance features. Because JavaScriptCore is a JIT-based engine, this inevitably means doing JIT work, which in turn includes adding new instructions to the JIT assemblers and changing the API between the assemblers and the JIT. Currently, the maintenance situation in the assembler layer is not great. We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then we have three assemblers that appear to be on life support: legacy (non-THUMB2, pre-v7) ARM, SH4, and MIPS. It is increasingly painful to maintain these three barely-supported assemblers. None of these assemblers has been updated to support the new JIT or interpreter infrastructure, and there appears to be no ongoing effort to do so. That means that for progress to be made on X86 and ARMv7, we need to increasingly scatter #if ENABLE(...) noise throughout the system to keep those other assemblers building. Neither the active JavaScriptCore contributors, nor those running the bots for those hardware platforms, appear to have much interest in maintaining those assemblers, other than the occasional build fix. This is not a good situation to be in. So, I am curious: is anyone shipping with the legacy ARM assembler, the MIPS assembler, or the SH4 assembler? As a secondary question, if you are shipping the legacy ARM assembler, are you doing so because you have legacy ARM hardware or because you have not had the chance to switch to the new ARM assembler in your codebase? -Filip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.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
Re: [webkit-dev] webkit2 with v8
They may have a desire for it, but certainly not a need -- Webkit includes a well maintained, guaranteed ABI stable JS engine that works on _all_ architectures, with a high performance JIT support available on numerous architectures and OS's. Being able to support two engines just in webcore has added substantial complexity to the codebase, and has led to many features being implemented only for one engine but not the other. There is a very large and substantial cost to this, and very little actual benefit. We have repeatedly stated that support for JS engines other than that provided by webkit is not a primary goal of webkit, and ports that wish to make use of any other engines do so at their own risk, and there attempts to do so can't interfere with the actual webkit project. --Oliver On Jun 1, 2012, at 10:12 AM, Jake wrote: What constitutes a need? Qt obviously has a need for it. Is there a threshold of ports needing a feature before it becomes blessed? On Fri, Jun 1, 2012 at 11:09 AM, Darin Adler da...@apple.com wrote: On Jun 1, 2012, at 9:55 AM, Jake j...@jakeonthenet.com wrote: I believe it's a disservice to the community as a whole to not provide proper javascript engine abstractions in webkit. I don’t agree. We should have abstractions for things that need to be abstract. Too many abstractions make the code much harder to work with. -- Darin ___ 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] Feature announcement: canvas pixel access API additions for high-resolution backing stores
On Apr 16, 2012, at 1:00 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
Could this be an opportunity to design an asynchronous API for fetching the
pixel buffer? It seems like many implementations are GPU backed now, and
fetching the pixel buffer is an expensive (blocking) operation. Had you
considered making such a change?
Adding async support was suggested on the whatwg thread about this. I think
async support is useful, but should not be tied to high DPI support. In
particular, we shouldn't, in my opinion, require authors to rewrite their
existing sync code to an async model just to properly support higher
resolutions.
In addition, the whatwg thread revealed that there are many hidden
complexities in the design of get/putImageData, in particular designing how
they work in the face of sychronous drawing operations to the same canvas.
The HiDPI problem is much more straightforward and does not need to be gated
on resolving the async design issues.
I think you are giving up a good opportunity. The barriers to an async API
are more readily overcome when there are extra benefits to developers. HiDPI
could be a great way to attract developers to a better API.
I've addressed those other concerns on the WhatWG thread.
No, gating HiDPI on rewriting your code into a more complex, and generally
slower model seems like a great way to encourage developers to ignore high dpi.
--Oliver
-Darin
Regards,
-Darin
On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein m...@apple.com wrote:
[This is actually an enhancement announcement to an existing feature]
Over at
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035112.html,
Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to
allow authors to take full advantage of high-resolution backing stores, when
available (whereas the existing API hides the fact that the backing store
resolution is not CSS pixel resolution, for compatibility with existing
content). The enhancements include a backingStorePixelRatio attribute and
{get,put}ImageDataHD functions on CanvasRenderingContext2D.
Through https://bugs.webkit.org/show_bug.cgi?id=83619 and
https://bugs.webkit.org/show_bug.cgi?id=83836, I am making these
enhancements, with the names prefixed with “webkit”.
There is no build-time option to disable these enhancements. Ports that
don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version
of the additional API. Ports that opt into high-DPI canvas need to enhance
their ImageBuffer implementation to fully support the resolutionScale and
CoordinateSystem parameters.
___
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
Re: [webkit-dev] Adding Encrypted Media Extensions
Last I saw, there hadn't been any attempt to actually define how the content is encrypted. Has that changed? If it hasn't how do we get interoperable implementations? The only way for this spec to not break the openness of video and audio is for the encryption algorithm to be completely defined in the spec. --Oliver On Apr 4, 2012, at 9:55 AM, David Dorwin wrote: Hi WebKit! I plan to add the Encrypted Media Extensions to the media elements. The extensions allow web applications using audio and video to control key exchange. The extensions will be behind the ENCRYPTED_MEDIA feature define. The feature is tracked as https://bugs.webkit.org/show_bug.cgi?id=82968. Implementation will be based on the draft proposal at http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html, which was published jointly by Google, Microsoft, and Netflix [1]. It appears a Media Task Force will be taking this on to produce a Working Draft [2]. Having an implementation will allow us to include implementation experience in the development of the draft. As described in the proposal, several new methods and events are added to HTMLMediaElement and a new keySystem parameter and attribute are added to canPlayType() and HTMLSourceElement, respectively. As with much of the media stack, most of the functionality will be implemented within the various ports. ENCRYPTED_MEDIA will be enabled for the Chromium port and covered by its buildbot. Regards, David [1] http://lists.w3.org/Archives/Public/public-html/2012Feb/0273.html [2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html ___ 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] feature proposal: restricting window.blur/focus
I am all for this change, but a not insubstantial part of that is my general hate for anything other than me ever changing the focused window and/or element. --Oliver On Apr 4, 2012, at 1:31 AM, Jochen Eisinger wrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ 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] UPDATED Re: Version control survey
I do think that we should also be considering what the responders are doing --
eg. do you work mostly on the core engine (WebCore, JSC, etc) vs. platform
specific engine work (eg.
WebCore/platform/graphics/{cg,cairo,skia,backendofdoom}) vs. WebKit API stuff
vs. release branching, etc
I think it would be worth tracking these differences for a number of reasons
* There are a number of reviewers who don't do substantial amounts of work
directly in the repo anymore, longterm apple and google contributors who no
longer work exclusively on webkit (on that note do we want to have some kind of
reviewer expiration?)
* Fairly elitist, but surely the opinion of people who work on core engine tech
should have more say than people working on the periphery: core engine work
benefits _everyone_ so I feel more weight should be given there
* The needs of a contributor are fairly strongly influenced by what they're
doing -- people working on build release branches, etc frequently want to do
the sorts of things that git is far better at than svn, but people just working
on single monolithic patches seem to prefer svn.
* A problem we these kinds of survey is that they are inherently biased in
favour of people who want change, people who don't tend to ignore them - I had
basically been ignoring this thread because it was going on and on and on
without actually adding any new information over the last git vs. svn debate,
had done nothing to change my mind, etc - i feel that I am not alone in this
kind of mental exhaustion (see
http://webkitmemes.tumblr.com/post/19019677135/webkit-dev-this-week)
Finally: I use git-svn, it allows me to do everything that I want to do that
git is meant to be good at, so I'm not sure why people keep saying that the
choice is between sticking with svn, or making everyone switch to git. My
counter argument to git-svn is slow so we should all use git is git-svn is
slow and this annoys me so i'm going to contribute patches to git to fix that.
--Oliver
On Mar 10, 2012, at 1:00 PM, Maciej Stachowiak wrote:
I will also post the results split out by contribution level once the survey
closes.
Regards,
Maciej
On Mar 10, 2012, at 12:58 PM, Jon Lee wrote:
Direct link to results:
http://kwiksurveys.com/results-overview.php?surveyID=LODHNK_f6f04dadmode=4
On Mar 10, 2012, at 12:49 PM, Maciej Stachowiak wrote:
Hi folks,
I made a bad choice of survey site. They want to charge me to see more than
100 responses or to export the data, but they won't take my money. Sadness.
Please try this survey instead, it will run through the 17th.
http://kwiksurveys.com?s=LODHNK_f6f04dad
Regards,
Maciej
On Mar 10, 2012, at 11:52 AM, Maciej Stachowiak wrote:
On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote:
On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak m...@apple.com
wrote:
Unfortunately SurveyMonkey sucks and I can't give everyone access to live
responses without paying them money. Current results:
- 97 people have answered
- About 67% use Git only (this has been consistent throughout the survey)
- Aabout 20% use Subversion only
- About 13% use Git and Subversion
- No one checked Other
As far as contribution levels of the responders:
- 37% are WebKit reviewers
- 25% are WebKit committers
- 25% are WebKit contributors (but presumably not committers or reviewers
yet)
- 13% are not WebKit contributors
Can we see the breakdown of git/svn users among reviewers committers?
I'm not certain if it's really useful to consider votes casted by
non-contributors here since we're presumably not trying to decide which
version control system is more popular in general public.
I would indeed like to get the contributor-only (and
reviewer/committer-only) statistics, but I'm having trouble upgrading to
the pro account that would enable this. I'll post the data once I have
it.
I do think it is somewhat interesting to find out what non-contributors
who nontheless check out source are using to access the WebKit repository.
The fact that so many people use Git says to me that our basic checkout
instructions should include the relevant git instructions as an
alternative. SVN instructions are on the main site at
http://www.webkit.org/building/checkout.html but Git instructions are
buried in the wiki.
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
___
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
Re: [webkit-dev] (no subject)
On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit This would annoy me quite a lot -- Any delta including new files or anything implicitly staged (eg. by git stash apply) would not be included. Or do you mean git diff HEAD ? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore question
On Dec 16, 2011, at 9:05 AM, Rolando Abarca wrote:
Hi all,
I'm using JavaScriptCore for scripting purposes (isolated from webkit), and
I'm encountering the following problem:
I would like to store a reference to an anonymous function, and later to be
able to call it as a callback, something like this:
---javascript
node.schedule(some name, function () { ... });
---
What I'm doing right now is in the definition of node.schedule, I store the
context and the function (as a JSValueRef), then when I need to call code in
there, I'm doing this:
JSObjectRef func = JSValueToObject(storedContext, storedCallback, NULL);
JSObjectCallAsFunction(cb-context, func, storedObject, 0, NULL, NULL)
It doesn't matter how I store the context/function, it always crashes when
trying to either convert the value to object or call the object as function.
At first I thought that the function was being garbage collected, but even
after protecting it, I still got the crash.
My guess is that the context is not the right one, so another question is:
what context should I be passing here?
This looks like you're storing the JSContextRef you receive when your callback
is called. That's incorrect as a given JSContextRef is only guaranteed to be
valid within the callback. All your functions should be from the same initial
JSGlobalContextRef you created when initialising your environment, and you
should just be using that GlobalContext rather than any per instance context.
You should also be protecting the function with JSValueProtect.
Hopefully this helps.
What would be the right way to do this?
Thanks,
--
Rolando Abarca M.
http://rolando.cl
Phones: +1 (415) 655-1041
+56 (2) 581-4591
___
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] Internal JSON Parsing
It's not safe to use ScriptObject for values that are kept alive by JS objects as it leads to cycles in the collector. Also the cached value for an attribute should be in the binding classes, not the implementation classes. The easiest way to understand why is to ask yourself how a non-js (objc, gobject, etc) binding layer would use the same cached value. I suspect you can probably just kill off the no custom getter+CachedAttribute check in the code generator as I think i was simply being conservative when i wrote that code. --Oliver On Dec 8, 2011, at 8:39 AM, Jarred Nicholls wrote: Hey webkittens, I'm working on https://bugs.webkit.org/show_bug.cgi?id=73648 to support the json response entity from XHR.response. Unless I'm mistaken (the purpose of this inquiry) we don't appear to have a VM-agnostic interface for internal JSON parsing, i.e., straight to the parsers. If so, what does everyone think about adding in that basic interface? What I'd like to avoid is preprocessor branches directly in XHR talking to JSC and V8 directly; instead, what would be ideal I think is an interface to parse and return a ScriptObject. Any additional input is surely welcomed. Thanks, Jarred ___ 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] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On Dec 8, 2011, at 1:25 PM, Rik Cabanier wrote: This might no longer be true, but isn't it the case that shaders are designed to take the same amount of time to execute, no matter what input they get? ie if you have an if/else block, the time of the shader would be whatever block takes the longest. This was done so you can schedule many of them at the same time without having to worry about synchronizing them. Rik That was only true in the early days of GLSL, etc when the hardware did not actually support branching. Now the hardware does support branching so these timing attacks are relatively trivial (see http://www.contextis.co.uk/resources/blog/webgl/poc/index.html). --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
No. People are using EcmaScript on the web. They have languages that compile to EcmaScript as an intermediate language. Dart could also do this (emscripten demonstrates that raw C can be compiled to EcmaScript), so if people wished they could do that. These are also not a significant proportion of websites at all. If we were to decide to support one of these natively it would make sense to support the most popular and widely used languages, but currently none of the languages that compile to ES have made any significant headway -- mostly because ES is actually a pretty good language (yes it has rough edges, but the same is true of _all_ languages). Adding direct and exposed support for a non-standard language is hostile to the open-web by skipping any form consensus driven language development that might happen (say the path taken by json2.js - the native JSON object), and foisting whatever language we want on the web instead. This implicitly puts any browser that supports additional proprietary extensions in the same position as a browser supporting something like vbscript, and has the same effect: breaking the open web by making content that only works effectively in a single product. For example back in the 90s Netscape had a feature called layers any browser could display the pages, but they would only look good in netscape. If we were to natively support some other language on the web say OliversAwesomeWebLanguage, and provided a tool to compile OAWL to ES any site that used OAWL would perform significantly worse on other browsers than on our own (this is a given as the only argument in favour of native support vs. compilation to JS is that native support is meant faster than going through JS). If OAWL did become a big enough platform then other vendors _might_ end up reversing engineering it and reimplementing it themselves, put us back in the position of the 90s browsers and the many variants of what is now called EcmaScript. On Dec 5, 2011, at 10:43 PM, Vijay Menon wrote: On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt oli...@apple.com wrote: The issue here isn't can we make multiple vms live in webkit it's can we expose multiple languages to the web, to the former i say obviously as we already do, to the latter I say that we don't want to. People are already using multiple languages on the web. E.g., https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS. Native runtime support is a natural next step. WebKit does support multiple VMs, but it does not support them concurrently at runtime. That is essentially what we want to enable. WebKit does support multiple bindings concurrently at runtime -- a lot of mac clients make use of the obj-c dom bindings while JS is executing, some also make use of the JS-ObjC bridge so that you have two different sets of bindings for the same objects at the same time, being used together in beautiful harmony ;) Cheers, Vijay --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote: Good day, everyone! I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. Of course, we're doing this because of our work on Dart, but our intent was to solicit a feedback from the WebKit community if there is any interest in supporting runtimes additional to JS (and not JS + Dart) in the first place. As I have already said, we already support multiple bindings being in use at the same time. Continuing to claim that is your goal is not helpful. Your goal is to allow additional non-standard languages to be provided by webcontent. This is an academic exercise as it doesn't match webkit's goal of being a standards compliant engine, and also has dubious advantage even when supported -- as Vijay said multiple languages already compile to EcmaScript, there is no reason that Dart can't as well. So even if it turns out that this can be implemented without regressing performance of those parts of webkit responsible for supporting open standards, it has a maintenance burden required to support a feature that has no business being in webkit. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote: On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt oli...@apple.com wrote: On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote: Good day, everyone! I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. Of course, we're doing this because of our work on Dart, but our intent was to solicit a feedback from the WebKit community if there is any interest in supporting runtimes additional to JS (and not JS + Dart) in the first place. As I have already said, we already support multiple bindings being in use at the same time. Those bindings are different because the code that uses them is not activated from web pages. Looking at the specific posted patches, those changes seem necessary to support activating a different language from a page eg script tag. So I think while that your specific claim that WebKit supports multiple bindings at the same time is true, it misses the point. No I was getting sick of the continual claim that this was about supporting multiple VMs/bindings, rather than adding proprietary extensions to webkit Continuing to claim that is your goal is not helpful. Your goal is to allow additional non-standard languages to be provided by webcontent. This is an academic exercise as it doesn't match webkit's goal of being a standards compliant engine, Is that WebKit’s goal? Um, yes. From http://www.webkit.org/projects/goals.html (I'm fairly sure this has already been quoted in an earlier email but just to bring it back in context): Goals Web Content Engine The project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and the DOM. --Oliver___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Dec 6, 2011, at 11:53 PM, Oliver Hunt wrote: On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote: Those bindings are different because the code that uses them is not activated from web pages. Looking at the specific posted patches, those changes seem necessary to support activating a different language from a page eg script tag. So I think while that your specific claim that WebKit supports multiple bindings at the same time is true, it misses the point. No I was getting sick of the continual claim that this was about supporting multiple VMs/bindings, rather than adding proprietary extensions to webkit To clarify I meant additional web facing languages, a la VBScript in IE. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
What is the benefit to the project in exposing an additional (non standardized) language to the web? All the bindings that webkit currently provides to are either standardized EcmaScript or platform specific bindings used by native code developers embedding webkit. Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE). Anyway if we were to add an additional language the language people have been asking for for years is Python which is already extremely popular and well known so it seems that it would be a much better choice to expose, but even then it seems like a bad idea. --Oliver On Dec 5, 2011, at 1:22 PM, Vijay Menon wrote: Hi Per, At a high-level, the idea is pretty simple. We want to be able to run another VM along a JS one. For example, if we see a Dart script on a web page, we want the Dart VM to be able to handle it. If we see a JS script, we want the JS one to handle it. Similarly, if an event listener on a page is triggered, we want to forward to the appropriate VM to run the user listener code. The changes here are mostly about refactoring some classes (e.g., ScriptController, ScheduledAction) to add that extra dispatch. I'm not familiar enough with the JavaFX model, but this may be useful if you want to provide direct access from Java to the DOM via Java bindings. Do you have a pointer on how you're handling multiple VMs in WebKit today? Cheers, Vijay On Mon, Dec 5, 2011 at 12:50 PM, Per Bothner per.both...@oracle.com wrote: On 12/05/2011 09:26 AM, Vijay Menon wrote: We’re planning to create a multi-vm branch on webkit.org http://webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. What is there to provide feedback on? Asking people to provide feedback on a huge patch dump seems unreasonable. Why did you choose the approach you did? Is there a planning document or white-paper? What changes did you make at a *high* level - not a set of patches? Did you run into problems or have to decide between alternative solutions? This may be interesting to the webnode portion of Oracle's JavaFX. We already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM. Having a standard and more efficient way of combining them might be helpful. Likewise more direct access from Java to the WebKit core might be helpful, though the standard DOM bindings don't require JavaScript. I don't know if a WebKit port using Nashorn (Oracle's next-generation JavaScript implementation on the JVM) will be helped by a multi-VM WebKit, or make it irrelevant (from Oracle's point of view, of course). -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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 branch to support multiple VMs (e.g., Dart)
Previous branches have been used to bring up interestingly complicated features, or features that had the potential to cause dramatic stability issues during their early work (such as the old svg-experimental branch). This project appear to be largely a make work project as it's already possible to have bindings for multiple languages (as the C++, GLib, ObjC, V8 and JSC bindings demonstrate). It seems an academic exercise to see if we can create a general architecture to make more bindings, as is exporting support for proprietary extensions like vbscript, python or dart to the web. As the 90s demonstrated such features are bad for developers, and bad for the open web. This may not be apparent to people who have not spent years working in the environment but random additions frequently cause significant pain down the road, even in the cases where the overall result was a good thing -- such as canvas - for the subsequent standardisation caused us quite a bit of compatibility problems, even though it was a very compact and contained api. --Oliver On Dec 5, 2011, at 6:09 PM, Ryosuke Niwa wrote: I agree with Peter here. It appears to me that having a WebKit branch to experiment a new feature will help us making an informed decision as to whether we want to accept patches or not for the feature better than looking at two giant patches posted on chromium.org. Preferably, Vijay also file a bug and possibly post a patch on bugs.webkit.org. - Ryosuke On Mon, Dec 5, 2011 at 5:39 PM, Peter Kasting pkast...@chromium.org wrote: On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen gga...@apple.com wrote: We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. It hadn't occurred to me to view the goals of the WebKit project as applying only to trunk, and not to branches. I'd be interested in hearing from other WebKit engineers: Do you think that the goals of the WebKit project apply to trunk alone, or to branches as well? It sounds from the quote above like Vijay is not trying to change what the goals are, only to obtain an environment where it's possible to demonstrate, by practical experience, that some set of changes is indeed consistent with WebKit's goals. In principle a branch seems appropriate for that to me unless there is widespread agreement that the entire idea of these patches is so contrary to what we want that no one should have ever even thought about doing them in the first place. I'm not sure things are that clear-cut, so seeing a more fleshed-out system might be useful. PK ___ 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] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?
The handwritten parser has numerous benefits over the old bison generated one, the most basic being: * It's more than 2 times faster than the bison parser * It doesn't require complete duplication of the grammar to support strict mode (and can identify strict mode in the first place) * It fixes a number of bugs inherent in the bison parser due to the way automatic semicolon insertion was implemented. There are a number of other benefits, but those are the most obvious. --Oliver On Nov 29, 2011, at 11:38 PM, PandaCanFly wrote: Hello everyone, I am researching WEBKIT and coming up against difficulty about Javascript parser。As I Know, WEBKIT of old version uses the bison parser to interpret javascript code. But WEBKIT of recently version doesn't uses bison parser. Instead, WEBKIT of recently version uses Top-To-Down Recursion parser. I have some details to add. 1) WEBKIT using bison parser has a source file named Grammar.cpp. 2) I know WEBKIT with 38688 version number uses bison parser. I hope someone can give me some explanation, thanks. ___ 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] starting implementation of postMessage tranferables
On Sep 22, 2011, at 7:46 PM, Ian Hickson wrote: On Thu, 22 Sep 2011, David Levin wrote: *Summary*: Implementing postMessage with transferable support as webkitPostMessage. *Details*: *Spec*: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages This describes window.postMessage and the same is true for Message Ports and Worker Context. It doesn't mention Array Buffers but that will be mentioned soon and is in the spec that talks about Array Buffers. Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=64629 *Plan*: 1. Add webkitPostMessage to all of these places to isolate us from possible spec changes. It will have the same functionality as postMessage. 2. Add the ability to transfer Message Ports. 3. Add the ability to transfer Array Buffers. After step 2, webkitPostMessage can be renamed to postMessage quite safely. The spec isn't going to change in a way that breaks you. I think we should wait and see -- spec changes have caused issues for us in the past (eg. localStorage :-/ ) There is not any substantive harm in prefixing, whereas there can be real problems down the road if we don't prefix. --Oliver -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ 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] run-bindings-tests
On Sep 8, 2011, at 7:21 PM, Alexey Proskuryakov wrote: 08.09.2011, в 12:25, Darin Adler написал(а): I find the bindings tests quite helpful. Because the perl script is so hard to read, it’s the changes in bindings script test results that I look at when reviewing changes to the bindings scripts. The fact that the results are checked in helps me review patches. OK, then they are valuable indeed. However, I still feel that there is a disconnect between the desired effect (provide a diff in a patch for review) and the implementation (tests that can pass or fail). This also puts the burden of maintaining the results on people who needn't care about them - for example, Oliver's patch clearly didn't need someone look over generated code changes. I think the argument is that it _did_ need someone - the reviewer didn't have any nice way to see the difference in output that would have been visible had i included updates to the expected output. My problem with the test is that it isn't run as part of run-webkit-tests (which is what we say you must run), the test output is fairly awful, and the test script doesn't support --help, or --reset (it turns out it does have an equivalent to --reset, but why use a different argument in one tool from what we use in the main one?) --Oliver I'm not sure what the better solution would be though. Perhaps a bot could provide a diff of DerivedSources for any patch that touches code generators, but I'm not volunteering to implement one :-) - WBR, Alexey Proskuryakov ___ 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] run-bindings-tests
On Sep 8, 2011, at 11:55 AM, James Robinson wrote: We used to not run these tests on the bots. This meant that people would change the bindings code and not update the expected results, so the expected results were always massively out of date. This meant when patching the bindings scripts you could not rely on run-bindings-tests at all, because the expectations were already broken before you made any changes! This it not theoretical, it happened to be multiple times and I know I'm not the only one. The real problem here is that people check in without looking at the bots and then do not respond when the bots go red. That's a people problem. The real problem is that we have a test suite: run-webkit-tests, that everyone runs (it's even mentioned at step 4 on http://www.webkit.org/coding/contributing.html , which is apparently not running all the tests. I run-webkit-tests before i commit (new-run-webkit-tests has ensured that any prior complains about time taken no longer exist, so kudos to those folk \o/ ), and yet I end up breaking the build in a way that would show up locally if the tests were simply run. run-webkit-tests should run all of the webkit tests -- not some subset, all of them. If failing a cross platform test can turn the bots red, then that test should be covered by run-webkit-tests. The other problem is people check in without looking at the bots. I do try to watch the bots, but the time between me landing and the bots actually going red can literally be hours. Of course i'm away from irc/email whatever when I land a patch at 4pm and it turns the bots red at 11pm. I appreciate this isn't as much of a problem for people who don't work on code for which all changes heralds a world rebuild and effect (apparently) every single test that exists in the repository, but it's certainly frustrating for those of us who do. (This is ignoring the overly aggressive rollouts of large patches the break only single platforms due to platform specific code that is difficult for anyone outside of that platform to fix) --Oliver - James - WBR, Alexey Proskuryakov ___ 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] WebCL Release
On Aug 24, 2011, at 3:20 PM, Tasneem Brutch - Samsung wrote: Khronos WebCL is not yet a specification, and the WebCL API has not yet been standardized. The WebCL members are currently discussing the security and interoperability issues in the WebCL Working Group. Samsung would like to introduce a WebCL patch at this time, to follow the ongoing specification activity in the Khronos WebCL working group. WebCL would not be enabled in the browser by default, and users will have the choice to enable it in the browser. That's not really a great consolation -- defining a spec where there's is the assumption it will be disabled by default doesn't seem like a good plan in the long term. In all honesty disabled by default is only a bit better than asking the user's permission in terms of security. The WebGL security concerns previously raised, related to the following aspects: 1) Cross domain image access - timed loop attack. 2) Issues related to general hardening. In response to item 1), WebGL and HTML specs have been updated, mandating CORS (Cross Origin Resource Sharing) for video, images and audio, and servers have to grant cross domain access to media resources. Item 2) was addressed by the WebGL working group, through ARB_ROBUSTNESS extensions, which provide additional protection being mandated. The new robustness specification limits the side-effects of a GPU reset after a Denial of Service attack. In addition the ANGLE shader validator was improved. The hardening policies for WebGL work because WebGL is built on a heavily restricted version of GLSL. My understanding was that OpenCL had access to pointers and arrays provided by the host application, but did not guarantee memory safety. Given all kernels provided to WebCL are untrusted code that is clearly unsafe, to what extent does the WebCL spec (or draft spec as the case may be) limit illegal memory operations? ARB_ROBUSTNESS is specifically a GPU flag (mostly needed due to the absence of any memory protection on GPU), but one of the goals of OpenCL was to provide a uniform interface to CPU and GPU compute resources so is not particularly relevant to the discussion of WebCL security. Now I will say I have no real development experience with OpenCL (essentially I have read the documentation and looked at the pretty demos), but it is my understanding that I can provide OpenCL with a specific piece of memory, in WebCL I assume an ArrayBuffer or similar, and then the kernel can compute an arbitrary index into that storage -- is that understanding correct? If so how does WebCL ensure that this behaviour is safe? In the short term, browser vendors would maintain white and black lists, so that the compromised system can have WebGL disabled until mitigation is developed. In the longer term, GPUs would provide increasingly robust security and tasking, to allow GPU to become a first-class computing platform alongside CPU. As I said above WebGL already introduces a large number of restrictions on the possible operations performed by a shader _without_ any support from the ARB_ROBUSTNESS. OpenCL however explicitly allows a lot of the memory access that WebGL deliberately prevents. As the WebCL standardization effort progresses, the WebCL API would be defined with security as the highest priority, with provisions for both short term, and longer term security and robustness solutions, similar to the approach taken by the WebGL working group. WebGL deliberately removed a number of features, and introduced a range of type safety requirements not originally present in GLES, does the WebCL WG have a table of attack surfaces and hardening solutions that have been taken? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCL Release
How has the WebCL spec dealt with the inherent security problems of OpenCL in the face of untrusted content? In the WebGL working group we spent a lot of time working on how to adequately restrict GLSL|ES to prevent security vulnerabilities, and I haven't really heard anything about what approach the WebCL WG has been taking. My concern is that OpenCL is far less restrictive than GLSL, and yet we had to clamp down on what was possible even then. --Oliver On Jul 5, 2011, at 10:41 AM, Won Jeon wrote: Dear Simon, Thanks for your interest in our WebCL prototype in WebKit. Currently, it's integrated with WebKit r78407 and hasn't been checked with WebKit's coding style guidelines. It's tested on Mac with Nvidia GPU which supports OpenCL support. Updating the code to a newer WebKit and Porting the code to other platforms should be straightforward because the only platform-dependent part is OpenCL support. WebGL is not needed for WebCL itself, but it would be better for interoperability between WebCL and WebGL, so that's why we started this work on Mac first. Regards, Won -Original Message- From: Simon Fraser [mailto:simon.fra...@apple.com] Sent: Tuesday, July 05, 2011 8:12 AM To: Gyuyoung Kim Cc: webkit-dev@lists.webkit.org; Simon Gibbs; Won Jeon - SISA; jinwoo7.s...@samsung.com Subject: Re: [webkit-dev] WebCL Release On Jul 3, 2011, at 6:28 PM, Gyuyoung Kim wrote: Hello WebKit Developers, Samsung has just open sourced an implementation of WebCL for WebKit. This is a prototype of a proposed WebCL standard that aims to define JavaScript APIs for OpenCL. The code is located at http://code.google.com/p/webcl/ and some demo videos at http://www.youtube.com/user/SamsungSISA. We're interested in any feedback on the prototype and how it can be better integrated with WebKit. Perhaps you can summarize here how it works now, and what directions you see for closer integration with WebKit? Simon ___ 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] Writing a new XML parser with no external libraries
I think considerable effort should be put into building up a suite of performance tests in advance of the new parser (probably culled from xml encountered in the wild, but also a number of extreme edge cases wouldn't go a miss either). We should also put effort into reducing any/all recursion in the parser as stack depth guards are not the most efficient mechanism to prevent stack overflows. --Oliver On Jun 28, 2011, at 6:12 PM, Jeffrey Pfau wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ 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] Extra review requirement for web-facing API? (Was: Re: Spellcheck API for WebKit)
On Jun 22, 2011, at 11:38 AM, Eric Seidel wrote: I think it's better for our reviewers to review only things they're comfortable with. A good reviewer shouldn't be reviewing things they aren't comfortable with anyway -- the whole point of a review is to have someone who has appropriate domain knowledge ensure that the patch is correct. Reviewing is about ensuring as much as possible the new code is correct and safe, if you aren't able to do that for a specific patch, you shouldn't be reviewing that patch (at least not for r+ purposes, anyone can r- if they see something obviously wrong). --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Are roll-outs getting a little out of hand?
On Jun 18, 2011, at 12:24 PM, Darin Adler wrote: I noticed these three roll-outs: http://trac.webkit.org/changeset/89190 http://trac.webkit.org/changeset/89191 In the case of these first two patches was any attempt made to actually fix the qt build? Every other build was apparently happy with the change so it seems like a Qt engineer (like Ossy_) could have attempted to fix the Qt build themselves, rather than just rolling out the patch and requiring someone else without familiarity with Qt to fix the Qt build through the slow and painful EWS process. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Public APIs for accessing the Javascript debugger
The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in JavascriptCore. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public JavascriptCore APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] Public APIs for accessing the Javascript debugger
It depends on what you mean by official I would probably r- any patch that attempted to create such an API, but it's conceivable that a sensible API could be made that masked the current craziness sufficiently to allow the craziness to be removed later. But any API would need to be very carefully thought out, and would probably require multiple iterations to get to the point where we'd consider the API sufficiently good. --Oliver On Jun 14, 2011, at 9:12 AM, demallien wrote: Is that an official response? On 14 Jun, 2011,at 06:03 PM, Oliver Hunt oli...@apple.com wrote: The current debugging mechanism is not particularly pleasant to use, nor is it very future proof, it has significant performance costs, and it requires the user to have significant knowledge of the inner workings of JSC. Before we started considering exposing JS debugging through API (and therefore introducing additional binary compatibility requirements) we would need to have an improved debugging mechanism that resolved these issues. --Oliver On Jun 14, 2011, at 7:38 AM, demallien wrote: Hi, I'm interested in providing a public C API for accessing debugger functionality in JavascriptCore. Ideally I would like the code to be merged into webkit, so I wanted to know if there is a policy reason for not already having debugger APIs available in the public JavascriptCore APIs? If so, my work will obviously not be compatible with the policy, and I won't bother trying to conform to webkit coding standards, as the code will clearly not be accepted into webkit. Othwerwise I'll make an effort to make it fit in with the rest of the system. So, is there a reason for there not being a publically accessible debugger API? Alli ___ 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] JSC bindings in the Qt bridge
A common problem the we're hitting when working on JSC is that the Qt bridge bindings are implemented in terms of JSC internals. This keeps causing us problems as no one working on JSC really knows anything about Qt or the API the bridge objects are intended to provide, and yet we are required to keep them running when making significant changes. Given there seems to be little focus on these bindings from Nokia it seems that the best path forward is to have them rewritten in terms of the JSC API rather than the JSC internals. This will insulate the bindings from future changes and make life a little easier for everyone. I've filed https://bugs.webkit.org/show_bug.cgi?id=60842 to track this change. If during the conversion people find any short comings in the JSC API that's useful too, as it's likely that those problems would impact other users of the JSC API and we would welcome bugs being filed on those them (CC'ing me :) ). Thanks, Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
An alternative would be to generate code for optional args along the lines of (pseudo code): void foo(Arg1Type arg1, [Optional] Arg2Type arg2); = Arg1Type arg1 = toArg1Type(arguments[0]); if (arguments.length 2) return impl-foo(arg1); Arg2Type arg2 = toArg2Type(arguments[1]); return impl-foo(arg1, arg2); This would allow the C++ impl to use overloading to resolve things correctly. --Oliver On Apr 21, 2011, at 10:16 PM, Jian Li wrote: One other way is to write custom binding code to handle this case specially. On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 6:29 PM, Jian Li wrote: I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding DefaultValue= extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 21, 2011, at 12:14 AM, Jian Li wrote: The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. 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] [webkit-changes] [83955] trunk
Indeed, i missed the gtk release one, but the point stands that just rolling out a patch (which should not roll out the changelogs) without providing any information about the crash doesn't help anyone. --Oliver On Apr 15, 2011, at 10:30 AM, Adam Roben wrote: On Apr 15, 2011, at 1:19 PM, Oliver Hunt wrote: Don't roll out patches that don't break any core builders, without making some attempt to diagnose the problem or providing information that will make it possible to fix the problem. The GTK bots are core builders. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Single location for people wanting to learn to use dev tools WAS: Blog post draft: dealing with exceptions using Web Inspector
On Apr 13, 2011, at 2:06 PM, Ojan Vafai wrote: Do we have a single page to point people to for learning to use the inspector? Would be nice if there were a page that just linked to all the blog posts. On Wed, Apr 13, 2011 at 2:02 AM, Yury Semikhatsky yu...@chromium.org wrote: I don't see this stack trace in the inspector when i try it :-/ Note that for more information on the recent features of the Web Inspector, you can visit the Chrome DevTools documentation page. It seems like it would be good to get inspector details onto webkit.org --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugid in ChangeLog
If you use webkit-patch everything just magically works (yay!!) --Oliver On Mar 26, 2011, at 11:30 AM, Brent Fulgham wrote: On Mar 26, 2011, at 10:41 AM, Darin Adler wrote: On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote: Sometimes folks commit changes without bug numbers. If those changes breaks things it's hard to find the correct context for the change. Can we make the bug number a requirement for a commit when it has a corresponding bug? IMHO it would be great if the style bot and the reviewer complain about missing bug numbers. I don’t think we should require a bug report for every commit. I don't want to have a bug report for everything either, but I do agree that my failure to include it in the changelog for the FontPlatformData change was a stupid oversight. I'll make sure to avoid that mistake in the future! -Brent ___ 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] Canvas backing resolution
For reference desktop webkit implementations will automatically increase the canvas backing store resolution as the device:css pixel ratio increases. --Oliver On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote: On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote: Hi again, I'm trying to keep the canvas bitmap at the same pixel resolution as the device, otherwise it is blurry. OK, I see. This, for example, works if the pixel ratio is 2. canvas style=width: 100px; height: 100px; width=200 height=200/canvas Yes, when the user has a zoom level set, I'd like to paint to match the pixel ratio, so that, a zoomed in user still receives crisp output, instead of blurry output. -webkit-device-pixel-ratio does not change when the user scaled the content; it is a device value. On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5 depending on it being a low, medium (160) or high dpi (240) device. On the iPhone 4 and the new iPod Touch it is 2.0. On Android devices, with for instance, a device-pixel-ratio of 1.5, you can disable the upscaling by adding target-densitydpi=device-dpi to the viewport meta tag. What you can do is to disable user scaling (add user-scaling=no to the viewport meta tag) and then handle zooming in your app using the touch events. This only works on mobile devices though. I haven't debugged with enough tablet devices, such as the color kindle, to know how many webkit distros it works with. What should I do about user zoom on the desktop (and possibly, the kindle) ? Drawing in high res, just-in-case, makes for a poorer experience for users at a 1.0 ratio, and asking users to slide a sharpen slider is a little awkward. Mozilla, in their implementation, has setup device-pixel-ratio to scale when the user scales content; they directly expose window css pixel ratio value to trusted scripts, but not to web content; requiring web content to use css device-pixel-ratio. Microsoft has exposed the values through window.screen. -Charles ___ 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] Canvas backing resolution
WebKit's canvas implementation has always scaled the backing buffer according to actual screen resolution, i suspect it doesn't pay any attention to zoom however :-/ Arguably that's a bug. --Oliver On Mar 4, 2011, at 10:08 AM, Charles Pritchard wrote: In the future? On Mar 4, 2011, at 8:51 AM, Oliver Hunt oli...@apple.com wrote: For reference desktop webkit implementations will automatically increase the canvas backing store resolution as the device:css pixel ratio increases. --Oliver On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote: On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote: Hi again, I'm trying to keep the canvas bitmap at the same pixel resolution as the device, otherwise it is blurry. OK, I see. This, for example, works if the pixel ratio is 2. canvas style=width: 100px; height: 100px; width=200 height=200/canvas Yes, when the user has a zoom level set, I'd like to paint to match the pixel ratio, so that, a zoomed in user still receives crisp output, instead of blurry output. -webkit-device-pixel-ratio does not change when the user scaled the content; it is a device value. On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5 depending on it being a low, medium (160) or high dpi (240) device. On the iPhone 4 and the new iPod Touch it is 2.0. On Android devices, with for instance, a device-pixel-ratio of 1.5, you can disable the upscaling by adding target-densitydpi=device-dpi to the viewport meta tag. What you can do is to disable user scaling (add user-scaling=no to the viewport meta tag) and then handle zooming in your app using the touch events. This only works on mobile devices though. I haven't debugged with enough tablet devices, such as the color kindle, to know how many webkit distros it works with. What should I do about user zoom on the desktop (and possibly, the kindle) ? Drawing in high res, just-in-case, makes for a poorer experience for users at a 1.0 ratio, and asking users to slide a sharpen slider is a little awkward. Mozilla, in their implementation, has setup device-pixel-ratio to scale when the user scales content; they directly expose window css pixel ratio value to trusted scripts, but not to web content; requiring web content to use css device-pixel-ratio. Microsoft has exposed the values through window.screen. -Charles ___ 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] A tip for committers
webkit-patch could be made aware of them -- how does the commit-queue handle it? If a patch doesn't include mime type info i would imagine it's doing something to prevent the annoying diff spew. --Oliver On Mar 3, 2011, at 8:42 AM, Adam Roben wrote: On Mar 3, 2011, at 11:40 AM, Oliver Hunt wrote: Can the style bot be made aware of .png at least and complain if you don't set the right flags? Subversion properties aren't captured in patches, so the style bot is too early in the process. We could add a pre-commit hook to check for the right properties, though. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sharing the OpenGL GraphicsContext3D implementation
I agree. My hope was always that the OpenGL backend could be shared among all
the webkit ports, my only suggestion is that rather than having a separate
OpenGLExtensionsFunctions class, I think we probably want something like
GraphicsContext3DOpenGL.{h,cpp} for all the common logic
and then
GraphicsContext3DOpenGL{Gtk, Mac, Wx, Posix, ...}.cpp
etc
To implement the functions that can't be shared.
This would be in keeping with our normal design approach for using system
platform specific APIs.
--Oliver
On Feb 22, 2011, at 12:53 PM, Zan Dobersek wrote:
Hi,
I'm writing this mail in order to propose changes that would make the OpenGL
implementation of the GraphicsContext3D a lot easier to share between the Mac
and Gtk port.
Currently the mentioned implementation is only used by the Mac port. The Gtk
port is also interested in using this implementation and there is already a
patch available in bug #31517[1] by Martin Robinson that brings the WebGL
functionality to daylight.
There is, however, the issue of the OpenGL extensions functions. Current
OpenGL implementation is Mac-only, and Mac port has a specific set of
extensions functions available. The same cannot be said for the Gtk port,
which can end up having extensions functions available that do not have the
same extension suffix as the Mac port's functions (EXT vs ARB). Because of
that the current proposed implementation acquires addresses of the OpenGL
extensions functions and then uses shims to make the GraphicsContext3D work.
I recommend a new class to be created for these two ports to use, named
something like OpenGLExtensionsFunctions. Extensions-specific functions in
the GraphicsContext3D class would then be replaced with calls to the
corresponding functions in this class, for example
OpenGLExtensionsFunctions::blitFramebuffer instead of current
::glBlitFramebufferEXT. Implementation for the Mac port would be simple,
passing arguments on to functions that are currently used in the
GraphicsContext3D class. Gtk port's implementation would simply call the
functions that were acquired, with no need to depend on shims.
Modifying the OpenGL implementation of the GraphicsContext3D class in this
way would ease the use of it for the Gtk port and perhaps any other port that
would go on to use this implementation with no damage to the Mac port.
I'd like to hear what Mac folks think of this approach and if there are any
other ideas that address this problem.
Regards,
Zan Dobersek
[1] https://bugs.webkit.org/show_bug.cgi?id=31517
___
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] code review tool changes
I just discovered that the review tool doesn't save the general comments, only inline ones (http://webkit.org/b/54121). This just got me when I clicked on the style bot to see what style checks had failed and lost my feedback :( This was particularly annoying as i had command-clicked the link (to open in a new tab) and the link actually forced the current page to navigate instead - http://webkit.org/b/54113 --Oliver On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote: On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai o...@chromium.org wrote: There's been a slew of changes to the code review tool. It's probably a good time to send a summary now that I don't intend to add significant new features. -Side-by-side diffs: You can view the entire diff or individual files in side-by-side diff. If you change the entire diff, we'll store that in localstorage and load diffs in side-by-side by default. -Comments and diff navigation: n/p keys will navigate to the next/previous comment. j/k will navigate to the next/previous diff. -Draft comments persist: draft comments are now stored in localstorage, so they will persist across reloads, crashes, etc. Since it's in localstorage it's stored per-machine.* Thank you for this in particular. Several times I've accidentally navigated away from a review and lost work. I just temporarily lost Internet connectivity while uploading a (large) review and when I came back to the review (same browser, etc.) all of my comments were lost. Is this functionality expected to work with Chrome 9 stable? When you click the publish button, we clear all the saved drafts. :( Otherwise we'd continue showing the draft comments alongside the published ones. I suppose I should find a way to make that happen when the publish actually succeeds instead. Thanks, -Ken -Ken -Expand diff context: You can expand the lines above/below a diff to see more context.** Hope this works well for you all. Obviously, file bugs if something isn't working. Ojan * Taking the next step and storing them online for non-security bugs (e.g. in S3 or appengine) would be a simple and welcome addition if someone feels moved. ** This currently only works if the patch includes the svn revision it was created at (i.e. it was created with SVN) or applies cleanly to trunk. Including the SVN revision in git diffs shouldn't be too hard. Again, if you feel moved to fix this, ping me. ___ 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] code review tool changes
I just discovered that the review tool doesn't save the general comments, only inline ones (http://webkit.org/b/54121). This just got me when I clicked on the style bot to see what style checks had failed and lost my feedback :( This was particularly annoying as i had command-clicked the link (to open in a new tab) and the link actually forced the current page to navigate instead - http://webkit.org/b/54113 --Oliver On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote: On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai o...@chromium.org wrote: There's been a slew of changes to the code review tool. It's probably a good time to send a summary now that I don't intend to add significant new features. -Side-by-side diffs: You can view the entire diff or individual files in side-by-side diff. If you change the entire diff, we'll store that in localstorage and load diffs in side-by-side by default. -Comments and diff navigation: n/p keys will navigate to the next/previous comment. j/k will navigate to the next/previous diff. -Draft comments persist: draft comments are now stored in localstorage, so they will persist across reloads, crashes, etc. Since it's in localstorage it's stored per-machine.* Thank you for this in particular. Several times I've accidentally navigated away from a review and lost work. I just temporarily lost Internet connectivity while uploading a (large) review and when I came back to the review (same browser, etc.) all of my comments were lost. Is this functionality expected to work with Chrome 9 stable? When you click the publish button, we clear all the saved drafts. :( Otherwise we'd continue showing the draft comments alongside the published ones. I suppose I should find a way to make that happen when the publish actually succeeds instead. Thanks, -Ken -Ken -Expand diff context: You can expand the lines above/below a diff to see more context.** Hope this works well for you all. Obviously, file bugs if something isn't working. Ojan * Taking the next step and storing them online for non-security bugs (e.g. in S3 or appengine) would be a simple and welcome addition if someone feels moved. ** This currently only works if the patch includes the svn revision it was created at (i.e. it was created with SVN) or applies cleanly to trunk. Including the SVN revision in git diffs shouldn't be too hard. Again, if you feel moved to fix this, ping me. ___ 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] Renaming directories
On Dec 21, 2010, at 1:49 PM, Maciej Stachowiak wrote: And we have JavaScriptCore API tests which are not run automated. The JSC API tests run as part of run-javascript-tests, which the build bots do execute --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Review tool changes
I really would like to be able to select some text and add a comment that uses the selection as context, a single line of context is frequently insufficient, this is about the only thing that still makes the new review tool less effective than the old review mechanism (for me at least). --Oliver On Sep 20, 2010, at 11:32 AM, Darin Adler wrote: On Sep 20, 2010, at 10:22 AM, Darin Fisher wrote: How about this? If any annotations were made to the patch, then the button gets named Preview. Else, the button is named Publish and when clicked performs its work in one shot. Was there a strong outcry for removing the preview step? I only found it bothersome when I wanted to issue a quick r=me on a patch that didn't require any additional changes. Good idea. Here’s another idea: The button starts out named Preview and works with a preview. If the review or commit-queue flag is altered then the button is changed to “Publish” and works without a preview. Thus if I like the preview work flow, I don’t set those flags until I get to the preview page. If I like the faster work flow, I can set a flag and then push Publish. One type of person who is not served by my proposal is someone who wants to add comments only and not set a flag but wants the faster work flow. -- Darin ___ 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] Blob scheme implementation
On Sep 14, 2010, at 5:56 PM, David Levin wrote: On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth aba...@webkit.org wrote: What do you think of the idea of having a re-useable BlobCore module that all the ports can share? I don't think this is a good idea. This re-usable module would only be used by the Safari WebKit port. As I understand it, Chromium wouldn't be able to re-use it due to not re-using WebKit types in general. With only one port using it, the module seems like it would not be able to have a good design. What about Gtk, Qt, Wx, Efl...? Where possible these days we seem to implement a single impl in webcore that is used by everyone --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to line-by-line code reviews
It would be nice if you could select a block of code and have the comment be for that block -- last i looked the line by line review basically loses context for reviews as it pushes the comments to the bottom and only includes a single line of context. --Oliver On Aug 29, 2010, at 11:13 AM, Adam Barth wrote: Based on some feedback, I'm going to try to improve the line-by-line review tool. I've landed the first iteration of the new design, which should be usable and have roughly the same functionality as the old design. I'll be adding new features shortly. The main difference is you now access the line-by-line review feature using the Formatted Diff link in bugs.webkit.org instead of the Review Patch link. I made this change so that folks who like the old Review Patch tool won't be bothered by the new tool. If you have feature requests, let me know. I'll post an update once the tool is awesomified. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
The reason ImageBuffer::image() makes a copy (be it a deep copy, or CoW) is almost exclusively for the purpose of ensuring correct behaviour in the case where a canvas is drawn onto itself, eg. context = myCanvas.getContext(2d); context.drawImage(myCanvas, 0, 0); Off hand I can think of no other case where this would be necessary, so it seems like the best solution would be to make the default behaviour for image() be to return a reference to a potentially mutable image, and to give the canvas a distinct method for getting a copied image in the case where it's actually necessary. --Oliver On Aug 4, 2010, at 2:45 PM, Christophe Public wrote: Hi, Actually, I was questioning also the necessity of this extra buffer. I'll just give an update and some numbers. We have a very large canvas (few MB) and our updates are very frequent but very small (clip area is for example 3x3 pixels), it takes about 25ms for our system to handle the expose. Once the double buffer is removed, the expose takes less than 1ms. We applied our change to image(). When the BitmapImage is created, we now pass the m_data.m_surface after increasing its reference count through cairo_surface_reference and removed the copy. Our tests didn't detect any issue after this change. Christophe On Wed, Aug 4, 2010 at 11:07 AM, David Hyatt hy...@apple.com wrote: I'm confused why a special method is needed though. Can't image() just avoid the full copy? Given how we use image() in WebKit, I don't think there's any reason to be concerned if image() continues to reflect the contents of the ImageBuffer. I think we should just switch to that model for the CG port also anyway, since I'm unconvinced we're truly avoiding a copy, and return an image with a custom data provider that feeds the current contents of the ImageBuffer to the image. dave (hy...@apple.com) On Aug 3, 2010, at 8:55 PM, Martin Robinson wrote: Resent from the proper address: On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson martin.james.robin...@gmail.com wrote: I notice that Qt added imageForRendering() and felt they could not use image() for some reason. I'd be curious if a Qt expert could weigh in on that, since maybe with a redesign a separate call would not be needed. I'm not a Qt expert, but just based on a quick look, it seems that imageForRendering avoids the full QPixmap copy. Christophe, when you open a bug for this issue, please CC me, as I have a small patch in my tree which has the same imageForRendering pecialization, but for Cairo. Martin ___ 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
Re: [webkit-dev] Handling IME composition events
On Jul 28, 2010, at 8:45 AM, Joone Hur wrote: Hello all, I’m working on a Hangul(Korean alphabet) composition issue in WebKit. https://bugs.webkit.org/show_bug.cgi?id=40518 By the way, I noticed that WebKit based browsers are inconsistent with IME composition events. According to the W3C DOM Level 3 events(http://bit.ly/bM7YVQ), 1) A browser should fire compositionstart, compositionupdate, and compositionend event during a composition. 2) The textEvent event should be dispatched after a compositionend event if the composition has not been canceled. 3) While a composition session is active, keyboard events should not be dispatched to the DOM (i.e., the text composition system swallows the keyboard events), and only compositionupdate events may be dispatched to indicate the composition process. The DOM Level 3 event model for input composition does not match the requirements of actual web content. This is unfortunate, but will hopefully be fixed in future. However, all ports of WebKit handle composition events in inconsistent ways. Even keyboard events are still dispatched to the DOM during a composition. Therefore, it is necessary to fix those problems as follows: 1) IME Composition events should be handled consistently in all ports of WebKit. I'm not sure this can be achieved as it depends (to an extent) on the platform IME system, and the active IME -- different IMEs have completely different behaviours making consistent behaviour across multiple platforms is an exercise in futility. However if you're seeing different behaviour with the same IME on a single platform that's a bug. 2) The textInput event should be dispatched after a compositionend event. Unsure of the specifics of this. 3) Keyboard events should not be dispatched during a composition. Key events must be sent while an IME is active otherwise sites break. IIRC you get keydown and keyup events, but not keypress. The keydown event when an IME is active has charCode 229 in order to be compatible with IE. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Parallel Webkit?
Shared-state parallel scripting (and concurrent DOM) seem inevitable I don't know why you believe this -- there is no intention of having shared state threading in ES, nor is there any desire in the ES technical committee to add any for of concurrency primitives to the language. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A Parallel Webkit?
On Jul 23, 2010, at 4:50 PM, Leo Meyerovich wrote: I wasn't entirely sure what OP was after of if the reply below adequately addressed his interests. WebKit2 seems to have little to do with taking advantage of parallel hardware in browser algorithms like lexing, parsing, selectors, JS compilation, JS execution, layout, DOM interactions, fonts, rendering, etc. JS execution and DOM manipulation are single threaded, and that thread is the UI thread, this fact cannot be changed. JS compilation is also done lazily in webkit so we don't ever end up with multiple pieces of code to compile concurrently. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrated at inconsiderate behavior
On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote: On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote: Maybe I should complain this in a different threads, but recently the commit bot waiting time is way too long. Several times a patch of mine got the r+ and cq+ and it landed two days later. This is really frustrating. I am very tempted to use svn directly to commit patches, but that means the patch only gets tested in my local environments. Like one time my patch breaks the leopard bot, turns out the failed test is skipped on leopard, which is exactly my OS. If I land it through the commit bots, I could identify the issue earlier. I agree they are closely related. A greener tree means a faster commit queue and a faster commit queue means less people subvert it and break the tree. The hard problem is figuring out how to fix the incentives so subverting the queue isn't so desirable. What do you mean by subvert the queue? The commit queue is a tool to streamline commits from contributors who do not have commit access to the repository. If you have the ability to commit you should not be using the commit queue to land your patches. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Frustrated at inconsiderate behavior
On Jul 7, 2010, at 7:26 PM, Jeremy Orlow wrote: On Thu, Jul 8, 2010 at 10:19 AM, Oliver Hunt oli...@apple.com wrote: On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote: On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote: Maybe I should complain this in a different threads, but recently the commit bot waiting time is way too long. Several times a patch of mine got the r+ and cq+ and it landed two days later. This is really frustrating. I am very tempted to use svn directly to commit patches, but that means the patch only gets tested in my local environments. Like one time my patch breaks the leopard bot, turns out the failed test is skipped on leopard, which is exactly my OS. If I land it through the commit bots, I could identify the issue earlier. I agree they are closely related. A greener tree means a faster commit queue and a faster commit queue means less people subvert it and break the tree. The hard problem is figuring out how to fix the incentives so subverting the queue isn't so desirable. What do you mean by subvert the queue? The commit queue is a tool to streamline commits from contributors who do not have commit access to the repository. If you have the ability to commit you should not be using the commit queue to land your patches. That is the opinion of a few contributors, yes. But even when there were some big downsides to committers using the commit queue, there was definitely no definitive direction to not use the queue. And now that pretty much all the problems with the queue have been systematically eliminated, I would argue that--if anything--we should actually ask everyone to use the queue when practical. webkit-patch land-safely does the job of running the tests automatically, that said if you have commit privileges you should be running the tests yourself otherwise you're wasting the reviewers time. Pushing a patch through the normal review path will have it built on multiple platforms (though it is annoying that once you get r+ those builders don't run). The only benefit of the commit-queue (as i see it) is that it will make sure that the patch still applies in the many hours between it being reviewed and it being landed. My opinion is that if people want to use the commit-queue to land patches they should be happy to drop their commit privileges thus mooting this entire issue. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bytecode Sequence for function.apply()
If you have a debug build of jsc, you can run 'jsc -d' and that will dump the generated bytecode --Oliver On May 20, 2010, at 8:42 AM, Nyx wrote: I've been working on a tool to generate a trace of JavaScript executions, built on JavaScriptCore. I'm trying to log calls to all functions and their arguments. To do this, I've instrumented the op_call and op_call_varargs bytecodes in Interpreter.cpp. The problem I'm having is that if someone calls a native/host function through apply, I don't see the call. For example, the call: string.fromCharCode.apply(null, [65, 66, 67]); Doesn't seem to correspond to an op_call or op_call_varargs, so I'm wondering how this is handled in JavaScriptCore, what kind of bytecodes generated, and if somebody has any idea what I could do to log the unseen calls to native functions, short of instrumenting every native function in WebKit. -- View this message in context: http://old.nabble.com/Bytecode-Sequence-for-function.apply%28%29-tp28623075p28623075.html Sent from the Webkit mailing list archive at Nabble.com. ___ 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] Client side JavaScript i18n API proposal
It seems like the majority of this belongs in EcmaScript directly rather than being restricted to web-oriented uses of ES. I'm also unsure of the relevance of CommonJS to either WebAPI or ES as CommonJS is not part of either standards body. For example the use of require implies making CommonJS modules part of WebAPI, rather than any of the current modules proposals working through TC39. --Oliver On May 20, 2010, at 4:45 PM, Nebojša Ćirić wrote: There are a number of areas where JavaScript i18n APIs are deficient. Our goal is to develop better client-side i18n API for JavaScript, and eliminate need for big JavaScript libraries or server side processing. Eventually, we want to make them a part of WebAPI (worked on by WebApp WG). Our proposal to API is up at http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh In a Phase 1, we would start with limited WebKit implementation (locale implementation and date formatting). A Phase 2 would extend it to cover collation, number/currency formatting, calendars... See bug https://bugs.webkit.org/show_bug.cgi?id=39451 for details (proposed API, motivation, related chromium bug and WebApps thread we started). We would like to start prototyping Locale part of the API in next couple weeks, both for JSC and V8, and we would appreciate your input wrt. proposed API. We'll continue working with WebApps group on standardizing the API but we would like to keep moving forward with the implementation too, thus cross-posting on webkit-dev. -- Nebojša Ćirić ___ 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] jsc -d does not dump bytecode in debug builds
What's your testcase? One potential issue you could be seeing is that we don't dump the bytecode until we compile code so the code for a function won't be dumped until you call it for instance, but you should at the very least be getting an bc dump for the containing global code. --Oliver On May 13, 2010, at 4:24 PM, Auro Tripathy wrote: What gives? The documentation says, Usage: jsc [options] [files] [-- arguments] -d Dumps bytecode (debug builds only) -e Evaluate argument as script code -f Specifies a source file (deprecated) -h|--help Prints this help message -i Enables interactive mode (default if no files are specified) -s Installs signal handlers that exit on a crash (Unix platforms only) ___ 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] Disabling the JIT
On Apr 27, 2010, at 2:10 PM, Nyx wrote: I also tried adding #define ENABLE_JIT 0 at the top of the Interpreter.cpp file in JavaScriptCore. This builds, but produces a segmentation fault. This would not work as you would end up with some parts of WebKit compiled with the jit enabled, and some not. If you want to try forcing the jit to be disabled with a #define you need to do it in Platform.h --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Recent SVG clipping change caused lots of leaks on the bot
looks like ~RenderSVGResourceClipper should be doing deleteAllValues(m_clipper); --Oliver On Apr 13, 2010, at 3:48 PM, Maciej Stachowiak wrote: https://bugs.webkit.org/show_bug.cgi?id=37527 http://trac.webkit.org/changeset/57511 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] Announcing WebKit2
On Apr 9, 2010, at 2:09 PM, Maciej Stachowiak wrote: On Apr 9, 2010, at 2:03 PM, Adam Barth wrote: On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote: We seem to welcome pretty much any port that has an active maintainer. IMHO, that's a good thing. I wonder if we should archive ports that don't have an active maintainer (e.g., by moving them into a branch). I think that would be good, if there are any such ports (I am not sure there are any on trunk currently that are totally unmaintained). S60? http://trac.webkit.org/browser/S60 --Oliver 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] Crashes during testing
My bad, fixing now. --Oliver On Feb 25, 2010, at 2:47 PM, Maciej Stachowiak wrote: On Feb 25, 2010, at 2:46 PM, Kenneth Russell wrote: A change committed some time since yesterday evening has introduced many crashes in JSC's GC during testing. A representative stack trace is attached. If you have made changes in this area recently, can you please look into this? Thanks, -Ken crash.txt Do you have steps to reproduce? 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] Crashes during testing
Update to r55258 or later :D --Oliver On Feb 25, 2010, at 2:46 PM, Kenneth Russell wrote: A change committed some time since yesterday evening has introduced many crashes in JSC's GC during testing. A representative stack trace is attached. If you have made changes in this area recently, can you please look into this? Thanks, -Ken crash.txt___ 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] Crashes during testing
But any regressions would have been blamed on eric. webkit-patch land does the correct thing, but i disable the testing prior to commit because a 25 minute delay prior to committing is more or less guaranteed to cause it to fail to commit due to someone else landing. --Oliver On Feb 25, 2010, at 2:58 PM, Kenneth Russell wrote: OK, thanks, that appears to have fixed it. How about that commit queue? Would have caught the crashes before they were checked in. -Ken On Thu, Feb 25, 2010 at 2:53 PM, Oliver Hunt oli...@apple.com wrote: Update to r55258 or later :D --Oliver On Feb 25, 2010, at 2:46 PM, Kenneth Russell wrote: A change committed some time since yesterday evening has introduced many crashes in JSC's GC during testing. A representative stack trace is attached. If you have made changes in this area recently, can you please look into this? Thanks, -Ken crash.txt___ 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
