Mailman 3 April 2005 - pypy-dev

Sprint in Heidelberg
by Carl Friedrich Bolz 06 Apr '05

06 Apr '05

Hi pypy-dev! Today I talked to the administrator of the institute of physics of the university of Heidelberg about the possibility of doing a PyPy sprint in Heidelberg this summer. He told me it would not be problem at all to use the rooms and facilities of the institute of physics as long as the sprint would take place during semester break, which ranges from 17. July to 16. October. It would be better though to stay in the range August-September since a lot of people are on holiday during that period. He even told me that he would support an official request (he thought the PyGame flowgraph viewer was pretty cool :-) ) and help me get the official stuff gone -- which also doesn't amount to much more than talking to a professor and reserving the sprinting room. So I can offer you the opportunity to sprint in Heidelberg this summer. I would really be delighted to host such an event. Regards, Carl Friedrich

1 0

Sprint in Heidelberg
by Carl Friedrich Bolz 06 Apr '05

06 Apr '05

Hi pypy-dev! Today I talked to the administrator of the institute of physics of the university of Heidelberg about the possibility of doing a PyPy sprint in Heidelberg this summer. He told me it would not be problem at all to use the rooms and facilities of the institute of physics as long as the sprint would take place during semester break, which ranges from 17. July to 16. October. It would be better though to stay in the range August-September since a lot of people are on holiday during that period. He even told me that he would support an official request (he thought the PyGame flowgraph viewer was pretty cool :-) ) and help me get the official stuff gone -- which also doesn't amount to much more than talking to a professor and reserving the sprinting room. So I can offer you the opportunity to sprint in Heidelberg this summer. I would really be delighted to host such an event. Regards, Carl Friedrich

1 0

Re: [pypy-svn] r10350 - pypy/dist/pypy
by Richard Emslie 05 Apr '05

05 Apr '05

Hi Seo, On Tue, 5 Apr 2005 sanxiyn(a)codespeak.net wrote: > Author: sanxiyn > Date: Tue Apr 5 21:19:01 2005 > New Revision: 10350 > > Added: > pypy/dist/pypy/README.22 > Log: > Document 2.2 compatibility > > +* opcode.py > +opcode module is new in 2.3, and is used in the interpreter core. > +Just copying this file from 2.3 should work. Without this, PyPy > +won't even start. Another hack would be to import pypy.tool.opcode. Not sure it's a good idea on the long run though! ;-) Cheers, Richard

1 0

Cancellation of Oxford sprint
by Jacob Hallén 05 Apr '05

05 Apr '05

I was just notified that the price of 45 pounds per day we were quoted was per day, per person. This makes the cost of sprinting, if you add it all up, higher than in Washington DC. Since partners dropped out because of the high costs in DC, I'm afraid we have to cancel, unless someone comes up with a much cheaper sprinting venue. We are still scheduled to give a talk at the ACCU on Saturday 23 April, where the ACCU pays for 2 nights in a hotel and conference attendance for the speakers. We have a 90 minute slot and paid attendance for 2 speakers. The idea is that we do one part about the general goals of the project and the setup of the EU project, and one part on the technical details of how things are implemented. I think Armin would be the best person to give the technical talk. I don't know who should give the general one. Do we have any volunteers? I'm going to the conference anyway, and I have my entrance paid, since I will speak on "Sprint driven development". I'm happy to assist anyone who wants to handle the general Pypy talk. Jacob

1 0

py.py py.py
by Sanghyeon Seo 05 Apr '05

05 Apr '05

