On Thu, Dec 06, 2012 at 02:14 -0800, Maciej Fijalkowski wrote: > On Thu, Dec 6, 2012 at 1:58 AM, Jonathan Slenders <[email protected]> > wrote: > > Hi all, > > > > Yesterday, I did some experiments with the existing javascript interpreter > > that was written in RPython. [1] > > It worked very well when interpreted by CPython, but failed to translate to > > C because of unsigned int issues. > > > > Quite a few times, unsigned and signed objects were compared or added, or > > one asigned to the other. (I'm not entirely sure.) > > But I had to replace r_uint32 by r_int32 and r_uint by r_int, about 25 > > times, before I could translate anything. > > Good question, I have no idea. Can't you use normal integers in those places? > > > > > So, my question is. What is the reason for having unsigned integers in the > > javascript interpreter? > > > > Apart from that, it works great, and I translated the interpreter even with > > the --sandbox option! > > > > A related question. how mature is the interpreter? It seems to run pretty > > stable, although there hasn't been any development done since june 2011. > > I'd like to choose this instead of Google's V8, because that way I can keep > > the same sandbox hypervisor for both Python and Javascript. > > The interpreter is relatively complete, however it does require fixing > a lot of corner cases from ECMA tests. There are quite a few missing > pieces: > > * the correct semicolon insertion requires a different parser > (standard says LL(1)) > > * regular expressions are not supported > > * xml literals are unsupported
just want add a little sidenote on the relevance of a Javascript/PyPy interpreter. As i recall, in previous years the perspective was that it's not of much use if it's not tied into the DOM on browsers. I think that's not true anymore as Javascript is increasingly used on the server via node.js and Rhino. One major use case has people looking into how to best perform e. g. js-templating on the server or client side exchangeably, depending on capabilities of the client. For that, there is no DOM integration needed. For a related discussion, see: http://stackoverflow.com/questions/5494839/templating-language-for-both-client-side-and-server-side-rendering Maybe the dreaded semicolon-insertion issue could even be ignored, not sure. cheers, holger > Cheers, > fijal > _______________________________________________ > pypy-dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/pypy-dev > _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
