re-boxing of CPython types.
if you can add in "assembly-level-like" infusion, where javascript snippets can be substituted directly into the resultant javascript output, then you are on to a winner. the pyjamas compiler uses this technique to directly interface with the DOM model of the browser.
I'm not going to comment on the merits of this (I actually think javascript is a better language to write javascript code in), but if this is exactly what pyjamas is doing, why would we want to do it on pypy?
the benefits of having a generic "assembler" mechanism in a compiler should be already clear, just as the "asm { ... }" statement shows in gcc. so i can safely assume that that's not what you're asking. which leaves the implication that it should be pypy that provides direct access to web browsers' DOM model, which most definitely is not the case. pyjamas comprises three parts: 1) a stand-alone python-to-javascript compiler [that has an "assembler" directive called JS()] 2) an independent library called DOM.py which mostly comprises JS() assembler directives. 3) an independent ui "widget" library which uses DOM.py to provide a widget set that is startlingly similar to python-qt4 and python-gtk2. the js tutorial which has been removed (so i cannot look at it) i remember it used mochikit, somehow, to do the same thing as DOM.py that implies that somehow there was the means to call javascript functions "as if from python". which, i can tell you from experience, makes a bit of a mess of the compiler as well as making a meal out of the interface between python and javascript.
however i believe that it would be relatively easy to go from this "good enough" / "relaxed" mode to "full python compliance" - the "strict" mode as i call it.
Exactly how? How do you map real python to javascript without killing the performance gain any js interpreter is going to give you?
ahh, i'm _so_ glad you asked :) one way to explain it is: i'm looking to replace cpython's PyType_IntObject, in intobject.h: typedef struct { PyObject_HEAD long ob_ival; } PyIntObject; with this: typedef struct { PyObject_HEAD JSObject *ob_ival; } PyIntObject; and in intobject.c, replace this: static PyObject * int_div(PyIntObject *x, PyIntObject *y) { long xi, yi; long d, m; CONVERT_TO_LONG(x, xi); CONVERT_TO_LONG(y, yi); switch (i_divmod(xi, yi, &d, &m)) { case DIVMOD_OK: return PyInt_FromLong(d); case DIVMOD_OVERFLOW: return PyLong_Type.tp_as_number->nb_divide((PyObject *)x, (PyObject *)y); default: return NULL; } } with this: static PyObject * int_div(PyIntObject *x, PyIntObject *y) { JSObject *d; /* the js object associated with x will have a javascript function __div__. get it, and call it. */ JSFunction *js_div_fn = get_js_function(x->ob_ival, "__div__"); d = call_js_function(js_div_fn, x->ob_ival, y->ob_ival); return PyInt_FromJSObject(d); } the function "int.__div__" will start off as a python class that will be compiled to javascript. in this way, i expect to gain the benefit of the aggressive JIT javascript JIT compilation of e.g. Google V8, _and_ keep interoperability with http://python.org's c-based modules (after a recompile, of course). i haven't quite worked out how the "coerce" function fits in to all this. and also someone kindly warned me about garbage collection, which i don't have a handle on, yet. in this way, all code that is actually python will end up being compiled to aggressively-JIT-optimised assembler. there will be no "checking" of CPython types. there will be no "conversion" to/from CPython types, because all CPython types will become is "boxes" around Javascript Objects. this is the approach that the unladen/swallow team will have to take, in their "Phase 2". they are _going_ to do this. so, i figured i might as well get a handle on it, in advance, to see if it's possible, and try to "get on the bandwagon" so to speak. also, i figured that there must be a way that you could also leverage this. there _has_ to be. in a generic way: typedef struct { PyObject_HEAD void *ob_ival; /* for DSO-loadable modules to override with something */ } PyIntObject; l.
Hello! 2009/4/23 Luke Kenneth Casson Leighton <lkcl@lkcl.net>:
however i believe that it would be relatively easy to go from this "good enough" / "relaxed" mode to "full python compliance" - the "strict" mode as i call it.
Exactly how? How do you map real python to javascript without killing the performance gain any js interpreter is going to give you?
ahh, i'm _so_ glad you asked :)
one way to explain it is:
[description of how to have cpython call back to javascript for implementation?] I don't think that's what Leonardo was getting at, but rather that if you have to support python semantics, at some point you've got to deal with that overhead. For example, you have to do bounds checking on all list subscription, because javascript won't raise exceptions for you in that case. I couldn't work it out poking about in the source how pyjamas deals with this, or the MRO, or python's scoping rules, et cetera. The point then is you're now implementing all those semantics in javascript rather than C, so you're dealing with an extra level of abstraction. William Leslie
I don't think that's what Leonardo was getting at, but rather that if you have to support python semantics, at some point you've got to deal with that overhead. For example, you have to do bounds checking on all list subscription, because javascript won't raise exceptions for you in that case.
yep. we have an emulation-implementation of list, dict and tuple that raise an appropriate javascript exception that's given the same name as the python one. additionally, flier liu, who wrote pyv8, has written some code into PyV8 that allows the transfer of exceptions between a python context and a javascript context. i believe he's only done it one-way so far. ... ok - actually, you're right: looking at pyjslib.py more closely, the only compliance with python exceptions is KeyError in the emulation-implementation of dict, which at least demonstrates the principle. so, one for the TODO list, then :) hmm, i should add some tests. l.
Hi Luke, I think I understand the point of your work, so let me point out the difference with our JavaScript backend. In your work, you are fine with emulating basic- or medium-level Python functionality, by giving up on the details. That's fine by itself; PyPy has a different goal for different people, and that's why our JavaScript backend wasn't really useful. It was compiling custom snippets of RPython code to JavaScript, which required advanced knowledge of type inference before being useful; or alternatively, we could compile the *whole* PyPy interpreter to JavaScript (if the JS backend was complete), which would not really be useful for JavaScript-oriented people, and definitely too slow. For an example of what I mean with "medium-level Python functionality", just try to run any existing application in your system: it will fail because most existing applications rely somehow on advanced features of Python. Of course, in the particular use case of your system, you expect most code to be written from scratch instead of, say, people importing Twisted in your environment. So that's why your system is fine for its use case, and why PyPy's JavaScript backend is far over-the-top in this case. A bientot, Armin.
On Thu, Apr 23, 2009 at 10:46 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Luke,
I think I understand the point of your work, so let me point out the difference with our JavaScript backend. In your work, you are fine with emulating basic- or medium-level Python functionality, by giving up on the details.
for the "web" mode, yes.
For an example of what I mean with "medium-level Python functionality", just try to run any existing application in your system: it will fail because most existing applications rely somehow on advanced features of Python.
well... it may come as a surprise to learn that the gtk "hello world" application ran successfully under pyjs+python-spidermonkey (and a few more, besides)- but i do know what you mean. by the time i moved on to the more comprehensive of the gtk examples, i quickly encountered the intobject-conflict issue, and more (which bernd dorn is looking at, in the "introspection" branch). but - leaving that aside: i thought last night about the garbage-collection issue a bit and i believe i understand: you'd have two separate garbage-collection systems (one in CPython and one in pypy) both keeping separate refcounts on the same object, and thus end up deleting the object out from underneath each other. in webkit, there is a similar issue - the solution they have there is that javascript objects are "marked as deleted" and also the c++ object has refcounting and both the javascript bindings and also any other language bindings make direct reference to the underlying c++ object refcounting. so i just wanted you to know that i do understand the complexities involved, and i'll think about it some more and answer later. l.
On Thu, Apr 23, 2009 at 1:26 PM, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: <snip>
so i just wanted you to know that i do understand the complexities involved, and i'll think about it some more and answer later.
Hi Luke, I couldn't help noticing but you seem to try to answer a lot of things that were no questions in the first place. regards, Eric
participants (4)
-
Armin Rigo -
Eric van Riet Paap -
Luke Kenneth Casson Leighton -
William Leslie