With revision 10311, py.py py.py runs again, but fails to print 1. As it takes more than 100 minutes to start up in my 23400 pystones machine, I am not patient enough to debug this... tinuviel@debian:~/pypy/dist/pypy/interpreter$ ./py.py py.py faking <type 'unicode'> faking <type 'module'> faking <type 'file'> faking <type 'posix.stat_result'> faking <type 'posix.statvfs_result'> faking <type '_sre.SRE_Pattern'> faking <type 'function'> faking <pypy type 'unicode'> faking <pypy type 'module'> PyPy in StdObjSpace on top of Python 2.3.4 (startupttime: 6103.75 secs) >>>>>1 faking <pypy type 'file'> Traceback (most recent call last): File "py.py", line 90, in main_ con.interact(banner) File "/home/tinuviel/pypy/dist/pypy/interpreter/interactive.py", line 137, in interact code.InteractiveConsole.interact(self, banner) File "/home/tinuviel/pypy/dist/lib-python-2.3.4/code.py", line 239, in interact more = self.push(line) File "/home/tinuviel/pypy/dist/lib-python-2.3.4/code.py", line 261, in push more = self.runsource(source, self.filename) File "/home/tinuviel/pypy/dist/pypy/interpreter/interactive.py", line 221, in runsource self.runcode(code) File "/home/tinuviel/pypy/dist/pypy/interpreter/interactive.py", line 169, in runcode pycode.exec_code(self.space, self.w_globals, self.w_globals) File "/home/tinuviel/pypy/dist/pypy/interpreter/eval.py", line 24, in exec_code return frame.run() File "/home/tinuviel/pypy/dist/pypy/interpreter/eval.py", line 70, in resume result = self.eval(executioncontext) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyframe.py", line 97, in eval self.dispatch() File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 57, in dispatch fn(self) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 283, in PRINT_EXPR print_expr(f.space, w_expr) File "/home/tinuviel/pypy/dist/pypy/interpreter/gateway.py", line 528, in appcaller return space.call_args(w_func, args) File "/home/tinuviel/pypy/dist/pypy/objspace/descroperation.py", line 88, in call_args return w_obj.call_args(args) File "/home/tinuviel/pypy/dist/pypy/interpreter/function.py", line 40, in call_args return frame.run() File "/home/tinuviel/pypy/dist/pypy/interpreter/eval.py", line 70, in resume result = self.eval(executioncontext) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyframe.py", line 97, in eval self.dispatch() File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 54, in dispatch fn(self, oparg) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 642, in CALL_FUNCTION w_result = f.space.call_args(w_function, args) File "/home/tinuviel/pypy/dist/pypy/objspace/descroperation.py", line 88, in call_args return w_obj.call_args(args) File "/home/tinuviel/pypy/dist/pypy/interpreter/function.py", line 40, in call_args return frame.run() File "/home/tinuviel/pypy/dist/pypy/interpreter/gateway.py", line 231, in run w_result = self._run() File "</home/tinuviel/pypy/dist/py/code/source.py:213>", line 3, in _run_UWS_ObjSpace_W_Root File "/home/tinuviel/pypy/dist/pypy/module/sys2/hook.py", line 8, in displayhook print_item_to(space, space.repr(w_obj), sys_stdout(space)) File "/home/tinuviel/pypy/dist/pypy/interpreter/gateway.py", line 528, in appcaller return space.call_args(w_func, args) File "/home/tinuviel/pypy/dist/pypy/objspace/descroperation.py", line 88, in call_args return w_obj.call_args(args) File "/home/tinuviel/pypy/dist/pypy/interpreter/function.py", line 40, in call_args return frame.run() File "/home/tinuviel/pypy/dist/pypy/interpreter/eval.py", line 70, in resume result = self.eval(executioncontext) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyframe.py", line 97, in eval self.dispatch() File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 54, in dispatch fn(self, oparg) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 642, in CALL_FUNCTION w_result = f.space.call_args(w_function, args) File "/home/tinuviel/pypy/dist/pypy/objspace/descroperation.py", line 88, in call_args return w_obj.call_args(args) File "/home/tinuviel/pypy/dist/pypy/interpreter/function.py", line 40, in call_args return frame.run() File "/home/tinuviel/pypy/dist/pypy/interpreter/eval.py", line 70, in resume result = self.eval(executioncontext) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyframe.py", line 97, in eval self.dispatch() File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 54, in dispatch fn(self, oparg) File "/home/tinuviel/pypy/dist/pypy/interpreter/pyopcode.py", line 502, in LOAD_ATTR w_value = f.space.getattr(w_obj, w_attributename) File "/home/tinuviel/pypy/dist/pypy/objspace/descroperation.py", line 120, in getattr w_descr = space.lookup(w_obj, '__getattribute__') File "/home/tinuviel/pypy/dist/pypy/objspace/std/objspace.py", line 250, in lookup w_type = w_obj.getclass(self) File "/home/tinuviel/pypy/dist/pypy/interpreter/baseobjspace.py", line 29, in getclass return space.gettypeobject(self.typedef) File "/home/tinuviel/pypy/dist/pypy/objspace/std/objspace.py", line 153, in gettypeobject self._typecache) File "/home/tinuviel/pypy/dist/pypy/interpreter/baseobjspace.py", line 103, in loadfromcache return cache.getorbuild(key, builder, self) File "/home/tinuviel/pypy/dist/pypy/tool/cache.py", line 26, in getorbuild result = builder(key, stuff) File "/home/tinuviel/pypy/dist/pypy/objspace/std/stdtypedef.py", line 85, in buildtypeobject dict_w[descrname] = w(descrvalue) File "/home/tinuviel/pypy/dist/pypy/objspace/std/objspace.py", line 205, in wrap return ft(self, x) File "/home/tinuviel/pypy/dist/pypy/objspace/std/fake.py", line 152, in __init__ self.name = d.__name__ AttributeError: 'FakeDescriptor' object has no attribute '__name__'

