Re: [webkit-dev] Optional parameter in IDL and undefined JS value
One other way is to write custom binding code to handle this case specially. On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak wrote: > > On Apr 21, 2011, at 6:29 PM, Jian Li wrote: > > I've pinged the spec author to make it clear in the spec. What is meant in > the spec is really that we want Blob.slice to have the same exact behavior > as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, > Blob.slice(start) has the same result as Blob.slice(start, undefined). > > The current code generator scripts will convert undefined value to 0. But > we really want to use the custom default value for Blob.slice. Do we want to > consider adding "DefaultValue=" extended attribute support to IDL? > > > I'd prefer if we can find a way to solve it that does not require diverging > our IDL dialect further from Web IDL, especially since this is the only > method likely to need the feature. Are there any other practical solutions? > > Regards, > Maciej > > > Thanks, > > Jian > > > On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak wrote: > >> >> On Apr 21, 2011, at 12:14 AM, Jian Li wrote: >> >> > The current File API spec says that: >> > If the end parameter is not provided (undefined), let relativeEnd be >> size. >> >> That seems like loose wording. Parameter not provided and parameter >> provided with a value of undefined are in general not the same thing. The >> spec should be explicit about which cases it's talking about. >> >> Regards, >> Maciej >> > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Apr 21, 2011, at 6:29 PM, Jian Li wrote: > I've pinged the spec author to make it clear in the spec. What is meant in > the spec is really that we want Blob.slice to have the same exact behavior as > Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) > has the same result as Blob.slice(start, undefined). > > The current code generator scripts will convert undefined value to 0. But we > really want to use the custom default value for Blob.slice. Do we want to > consider adding "DefaultValue=" extended attribute support to IDL? I'd prefer if we can find a way to solve it that does not require diverging our IDL dialect further from Web IDL, especially since this is the only method likely to need the feature. Are there any other practical solutions? Regards, Maciej > > Thanks, > > Jian > > > On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak wrote: > > On Apr 21, 2011, at 12:14 AM, Jian Li wrote: > > > The current File API spec says that: > > If the end parameter is not provided (undefined), let relativeEnd be > > size. > > That seems like loose wording. Parameter not provided and parameter provided > with a value of undefined are in general not the same thing. The spec should > be explicit about which cases it's talking about. > > Regards, > Maciej > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new-run-webkit-tests new results.html format
On Apr 21, 2011, at 4:47 PM, Ojan Vafai wrote: > Thanks for the quick feedback. > > On Thu, Apr 21, 2011 at 4:21 PM, Maciej Stachowiak wrote: > (1) Takes two lines per entry unless you make your window ridiculously wide. > This makes it hard to scan. > > I'll make it whitespace:nowrap. That will mean the right side might get cut > off, but I think that's fine. I'll take a look once there is a demo version. > > (2) Slow to load (apparently it loads a 3 meg JSON file before displaying > anything?) > > Loading it locally is very fast for me. I guess I should try it on a laptop > though. I'm on a laptop. On my home WiFi, it takes 5-15 seconds. This old-style results page takes less than 200ms, uncached: http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r84598%20(28450)/results.html > For context, we reuse the JSON file that's used for the test runtime > treemaps, which means we need an entry for each test. That json will will get > .5 meg smaller shortly. There are a number of approaches to make this smaller > if needed. Some options would be to generate a separate JSON file, or to make > the data format in the existing json file more compact. It seems to me that only data on unexpected failures should be needed for initial display. Making the page load fast seems more important than convenience of reusing an existing JSON file. I hope you will agree that 5-15 second load time is not acceptable. I'm sure it would be even worse in poor network conditions, where even the old-style pages can be a challenge to load. I would also like to be able to look at results pages on my iPhone or iPad without invoking the OOM killer. > > (3) I like PrettyPatch format better than wdiff format. > > This is orthogonal. new-run-webkit-tests will use whichever one is available > on the system. The results.html file will display whichever one was used. What would the bots display if this is deployed? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
I've pinged the spec author to make it clear in the spec. What is meant in the spec is really that we want Blob.slice to have the same exact behavior as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, Blob.slice(start) has the same result as Blob.slice(start, undefined). The current code generator scripts will convert undefined value to 0. But we really want to use the custom default value for Blob.slice. Do we want to consider adding "DefaultValue=" extended attribute support to IDL? Thanks, Jian On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak wrote: > > On Apr 21, 2011, at 12:14 AM, Jian Li wrote: > > > The current File API spec says that: > > If the end parameter is not provided (undefined), let relativeEnd be > size. > > That seems like loose wording. Parameter not provided and parameter > provided with a value of undefined are in general not the same thing. The > spec should be explicit about which cases it's talking about. > > Regards, > Maciej > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new-run-webkit-tests new results.html format
Thanks for the quick feedback. On Thu, Apr 21, 2011 at 4:21 PM, Maciej Stachowiak wrote: > (1) Takes two lines per entry unless you make your window ridiculously > wide. This makes it hard to scan. > I'll make it whitespace:nowrap. That will mean the right side might get cut off, but I think that's fine. > (2) Slow to load (apparently it loads a 3 meg JSON file before displaying > anything?) > Loading it locally is very fast for me. I guess I should try it on a laptop though. For context, we reuse the JSON file that's used for the test runtime treemaps, which means we need an entry for each test. That json will will get .5 meg smaller shortly. There are a number of approaches to make this smaller if needed. Some options would be to generate a separate JSON file, or to make the data format in the existing json file more compact. > (3) I like PrettyPatch format better than wdiff format. > This is orthogonal. new-run-webkit-tests will use whichever one is available on the system. The results.html file will display whichever one was used. > (4) Blue text on a blue background is not great for legibility. > I'll change the blue background to #eee. > (5) When running pixel tests, the animated image diffs are handy. > Oh right. I forgot about these. I'll think of something for this. > > (1) and (2) seem like the most serious regressions relative to ORWT. > > Regards, > Maciej > > > On Apr 21, 2011, at 2:11 PM, Ojan Vafai wrote: > > > http://build.chromium.org/f/chromium/layout_test_results/Webkit_Linux_64/results/layout-test-results/results.htmlshows > the latest run of Chromium's Linux 64 bot. > > Beware the expand all link with that many failures. It gets very slow. > > On Tue, Apr 19, 2011 at 2:36 PM, Eric Seidel wrote: > >> Would be nice to have a live demo to see all the new javascripty-ness. >> Do you have an example from a NRWT run on build.webkit.org or >> build.chromium.org? >> >> Thanks for all your work on this, Ojan. >> >> -eric >> >> On Tue, Apr 19, 2011 at 2:29 PM, Ojan Vafai wrote: >> > As of r84294, new-run-webkit-tests's results.html has a new format. >> > Non-chromium people, feel free to take a look and see if this addresses >> your >> > concerns in https://bugs.webkit.org/show_bug.cgi?id=37736. Chromium >> people, >> > if you encounter problems or have feature requests, please let me know >> or >> > file bugs. >> > >> > Some of the new features: >> > -View actual/expected results inline. >> > -View actual/expected/diff images at 3x zoom to better see what changed. >> > -Control showing expected failures with a checkbox instead of a >> commandline >> > flag to new-run-webkit-tests. >> > -Link to the httpd error logs. >> > -Show failure type and expected failure type. >> > Ojan >> > ___ >> > 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] new-run-webkit-tests new results.html format
Some concerns with this new format: (1) Takes two lines per entry unless you make your window ridiculously wide. This makes it hard to scan. (2) Slow to load (apparently it loads a 3 meg JSON file before displaying anything?) (3) I like PrettyPatch format better than wdiff format. (4) Blue text on a blue background is not great for legibility. (5) When running pixel tests, the animated image diffs are handy. (1) and (2) seem like the most serious regressions relative to ORWT. Regards, Maciej On Apr 21, 2011, at 2:11 PM, Ojan Vafai wrote: > http://build.chromium.org/f/chromium/layout_test_results/Webkit_Linux_64/results/layout-test-results/results.html > shows the latest run of Chromium's Linux 64 bot. > > Beware the expand all link with that many failures. It gets very slow. > > On Tue, Apr 19, 2011 at 2:36 PM, Eric Seidel wrote: > Would be nice to have a live demo to see all the new javascripty-ness. > Do you have an example from a NRWT run on build.webkit.org or > build.chromium.org? > > Thanks for all your work on this, Ojan. > > -eric > > On Tue, Apr 19, 2011 at 2:29 PM, Ojan Vafai wrote: > > As of r84294, new-run-webkit-tests's results.html has a new format. > > Non-chromium people, feel free to take a look and see if this addresses your > > concerns in https://bugs.webkit.org/show_bug.cgi?id=37736. Chromium people, > > if you encounter problems or have feature requests, please let me know or > > file bugs. > > > > Some of the new features: > > -View actual/expected results inline. > > -View actual/expected/diff images at 3x zoom to better see what changed. > > -Control showing expected failures with a checkbox instead of a commandline > > flag to new-run-webkit-tests. > > -Link to the httpd error logs. > > -Show failure type and expected failure type. > > Ojan > > ___ > > 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] Platform LayoutTests are out of control
On Thu, Apr 21, 2011 at 3:32 PM, David Levin wrote: > On Wed, Apr 20, 2011 at 11:35 PM, Brent Fulgham wrote: > >> > These got general support, but no one actively interested in going >> through our existing tests to see where they could be applied. Would you be >> interested in helping organize such an effort? :) >> >> Oh sure, Peter -- ruin my nice rant with the opportunity to DO something >> about it! >> >> I guess I've made my bed. I'll ping you off list for details or ideas. >> > > btw, if you or anyone else wants to work on this, I've attached a list > (based on what platform specific changes over the last 10k changes). This > is the number of times a result has been modified. (It counts a linux and a > mac change as two changes for that result.) > > I cut out everything below 20 changes. I'm also attaching my hacky script > in case anyone else want to modify it to measure things differently (or if > you want to double check what I did). > Looks like the vast majority of these are SVG, which need to be pixel tests. Perhaps some of these are good candidates for reftests though once run-webkit-tests support them. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] new-run-webkit-tests new results.html format
http://build.chromium.org/f/chromium/layout_test_results/Webkit_Linux_64/results/layout-test-results/results.htmlshows the latest run of Chromium's Linux 64 bot. Beware the expand all link with that many failures. It gets very slow. On Tue, Apr 19, 2011 at 2:36 PM, Eric Seidel wrote: > Would be nice to have a live demo to see all the new javascripty-ness. > Do you have an example from a NRWT run on build.webkit.org or > build.chromium.org? > > Thanks for all your work on this, Ojan. > > -eric > > On Tue, Apr 19, 2011 at 2:29 PM, Ojan Vafai wrote: > > As of r84294, new-run-webkit-tests's results.html has a new format. > > Non-chromium people, feel free to take a look and see if this addresses > your > > concerns in https://bugs.webkit.org/show_bug.cgi?id=37736. Chromium > people, > > if you encounter problems or have feature requests, please let me know or > > file bugs. > > > > Some of the new features: > > -View actual/expected results inline. > > -View actual/expected/diff images at 3x zoom to better see what changed. > > -Control showing expected failures with a checkbox instead of a > commandline > > flag to new-run-webkit-tests. > > -Link to the httpd error logs. > > -Show failure type and expected failure type. > > Ojan > > ___ > > 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] checksum files are no longer used by layout tests
I've just committed the change to run-webkit-tests (old and new) to have it ignore .checksum files and instead read image checksums from png files. This is why there were big checkouts during the last few days as I was updating the old .png files to have checksums embedded. I'll be doing a follow up commit that deletes all the existing .checksum files from the tree since they are no longer needed. This should involve no action on your part. run-webkit-tests (old and new) should no longer generate .checksum files for new tests or when using --reset-results. If you have a patch already created that includes a .checksum file, it's OK to commit it. run-webkit-tests will ignore the .checksum file and I will come by later and delete the .checksum file. As a reminder, if you need to actually see the checksum value, you can use Tools/Scripts/read-checksum-from-png. Let me know if you see any problems. tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Plans to fully merge the Android port
On Thu, Apr 21, 2011 at 9:14 AM, Ariya Hidayat wrote: >> I started to look into the state of the Android port/platform and the state >> in >> WebKit. It appears to me that the Android team at Google has decided to use >> the chromium tree as upstream (it might have changed with Android 3.0),... > > On a side note, Android 3.0 (Honeycomb) is actually the beginning of > Chromium as the base for the Android port. Check out > honeycomb(-release) branch in > http://android.git.kernel.org/?p=platform/external/webkit.git;a=summary > and it seems that it is using 9.0.597 for the base. > > Remains to be seen whether Android 2.4 (Ice Cream) uses the same > strategy or just follows the previous 2.3. I can't speak to any future plans for the Android port, but I can offer the following information from the revision history. About 6 months ago, I tried to remove the Android build system in Bug 48111. At the time, Steve Block wrote: 8< Android WebKit is pretty forked from upstream, but we do take regular merges. These build files are pretty well maintained by people adding or removing source files upstream and these changes do help us in performing our merges. [...] I can send a patch to reinstate these files and to bring them up to date. We'll also make more of an effort to keep them as up to date as possible, given our current state of forking. >8 Since then, WebCore/Android.mk has been modified 81 times, but only once by someone who I recognized as being associated with the Android port. WebCore/platform/android has been modified a total of 23 times, of which 4 patches where written by someone I recognize as being associated with the Android port (most recently 5 months ago). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Plans to fully merge the Android port
> I started to look into the state of the Android port/platform and the state in > WebKit. It appears to me that the Android team at Google has decided to use > the chromium tree as upstream (it might have changed with Android 3.0),... On a side note, Android 3.0 (Honeycomb) is actually the beginning of Chromium as the base for the Android port. Check out honeycomb(-release) branch in http://android.git.kernel.org/?p=platform/external/webkit.git;a=summary and it seems that it is using 9.0.597 for the base. Remains to be seen whether Android 2.4 (Ice Cream) uses the same strategy or just follows the previous 2.3. -- Ariya Hidayat http://www.linkedin.com/in/ariyahidayat ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Plans to fully merge the Android port
Hi all, I started to look into the state of the Android port/platform and the state in WebKit. It appears to me that the Android team at Google has decided to use the chromium tree as upstream (it might have changed with Android 3.0), it appears to me that there are still things not merged to the WebKit tree, that the LayoutTests were not updated in eight month, that the git repository published by the Android team does not even include the LayoutTests. Is there any plan to fully merge the code, have updated LayoutTests and build-webkit integration? regards holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform LayoutTests are out of control
On Apr 21, 2011, at 2:41 AM, Brent Fulgham wrote: > I think it's just been especially bad the last few days. I believe this is because Tony Chang has been working on converting existing pixel results to have embedded checksums, rather than out-of-line .checksum files. This is a one-time conversion, and when it's completed it should reduce the total number of files (though not file size) considerably. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Apr 21, 2011, at 12:14 AM, Jian Li wrote: > The current File API spec says that: > If the end parameter is not provided (undefined), let relativeEnd be size. That seems like loose wording. Parameter not provided and parameter provided with a value of undefined are in general not the same thing. The spec should be explicit about which cases it's talking about. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
It seems that we're doing the right thing for Array.slice in WebKit in order to be consistent with ECMAScript 5, 15.4.4.10. Since Blob.slice in File API is following the same route, we probably want to fix the handling in Blob.slice and keep other DOM methods as they're now. On Thu, Apr 21, 2011 at 12:14 AM, Jian Li wrote: > The current File API spec says that: > If the end parameter is not provided (undefined), let relativeEnd be > size. > This seems to indicate that passing undefined as end parameter is same as > omitting it. Per the latest discussion on public-webapps, we're in the > process of making it be more like Array.slice. I will also ping the spec > author about this issue. > > Unfortunately we have inconsistency between Array.slice and other DOM > methods, in terms of handling undefined parameter value in WebKit. We also > have inconsistency among different browser vendors for interpreting > Array.slice(start, undefined). > > > On Wed, Apr 20, 2011 at 11:17 PM, Cameron McCormack wrote: > >> Jian Li: >> > > I am referring to Blob.slice(start, end) that mimics Array.slice. >> Where in >> > > WebIDL has this behavior defined? Sorry I can't find it in the spec. >> > > >> > > For Array.slice(start, end), both Safari and Chrome treat passing >> undefined >> > > as omitted parameter, while Firefox and IE treat passing undefined as >> 0. >> >> Ryosuke Niwa: >> > Doesn't that mean the current behavior (i.e. treating undefined as 0) is >> > correct since that's what other browsers do? >> >> The File API spec currently says: >> >> Blob slice(in optional long long start, >> in optional long long end, >> in optional DOMString contentType); >> >> and Web IDL says that if you call >> >> blob.slice(10, undefined); >> >> then this is calling the function with two arguments, where the second >> argument will be converted to 0 due to how the conversion of JS >> undefined to an IDL long long value is defined. This is not the same as >> calling >> >> blob.slice(10); >> >> Whenever some optional arguments are omitted, the prose for the >> definition of the operation defines what that means; it’s not >> automatically “convert from undefined”. >> >> There is no way in Web IDL to state that when undefined is passed as an >> argument explicitly that it is handled differently from the rules in >> http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the >> authors of the File API spec could include this additional requirement >> in prose, overriding Web IDL, if they wanted). >> >> -- >> Cameron McCormack ≝ http://mcc.id.au/ >> > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
The current File API spec says that: If the end parameter is not provided (undefined), let relativeEnd be size. This seems to indicate that passing undefined as end parameter is same as omitting it. Per the latest discussion on public-webapps, we're in the process of making it be more like Array.slice. I will also ping the spec author about this issue. Unfortunately we have inconsistency between Array.slice and other DOM methods, in terms of handling undefined parameter value in WebKit. We also have inconsistency among different browser vendors for interpreting Array.slice(start, undefined). On Wed, Apr 20, 2011 at 11:17 PM, Cameron McCormack wrote: > Jian Li: > > > I am referring to Blob.slice(start, end) that mimics Array.slice. Where > in > > > WebIDL has this behavior defined? Sorry I can't find it in the spec. > > > > > > For Array.slice(start, end), both Safari and Chrome treat passing > undefined > > > as omitted parameter, while Firefox and IE treat passing undefined as > 0. > > Ryosuke Niwa: > > Doesn't that mean the current behavior (i.e. treating undefined as 0) is > > correct since that's what other browsers do? > > The File API spec currently says: > > Blob slice(in optional long long start, > in optional long long end, > in optional DOMString contentType); > > and Web IDL says that if you call > > blob.slice(10, undefined); > > then this is calling the function with two arguments, where the second > argument will be converted to 0 due to how the conversion of JS > undefined to an IDL long long value is defined. This is not the same as > calling > > blob.slice(10); > > Whenever some optional arguments are omitted, the prose for the > definition of the operation defines what that means; it’s not > automatically “convert from undefined”. > > There is no way in Web IDL to state that when undefined is passed as an > argument explicitly that it is handled differently from the rules in > http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the > authors of the File API spec could include this additional requirement > in prose, overriding Web IDL, if they wanted). > > -- > Cameron McCormack ≝ http://mcc.id.au/ > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
