[pypy-dev] Javascript interpreter and r_uint

[Maciej Fijalkowski]

On Thu, Dec 6, 2012 at 3:52 AM, holger krekel <holger at merlinux.eu> wrote:
> On Thu, Dec 06, 2012 at 02:14 -0800, Maciej Fijalkowski wrote:
>> On Thu, Dec 6, 2012 at 1:58 AM, Jonathan Slenders <jonathan at slenders.be> 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