Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
Argh, sending from the right address this time. On Fri, Apr 12, 2013 at 4:39 PM, Jarred Nicholls jarred.nicho...@gmail.comwrote: On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo fpi...@apple.com wrote: On Apr 12, 2013, at 8:36 AM, Hudson, Rick rick.hud...@intel.com wrote: I'm assuming that we agree that JavaScript must evolve to leverage the hardware's power stingy parallelism. True, but there is also the question of how high of a priority we should give to this relative to other project goals, and also what opportunity costs are introduced from any particular implementation of parallelism that we choose. What you are proposing will only work for code that performs non-effectful operations. This is a limited form of parallelism, and I'm not sure that it's a general enough programming model to warrant adding new things to the platform. For completeness there seems to be the following approaches. 1)Add nothing to the language and rely on increasingly sophisticated compilers to detect opportunities to safely parallelize computations within the current semantics. 2)Add methods to Array that provide parallel semantics. 3)Add syntax and keywords such as parallelFor to introduce parallelism. 4)Add a parallel type (ParallelArray) and associated methods that provide parallel semantics. You forgot the obvious ones: 5) Message passing 6) Shared mutable memory with either threads and locks, or something along those lines. We sort of already have (5) but it is half baked; I think there is opportunity to improve it. We don't have (6). (6) subsumes all of (1), (2), (3), (4), and (5) as it would allow the programmer to roll all of those primitives in JS. We should not reject shared mutable memory out of hand. It is the prevailing technique for implementing concurrency and parallelism in the other languages that people use. The _nothing_ approach would have to deal with array methods, such as map and reduce, that have sequential semantics. For example reduce is really reduce right (or fold right) and these semantics defeat parallelization. For example the EIC signature for the function/closure passed to reduce assumes E === C[I] but the value E could be the result of previous invocation of the function. This approach seems to be strictly worse than the methods approach. A similar nothing approach is to analyze loops to mechanically discover opportunities for parallelization. While there exists decades of literature that have been full of optimism the reality is that this approach has not achieved wide spread success. Part of that lack of success stems from the fact that most code that does things to arrays has subtle loop-carried side-effects. The closures passed to ParallelArray methods could have those, also; and if they did then you wouldn't be able to soundly parallelize. You haven't convinced me that ParallelArray will be any more successful than the full autoparallelization approach. You also haven't convinced me that it will be any more successful than other eclectic ideas, like OpenMP, for example. I don't think that such annotation-based approaches have been particularly successful in other languages. The languages that have seen the most success in parallel development are precisely those that give *complete* control to the programmer, such as Java, which gives you threads and locks combined with a sensible memory model - and allows you to craft your algorithm in the way that best suits your problem domain. Why is this approach being rejected? The _methods_ approach side steps the semantics issue raised in the nothing approach but does not compose well with the original methods. For example Array has several inherently sequential methods, such as push and pop, that do not have a reasonable parallel semantics since they force mutation. That said this approach has its proponents. Nico http://smallcultfollowing.com/babysteps/blog/2013/02/26/splitting-the-pjs-api/suggested that we add unorderedMap and unorderedReduce to indicate that the scheduling of the computation be unordered. While the idea is compelling on the surface it is likely to lead to the development of algorithms that are at first sequential and then hacked to make them parallel. This approach will impede the goal of having programmers develop parallel algorithms and the appropriate parallel data structures. The methods approach would miss a real opportunity here to move programmers away from the sequential models and on to parallel models. ParallelArray also misses this opportunity. The only thing that ParallelArray does is adds methods that could have been added to Array, and requires you to say, when you write your code, if you want parallelization or not. The only problem this solves is inferring the is it profitable to parallelize question. I'm not sure that inferring the answer to this question is hard enough
Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit
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.comwrote: 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... With that said, I totally agree that using intrinsic idioms and heuristics that is more webby would be nice. But at some point there will be use cases that do not translate and will require explicit developer control in one form (WebCL) or another (new ECMAScript idioms). Detecting and optimizing all variations of homogenous parallelable operations seamlessly inside the JS engine is hard, to put it mildly. [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4 [2] http://www.khronos.org/webcl/public-mailing-list/ [3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL ___ 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] Compiling WebKit up to 25% faster in Windows?
On Tue, Mar 26, 2013 at 2:37 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell brat...@opera.comwrote: Is this something that has been talked about in the past, and would you be interested in replacing the long list of directories to search for every include with paths (relative some good base) directly in the include directives? Using explicit paths to include files has been talked about in the past; e.g. https://lists.webkit.org/pipermail/webkit-dev/2011-November/018632.html The most convincing counter argument I can remember is that it'll make refactoring harder because you'll have to update all #include's when you move headers. A few tailored scripts make that an easier job. We're all engineers after all. It would be great if we can figure out if this also improves the build time on Mac/Linux. Agreed. Somewhat apples and oranges of course, but the noticeable slow down when compiling WebKit versus the rest of Chromium, file to file, is enormous. Chromium does a full path include directive from the base of the src by convention. I'd love to see Windows builds sped up; definitely the biggest pain point in continuous integration. - R. Niwa ___ 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] Compiling WebKit up to 25% faster in Windows?
On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote: 2013/3/26 Ryosuke Niwa rn...@webkit.org: On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo fpi...@apple.com wrote: On Mar 26, 2013, at 1:40 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.org wrote: On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org wrote If we have consensus that we should just switch to paths relative to Source (or maybe a couple different options), that would be (IMO) a big win. It sounds like Daniel co. have already done the big bang conversion. I think using full path would be a serious hit regarding hackability. I would rather spend some time tweaking my compiler to cache each directory content than waste time finding where is every single header I need to include. Interesting. I have the exact opposite experience, having to paw around to figure out where Font.h actually lives rather than just seeing WebCore/platform/graphics/Font.h. At any rate, to be clear, I would be in favor of that change but I'm not expecting it to happen :). I'm with Dirk on this. Full path would help hackability for me. I don't use an IDE, so I'll be typing more. But I spend more time reading code than typing code. Also we have a lot of stupid in header file naming right now. For example the DFG calls the JSC::DFG::Node header DFGNode.h, and puts it in JavaScriptCore/dfg/DFGNode.h. So we duplicate the namespacing of JSC::DFG::Node in both the filename and the directory name. Ridiculous! If we had a discipline to always include using paths relative to Source, then we could just rename it to JavaScriptCore/dfg/Node.h. That would make me happy. That'll make me sad because then Xcode will then find both WebCore/dom/Node.h and JavaScriptCode/dfg/Node.h when I type Node.h. Unfortunately, we can't name Node.h in WebCore/dom DOMNode.h because DOMNode.h already exists for Objective C bindings. IMHO, we should be favoring code readability instead of a tool's feature. +1 for full paths. -jesus My sentiment exactly. And I agree with Dirk and Filip, seeing full paths improves (my) hackability and clearly shows layer dependencies (and violations). I'd say that it would also help people understand where certain headers live (educational) and to know which header specifically is being included at compile time rather than it being a guessing game. This is just my opinion, but its rendered through experience working in both chromium code and webkit code. Having a few files named the same hasn't at all effected my ability to find the right file (Sublime Text 2), though I understand that argument. In fact I'm forced to learn the difference and distinguish the locations between similarly named files in the code base; I've found it very helpful. Jarred - R. Niwa ___ 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] New WebKit reviewer: Gyuyoung Kim
Congrats! On Tue, Aug 21, 2012 at 3:38 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: I’m pleased to announce that Gyuyoung Kim is now a WebKit reviewer. Gyuyoung joined the WebKit team as part of an effort to port WebKit to the EFL platform. Since then he has taken leadership of the Samsung activities in WebKit trunk and helped integrating his team members in the community and community practices. Lately, Gyuyoung have been focused on adding device API's to WebKit, as well as refocusing the EFL efforts on WebKit2. Please join me in congratulating him in his new WebKit reviewer role. -- 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
Re: [webkit-dev] WebKitQt
On Thu, Aug 16, 2012 at 11:42 PM, blake fiddler blake.fidd...@gmail.comwrote: Hey! I have problem with WebKit Qt port build. Please address Qt related questions to the webkit-qt mailing list in the future. Why you disable Qt4.x ??? As I can understand now WebkitQt works only with 5.0 version? You understand correct, sir. I recommend subscribing to webkit-qt as well, as this change was discussed. But Qt5 isn't stable version - it's beta. Building WebKit from trunk is the antithesis of stable, so I hardly think that matters. I wouldn't dare speak for the QtWebKit team, but I'd imagine that supporting both major versions became too cumbersome. ___ 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] Using namespace std
On Wed, May 16, 2012 at 3:04 PM, Anders Carlsson ander...@apple.com wrote: On May 16, 2012, at 9:31 AM, Darin Adler da...@apple.com wrote: On May 16, 2012, at 9:20 AM, Allan Sandfeld Jensen wrote: there is another conflict which is entirely our own fault. It is between WTF::bind and the new std::bind from C++11 We should find a good solution for this. I’d suggest talking with Anders Carlsson about it. I've run into this and had to use the fully qualified WTF::bind in those cases. FWIW, I don't think we really need using directives for the std namespace - the fully qualified name is short enough and I like the additional clarity that we're calling something in the standard library. Ditto. After awhile, one gets used to it and I for one especially appreciate the additional clarity that it brings when reading code in a very large project. - Anders ___ 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: Adding iframe seamless
On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak m...@apple.com wrote: On May 1, 2012, at 4:04 PM, Adam Barth aba...@webkit.org wrote: On Tue, May 1, 2012 at 3:50 PM, Maciej Stachowiak m...@apple.com wrote: On May 1, 2012, at 3:31 PM, Eric Seidel e...@webkit.org wrote: Is your goal to be able to disable the feature to prevent a late-known security issue? Or is your goal to universally disable seamless for a port entirely? I'm not sure I understand the difference between these. The capability I'm looking for is to disable the entire feature if necessary. However, I don't expect that any ports Apple is involved with would leave it off indefinitely. I hope that answers your questions. One approach to ENABLE_SEAMLESS is to put the seamless property on HTMLIFrameElement behind [Conditional=SEAMLESS] and then to change Document::mayDisplaySeamlessWithParent to always return false. That should make the feature invisible to the web. The changes to the layout and navigation algorithms wouldn't be ifdefed, but they'll do the same things they do today because the engine won't ever treat an iframe as seamless. I'm not too picky about how it's done, but I'd feel more comfortable with #ifdef protecting the code changes rather than if(). If the changes are so entangled that it's not easy to put only the changes in an ifdef, then I would be skeptical that they actually have no possible effect on the non-seamless case. Do we not have sufficient tests to lend us more confidence in this area? If they aren't that entangled, then adding the right #ifdef should be straightforward. 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] Feature Announcement: Adding iframe seamless
On Wed, May 2, 2012 at 2:03 PM, Maciej Stachowiak m...@apple.com wrote: On May 2, 2012, at 6:14 AM, Jarred Nicholls jar...@webkit.org wrote: On Tue, May 1, 2012 at 7:39 PM, Maciej Stachowiak m...@apple.com wrote: I'm not too picky about how it's done, but I'd feel more comfortable with #ifdef protecting the code changes rather than if(). If the changes are so entangled that it's not easy to put only the changes in an ifdef, then I would be skeptical that they actually have no possible effect on the non-seamless case. Do we not have sufficient tests to lend us more confidence in this area? There's no amount of automated testing that would make me comfortable with landing a major feature today and shipping it to customers tomorrow (exaggerated case, but this is the kind of thing we're talking about). I wholeheartedly agree, and agree #ifdefs provide safety in this regard. I was speaking more towards the skepticism that the runtime conditional checks were not adversely affecting the non-seamless case. I would hope to think that our automated tests were (or will be) abundant and thorough enough to prove with some level of confidence that what Adam suggests would work. If that isn't the outcome, then one could argue tests are worthless in all situations. #ifdefs are valuable and necessary for the reasons you stated, particularly security and bugs in new exposed features. These things ought to be gradually exposed, starting with explicit opt-ins. But, aside from that and as a separate issue really, I would hope to think that our tests properly mitigate concern for regressions on code that is being modified. Nearly every significant feature has had security holes or site compatibility issues discovered post-landing, even if it passes all tests. That's why things like this need bake time; it can take from a few weeks to a few months of being enabled on trunk for a new feature to get really solid. This is not a disparagement of anyone's coding skills or test coverage, that's just the reality. The problems that take a while to flush out can often be issues due to specific sites doing unexpected and strange things. Because we don't have a centralized release schedule for WebKit, that means there isn't necessarily a single window that is a good time for all vendors to take such a risk. That is why ifdefs are valuable even if a feature is ready to be on by default in testing builds like WebKit nightlies or Chromium canary channel. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
On Apr 24, 2012, at 9:07 AM, Adam Roben aro...@webkit.org wrote: On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@webkit.org wrote: (from correct address) On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@sencha.com wrote: On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann simon.hausm...@nokia.com wrote: On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote: Hi WebKit, I've been using a fork of the following repo: https://github.com/WebKit/webkit However, yesterday there was discussion on #webkit that the SHA-1 checksums on this repo are different from repo at git.webkit.org, which means folks working on both need to have both versions checked out. I believe the reason for them being different is because in the github repo the commit author fields are resolved. Yeah that's totally it. So svn.webkit.org = git.webkit.org = github would need to be the mirroring strategy. Sounds dicey :) I don't see what would be dicey about it. The svn.webkit.org - git.webkit.org step is the fragile one; after that it's just a simple git push to get things over to GitHub. This sounds like a pretty good approach to me, though of course it will cause some havoc for people who have already been doing work using the current GitHub repository. I was being facetious. The notion of chaining repos is always fun but technically you're right; it's as easy as a push, and that is more or less immune to errors i.e. if a push failed due to some network or server issue it would just push again the next commit and be back on track. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Debugging With Xcode
On Apr 23, 2012, at 9:03 PM, Eric Seidel e...@webkit.org wrote: Does anyone still debug WebKit on Mac OS X with Xcode 4? 1. I don't know how to actually set up Xcode to point to WebKitBuild like it used to. http://www.webkit.org/building/debug.html Mentions a Legacy option which does not exist for me. Simon Fraser helped me set up WebKitBuild on one of my machines, but I don't really know how to repeat that process. 2. Xcode tries to Re-index WebCore, seemingly every time I open WebCore.xcodeproj. This is a hour+ process on my 12-core Mac Pro! The re-indexing takes a lot of processing power, and seems to render both my machine, and Xcode largely unusable. I understand that Xcode isn't really designed for projects as large as WebCore, but we've made it work in the past, and I'm curious if anyone is still making it work? If the Apple folks have any suggestions or updates to http://www.webkit.org/building/debug.html, they would be most appreciated. :) Thanks! -eric Xcode 4.2.1 Build version 4D502 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev I usually create an empty project, add the source files I care about, and then attach to the appropriate renderer process - but also use WebCore.xcodeproj directly on occasion. I run the same version as you and once ran into an infinite indexing cycle, but after a swift kick from Activity Monitor, I haven't seen it again. Xcode works great as a gdb front end for me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] github mirror
Wouldn't we need to continually mirror git.webkit.org to github as well? I presume github is mirroring directly from svn right now. I'd think the out-of-sync issue would simply occur again unless we started to mirror git. webkit.org to github instead of svn to github. I don't know what all Git takes into account when creating the sha1 outside of content, tree and commit meta data, so I'm unsure if doing this git. webkit.org = github forced push would mean that future svn commits - being mirrored to both repos in parallel - would result in identical sha1 hashes going forward...? Jarred On Wed, Apr 18, 2012 at 6:53 AM, Shezan Baig shezbaig...@gmail.com wrote: Hi WebKit, I've been using a fork of the following repo: https://github.com/WebKit/webkit However, yesterday there was discussion on #webkit that the SHA-1 checksums on this repo are different from repo at git.webkit.org, which means folks working on both need to have both versions checked out. I believe the answer to this problem is in: http://help.github.com/move-a-repo/ (look at the last section titled Manual clone and push) Anyone in the WebKit organization on https://github.com/WebKit should be able to push this. Once this is pushed, we can retire the existing repo on github. This means the existing forks will be unusable, but I think it will be good to do this earlier rather than later, so we just have one repo, and this will make it easier for existing git.webkit.org users to switch to github. Thanks, -shez- ___ 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] github mirror
(from correct address) On Wed, Apr 18, 2012 at 11:06 AM, Jarred Nicholls jar...@sencha.com wrote: On Wed, Apr 18, 2012 at 11:02 AM, Simon Hausmann simon.hausm...@nokia.com wrote: On Wednesday, April 18, 2012 06:53:46 AM ext Shezan Baig wrote: Hi WebKit, I've been using a fork of the following repo: https://github.com/WebKit/webkit However, yesterday there was discussion on #webkit that the SHA-1 checksums on this repo are different from repo at git.webkit.org, which means folks working on both need to have both versions checked out. I believe the reason for them being different is because in the github repo the commit author fields are resolved. Yeah that's totally it. So svn.webkit.org = git.webkit.org = github would need to be the mirroring strategy. Sounds dicey :) Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake for Apple's Windows port
On Thu, Apr 12, 2012 at 3:08 PM, Adam Treat atr...@rim.com wrote: If my memory serves me the problem was that Apple couldn't figure out how to get cmake installed on the Apple build system machine. @WebKitMemes you're up From: webkit-dev-boun...@lists.webkit.org [ webkit-dev-boun...@lists.webkit.org] on behalf of Dirk Pranke [ dpra...@chromium.org] Sent: Thursday, April 12, 2012 2:06 PM To: Patrick Gansterer Cc: WebKit Development Subject: Re: [webkit-dev] CMake for Apple's Windows port I think this is great; I've been meaning to spend some time on the apple win port trying to fix the remaining bugs holding up the switch to NRWT, but the fact that the apple win port still uses VS2005 is definitely an impediment (yes, I can probably just pull the binaries down from a bot for my purposes, but I'd really like to be able to build it). Patrick, have you documented what all you need to install on a Win box in order to be able to run CMake and do the build? Can someone from Apple weigh in on whether switch to CMake would be feasible? -- Dirk On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer par...@paroga.com wrote: Hi, it's more than a year since the last discussion about the build system of Apple's Windows port. In the meantime I merged most of the general changes into the CMake files in the repository and have a working patch with a few CMake files at [1] as written in [2]. I don't think that it is ready to replace the existing vcproj files already, but I like to hear all points needed to do that. Adding CMake files for the WinCairo port (which uses the vcproj files too) will be very easy when the Apple version has been added. Here some benefits to the CMake version: 1) Shared build system: The shared files are already used by the Blackberry, EFL and WinCE port, so only the list of platform specific files needs to be maintained. 2) No dependency on cygwin [3]: The CMake build system searches for the Win32 version of the required executables (bison, gperf, flex, perl and python) like the WinCE port does already (see [4]). 3) Less Solution targets: Some of he current vcproj files only used for triggering Makefiles. The vcproj generates more native vcproj files, which e.g. allows clicking on one of the IDL files to generate the corresponding files. 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows an easy transition to other (newer) Visual Studio versions, since every developer can choose his preferred version. 5) It's possibe to create Makefiles: The output of the windows buildbots shows much unwanted messages. Using Makefiles on the bots can produce cleaner logs and take advantage of all cores when used with JOM [7]. Would be great if people who use the current VS Solution can give the CMake version a try and provide some feedback about it. BTW: There is also a patch to switch Wx to CMake at [8], but it did not get a positive response. [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html [3] https://bugs.webkit.org/show_bug.cgi?id=48166 [4] http://trac.webkit.org/wiki/WinCE#Build [5] https://bugs.webkit.org/show_bug.cgi?id=53445 [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html [7] http://qt-project.org/wiki/jom [8] https://bugs.webkit.org/show_bug.cgi?id=73100 -- Patrick ___ 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 - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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] check-webkit-style should remind folks to update the results for run-bindings-tests
[From the correct email] On Mon, Apr 9, 2012 at 12:26 PM, Jarred Nicholls jar...@sencha.com wrote: On Mon, Apr 9, 2012 at 12:18 PM, Ryosuke Niwa rn...@webkit.org wrote: We have discussed this before: https://lists.webkit.org/pipermail/webkit-dev/2011-September/017868.html A better change would be for us to generate the diff on EWS, and get rid of binding tests step from build bots since they aren't really testing anything. The primary use case of run-bindings-tests is to see the diff before/after a code generator change and it has no business running on the bot or in check-webkit-style. Either way, we concluded that running the binding tests is very quick and cheap, so wherever it is still effective to prevent regressions in code generation is fine by me; on an as-needed basis (EWS) is clearly ideal, rather than on all builds. - Ryosuke On Mon, Apr 9, 2012 at 6:39 AM, Vineet Chaudhary rgf...@motorola.comwrote: Hi All, It is observed that if changes are made in Codegenerator*.pm we need to rebase results of run-bindings-tests. Many times authors forgot to update these binding results. IMO we should add check in ./check-webkit-style to warn/(give a chance) author to run run-bindings-tests if Codegenerator is modified. I have filed bug for this https://bugs.webkit.org/show_bug.cgi?id=83354. Please let me know if any suggestions to make this change. Thanks, Vineet ___ 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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] trac.webkit.org is down
On Mon, Mar 19, 2012 at 8:37 AM, Mike Lawther mikelawt...@google.comwrote: On 19 March 2012 22:44, Alexis Menard alexis.men...@openbossa.org wrote: Hi, On Wed, Feb 29, 2012 at 12:00 PM, William Siegrist wsiegr...@apple.com wrote: This should be fixed now. trac is down today for us. Yeah it's gotta be the server. http://www.downforeveryoneorjustme.com/trac.webkit.org It's 6:30am PST so we just need to have patience. bugs.webkit.org is also down with this error : I'm also seeing them down with the same symptoms from my home connection in Sydney. Traceroutes appended: traceroute to bugs.webkit.org (17.254.20.233), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 2.607 ms 0.875 ms 0.652 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.653 ms 18.283 ms 18.731 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 18.890 ms 18.652 ms 18.288 ms 4 syd-sot-ken2-crt2-ge-9-0-0 (203.29.135.173) 17.809 ms 19.238 ms 18.143 ms 5 te9-1.ccr02.lax04.atlas.cogentco.com (38.104.210.53) 227.246 ms 207.515 ms 207.168 ms 6 te0-2-0-7.ccr21.lax01.atlas.cogentco.com (154.54.24.69) 207.495 ms te0-3-0-7.ccr21.lax01.atlas.cogentco.com (154.54.1.9) 208.140 ms 208.054 ms 7 te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 221.802 ms te9-3.mpd01.sjc01.atlas.cogentco.com (154.54.25.186) 222.440 ms te3-1.mpd01.sjc01.atlas.cogentco.com (154.54.5.185) 374.174 ms 8 38.104.134.70 (38.104.134.70) 220.819 ms 220.666 ms 220.254 ms 9 border1.t7-1-bbnet1.sje.pnap.net (66.151.144.4) 391.199 ms 292.140 ms 255.343 ms 10 * * * 11 * * * [etc] traceroute to trac.webkit.org (17.254.20.241), 64 hops max, 52 byte packets 1 192-168-1-254 (192.168.1.254) 3.605 ms 0.754 ms 3.930 ms 2 syd-sot-ken2-bras2-lo20 (10.20.21.199) 18.515 ms 18.350 ms 18.426 ms 3 syd-sot-ken2-csw2-tg-3-1 (202.7.214.29) 19.037 ms 18.247 ms 18.236 ms 4 syd-sot-ken2-crt1-ge-9-0-0 (202.7.171.173) 18.632 ms 18.394 ms 18.429 ms 5 ix-8-3-0-0.tcore2.lvw-losangeles.as6453.net (64.86.252.125) 200.775 ms 200.856 ms 200.622 ms 6 xe-8-0-0.edge1.losangeles9.level3.net (4.68.62.117) 201.657 ms 201.147 ms 200.371 ms 7 vlan60.csw1.losangeles1.level3.net (4.69.144.62) 203.967 ms vlan80.csw3.losangeles1.level3.net (4.69.144.190) 200.859 ms vlan90.csw4.losangeles1.level3.net (4.69.144.254) 205.358 ms 8 ae-83-83.ebr3.losangeles1.level3.net (4.69.137.41) 203.072 ms 200.655 ms ae-93-93.ebr3.losangeles1.level3.net (4.69.137.45) 200.738 ms 9 ae-3-3.ebr1.sanjose1.level3.net (4.69.132.9) 211.694 ms 211.626 ms 212.040 ms 10 ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 221.184 ms ae-61-61.csw1.sanjose1.level3.net (4.69.153.2) 211.839 ms ae-71-71.csw2.sanjose1.level3.net (4.69.153.6) 218.424 ms 11 ae-41-80.car1.sanjose2.level3.net (4.69.152.139) 212.528 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 212.445 ms ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 212.433 ms 12 * * * 13 * * * [etc] mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)
On Fri, Mar 16, 2012 at 3:41 PM, Ariya Hidayat ariya.hida...@gmail.comwrote: See point 3 of Landing your code. Reviewer adds a link to pull request in changelog. But now it means I have to search in two places: Bugzilla and Github, in case I want to look up some past issues/problems. In fact, Github does not a way to search for review comments. GitHub's API has hooks/events for comments on issues PRs to where it would be possible to integrate WebKit's GitHub mirror with Bugzilla so that all comments on PRs could post back to the related Bugzilla bug. Some convention would be necessary in the PR title or description to figure out which bug # it relates to, and a little work would be necessary to write out the comment into Bugzilla with some code for context (by taking the diff that's sitting on GitHub). Definitely work involved, but doable. -- Ariya Hidayat, http://ariya.ofilabs.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] Git/SVN is slow
Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to svn.webkit.org succeed in acceptable times however, for me. Perhaps the hops following ae-11-70 and ae-21-60 simple aren't able to reply with proper ICMP packets; no real conclusion to based on that info alone, but maybe worth passing off to the provider and/or directly to Level3. Jarred On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub le...@google.com wrote: Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are dog slow :( 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms 3.056 ms 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms 9 * * * 10 * * * 11 * * * On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers p...@google.com wrote: Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Thanks for looking into this. Philip On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wsiegr...@apple.comwrote: Our network provider did not find anything wrong. If anyone is currently seeing slow download times, I would like to see a traceroute to the server. Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ 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] Git/SVN is slow
Well I was just about to follow up that from the east coast on Comcast bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. That's about as fast as it's always been. Same goes for nightly.webkit.org . There's a number of possible issues that would result in slow response times and slow downloads. E.g., it could be sheer packet loss between carrier backbones and not necessarily tapped bandwidth. On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't really think checking the latency is interesting. What's killing us is bandwidth. As far as I tested yesterday, the ping at my work (Google SF office) gives me a reasonable time as well. There's something that's killing our bandwidth. Does anyone know some tools to investigate this? - Ryosuke On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls jar...@webkit.orgwrote: Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to svn.webkit.org succeed in acceptable times however, for me. Perhaps the hops following ae-11-70 and ae-21-60 simple aren't able to reply with proper ICMP packets; no real conclusion to based on that info alone, but maybe worth passing off to the provider and/or directly to Level3. Jarred On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub le...@google.com wrote: Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are dog slow :( 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms 3.056 ms 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms 9 * * * 10 * * * 11 * * * On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers p...@google.com wrote: Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Thanks for looking into this. Philip On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wsiegr...@apple.com wrote: Our network provider did not find anything wrong. If anyone is currently seeing slow download times, I would like to see a traceroute to the server. Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http
Re: [webkit-dev] Moving to Git?
On Thu, Mar 8, 2012 at 7:46 AM, Sergio Villar Senin svil...@igalia.comwrote: En 08/03/12 13:35, Ashod Nakashian escribiu: WebKittens, In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again). Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not. A version of git ships with Xcode, and without Xcode I don't think anyone attempting to hack on WebKit will get very far :3 Anyway I'd be really pleased if that move happens. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] git.webkit.org problem
On Wed, Feb 29, 2012 at 3:38 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Feb 29, 2012 at 11:32 AM, Lucas Forschler lforsch...@apple.comwrote: I am looking into improving performance of build.webkit.org. After doing some initial research I feel that buildbot isn't the most efficient in terms of processing a large number of requests. I believe requests are processed serially, and not in parallel. The buildbot documentation mentions a limit to the number of slaves that can be supported, but doesn't give any specific numbers. As webkit has grown, and the number of builds and slaves we are supporting has increased, it seems the server is showing signs of reaching this capacity. We may have reached a limit on the number of slaves we can handle with our current configuration. On Chromium side, buildbot appears to leak a great amount of memory. e.g. we end up running out of memory at some point because buildbot keeps leaking some memory over time :( Do you see the same issue on your buildbot? -Upgrades to hardware. It's possible faster hardware could alleviate some problems. It is unclear if this is really the limiting factor, or how much additional capacity this would provide. My understanding is that we use a really fast server but still experience a similar problem. -Updating the way files are transferred (https://bugs.webkit.org/show_bug.cgi?id=73484) Would it make sense to have a separate apache server, etc... for receiving these files? twistd doesn't appear to be a cut out for uploading/downloading megabytes of data. -Upgrade the version of buildbot. (0.8.3 - 0.8.5). Version 0.8.4 and higher supposedly has a threading improvement, but it's unclear how much it would benefit us since it looks to be mostly database related. I've been told that upgrading buildbot didn't improve the performance. But upgrading it to 0.8.5 is probably a good nonetheless since it fixes various bugs I've encountered while maintaining Chromium bots and also when I ran buildbot locally. -Investigating some kind of apache caching layer on top of buildbot MUST DO THIS. This will greatly reduce the latency for most people. -Adding a second master to the buildbot system. buildbot supports multi-master mode. We could potentially split out build and test onto two separate masters. build.webkit.org and test.webkit.org ? build.chromium.org takes this approach. But then we won't be able to see both build and test step at once though... Would it make more sense to split per port? e.g. Apple Mac Apple Win, Qt Gtk, Chromium misc or something along that line? If this is pursued, then I would tend to agree with a per-port split vs a vertical split. But, it would mean more masters and more places to keep an eye on when doing cross-port changes, which could get out of hand. - Ryosuke ___ 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] optimising png files in LayoutTests - an experiment
On Wed, Jan 25, 2012 at 4:57 PM, Elliot Poger epo...@google.com wrote:
In deciding whether to just let the PNGs get shrunk over time or to do a
pass over all of them at once, I think we should decide what we are trying
to optimize for. (Download time for initial checkout of the webkit tree?
For git users, the history is there and so initial checkout is not really
going to change afaik.
Time for existing developers to update their trees? Storage space in the
repository?)
I would think that, except for initial checkout of the webkit repository,
the others would be optimized by lazily converting the files (waiting until
we need to check in new baselines, instead of shrinking them all at once).
On Wed, Jan 25, 2012 at 1:12 PM, Dirk Pranke dpra...@chromium.org wrote:
I like the idea. I'm not sure I agree w/ Adam that I'd roll the code
into DRT, insofar as I don't know how big it is and I would definitely
want the code shared across all of the DRT implementations. I'd
probably also do a pass over all of the existing PNGs at some point
rather than wait for them to be updated as necessary.
-- Dirk
On Tue, Jan 24, 2012 at 10:43 PM, Mike Lawther mikelawt...@chromium.org
wrote:
Hi guys,
Just thought I'd share the results of an experiment I did in optimising
the
png files in LayoutTests.
I used a tool on Mac called ImageOptim (http://imageoptim.pornel.net/)
which
tries a set of different png lossless optimising tools (like pngcrush -
I
also downloaded and included PNGOUT). Note that this strips out some of
the
stuff we need, like the hash, so if doing this for real we'd have to
watch
out for that.
My results were:
Before:
$ ls -laR LayoutTests/ | grep png$ | awk '{total = total + $5}END{print
total}'
1220535840
Test:
$ find LayoutTests/ | grep png$ | xargs open -a ImageOptim.app
After:
$ ls -laR LayoutTests/ | grep png$ | awk '{total = total + $5}END{print
total, 1220535840 - total}'
937198328 283337512
So this has saved ~280MB (~23% of the original size).
Based on this, it seems worthwhile to include a png optimiser somewhere
in
the patch upload/submit toolchain, and also (separately) to optimise the
existing pngs.
Thoughts?
mike
___
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] *.webkit.org is down
On Thu, Jan 19, 2012 at 3:19 PM, Alexis Menard alexis.men...@openbossa.orgwrote: Hi, It seems that *.webkit.org are down (bugs.webkit.org, trace.webkit.org, …). I can confirm here in Maryland, USA that www, bugs, trac, etc. are all up. Here in Brazil we can't access to any of them. I tried two different internet providers with their own DNS and I even tried google DNS with no luck. Might you try OpenDNS? 208.67.222.222/208.67.220.220 Talking to some people in #webkit it seems that not everyone is affected (maybe only people outside US?). Anyone who knows where the servers sits would mind to have a look at them? Thank you very much. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard alexis.men...@openbossa.orgwrote: On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Hi Eric, Is there a patch somewhere or you are still working on it? The bug link contains nothing. I would like to apply it here and test the Qt port so you'll get a bit more confidence before landing it. I believe other ports are interested too. Nevermind wtf is already a static lib for Qt :D. /me is going to hide himself for not opening wtf.pro for a while. To be clear, if we're talking about moving Source/JavaScriptCore/wtf = Source/WTF, there would still be project file changes necessary to support that move, so testing it wouldn't hurt :) -Jarred Thanks. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ietestcenter tests
On Tue, Jan 10, 2012 at 5:22 PM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, As you're probably aware, our friend at Microsoft have posted a bunch of standards compliance tests on http://samples.msdn.microsoft.com/ietestcenter/. In the spirit of good-natured competition, I thought we might try to get a higher score than the latest beta of IE10. (WebKit's score is already higher than IE9, so there's not much of a challenge there.) I've compiled a spreadsheet of the tests we're failing: https://docs.google.com/spreadsheet/ccc?key=0AppchfQ5mBrEdHAtbzNvcFdfSlBBbGN0NjY1UFlLYlE Many of these bugs look to be pretty easy to fix, so if you're just starting out in WebKit or looking to learn about a new area of the project, these might be good places to start. Seasoned contributors are also welcome, of course. :) Happy hacking, Adam Good deal, thanks for sharing Adam. 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] chromium image tests on lion
Thanks Ojan. There is an older issue for this that I went ahead and starred: http://code.google.com/p/chromium/issues/detail?id=101398 Thanks all for the replies. Cheers, Jarred On Mon, Jan 9, 2012 at 1:41 PM, Ojan Vafai o...@chromium.org wrote: For those who want to follow along, I filed http://code.google.com/p/chromium/issues/detail?id=109637 for getting a Lion chromium bot running. On Mon, Jan 9, 2012 at 10:38 AM, Ojan Vafai o...@chromium.org wrote: Chromium lacks a builder for Lion, so I expect there are likely many failures that noone has taken the time to look into. On Mon, Jan 9, 2012 at 1:05 AM, Jochen Eisinger joc...@chromium.orgwrote: On Mon, Jan 9, 2012 at 7:47 AM, Simon Fraser simon.fra...@apple.comwrote: This could have been me: http://trac.webkit.org/changeset/104351 That changeset does not affect the chromium port -jochen Ideally we'd turn on mock scrollbars everywhere and then regenerate all the results (checking for actual failures). Not sure if I'll have time to do that though. Simon On Jan 7, 2012, at 8:44 AM, Jarred Nicholls wrote: Hey all, I'm running the layout tests for chromium on lion, and pretty much all of them is failing. LayoutTestHelper fails to set the generic RGB color profile, but after setting it manually the image diffs are very subtle (mostly around test rendering, but not too much on color). Related to Skia change and/or just outdated expectations? Given that Lion isn't a core test runner for chromium and it's been red since who knows when, I suppose this is to be expected for now. Appreciate any comments so I can safely overlook this, 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 ___ 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] chromium image tests on lion
Hey all, I'm running the layout tests for chromium on lion, and pretty much all of them is failing. LayoutTestHelper fails to set the generic RGB color profile, but after setting it manually the image diffs are very subtle (mostly around test rendering, but not too much on color). Related to Skia change and/or just outdated expectations? Given that Lion isn't a core test runner for chromium and it's been red since who knows when, I suppose this is to be expected for now. Appreciate any comments so I can safely overlook this, thanks! Jarred ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] js-test-(pre|post).js in http tests
Any particular reason we aren't using js-test-pre and js-test-post harness code in our http tests, other than the fact that it's additional http resources loaded per test? I could spend a year improving our current tests; they are completely fugly. Thanks, Jarred ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js-test-(pre|post).js in http tests
On Mon, Dec 19, 2011 at 1:57 PM, Adam Klein ad...@chromium.org wrote: Which tests are you referring to? I've certainly written HTTP tests that use the JS test harness, e.g., http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/filesystem/resolve-uri.html. Note the resources are in fact copied to a special '/js-test-resources/' directory to make them accessible via HTTP. Ahh beautiful, I was unaware the resources were copied to an accessible path prior to the test run. A did a physical search for the files and a poor grep for their potential use in http/tests. Thanks Adam for the tip! - Adam On Mon, Dec 19, 2011 at 7:08 AM, Jarred Nicholls jar...@webkit.orgwrote: Any particular reason we aren't using js-test-pre and js-test-post harness code in our http tests, other than the fact that it's additional http resources loaded per test? I could spend a year improving our current tests; they are completely fugly. 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] Incremental steps towards moving WebCore/platform out of WebCore
On Thu, Dec 15, 2011 at 1:55 AM, Adam Barth aba...@webkit.org wrote: I was working backwards from what's going to be needed to move WebCore/platform out of WebCore, and it occurred to me that we'll probably want a separate namespace for the code once it's outside of WebCore, just like WTF has a separate namespace from JSC. It seems like introducing the new namespace before the move would be beneficial because it would help us sort out whatever layering violations we have today (as they'd become apparent because of the explicit mention of the WebCore namespace). What would be an appropriate name for the namespace? My first instinct is Platform to match the name of the new directory, but I'm open to suggestions. I think Platform is good. When explaining it to an outsider, I refer to it as the Client Interface or Port Interface. If Platform doesn't resonate well with everyone then maybe something around that verbiage would fit. But honestly I can't think of anything better than Platform. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Internal JSON Parsing
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
Re: [webkit-dev] Internal JSON Parsing
That's precisely what I wanted to do initially. I had conflicting feelings on this, but my first intuition was to cache in the bindings the value directly parsed and state managed by the respective VM. I don't see this value being used by a different binding layer in parallel. On Thu, Dec 8, 2011 at 12:08 PM, Oliver Hunt oli...@apple.com wrote: 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] WebKit branch to support multiple VMs (e.g., Dart)
On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin ant...@chromium.org 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. And we're not only talking about the browsers proper, our hope was, for example, that people embedding WebKit into apps may benefit from hopefully tight integration or, another idea, if we can provide better isolation for JS proper using similar approach. And sure, this patch--- https://bugs.webkit.org/show_bug.cgi?id=73897 ---is only a tiny step in this direction---Fillip is absolutely right that integrating several GCing VMs is tricky---we're pretty much aware of this and hope we can address this, but, again, the patch is only initial infrastructure to enable more than a single runtime. If consensus in the community is nobody needs more than JS runtime in the browser (for any reason), so it be---we looked for feedback from the community and we got it. If the community response is idea is good, but you need to account for..., great, we're happy to do that. Maybe it'll make this patch feel less experimental and Geoff would be less reluctant to see it on the branch. It would be easier to just host the branch in a mirror somewhere else, continue experiments there, and report back to the community. Many others do this, e.g., Samsung and WebCL. And I can definitely understand concerns which are raised by Dart in the browser, but I really hope it's a separate issue. Thank you very much all for your feedback! yours, anton. On Tue, Dec 6, 2011 at 8:24 AM, Oliver Hunt oli...@apple.com wrote: 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
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Tue, Dec 6, 2011 at 8:17 AM, Anton Muhin ant...@chromium.org wrote: Thanks a lot, Jarred. We're fine w/ hosting in other repo (but we'll be happier to live close to the WebKit). What would you suggest as a measure of success for this extra-repo branch? I think that's a fair question. Based on current dialogue, there are some points to be proven such as no performance degradation or large increase of memory consumption to run the status quo, hackability, etc. Posting the patches was a good first step to viewing the changes, but the separate repo would allow those interested to follow along without the worries (on both sides) of how the separate branch affects WebKit proper. From the performance/memory standpoint, one good measure of success is empirical evidence that neither are compromised when running the current VMs. Even if no additional VMs are supported in WebKit proper, I understand the benefits to having the interface available for other consumers of the engine in closed/embedded scenarios, regardless of the controversial issues of what's best for the open web (it reminds me of the controversies around supported video codecs for the video element and what a nightmare that is for the open web). I'm fairly new to the WebKit community myself, so I'm just suggesting what I would do that would be frictionless :) yours, anton. On Tue, Dec 6, 2011 at 2:10 PM, Jarred Nicholls jar...@webkit.org wrote: On Tue, Dec 6, 2011 at 5:55 AM, Anton Muhin ant...@chromium.org 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. And we're not only talking about the browsers proper, our hope was, for example, that people embedding WebKit into apps may benefit from hopefully tight integration or, another idea, if we can provide better isolation for JS proper using similar approach. And sure, this patch--- https://bugs.webkit.org/show_bug.cgi?id=73897 ---is only a tiny step in this direction---Fillip is absolutely right that integrating several GCing VMs is tricky---we're pretty much aware of this and hope we can address this, but, again, the patch is only initial infrastructure to enable more than a single runtime. If consensus in the community is nobody needs more than JS runtime in the browser (for any reason), so it be---we looked for feedback from the community and we got it. If the community response is idea is good, but you need to account for..., great, we're happy to do that. Maybe it'll make this patch feel less experimental and Geoff would be less reluctant to see it on the branch. It would be easier to just host the branch in a mirror somewhere else, continue experiments there, and report back to the community. Many others do this, e.g., Samsung and WebCL. And I can definitely understand concerns which are raised by Dart in the browser, but I really hope it's a separate issue. Thank you very much all for your feedback! yours, anton. On Tue, Dec 6, 2011 at 8:24 AM, Oliver Hunt oli...@apple.com wrote: 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
Re: [webkit-dev] getComputedStyle returns percentage values for left / right / top / bottom
Indeed it is correct. The CSS W3 draft also states that those properties return the specified value, which if a percentage should return a percentage by definition. On Mon, Nov 21, 2011 at 10:49 PM, Xianzhu Wang (王显著) wangxian...@chromium.org wrote: Sorry my previous post might be misleading. Just verified that in the CSSOM draft the list of properties that getComputedStyle() may return the used value doesn't include left/right/top/bottom. That is, according to the draft, WebKit's current behavior about left/right/top/bottom is correct. On Tue, Nov 22, 2011 at 10:50 AM, Xianzhu Wang (王显著) wangxian...@chromium.org wrote: A related bug is: https://bugs.webkit.org/show_bug.cgi?id=42799 It's about the problem of pixelXXX CSS properties. Is these pixelXXX properties a workaround of bug 29084? I think after we fix 29084 we can drop the pixelXXX properties. The current draft CSSOM says getComputedStyle() should return the resolved values, and for width, height etc., if the property applies to the element or pseudo-element and the resolved value of the 'display' property is not none, the resolved value is the used value. Otherwise the resolved value is the computed value. On Tue, Nov 22, 2011 at 8:02 AM, Ryosuke Niwa rn...@webkit.org wrote: Per bugzilla discusion, FF, IE, and Opera all return pixel values so we should just fix this bug. - Ryosuke On Mon, Nov 21, 2011 at 3:19 PM, Mike Sherov mike.she...@gmail.comwrote: I'd like to begin working on this bug ( https://bugs.webkit.org/show_bug.cgi?id=29084), and making sure that getComputedStyle() always returns a pixel value used value when expected, although I suspect this is a controversial change, and http://www.webkit.org/coding/contributing.html#writecode says to ask in this mailing list before making a controversial change. Can anyone give me some feedback here on whether or not I can and should move forward on this? ___ 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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] getComputedStyle returns percentage values for left / right / top / bottom
2011/11/22 Jarred Nicholls jar...@sencha.com Indeed it is correct. The CSS W3 draft also states that those properties return the specified value, which if a percentage should return a percentage by definition. By that I meant the *older* CSS drafts - the point being that it's always been defined in that way for those properties. On Mon, Nov 21, 2011 at 10:49 PM, Xianzhu Wang (王显著) wangxian...@chromium.org wrote: Sorry my previous post might be misleading. Just verified that in the CSSOM draft the list of properties that getComputedStyle() may return the used value doesn't include left/right/top/bottom. That is, according to the draft, WebKit's current behavior about left/right/top/bottom is correct. On Tue, Nov 22, 2011 at 10:50 AM, Xianzhu Wang (王显著) wangxian...@chromium.org wrote: A related bug is: https://bugs.webkit.org/show_bug.cgi?id=42799 It's about the problem of pixelXXX CSS properties. Is these pixelXXX properties a workaround of bug 29084? I think after we fix 29084 we can drop the pixelXXX properties. The current draft CSSOM says getComputedStyle() should return the resolved values, and for width, height etc., if the property applies to the element or pseudo-element and the resolved value of the 'display' property is not none, the resolved value is the used value. Otherwise the resolved value is the computed value. On Tue, Nov 22, 2011 at 8:02 AM, Ryosuke Niwa rn...@webkit.org wrote: Per bugzilla discusion, FF, IE, and Opera all return pixel values so we should just fix this bug. - Ryosuke On Mon, Nov 21, 2011 at 3:19 PM, Mike Sherov mike.she...@gmail.comwrote: I'd like to begin working on this bug ( https://bugs.webkit.org/show_bug.cgi?id=29084), and making sure that getComputedStyle() always returns a pixel value used value when expected, although I suspect this is a controversial change, and http://www.webkit.org/coding/contributing.html#writecode says to ask in this mailing list before making a controversial change. Can anyone give me some feedback here on whether or not I can and should move forward on this? ___ 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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
On Wed, Nov 2, 2011 at 4:23 PM, Adam Barth aba...@webkit.org wrote: As discussed previously, I think it would benefit the project to move WTF out of JavaScriptCore: https://lists.webkit.org/pipermail/webkit-dev/2010-December/015427.html https://lists.webkit.org/pipermail/webkit-dev/2011-February/015940.html Previously, we've been unable to do this because of Apple's internal build process. In thinking about this problem again recently, I wonder if the following would work: 1) Move JavaScriptCore.xcodeproj from Source/JavaScriptCore/JavaScriptCore.xcodeproj to Source/JavaScriptCore.xcodeproj. 2) Change how Apple submits JavaScriptCore to the internal build process to submit Source as the code for JavaScriptCore instead of Source/JavaScriptCore. 3) Move Source/JavaScriptCore/WTF to Source/WTF. Mark, do you have a sense for whether this plan is feasible? If not, is there another approach that would work better? (If my understanding is correct, we could also apply this approach to the other xcodeproj files, which would let us get rid of ForwardingHeaders and move Source/WebCore/platform to Source/Platform.) That'd be most excellent. ChangeLog would be cleanly split out as a nice side effect to doing this, as well as w/ WTF vs. JavaScriptCore. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please use platform prefixes in bug titles
On Wed, Oct 5, 2011 at 9:56 PM, Martin Robinson mrobin...@webkit.orgwrote: On Wed, Oct 5, 2011 at 6:09 PM, David Levin le...@chromium.org wrote: btw, I'm not planning to work on this for now but would be happy to give advice if someone took it up. A queryable mapping of which source directories and files apply to which ports could be quite useful indeed. +1 --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pthreads and other threading primitives
On Mon, Sep 26, 2011 at 1:47 PM, Alexey Proskuryakov a...@webkit.org wrote: In the wake of Geoff's work to simplify threading ifdefs, and Adam's review of supported ports, I'm curious what people think about maintaining many platform branches in our WTF and JavaScriptCore threading code. Right now, it feels rather non-systemic, with some code built upon pthreads, Qt or Gtk libraries, and some calling into Win32 API directly. Some specific examples: - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads; - FastMalloc works with pthreads or Win32 API; - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API; - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely custom. Chromium doesn't even use supposedly cross-platform parts in MainThread.cpp. Supporting multiple implementation has a high cost, both in the work directly applied to that, and in having subtle behavior differences. Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I see that most lines are last touched by people who are not directly affiliated with these ports. I remember that performance was given as the primary reason to not use pthreads everywhere. What pthreads functionality in particular needs to be reimplemented in WTF for performance? And are there big reasons to use anything except for POSIX and Win32 APIs for us? IMHO, I think JSC should go right to the metal rather than be abstracted with port specific threading classes. In other words, it should be broken out by platform threading libs - POSIX and Win32 - and not by port. After a very rudimentary scan, I saw no reason to not use straight Win32 and POSIX. This would arguably reduce port barrier-to-entry and maintenance, on top of the obvious code simplicity and slight performance increase. Do we want to require that platforms support pthreads, so that code that isn't performance critical could have just one implementation? That's the status quo :) MachineStackMarker only works with pthreads, so QtWin32 and Win ports need pthreads-win32 right now. pthreads is the least common denominator at the moment. Though there are performance reasons for getting away from that, there is also the fact that pthreads-win32 is an unmaintained project whose last update was 5 years ago. - WBR, Alexey Proskuryakov Definitely worth a full reviewer analysis and vote I think. This is one of the many WebKit cleanup tasks to consider. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
On Tue, Sep 13, 2011 at 11:27 AM, Eric Seidel e...@webkit.org wrote: Folks can track the general task of feature removal at: https://bugs.webkit.org/show_bug.cgi?id=68012 Nice this is helpful, thanks. I will link all the Remove ENABLE_* bugs to that one. -eric On Tue, Sep 13, 2011 at 11:20 AM, Eric Seidel e...@webkit.org wrote: Hearing no objections to removing any of the sub-defines, I will post a patch to do so shortly. I'll leave the ENABLE_SVG define for now. -eric On Tue, Sep 13, 2011 at 11:12 AM, Baldeva, Arpit abald...@ea.com wrote: Same here. We disable SVG for code size reasons as well. It would be nice to continue to have the top level define for that purpose. Thanks! -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] On Behalf Of Dan Minor Sent: Monday, September 12, 2011 7:07 AM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Do you compile with ENABLE_SVG diabled? When doing ports to various embedded systems we often disable SVG to reduce the size of the resulting library. It would be nice to retain the top level ENABLE_SVG define for this purpose. Thanks, Dan On 09/09/2011 05:42 PM, Eric Seidel wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ 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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More ports on nightly.webkit.org?
On Mon, Sep 12, 2011 at 11:57 AM, Ryosuke Niwa rn...@webkit.org wrote: Also, I often encounter regressions or bugs only reproduce on certain ports but I haven't been able to confirm those bugs because I don't have a luxury of building those ports just to confirm bugs. Providing nightlies for those ports will greatly enhance our ability to narrow down regression windows and triage bugs. Massive point. - Ryosuke On Mon, Sep 12, 2011 at 11:38 AM, Kaustubh Atrawalkar hwn...@motorola.com wrote: Yes, I second Ryosuke and really would like to support this idea. Not even just end user but developers like us would also like to have sneak in these nightly builds. It will not only help to test the nightly on daily basis but also will help to improve and contribute more. I m ready to help for this in any way possible. - Kaustubh On 12-Sep-2011, at 11:43 PM, Ryosuke Niwa rn...@webkit.org wrote: An excellent idea! - Ryosuke On Mon, Sep 12, 2011 at 11:10 AM, Adam Barth aba...@webkit.org aba...@webkit.org wrote: Do any ports besides the Apple ports produce nightly builds that end-users might be interested in using? If so, it might make sense to expand the offerings on http://nightly.webkit.org/ http://nightly.webkit.org/ to include more choices. For example, Linux users might enjoy a nightly build that runs on Linux. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.orgwebkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev 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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk
On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth aba...@webkit.org wrote: Leandro's recent message reminded me that there was some discussion on this list about the burden caused by storing and maintaining pixel baselines for an ever-growing list of configurations. I've been working on a proposal for moving pixel baselines to a branch so that they don't bother most folks. Unfortunately, I haven't been able to work out all the details yet. Here's a somewhat rough, work-in-progress proposal. If you like this approach, I can spend more time trying to solve the remaining problems. == Motivation == Maintaining pixel test results in svn.webkit.org for the various Chromium configuration imposes a number of costs on the WebKit community: All members of the community need to store these results locally when they create a checkout of WebKit. Updating the pixel results creates churn in the project that increases the time required to update a working copy and makes it more difficult to understand what is actually changing in the project. As the Chromium port grows in complexity, there is pressure from the Chromium project to expand the number of test configurations, increasing these costs on the WebKit community. == Proposal (Work-in-progress) == One option is to stop running pixel test altogether, but that decreases test coverage and costs correctness. Another possibility is to store the pixel results in a location where they are largely invisible to the rest of the WebKit community. For example, we could store the pixel results for chromium-linux the following location: http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux Chromium contributors could then use gclient and DEPS to map these results into their working copies and non-chromium contributors could safely ignore any changes in the PixelResults “branch”. FIXME: What about non-platform specific results? == Problems == The main reason this proposal is half-baked is I haven't quite been able to work out how folks can do some common operations: 1) Land patch with expected image failures (+ revert) 2) Land patch with new image baselines (+ revert) 3) Land new baselines Because the pixel results and trunk are in the same SVN repo, we should be able to do these things atomically, but dealing with the sparse checkout is kind of tricky. Another big question mark is how this would work for contributors who use git. When git mirrors an SVN repro, it only mirrors trunk, so the PixelResults directory wouldn't exist in the git version of the repository. git-svn would be the fallback - I'd rather take razor blades to my eyes. But this is a noble effort in general, thanks. Do we need to do anything to alleviate history in the git mirror? I'd love to clone 25MB and not 2.1GB. Thoughts? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ 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 Fri, Sep 9, 2011 at 12:07 PM, Adam Barth aba...@webkit.org wrote: run-layout-tests? too obvious. as an ode to Paul, I propose run-the-mother-effing-layout-tests http://mothereffinghsl.com/ ;) On Sep 9, 2011 8:04 AM, Adam Roben aro...@apple.com wrote: On Sep 9, 2011, at 10:59 AM, Adam Roben wrote: On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote: On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote: On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote: I'm happy to write a run-all-tests script which runs all known tests that platform can handle. :) I think run-webkit-tests should be this. We can come up with a new name for the “just run the tests in the LayoutTests directory” tool. I would like that too. But there are going to be stages to get here. If we did this today, bots would break if nothing else. I'll see about adding a run-all-tests script soon and we can work to have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?) An alternate path to success would be: 1) Decide what to call the script that just runs tests from LayoutTests 2) Rename run-webkit-tests to that new name and add a new script called run-webkit-tests that just calls the renamed script 3) Slowly make run-webkit-tests call out to other test-running scripts I of course forgot: 2.5) Change the bots to call the renamed script -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] make-script-test-wrappers not being maintained
On Thu, Sep 8, 2011 at 10:58 AM, Eric Seidel e...@webkit.org wrote:
We could also teach DumpRenderTree to lie about what / is, so we
could include the scripts like this:
script href=/fast/js/resources/js-test-pre.js
+1 But this goes back to solving the problem of deriving a path to the
LayoutTests, other than via the DRT executable's location.
These bugs are regarding remapping /tmp/LayoutTests requests, but the same
idea applies to remapping any URL to something real:
https://bugs.webkit.org/show_bug.cgi?id=67239
https://bugs.webkit.org/show_bug.cgi?id=65781
On Thu, Sep 8, 2011 at 1:14 AM, Adam Barth aba...@webkit.org wrote:
On Thu, Sep 8, 2011 at 12:41 AM, Maciej Stachowiak m...@apple.com
wrote:
Do you have an idea for how to avoid needing to adjust the number of
../
path segments in the path to the harness? That's the most annoying step
of
the current copy/paste solution, and it does not seem like simplifying
the
boilerplate as you suggest resolves that issue.
One approach is to have an inline script that examines the URL and
sets the base URL appropriately:
script
document.write('base href=' + location.href.substr(0,
location.href.lastIndexOf('LayoutTests/') + 'LayoutTests/'.length) +
'');
/script
Of course, you could make the script more readable if you were willing
to have it extend to more than one line. If you wanted to get really
fancy, you could restore the original base URL after loading the
appropriate test harness scripts.
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
--
*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] make-script-test-wrappers not being maintained
On Thu, Sep 8, 2011 at 11:04 AM, Tom Zakrajsek t...@codeaurora.org wrote:
Wouldn't that make it so that the tests would *only* work in DRT?
Yeah that's not good ;)
On 09/08/2011 07:58 AM, Eric Seidel wrote:
We could also teach DumpRenderTree to lie about what / is, so we
could include the scripts like this:
script href=/fast/js/resources/js-**test-pre.js
On Thu, Sep 8, 2011 at 1:14 AM, Adam Barthaba...@webkit.org wrote:
On Thu, Sep 8, 2011 at 12:41 AM, Maciej Stachowiakm...@apple.com
wrote:
Do you have an idea for how to avoid needing to adjust the number of
../
path segments in the path to the harness? That's the most annoying step
of
the current copy/paste solution, and it does not seem like simplifying
the
boilerplate as you suggest resolves that issue.
One approach is to have an inline script that examines the URL and
sets the base URL appropriately:
script
document.write('base href=' + location.href.substr(0,
location.href.lastIndexOf('**LayoutTests/') + 'LayoutTests/'.length) +
'');
/script
Of course, you could make the script more readable if you were willing
to have it extend to more than one line. If you wanted to get really
fancy, you could restore the original base URL after loading the
appropriate test harness scripts.
Adam
__**_
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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-**devhttp://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-**devhttp://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 menu element
Consider that menu and dir were both deprecated in HTML4 in 1999[1], and are
obsolete with HTML5. HTML4 Transitional/loose DTD still recognizes them.
Jarred
[1]: http://www.w3.org/TR/html4/struct/lists.html#h-10.4
On Tue, Sep 6, 2011 at 5:40 AM, Antaryami Pandia xqb...@motorola.comwrote:
Hi,
We are intending to implement the HTML5 menu tag.
The related specs can be found at:-
-
http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element
-
http://dev.w3.org/html5/spec/interactive-elements.html#the-menu-element .
A bug for the purpose is already logged at webkit bugzilla (
https://bugs.webkit.org/show_bug.cgi?id=58454).
Currently webkit does have a support for menu tag (not html5) with below
interface:-
interface HTMLMenuElement : HTMLElement {
attribute [Reflect] boolean compact;
};
Where as the proposed new implementation will have the interface as:-
interface HTMLMenuElement : HTMLElement {
attribute DOMString type;
attribute DOMString label;
};
So my question is should we also support the earlier menu tag
implementation?
Regards,
-Antaryami
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing HTML5 menu element
I don't know how to answer that, as I don't know the policy at this given
moment. But I did want to provide some information for the deciders. I'm
just as curious; I'm not sure if or when the last time a name clash like
this has occurred.
Jarred
On Tue, Sep 6, 2011 at 8:09 AM, Antaryami Pandia xqb...@motorola.comwrote:
So moving forward should we modify the existing HTMLMenuElement class or
keep it in some way for backward compatibility.
Regards,
-Antaryami
On Tue, Sep 6, 2011 at 5:06 PM, Jarred Nicholls jar...@sencha.com wrote:
Consider that menu and dir were both deprecated in HTML4 in 1999[1], and
are obsolete with HTML5. HTML4 Transitional/loose DTD still recognizes
them.
Jarred
[1]: http://www.w3.org/TR/html4/struct/lists.html#h-10.4
On Tue, Sep 6, 2011 at 5:40 AM, Antaryami Pandia xqb...@motorola.comwrote:
Hi,
We are intending to implement the HTML5 menu tag.
The related specs can be found at:-
-
http://www.whatwg.org/specs/web-apps/current-work/#the-menu-element
-
http://dev.w3.org/html5/spec/interactive-elements.html#the-menu-element.
A bug for the purpose is already logged at webkit bugzilla (
https://bugs.webkit.org/show_bug.cgi?id=58454).
Currently webkit does have a support for menu tag (not html5) with below
interface:-
interface HTMLMenuElement : HTMLElement {
attribute [Reflect] boolean compact;
};
Where as the proposed new implementation will have the interface as:-
interface HTMLMenuElement : HTMLElement {
attribute DOMString type;
attribute DOMString label;
};
So my question is should we also support the earlier menu tag
implementation?
Regards,
-Antaryami
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
--
*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
http://twitter.com/jarrednicholls
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
