On Thu, Dec 6, 2012 at 3:52 AM, holger krekel <[email protected]> wrote: > 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.
Judging from internet flamewars, no it cannot be. However, the rewrite of the parser is not such a horrible idea, it's also necessary for the descriptive error messages I think. The problem, *right now* is that it's a proof of concept that requires some work to be finished and/or to use JIT and be fast. I won't do it, also because I have other Open Source commitments at hand. Cheers, fijal _______________________________________________ pypy-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
