W3C home > Mailing lists > Public > www-dom-ts@w3.org > August 2001

Re: [Action Items] Top priority (Revision period, ECMA transform, Harness, Packaging)

From: Curt Arnold <carnold@houston.rr.com>
Date: Wed, 22 Aug 2001 15:58:55 -0500
Message-ID: <00c601c12b4d$420451a0$a800a8c0@CurtMicron>
To: "Jason Brittsan" <jasonbri@microsoft.com>
Cc: <www-dom-ts@w3.org>
I have been primarily trying to get the tests fixed and haven't been
spending any time on the ECMAScript stuff recently.

Probably the first thing to do is to get commit access to the W3C CVS
server.  If you do not already have a public key on file with the W3C,
generate one and send it to Dimitris so he can have you added to the
project.  Fred Drake recommended the SSH and CVS set up HOW-TO at the Python
site http://python.sourceforge.net/winssh.txt, the little tidbit about
ssh-keygen failing unless -f is specified was definitely a piece of
information that I wish I had known.

-------

The second thing is to snag the inital domunit release which contained my
initial take on the NIST test suite for ECMAScript.
http://prdownloads.sourceforge.net/xmlconf/DOMUNIT.zip.  In that download,
there should be a jsunit directory which contains JScript based tests.

Download Jsunit from http://www.jsunit.net and expand it into
domunit/jsunit/jsunit

There should be a file like DOMTestCaseConfig.js in the /domunit/jsunit
directory that will need to be edited to provide your base directory and the
parser under test.

Then load /domunit/jsunit/jsunit/testRunner.html in IE, hit the browse
button and file a test file in /domunit/jsunit.  Hopefully you should now be
running tests.

We will probably diverge substantially from that, but that it at least where
I'm starting from.

-------

If you have (or want to setup) the build environment, build the
"dom1-core-ecmascript" target to generate a directory of .js files (I think
it is build/ecmascript/level1/core).  I haven't done any verification of the
code and am not an ECMAScript expert.  Could you examine the files to notice
any significant structural problems such as using language features that
would not be available on all targets.  Is there any tool we could use to
check the generated syntax before trying to run the tests, for example,
could JScript.NET's command line compiler.

I've placed a snapshot of the currently generated ECMAScript at http://home.
houston.rr.com/curta/ecmascript.ZIP

The tests (like the Java implementation) have two parts, the constructor,
which determines if the test is compatible with the capabilities of the
parser under test, and the test itself.  If a test was incompatible (say it
required hasFeature("HTML","") to be true and it was running on just an XML
parser), then it would throw an exception in the constructor and not be
reported as either a pass or a failure.
Received on Wednesday, 22 August 2001 16:59:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:03 UTC