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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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
…
[View More]idea on the long run though! ;-)
Cheers, Richard
[View Less]
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. …
[View More]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
[View Less]
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 <…
[View More]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__'
[View Less]
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 …
[View More]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
[View Less]
