Re: [webkit-dev] Should we put the webkit.org mailing lists on Gmane?
On Dec 14, 2009, at 10:09 PM, David Kilzer wrote: On Mon, December 14, 2009 at 6:47:50 PM, Adam Roben wrote: On Jun 13, 2009, at 9:00 AM, Adam Roben wrote: I think it would be good to put our mailing lists on Gmane (including importing the archives of the lists). The lists are now all on Gmane. Archives for the newer lists have not been imported, but Gmane already has data going back to July 2009. The newsgroups all fall under the gmane.os.opendarwin.webkit prefix, to match the already-existing gmane.os.opendarwin.webkit.devel group. The group names (and their equivalent lists.webkit.org lists) are: gmane.os.opendarwin.webkit. devel (webkit-dev) gtk (webkit-gtk) jobs (webkit-jobs) qt (webkit-qt) user (webkit-help) (user was chosen by the Gmane administrators, presumably to match other projects' groups.) Can we drop the os.opendarwin part? The project formerly known as opendarwin is mostly (http://www.opendarwin.org/) dead. I think gmane.org.webkit would be better. In my original proposal to this list [1] and in my subscription request to Gmane, I suggested that the lists be prefixed with gmane.comp.web.webkit., to match other similar projects. But I was told that Gmane groups cannot be renamed, so it seemed best to give all the lists the same (outdated) prefix. -Adam 1. http://thread.gmane.org/gmane.os.opendarwin.webkit.devel/8252/focus=8501 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JIT on Windows CE
Hi İsmail, I’ve tried to get JIT working a couple of times on our wince build but with limited success. There’s some strangeness going on with the crossover of arguments from the wince compiler toolchain through to the JIT code (probably with the stack frame or something like that). My debug builds seem to run more reliably (it does crash as well eventually) but as soon as I try this same thing on a release build it blows up pretty quickly in the JITted code; the crashes are rather non-deterministic. I’m suspicious that ctiTrampoline needs some modifications that I haven’t been able to determine for it to work reliably on wince. Jason. From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Ismail Dönmez Sent: Friday, December 11, 2009 12:28 AM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] JIT on Windows CE Hi all; I wonder if anyone is working on JIT support for Windows CE. I know the platform has lots of limitations but still I guess someone might be interested on running JIT. Regards, i.d. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). How does 'reparentling' work in the absence of the use-case i mentioned? When the current parent removes the iframe from its DOM, does unload not get fired, do pending xhr's, and do timers continue run such that they survive after being added to a new parent's DOM how's that work in the magic iframe scheme? -Darin On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman micha...@google.comwrote: How does reparenting across in-place frame navigations work in this scheme? Is a de-parented iframe guaranteed to linger long enough for the new page to get it by name and re-parent it if desired? On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov dim...@chromium.org wrote: Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ 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] SharedScript: next steps and result of offline discussion.
On Tue, Dec 15, 2009 at 11:09 AM, Michael Nordman micha...@google.comwrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). How does 'reparentling' work in the absence of the use-case i mentioned? When the current parent removes the iframe from its DOM, does unload not get fired, do pending xhr's, and do timers continue run such that they survive after being added to a new parent's DOM how's that work in the magic iframe scheme? One idea was to leverage adoptNode to make it clear that parenting is being exchanged. -Darin -Darin On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman micha...@google.comwrote: How does reparenting across in-place frame navigations work in this scheme? Is a de-parented iframe guaranteed to linger long enough for the new page to get it by name and re-parent it if desired? On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov dim...@chromium.orgwrote: Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ 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] SharedScript: next steps and result of offline discussion.
On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] QtConnectionObjects not cleaned up for QtOwnership objects
For all the Qt people out there, here is my problem:
We have quite a few QObjects that we are inserting into JavaScript
using addToJavaScriptWindowObject, however because we have limited
resources and are creating so many of these objects, we would prefer
that they are NOT ScriptOwnership objects so that there is not as much
duplication for each frame. This presents a problem when it comes to
using 'connect' to handle signals. Each connect creates a
QtConnectionObject which references the JSHTMLDocument object. The
QtConnectionObject is never destroyed because the QObject is never
destroyed, and this prevents most of the objects from being cleaned up
by the gc when the page is refreshed leading to a significant memory
leak.
The solution I'm working on essentially makes the QtConnectionObject
'script owned' so that it is cleaned up when the script is destroyed:
Index: qt_runtime.cpp
===
--- qt_runtime.cpp (revision 52150)
+++ qt_runtime.cpp (working copy)
@@ -1527,6 +1527,11 @@
else {
// Store connection
connections.insert(sender, conn);
+// also create a script wrapper for the
connection object, but make sure that it is destroyed when
+// the script goes away
+d-m_instance-rootObject()-gcProtect(
+ QtInstance::getQtInstance(conn,
d-m_instance-rootObject(), QScriptEngine::ScriptOwnership)-
+
createRuntimeObject(exec-dynamicGlobalObject()-globalExec()));
}
} else {
// Now to find our previous connection object. Hmm.
This seems to be working in my limited tests. Can anyone comment on
the validity of this solution?
Thanks,
Andrew
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sunspider 0.9.1 preview
[+cc John Resig since he's using this as part of dromaeo] Overall, sounds like good progress. A couple of ideas: - can we make it so that if you try to cut-and-paste comparisons of 0.9 to 0.9.1 results, it will say these results are from a different version? - can we make the version more prominent in the title? - what would you think of reducing the setTimeout(..., 500) to something like setTimeout(..., 100)? This will cut the runtime of the test by ~80% :-) I'll volunteer to do any of these tasks this week if you want me to look at it. Mike On Mon, Dec 14, 2009 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote: Hello folks, Over the past few days I made some changes to SunSpider to address some of the more serious issues reported. I focused on only changes that seem to make a significant difference to fairness and validity, so for example I did not remove accidental access to global variables. I also made a small number of harness changes that do not affect results but fix flaws in the harness. We are hesitant to change the SunSpider content or harness much at all, since it's been used for cross-version and cross-brwoser comparisons for so long. But these problems (many originally suggpointed out by Chrome or Mozilla folks) seemed important enough to address. Also, in addition to the patched content set, the original sunspider-0.9 content set is also available to run through the new harness. The most important harness change is greatly reducing the time between tests (as sugested by Mike Belshe) to avoid the negative impact of power management on many systems (both Mac and Windows), and which are most apparent for very fast browsers. I'm deliberately not posting this on the web site yet because I don't want a flood of gawkers testing their browser before enough people have had a chance to review and verify these changes. Harness changes: In-browser SunSpider suffers excessive penalty under power management https://bugs.webkit.org/show_bug.cgi?id=32505 Enable Web-hosted version of SunSpider to handle multiple versions https://bugs.webkit.org/show_bug.cgi?id=32478 Use JSON.parse instead of eval for Web-hosted SunSpider results processing https://bugs.webkit.org/show_bug.cgi?id=32490 Some Browser-hosted SunSpider files are not valid HTML5 https://bugs.webkit.org/show_bug.cgi?id=32536 Make sunspider-0.9.1 the default content set (both command-line and hosted) https://bugs.webkit.org/show_bug.cgi?id=32537 Content changes (in sunspider-0.9.1 suite only; sunspider-0.9 is as originally posted): SunSpider/tests/string-base64.js does not compute a valid base64 encoded string https://bugs.webkit.org/show_bug.cgi?id=16806 sunspider regexp-dna is inaccurate on firefox https://bugs.webkit.org/show_bug.cgi?id=18989 Further changes I'm considering but am unsure about: - Add correctness checking to all tests that don't use random numbers. - Stop using array-like indexing of strings in the base64 test since that doesn't work in IE8 and lower; but it is a standard construct now (ES5), future IE will support it, and it's a useful thing to test. Changes that probably won't be considered until a 2.0 version: - Adding new tests to cover other areas. - Rebalancing the runtime of the existing tests. - Considering different scoring methodology such as bigger-is-better or geometric mean or the like. - Removing use of random numbers from tests that do use them. 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] SharedScript: next steps and result of offline discussion.
Saving a subsite of live script and DOM objects across a full page load does not seem useful to me Lots of sites use actual frame navigations to navigate. On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. This assumes that pages are heavy I believe. The use case was about having most of the load in the shared object and pages being light UI 'frames'. This would allow to use regular URLs and history management of the browser directly. Moving most of the code and parking DOM (like editor chrome) in a shared object could enable very lightweight pages. It sounds a bit theoretical now but the hope was that it brings interesting way of building apps in a way which could be better and perhaps simpler then building heavy non-navigatable ajax pages that have to generate content and use onbeforeunload to warn user that moving away is a bad idea :-) Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedScript: next steps and result of offline discussion.
On Dec 15, 2009, at 12:38 PM, Dmitry Titov wrote: On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. This assumes that pages are heavy I believe. The use case was about having most of the load in the shared object and pages being light UI 'frames'. This would allow to use regular URLs and history management of the browser directly. Moving most of the code and parking DOM (like editor chrome) in a shared object could enable very lightweight pages. Regardless of how light the page is, a page transition is likely to be much more disruptive to user flow, particularly if the new page has to be loaded over the network and the operation takes a long time. It sounds a bit theoretical now but the hope was that it brings interesting way of building apps in a way which could be better and perhaps simpler then building heavy non-navigatable ajax pages that have to generate content and use onbeforeunload to warn user that moving away is a bad idea :-) I think you bundled up a lot of concepts in there that are not intrinsically tied together. You can have a page self-load new markup as HTML, insert it into itself, and update the URL and history entries with pushState, without having to do a full page load. Having no page load and replacing only the things you want to change seems better to me than having a full page load but somehow trying to save code and data across it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] QtConnectionObjects not cleaned up for QtOwnership objects
This should go to the webkit...@lists.webkit.org list instead. Please repost
there.
Creating a bug report on bugs.webkit.org for tracking your issues is another
welcome option.
Kenneth
On Tue, Dec 15, 2009 at 5:24 PM, Andrew Webster apwebs...@gmail.com wrote:
For all the Qt people out there, here is my problem:
We have quite a few QObjects that we are inserting into JavaScript
using addToJavaScriptWindowObject, however because we have limited
resources and are creating so many of these objects, we would prefer
that they are NOT ScriptOwnership objects so that there is not as much
duplication for each frame. This presents a problem when it comes to
using 'connect' to handle signals. Each connect creates a
QtConnectionObject which references the JSHTMLDocument object. The
QtConnectionObject is never destroyed because the QObject is never
destroyed, and this prevents most of the objects from being cleaned up
by the gc when the page is refreshed leading to a significant memory
leak.
The solution I'm working on essentially makes the QtConnectionObject
'script owned' so that it is cleaned up when the script is destroyed:
Index: qt_runtime.cpp
===
--- qt_runtime.cpp (revision 52150)
+++ qt_runtime.cpp (working copy)
@@ -1527,6 +1527,11 @@
else {
// Store connection
connections.insert(sender, conn);
+// also create a script wrapper for the
connection object, but make sure that it is destroyed when
+// the script goes away
+d-m_instance-rootObject()-gcProtect(
+ QtInstance::getQtInstance(conn,
d-m_instance-rootObject(), QScriptEngine::ScriptOwnership)-
+
createRuntimeObject(exec-dynamicGlobalObject()-globalExec()));
}
} else {
// Now to find our previous connection object. Hmm.
This seems to be working in my limited tests. Can anyone comment on
the validity of this solution?
Thanks,
Andrew
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sunspider 0.9.1 preview
On Tue, Dec 15, 2009 at 1:01 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 12:30 PM, Mike Belshe wrote: [+cc John Resig since he's using this as part of dromaeo] Overall, sounds like good progress. A couple of ideas: - can we make it so that if you try to cut-and-paste comparisons of 0.9 to 0.9.1 results, it will say these results are from a different version? Good idea. Filed https://bugs.webkit.org/show_bug.cgi?id=32573 - can we make the version more prominent in the title? I'll see if I can find a reasonable way to do so. https://bugs.webkit.org/show_bug.cgi?id=32574 - what would you think of reducing the setTimeout(..., 500) to something like setTimeout(..., 100)? This will cut the runtime of the test by ~80% :-) I don't know if you noticed in my comments below, but the gap between individual tests is now 10ms, there is only a one-time initial delay of 500ms to give browsers a chance to recover from the effects of loading the driver page. Ok - I had checked the code, saw the 500ms setTimeout there, and then griped :-) This sounds great! Or are you talking about the initial 500ms delay? On my MacBook Pro, in 64-bit Safari, each run of the test takes 370ms measured time, plus 260ms for the gaps between tests, and there are a total of 5 cycles. So actual test time is 3780. So reducing the initial pause from 500ms to 100ms would be a 10% improvement on total runtime of the benchmark. I don't think that would be a meaningful difference. But I can look at whether this number can be reduced without distorting the results. Agree - I don't care about that. thanks, Mike I'll volunteer to do any of these tasks this week if you want me to look at it. In general help is welcome, but I think I can take care of the two bugs cited above. Regards, Maciej Mike On Mon, Dec 14, 2009 at 11:32 PM, Maciej Stachowiak m...@apple.com wrote: Hello folks, Over the past few days I made some changes to SunSpider to address some of the more serious issues reported. I focused on only changes that seem to make a significant difference to fairness and validity, so for example I did not remove accidental access to global variables. I also made a small number of harness changes that do not affect results but fix flaws in the harness. We are hesitant to change the SunSpider content or harness much at all, since it's been used for cross-version and cross-brwoser comparisons for so long. But these problems (many originally suggpointed out by Chrome or Mozilla folks) seemed important enough to address. Also, in addition to the patched content set, the original sunspider-0.9 content set is also available to run through the new harness. The most important harness change is greatly reducing the time between tests (as sugested by Mike Belshe) to avoid the negative impact of power management on many systems (both Mac and Windows), and which are most apparent for very fast browsers. I'm deliberately not posting this on the web site yet because I don't want a flood of gawkers testing their browser before enough people have had a chance to review and verify these changes. Harness changes: In-browser SunSpider suffers excessive penalty under power management https://bugs.webkit.org/show_bug.cgi?id=32505 Enable Web-hosted version of SunSpider to handle multiple versions https://bugs.webkit.org/show_bug.cgi?id=32478 Use JSON.parse instead of eval for Web-hosted SunSpider results processing https://bugs.webkit.org/show_bug.cgi?id=32490 Some Browser-hosted SunSpider files are not valid HTML5 https://bugs.webkit.org/show_bug.cgi?id=32536 Make sunspider-0.9.1 the default content set (both command-line and hosted) https://bugs.webkit.org/show_bug.cgi?id=32537 Content changes (in sunspider-0.9.1 suite only; sunspider-0.9 is as originally posted): SunSpider/tests/string-base64.js does not compute a valid base64 encoded string https://bugs.webkit.org/show_bug.cgi?id=16806 sunspider regexp-dna is inaccurate on firefox https://bugs.webkit.org/show_bug.cgi?id=18989 Further changes I'm considering but am unsure about: - Add correctness checking to all tests that don't use random numbers. - Stop using array-like indexing of strings in the base64 test since that doesn't work in IE8 and lower; but it is a standard construct now (ES5), future IE will support it, and it's a useful thing to test. Changes that probably won't be considered until a 2.0 version: - Adding new tests to cover other areas. - Rebalancing the runtime of the existing tests. - Considering different scoring methodology such as bigger-is-better or geometric mean or the like. - Removing use of random numbers from tests that do use them. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sunspider 0.9.1 preview
On Dec 15, 2009, at 1:01 PM, Maciej Stachowiak wrote: On Dec 15, 2009, at 12:30 PM, Mike Belshe wrote: A couple of ideas: - can we make it so that if you try to cut-and-paste comparisons of 0.9 to 0.9.1 results, it will say these results are from a different version? Good idea. Filed https://bugs.webkit.org/show_bug.cgi?id=32573 - can we make the version more prominent in the title? I'll see if I can find a reasonable way to do so. https://bugs.webkit.org/show_bug.cgi?id=32574 Both now done. By the way, if anyone wants to try the new version in advance of it going up on webkit.org, you can run ./make-hosted in the SunSpider directory and open hosted/sunspider.html to get started. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Sunspider 0.9.1 preview
On Dec 15, 2009, at 3:07 PM, Mike Belshe wrote: On Tue, Dec 15, 2009 at 1:01 PM, Maciej Stachowiak m...@apple.com wrote: - what would you think of reducing the setTimeout(..., 500) to something like setTimeout(..., 100)? This will cut the runtime of the test by ~80% :-) I don't know if you noticed in my comments below, but the gap between individual tests is now 10ms, there is only a one-time initial delay of 500ms to give browsers a chance to recover from the effects of loading the driver page. Ok - I had checked the code, saw the 500ms setTimeout there, and then griped :-) This sounds great! OK cool. The 10ms between tests was necessary to address https://bugs.webkit.org/show_bug.cgi?id=32505 . It does increase variance a bit, but it's the only way to get rid of the severe distortion from CPU stepping on modern Mac and Windows systems. The new results should be much closer to what you get running the command-line version. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
