303857 - last available tests for SpiderMonkey out of date

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mikhail T.]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.4; FreeBSD; X11; amd64) KHTML/3.4.1 (like Gecko)
Build Identifier: 

The latest available stand-alone release of js is 1.5rc6 -- from June 2004. 
That's pretty old in itself (browsers ship with much newer js sources), but the 
last tarball with tests for js is even older -- from 2002. 
 
Several tests in there are broken (fixed since in CVS), several should not be 
there at all... 
 
Please, release the new SpiderMonkey (suitable for use with firefox _instead 
of_ firefox' own version) along with the functional test suite. Thank you... 

Reproducible: Always




I'm quite certain, some part of this report will be mis-filed, but I could not 
find a better component. Sorry.

Comment 1

[Bob Clary [:bc] (inactive)]

I plan on releasing js 1.5rc7 when Firefox 1.5 is released and can include the
js tests in a separate tarball at the same time.

Comment 2

[Mikhail T.]

Is not that (firefox-1.5) going to happen a long time from now? Perhaps, you can
release something in the interim -- the 1.5rc7 and all of tests it is supposed
to pass?

The current-latest 1.5rc6 is so stale now (14 months), bug-reports against it
are considered meaningless (and time wasting!) by some of its maintainers... :-(

Comment 3

[Bob Clary [:bc] (inactive)]

(In reply to comment #2)

The final call is up to Brendan, but I believe Firefox 1.5 will be about in
September and is not too long to wait given the time since the last release.
Keeping up to date with CVS is the best approach if you want to file bugs in
general anyway imo.

Comment 4

[Mikhail T.]

BTW, the jsDriver.pl should, probably, exit with a non-zero status if it
encounters any failures -- this way its use can be automated easier...

The trivial patch is right here:

--- tests/jsDriver.pl     Fri Nov  8 16:56:41 2002
+++ tests/jsDriver.pl     Mon Aug  8 01:50:54 2005
@@ -142,5 +142,7 @@
 
         &write_results;
-
+       if ($failures_reported) {
+           exit 1;
+       }
     }
 }

Comment 5

[Mikhail T.]

(In reply to comment #3)
> (In reply to comment #2)
> 
> The final call is up to Brendan, but I believe Firefox 1.5 will be about in
> September and is not too long to wait given the time since the last release.

Oh, well...

> Keeping up to date with CVS is the best approach if you want to file bugs in
> general anyway imo.

I really don't want to file bugs :-) I want the FreeBSD ports to work properly.
CVS is *your* internal thing. What *we* -- the porters -- deal with are the
releases and, possibly, vendor's own patches.

When the differences are slight, we can take the newer versions of some of the
sources from the vendor's CVS and add them to the port's own FreeBSD-specific
set of patches. But when the differences represent 14 months worth of
development (jsxml!), I'd rather lean on the vendor to cut a new release...

Push, push, ehh-hh, puuush...

Comment 6

[Mikhail T.]

Also, per bug 10278 and bug 101964, I'm removing the
js1_3/regress/function-001-n.js, js1_2/function/function-001-n.js,             
  js1_3/Script/function-001-n.js, and js1_5/Array/regress-101964.js locally.

Ideally, only the tests, which are supposed to pass should be part of the
released test-tarball.

Comment 7

[Bob Clary [:bc] (inactive)]

(In reply to comment #6)

I do not intend to cvs remove tests. If you wish to exclude tests which are
obsolete, use -L spidermonkey-n.tests on the js shell command line.

Comment 8

[Mikhail T.]

(In reply to comment #7) 
> I do not intend to cvs remove tests. 
 
What's the point of there being a test, which is known to be bogus? History? 
Well, that's what CVS' Attic is for :-) Anyway, short of cvs-removal, can you 
ensure, these don't make it into the tarball? 
 
> If you wish to exclude tests which are obsolete, use -L spidermonkey-n.tests 
> on the js shell command line. 
 
Yes, but this means, I (and everyone else, who will want to test their newly 
built js) will have to investigate each test failure. 
 
Would not it better to have only functional tests in the first place? 
 
Alternatively, if there is some other way of knowing, which tests are supposed 
to fail (such as the bug-id), then the jsDriver.pl should be modified 
differently, from what I proposed in comment 4. It should only exit with a 
non-zero status, when there are _unexpected_ failures. 
 

Comment 9

[Tom S [:evilpie]]

We released https://developer.mozilla.org/En/SpiderMonkey/1.8.5.