It has never built since Makefile.ref was deprecated, so nobody should be
complaining, I hope. It's also quite buggy -- even simple things like
read-write streams throw-on-open when O_RDWR != O_RDONLY | O_WRONLY (which
is just about everywhere UNIX).
If anybody out there really needs this functionality, I have some code you
can probably bend into the same API, offered under the same license terms as
SpiderMonkey -- hit me up for details.
Wesley W. Garland
Director, Product Development
+1 613 542 2787 x 102
I ran across this today after banging my head against all the
requirements to get narcissus and File() working in order to parse and
manipulate JS parse trees (now I want those 2 days of my life back).
What started me down this road was Brendan's post warning folks away
from the jsparse, and that until jsparseapi existed (if ever)
narcissus would be the best bet (https://wiki.mozilla.org/
> but you should really consider one of the other, actually-maintained solutions out there instead if at all possible.
So if narcissus can't really talk to the real world (w/out File()),
what's the best advice right now for mucking with JS parse trees?
Sorry for not getting back to this sooner, I'm bad at reading newsgroups regularly...
Dave Herman is working on some AST creation/manipulation APIs, I believe prototyping ES6 strawmen -- that's probably the best advice long-term. *right now*, I'm not so sure.
In *theory* you should be able to get Narcissus to run under gpsee's JS
shell, which would let you use the CommonJS fs-base API to do your file I/O.
Hit me up in #gpsee on freenode if you want help.