Closed Bug 790257 Opened 12 years ago Closed 11 years ago

Request SpiderMonkey release (1.8.6?), for use in code coverage tools

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 735599

People

(Reporter: glind, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [js:waitingforinfo][js:t])

Brew install uses 1.8.5, from March 2011.  As part of using `brew spidermonkey` in deploying code coverage tools, it would be nice to have the 4 nits below resolved, so this code plays better with `escodegen`.

1) -1 literals are unary expressions
2) range vs loc
3) handler vs handlers in unary expressions
4) computed identifiers for "word with space"  

(as outlined in the four depends on bugs).

This is my no means an exhaustive list, just what I found when validating my own code!

As an alternative, if it makes sense to just finish up Harmony support in both `esprima.js` and `escodegen`, that would be awesomely helpful!

https://github.com/ariya/esprima/tree/harmony
https://github.com/Constellation/escodegen/issues/12

(Brew depends on:  

class Spidermonkey < Formula
  homepage 'https://developer.mozilla.org/en/SpiderMonkey'
  url 'http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz'
  version '1.8.5'

  # This is terribly, terribly slow the first time.
  # head 'https://hg.mozilla.org/tracemonkey', :using => :hg
  head 'https://hg.mozilla.org/tracemonkey/archive/tip.tar.gz', :using => :curl

)
That's a pretty ancient version of the source. But I'm not even sure what you want--could you tell us more about what you're trying to do?
Whiteboard: [js:waitingforinfo]
dmandelin,
Overall goal:  code coverage when testing Mozilla-specific js code.  

One technique (used by CoverJS) is "js code" -> AST -> add nodes with incrementers -> escodegen to produce code.  There are probably others, but easy manipulation of the AST and converting that AST back into code comes up in lots of them :)  

Where does spidermonkey fit in?


Several things:

1.  It would be nice to have a more recent version of spidermonkey "close at hand" for lots of reasons.  'brew install spidermonkey' is about as 'close at hand' as one can get in OSX.

2.  In that version, it would be nice if Reflect.parse() gave accurate output.  There are few possible bugs (linked in this bug), one of which is already fixed.  

3.  Spidermonkey's Reflect.parse() should be authoritative, and can be used as inputs to `escodegen`.



(As an alternative, I have been working on getting all the moz stuff into `esprima`, but the `allow_starless_yield` piece complicates things, since esprima is really targeting Harmony.)


This is not a rush, but a 'test the waters'.  If having updated SpiderMonkey would help others, then I hope we can see one.  Otherwise, I can always (as a fallback) just use my own forked `esprima` and `escodegen`.
Old spidermonkey doesn't know about 'of' either... With both

'each' 

and 

for (let [a,b] in ...)  

not okay / deprecating, it would be nice to have Spider Monkey recognize 'of'
What this seems to come down to is this: we can half-ignore JS embedders all we want by only packaging up releases fairly infrequently.  We do have the half-justification that we're changing JSAPI so frequently now that it eases the migration pain for embedders.  But if we choose to do that, we're also choosing to ignore our own embedders (excepting the biggest embedder, Gecko, of course).

So basically this bug's asking, on behalf of Mozilla-project but non-Gecko embedders, for us to actually care about and package up releases more frequently than we do.  Do we actually care enough to do it?  (It might also help to know what other Mozilla embedders exist besides code-coverage and Gecko.  More than just those two probably further affects the calculus.)

(Note to anyone trying to read this too literally: I am deliberately exaggerating the SpiderMonkey team's position on doing releases to sharpen the horns of the dilemma, to mix metaphors almost cleverly.  We do much more than half-ignore embedders, in reality.  But we still don't package up releases very much.)
...where by "do much more" I mean "do much more to help embedders than simply half-ignore them", since it has been pointed out to me my phrasing was open to multiple interpretations.  :-)  (Freudian slip?  Naaaaah.)
Hey Jeff,

I think that's a cogent statement.  It would be nice if there were more releases, which might help with lots of process pieces (smoke detection, feature rollouts, independent verification, etc).

Fwiw, I actually am in the midst of fixing / pushing both to both Esprima and Escodegen, so the immediate problem is solved.
Whiteboard: [js:waitingforinfo] → [js:waitingforinfo][js:t]
We did a SpiderMonkey 17 release semi-recently which addresses this concern, see bug 735599.  The plan going forward is to do releases in concert with Firefox ESRs, so the next will be 24 in October or November or so.  (Ideally in concert with Firefox releases or not too long after, but a little slack time wouldn't be the end of the world.  In any case, delays shouldn't be as crazy as they used to be.)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.