[webkit-dev] Use testRunner instead of layoutTestController in new regression tests (a.k.a. layout tests)
Hello WebKittens, I've exposed layoutTestController as testRunner in http://trac.webkit.org/changeset/119946. Moving forward, please use window.testRunner (as supposed to window.layoutTestController) in new tests you write. If you're interested in helping the effort to update existing tests to use testRunner instead of layoutTestController, run variants of the following shell command: find LayoutTests/fast/css LayoutTests/platform/*/fast/css -type f -not -wholename '*/.svn/*' -print0 \ | xargs -0 grep -nHl layoutTestController \ | xargs sed -i -e s/layoutTestController/testRunner/g then revert all new line changes. While sed adds a new line at the end of each file when one is missing, this causes documents in quirks mode to render differently and thus the modified tests to fail. Upload the patch and cc me. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use testRunner instead of layoutTestController in new regression tests (a.k.a. layout tests)
FYI, all conversion bugs *depend on* https://bugs.webkit.org/show_bug.cgi?id=88210 - Ryosuke On Mon, Jun 18, 2012 at 11:48 PM, Ryosuke Niwa rn...@webkit.org wrote: Hello WebKittens, I've exposed layoutTestController as testRunner in http://trac.webkit.org/changeset/119946. Moving forward, please use window.testRunner (as supposed to window.layoutTestController) in new tests you write. If you're interested in helping the effort to update existing tests to use testRunner instead of layoutTestController, run variants of the following shell command: find LayoutTests/fast/css LayoutTests/platform/*/fast/css -type f -not -wholename '*/.svn/*' -print0 \ | xargs -0 grep -nHl layoutTestController \ | xargs sed -i -e s/layoutTestController/testRunner/g then revert all new line changes. While sed adds a new line at the end of each file when one is missing, this causes documents in quirks mode to render differently and thus the modified tests to fail. Upload the patch and cc me. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
If the object file is meant by a cfg IR dump, then yes. Assume that all of repeated compilations are okay, but then again going through all the passes of the optimizations in caller function probably does not make sense. Or I'm not right? -- You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 4GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748STATUS=MAIN ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
And I think You talk about JSC compiling, not about DFG JIT work. -- You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 4GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748STATUS=MAIN ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
On Jun 19, 2012, at 5:04 AM, Nare Karapetyan wrote:
If the object file is meant by a cfg IR dump, then yes.
Assume that all of repeated compilations are okay,
but then again going through all the passes of the optimizations
in caller function probably does not make sense.
Or I'm not right?
You've got the right intuition, but there are some subtleties:
- If a function gets hot enough to warrant DFG optimizations then some
callsites that may dispatch to that function may decide to inline it, while
others won't. Currently our heuristics are such that when a function gets
inlined, it will also usually but not always get compiled stand-alone for the
benefit of callsites that choose not to inline. I don't believe those
heuristics are right, and we can easily improve them by triggering
baseline-DFG tier-up in prologues rather than in epilogues. We could even go
further and say that when tier-up is triggered we walk the stack to find the
first known-hot method and only optimize that one. But even if you did that,
you may have situations where a function foo() calls function bar() in two
places, and we choose to inline bar() into foo() at the first callsite but not
the second one. This can happen if the second callsite has gone polymorphic.
My gut feeling is that any optimizations you did to avoid compiling bar() would
have only fairly limited benefit because polymorphic callsites are rather
common in JS.
- The two compilations that you speak of can be arbitrarily far apart in time.
Hence, if we wanted to cache compilation artifacts from one to the other, we'd
risk increasing memory footprint. The DFG IR requires a fair amount of memory,
so it's not clear that doing such caching would be better than reparsing from
bytecode.
- Even if you believed that the DFG IR was compact enough to cache - or if you
came up with fancy ways to compress it - you'd still have a much bigger
problem: every time that we parse bytecode into DFG IR we will likely do subtly
different optimizations, because we will likely have subtly different profiling
data and watchpoint state. For example, on the first compilation we may see
that some prototype P has some set of fields {F, G, H} that are all specialized
to functions. This allows us to use really aggressive optimizations on method
calls that have P in the prototype chain. But between this compilation and the
next one, someone might delete field F, store a string into field G, and
install a getter on H that does arbitrary things when called (triggers
navigation, starts workers, does XML requests, whatever). Then the second
compilation would actually parse the bytecode differently, and would produce a
different DFG IR to reflect the fact that it would be neither wise nor sound to
perform the same optimizations that we had performed before. And by the way,
the previous compilation would now be invalidated because of changes in P's
state, but that's a different issue.
- Even if you believed that you could make the bytecode-DFGIR parsing
deterministic, then you still wouldn't be able to cache anything more than the
IR immediately after parsing. It would not be possible to cache the results of
any subsequent phase, since the subsequent phases do whole-compilation-unit
analyses of the IR. For example if you have foo() calls bar(a, b, c) and bar()
gets inlined, then the subsequent phases would treat the arguments a, b, c to
bar() rather differently than if bar() had not been inlined. Any type
information available at bar()'s callsite would be propagated into bar().
Likewise, any type information available at bar()'s return point would be
propagated back into foo(). There is no sane way to make this behave the same
if bar() is not inlined as it would behave when bar() is inlined. I mean, you
could turn off all of the optimizations we do that are based on
whole-compilation-unit static analysis, but then you'd get a disastrous
slow-down on the benchmarks.
-Filip
--
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Proposal to add 'compile-tools' step to the build bots
Hello all, Currently our build bots have a compile-webkit step. This step does NOT build any of the tools used by the testers. Instead, the testers are building the tools at execution time. I would like to add a compile-tools step to run directly after the compile-webkit step. The tools components would be packaged up into the archive, and then downloaded by the test bots for execution. This will allow us to catch any breaks in the tools in the compile phase rather than the test phase. I plan to add this to build.webkit.org and will send a patch out for review. Please let me know if you have any interest or concerns in the implementation. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] (no subject)
http://www.tiochechito.com/wp-content/themes/classica/olfdvd.html?dhe=zam.dhegabmwwj=zafza.hzmbn=wmmv ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal to add 'compile-tools' step to the build bots
Sounds like a good idea to me. Many ports already build DumpRenderTree, etc. as part of build-webkit. (Gtk/Qt come to mind.) http://trac.webkit.org/browser/trunk/Tools/Scripts/build-dumprendertree#L74 On Tue, Jun 19, 2012 at 1:33 PM, Lucas Forschler lforsch...@apple.com wrote: Hello all, Currently our build bots have a compile-webkit step. This step does NOT build any of the tools used by the testers. Instead, the testers are building the tools at execution time. I would like to add a compile-tools step to run directly after the compile-webkit step. The tools components would be packaged up into the archive, and then downloaded by the test bots for execution. This will allow us to catch any breaks in the tools in the compile phase rather than the test phase. I plan to add this to build.webkit.org and will send a patch out for review. Please let me know if you have any interest or concerns in the implementation. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal to add 'compile-tools' step to the build bots
Hi, The idea is good, we should catching build errors as soon as possible. But why don't you make the Apple's part of build-webkit to build DRT/WTR/ImageDiff/testbrowser/... too? I checked the bot logs and it seems that all port (Qt,GTK,Chromium,EFL) except Apple ports build everything in the compile-webkit step. As far as I remember, the tools components build separately, because only developers (who would like to run tests) and buildbots need DRT and friends. What if adding --developer-build / --build-tools / ... or any similar option to build-webkit instead of master.cfg hacking? br, Ossy Eric Seidel írta: Sounds like a good idea to me. Many ports already build DumpRenderTree, etc. as part of build-webkit. (Gtk/Qt come to mind.) http://trac.webkit.org/browser/trunk/Tools/Scripts/build-dumprendertree#L74 On Tue, Jun 19, 2012 at 1:33 PM, Lucas Forschler lforsch...@apple.com wrote: Hello all, Currently our build bots have a compile-webkit step. This step does NOT build any of the tools used by the testers. Instead, the testers are building the tools at execution time. I would like to add a compile-tools step to run directly after the compile-webkit step. The tools components would be packaged up into the archive, and then downloaded by the test bots for execution. This will allow us to catch any breaks in the tools in the compile phase rather than the test phase. I plan to add this to build.webkit.org and will send a patch out for review. Please let me know if you have any interest or concerns in the implementation. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] new bugzilla keyword: 'NRWT'
Hi all, A new keyword 'NRWT' for new-run-webkit-tests-related issues has been added to bugzilla (thanks Eric!). I've updated all of the open bugs I have found that are NRWT-related, and will try to keep things up to date in the future, but if you felt like adding the keywords when filing new bugs (or have bugs that I missed that you felt like updating) that would be great. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal to add 'compile-tools' step to the build bots
On Tue, Jun 19, 2012 at 2:28 PM, Osztrogonac Csaba o...@inf.u-szeged.huwrote: The idea is good, we should catching build errors as soon as possible. But why don't you make the Apple's part of build-webkit to build DRT/WTR/ImageDiff/testbrowser/**... too? I checked the bot logs and it seems that all port (Qt,GTK,Chromium,EFL) except Apple ports build everything in the compile-webkit step. That sounds like a preferable solution. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal to add 'compile-tools' step to the build bots
Adding tools to build-webkit for apple is much easier. I'll work on that. Thanks for the feedback. Lucas On Jun 19, 2012, at 1:58 PM, Eric Seidel wrote: Sounds like a good idea to me. Many ports already build DumpRenderTree, etc. as part of build-webkit. (Gtk/Qt come to mind.) http://trac.webkit.org/browser/trunk/Tools/Scripts/build-dumprendertree#L74 On Tue, Jun 19, 2012 at 1:33 PM, Lucas Forschler lforsch...@apple.com wrote: Hello all, Currently our build bots have a compile-webkit step. This step does NOT build any of the tools used by the testers. Instead, the testers are building the tools at execution time. I would like to add a compile-tools step to run directly after the compile-webkit step. The tools components would be packaged up into the archive, and then downloaded by the test bots for execution. This will allow us to catch any breaks in the tools in the compile phase rather than the test phase. I plan to add this to build.webkit.org and will send a patch out for review. Please let me know if you have any interest or concerns in the implementation. Thanks, Lucas ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-efl] EFL Linux Debug Buildbot online
Hi efl folks, Great jobs !! Why don't we make EFL category for our build bots ? - http://build.webkit.org/ Cheers, Gyuyoung. 2012/4/13 Dominik Röttsches dominik.rottsc...@linux.intel.com Hi, I am happy to inform you that the EFL Debug Buildbot got online tonight (EEST). By now it has completed its maiden build 0 :-) http://build.webkit.org/builders/EFL%20Linux%20Debug There's some tuning to do in the next few days, but it already gives us useful information. Let's continue to work on getting the bots green. Regards, Dominik -- Dominik Röttsches dominik.rottsc...@linux.intel.com dominik.rottsc...@linux.intel.com Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 ___ webkit-efl mailing list webkit-...@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl -- - Gyuyoung ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Issue regarding Same Origin check with Blobs and XMLHttpRequest
[webkit-dev - bcc] What URL are you trying to load? The error message doesn't say. I wonder if you're trying to load a relative URL, which is trying to be resolved relative to the blob URL. It might work better with an absolute URL. Adam On Thu, May 10, 2012 at 1:32 AM, Vishal Shah vis...@sokrati.com wrote: Hello, I have implemented a web worker that handles XMLHttpRequest object for my application When I create a separate *.js file for the worker's script it works perfectly fine. However, when trying to instantiate the worker using a Blob, Chrome throws an error as follows: XMLHttpRequest cannot load . Cross origin requests are only supported for HTTP. The URL of the blob is blob:http%3A//localhost%3A8080/047cca65-b588-4077-a81d-84e772dde20d which when decoded is blob:http://localhost:8080/047cca65-b588-4077-a81d-84e772dde20d; And my application is also running at localhost:8080 I think somehow the same origin check is failing for the blob. Following is the code snippet I am trying to implement: var blobBuilder, blobBuilderClass, blobURL, urlClass, worker; blobBuilderClass = wObj.BlobBuilder || wObj.WebKitBlobBuilder || wObj.MozBlobBuilder; urlClass = wObj.URL || wObj.webkitURL; blobBuilder = new blobBuilderClass(); blobBuilder.append(workerFunction.toString() + ;\nworkerFunction();); blobURL = urlClass.createObjectURL(blobBuilder.getBlob()); worker = new Worker(blobURL); urlClass.revokeObjectURL(blobURL); Am I doing anything wrong here or is it a known bug in Chrome? Please suggest. References to any related article will be helpful. If this is not the correct list to be contacted, please suggest me the correct one. Thanks and Regards, Vishal Shah Sokrati Inc. ___ 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] SVG video chat (2)
That would be great, but please also provide different times. I am not available from 9 to 12 mostly. So I have to say no to all provided times. Before or after that is fine. Greetings, Dirk On Jun 7, 2012, at 9:48 AM, Philip Rogers wrote: Last month we had a video chat with the SVG team in WebKit and it was very well received. If there are other highly-coupled, highly-distributed sub-components of WebKit I would highly recommend setting one of these up. SVG, The last video chat went great and as a group we decided to do it again. If you'd like to join please add your name, availability, and topics you'd like to discuss to the spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdDQ3RUM0bzlGZUpENnAtTHh5aFJBU0E Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EFL Debug Buildbot Green
Wow, great !! EFL release bot will become green. Gyuyoung. On Fri, May 11, 2012 at 4:04 AM, Dirk Pranke dpra...@chromium.org wrote: +1 :). On Thu, May 10, 2012 at 12:01 PM, Ojan Vafai o...@chromium.org wrote: That's a great milestone. Congratulations! On Thu, May 10, 2012 at 8:43 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: Hi all, We're happy to share with you that yesterday the EFL Linux Debug Buildbot has turned green for the first time. http://build.webkit.org/builders/EFL%20Linux%20Debug This has been an example of a great team effort [1]. We'd like to thank the friendly reviewers and committers who helped us for their support! We'll keep a close eye on our buildbot lamp http://goo.gl/ei1gL from now and set up a gardening schedule to keep it green and tidy in the future. Dominik [1] http://wkb.ug/85601 -- Dominik Röttsches dominik.rottsc...@intel.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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- - Gyuyoung ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SVG video chat (2)
Last month we had a video chat with the SVG team in WebKit and it was very well received. If there are other highly-coupled, highly-distributed sub-components of WebKit I would highly recommend setting one of these up. SVG, The last video chat went great and as a group we decided to do it again. If you'd like to join please add your name, availability, and topics you'd like to discuss to the spreadsheet: * https://docs.google.com/spreadsheet/ccc?key=0AorN2u5hCJiUdDQ3RUM0bzlGZUpENnAtTHh5aFJBU0E * Thanks, Philip ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] How to access the page group settings from WorkerContext
Hi, webkit-dev, I am trying to make indexedDB working for JSC. One of the problems I am now having is to access the page group settings from the WorkerContext to get the indexedDataBasePath to store the database. Anybody can help and suggest the best way to access the page GroupSettings from the WorkerContext, especially from the SharedWorkerContext? Thanks --Charles From My BlackBerry - 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] How to access page GroupSettings from WorkerThread
Hi, Webkit-dev, I am working on JSC binding for IndexedDB. One problem I am facing now is to access the page groupsettings from the WorkerContext(especially the SharedWorkerContext) for IndexedDB file path settings to access the database when the indexeddb code runs in the workerthread. Anybody can guide me what's the best way to do this: access the page groupsettings from a workcontext? Thanks --Charles From My BlackBerry - 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
Re: [webkit-dev] How to access page GroupSettings from WorkerThread
A few possibilities, in order of increasing complexity and work 1. If it can't change, you could pass it in when the worker is created. 2. If it can change, you do a postMessage to the main thread to get the value. 3. If you can't get the value in an async manner, perhaps you can make a method to allow thread safe access. On Wed, Jun 13, 2012 at 6:42 PM, Charles Wei charles@torchmobile.com.cn wrote: Hi, Webkit-dev, I am working on JSC binding for IndexedDB. One problem I am facing now is to access the page groupsettings from the WorkerContext(especially the SharedWorkerContext) for IndexedDB file path settings to access the database when the indexeddb code runs in the workerthread. Anybody can guide me what's the best way to do this: access the page groupsettings from a workcontext? Thanks --Charles From My BlackBerry - 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] malloc(0)
http://sourceforge.net/mailarchive/message.php?msg_id=29406824 http://bugs.icu-project.org/trac/ticket/9396 There was a fair amount of activity on my WebKit patch (thanks everyone!) ( https://bugs.webkit.org/show_bug.cgi?id=88936) but it seems to have stopped. Did I do something wrong? Thanks, Myles On Wed, Jun 13, 2012 at 3:53 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I started a thread on icu-design (mailing list) about it. As soon as it appears in the archives, I'll post a permalink to the thread. The null pointer check shouldn't matter - if the pointer isn't null, then it's valid anyway :-) --Myles On Wed, Jun 13, 2012 at 3:37 PM, Benjamin Poulain benja...@webkit.orgwrote: On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler da...@apple.com wrote: There is still the question of if I can upstream this to ICU, which I'm checking on. I was not proposing changing ICU. I did. In addition to changing WebKit, not using the pointer when the length is zero does not necessarily seem like a bad idea to me. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