1 0

Next step: gen???.py
by Armin Rigo 02 Apr '05

02 Apr '05

Hi there, This is a status report and a "what to do next" summary. The status is easily summarized as follows: the PyPy interpreter is quite complete and highly compliant with CPython, minus a number of dark corners that are only likely to bite user programs using the most introspective features of the standard library (most notably pickling). The flow graph and annotation subsystems work quite nicely too; we can successfully annotate more or less all of PyPy, or at least we are getting close to this goal. The "next" step is low-level code generation. Here, we have a rather large number of prototypes all around. The most complete one is genc.py, which is able to produce code for roughly the complete PyPy interpreter, but without using the annotations -- i.e. it is very slow code, and it is essentially dependent on CPython. Approaching the same goal but from the opposite direction, we have genllvm.py, which is only able to translate fully annotated graphs and doesn't have any mean of fall-back for things like faked objects which cannot be annotated. Finally there are other very incomplete or deprecated or planning-only back-ends: gencl, genpyrex, genjava. Not to mention geninterplevel whose goal is still different. The question is which line of work to focus on right now. All of these back-ends are interesting and worthwhile in the long run but we need to select a first one. There are basically 4 reasonable options: * Enhance genc.py. This is a step-by-step process, and any intermediate version can still be tested against the whole PyPy and against the snippet examples. Another advantage of genc is that it is the only option that doesn't depend on any external tool other than a C compiler. * Enhance genc.py using the C++ facility of function overloading for simplicity (basically, we would generate "z=add(x,y)" in the file and let the C++ compiler decide which version of add() to call based on the declared types of x and y). This might well be the easiest solution. A minor drawback is to require a C++ compiler. A possibly larger drawback is that the C++ compilation time might be quite larger, even for similar-looking code. (Having to know C++ in the first place shouldn't be that big a drawback if we don't use fancy C++ features.) * Go for genllvm.py. An obvious drawback is that we'd all have to install LLVM. The problem with genllvm right now is that it cannot make sense of unannotated code (or code containing the SomeObject annotation). We don't know yet for sure the quantity of such SomeObjects in the annotated PyPy source code, but a guess is that they occur mainly for "fake" stuff (file, long, unicode...). If so, there is one way around this problem. Carl pointed out that it *might* be easy to link the LLVM compiler output with CPython, possibly making a C extension module for CPython. If so, then we would add in genllvm support for "black box" PyObject pointers, and use a few functions from the CPython C-API to manipulate them. The goal here would be to modify the source code of the interpreter/module/objspace to reduce the number of operations that need to be performed on these "black boxes". For example, we could possibly reduce all these operations to method calls. In other words, we would say that using CPython objects like "long" at interp-level is temporarily OK but only if they are manipulated via method calls. This would make the genllvm support for them much easier. * genjava.py could be another option. It has a simpler type system, which matches ours quite well, but genjava doesn't exist yet at all (the one in the java/ subdirectory had a different goal in mind). We get memory management for free. If we add the requirement to compile with GCJ it could be easy to make a CPython extension module too, with the same problems and solutions about SomeObject as above. All in all, each 4 option is equally possible. If I have to pick one, I guess the first 2 options pass the additional criteria of "very good confidence that it will work within a couple of months". This is definitely biased by the fact that I'm not fluent in Java and know very little about LLVM, but also by my lack of knowledge about the ease of installation and integration of the corresponding tools. Then to pick one of the first two options, the second one (allowing some C++ facilities to sneak it) is my favourite. Comments and feed-back are welcome! Armin

8 12