Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)
On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak m...@apple.com wrote: The main problem would be getting the right path to the script file. Unless we duplicate it in every directory with script tests, it kinda has to be a relative path that depends on the directory. Subversion (and git) handle relative symbolic links just fine, so that is another option. Dave -- Sent from my iPhone 4 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)
I think symlinks would be an excellent option, assuming Git and SVN have some solution for win32. On Tue, Jul 27, 2010 at 11:50 AM, David Kilzer ddkil...@webkit.org wrote: On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak m...@apple.com wrote: The main problem would be getting the right path to the script file. Unless we duplicate it in every directory with script tests, it kinda has to be a relative path that depends on the directory. Subversion (and git) handle relative symbolic links just fine, so that is another option. Dave -- Sent from my iPhone 4 ___ 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] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)
git help config says: core.symlinks If false, symbolic links are checked out as small plain files that contain the link text. git-update-index(1) and git-add(1) will not change the recorded type to regular file. Useful on filesystems like FAT that do not support symbolic links. The default is true, except git-clone(1) or git-init(1) will probe and set core.symlinks false if appropriate when the repository is created. My vague recollection is that NTFS has a sort of symlink-like thing but that they have the tendency to break stuff (e.g. virus scanners get confused). On Tue, Jul 27, 2010 at 12:40 PM, Eric Seidel e...@webkit.org wrote: I think symlinks would be an excellent option, assuming Git and SVN have some solution for win32. On Tue, Jul 27, 2010 at 11:50 AM, David Kilzer ddkil...@webkit.org wrote: On Jul 26, 2010, at 6:08 PM, Maciej Stachowiak m...@apple.com wrote: The main problem would be getting the right path to the script file. Unless we duplicate it in every directory with script tests, it kinda has to be a relative path that depends on the directory. Subversion (and git) handle relative symbolic links just fine, so that is another option. Dave -- Sent from my iPhone 4 ___ 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] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)
On Mon, Jul 26, 2010 at 8:22 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote: You can see many more examples of dom2string in the non-html5 results (where there are a zillion failure cases): http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt dom2string.js came from http://code.google.com/p/html5lib I thought, but I couldn't find the source for it there. I'm not wedded in any way to dom2string. But I do like the output it produces slightly more than the current dumpAsMarkup. I agree, standardization might be nice. dom2string uses for #text and /#text. newlines return you to the start of the line as you would expect. (see the runner-expected.txt above). -eric p.s. Would be nice if we could just inject certain javascript into every page. Sorta like how v8 allows you to define engine-level functions in javascript. Would be nice to just make dumpAsMarkup() part of DRT, but write it in javascript. :) That's easy to do, DRT could just force loading of the JS file that implements dumpAsMarkup() (or whatever we end up calling it). But I'm not sure that is better than including a JS file in the test explicitly. For one thing, most of the logic to dumpAsMarkup() (other than forcing a text dump) should work in any other browser, so it would make it easier to try our tests in other browsers if the JS code implementing it is included explicitly instead of magically. It would also make the tests more useful to try in a WebKit-based browser like Safari or Chrome, for that matter - you wouldn't need DRT to see the output. Hmmm True. This reminds me of my previous thoughts of making DRT's controllers entirely a NPAPI plugin. (Might make it possible to run DRT-like tests in Safari or chrome renderers easier, and opens the door for possible x-browser testing using expanded javascript APIs.) But that also has the same trouble of DRT being too smart where explicit HTML is easier to run x-browser. The idea behind auto-injecting JS appeals to me more for making script-tests easier. Then again it should be possible to re-write our script-test support so that this is all you need to write: script src=script-tests.js/script script description(foo); shouldBe(foo, bar); /script script src=end-script-test.js/script Instead of the current (cumbersome) templating system. Should be possible to even get rid of the final end-script-test.js tag if we're smart. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)
Then again it should be possible to re-write our script-test support so that this is all you need to write: script src=script-tests.js/script script description(foo); shouldBe(foo, bar); /script script src=end-script-test.js/script Instead of the current (cumbersome) templating system. Should be possible to even get rid of the final end-script-test.js tag if we're smart. Yes! The templating system is just too much overhead, not to mention that it creates too many files. There's a few minor issues with the above though: 1. What if you want to include multiple js files? For example, then editing/selection tests include two JS files. Maybe we should just move all our JS code into one file? 2. The src will need to be relative, so you'll need some ../.. action. But that seems OK to me. Unless we had a script that put the JS files in every directory (or maybe in the resources subdirectory of every directory). Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)
On Jul 26, 2010, at 5:46 PM, Ojan Vafai wrote: Then again it should be possible to re-write our script-test support so that this is all you need to write: script src=script-tests.js/script script description(foo); shouldBe(foo, bar); /script script src=end-script-test.js/script Instead of the current (cumbersome) templating system. Should be possible to even get rid of the final end-script-test.js tag if we're smart. Yes! The templating system is just too much overhead, not to mention that it creates too many files. There's a few minor issues with the above though: 1. What if you want to include multiple js files? For example, then editing/selection tests include two JS files. Maybe we should just move all our JS code into one file? 2. The src will need to be relative, so you'll need some ../.. action. But that seems OK to me. Unless we had a script that put the JS files in every directory (or maybe in the resources subdirectory of every directory). The template in fast/js is currently this: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN html head link rel=stylesheet href=resources/js-test-style.css script src=resources/js-test-pre.js/script /head body p id=description/p div id=console/div script src=YOUR_JS_FILE_HERE/script script src=resources/js-test-post.js/script /body /html We could reduce it to this by having the test script document.write the skeleton content and the stylesheet (as an inline style to avoid having to guess a path), and by using the load event for the post-test script: !DOCTYPE html script src=resources/js-test-pre.js/script script src=YOUR_JS_FILE_HERE/script You don't want to drop the doctype because that would put the test in quirks mode (probably not desired for most tests). This is simple enough to hand-author, and you could use an inline script for the script, and also add other custom content to the DOM if desired. The main problem would be getting the right path to the script file. Unless we duplicate it in every directory with script tests, it kinda has to be a relative path that depends on the directory. For pure JS tests (mostly ones in fast/js), I think it's a good idea to keep the script file separate so we can keep open the possibility of running these tests in a command-line JS shell and not just in a full web engine. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
