Closed Bug 303857 Opened 15 years ago Closed 9 years ago

last available tests for SpiderMonkey out of date

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: mi+mozilla, Assigned: bc)

References

()

Details

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.
Assignee: rginda → general
Component: JavaScript Debugger → JavaScript Engine
Product: Other Applications → Core
QA Contact: caillon → general
Version: unspecified → Trunk
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.
Assignee: general → bob
Status: UNCONFIRMED → NEW
Ever confirmed: true
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... :-(
(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.
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;
+       }
     }
 }
(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...
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.
(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.
(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. 
 
Blocks: js1.6rc1
Flags: testcase-
We released https://developer.mozilla.org/En/SpiderMonkey/1.8.5.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.