[pypy-dev] The JVM backend and Jython
Hi all, It was nice meeting up with many of you at PyCon! I've been thinking about the first steps towards collaboration between the Jython project and the PyPy project. It looks like it isn't going to be too long before we are all (CPython, PyPy, IronPython, Jython, etc) working on a single shared repository for all of our standard library .py code. In my ideal world there would come a day when there is also no standalone Java code in the Jython project: that is the shared standard library would contain all of Jython's .py files, and all of the Java would be generated from PyPy and Jython as a standalone project would disappear. It is possible that this is too ambitious, but big goals are more fun, right? In reality even if this where to get going, I imagine it would be a 10+ year plan :) So to my question - just how broken is the JVM backend? Are there workarounds that would allow the Java code to get generated? I ask because I would like to evaluate the generated Java parser as a potential replacement for our current ANTLR based parser. It seems like a nice baby step towards real collaboration since it seems like a relatively easy place to start. Clearly it would need adjustments to actually work for Jython - but I'd be able to look into that part. I don't think I have the time to try to unbreak the translation though... -Frank ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Pypy custom interpreter JIT question
Hi Andrew, On Mon, Mar 28, 2011 at 7:21 PM, Andrew Brown wrote: > When the optimizer encounters a "pure" function, it must compare the objects > "promote - promote the argument from a variable into a constant". Could this > be an appropriate alternate to the @purefunction solution? Or, I'm guessing, > does it just mean the name bracket_map won't change bindings, but does not > impose a restriction on mutating the dictionary? One point of view on 'promote' is to mean "this variable was red, but now turn it green (i.e. make it constant)". It has no effect on a variable that is already green (= a constant). We have no support for considering that a dict is immutable, so it needs to be done with @purefunction. But to be effective, @purefunction must receive constant arguments; so in one or two places in the source code of PyPy you will find a construction like: x = hint(x, promote=True) # turn x into a constant some_pure_function(x) # call this pure function on x Indeed, Carl Friedrich's blog series explains it nicely, but it should also mention that when the hints described in the blog are applied not to integer but to pointers, they apply only to the pointers themselves, not on the fields of the objects they point to. A bientôt, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] Hacking dropbox
Hi, I don't have any news from the dropbox side, but as an aside note, I found a project which is open source and implements the very same technique I used for dropbox, and additionally it also decompiles back to the source code: http://code.google.com/p/pyretic/ ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
