Mailman 3 May 2004 - pypy-dev

Jiwon's new __builtin__interp.py file
by Laura Creighton 29 May '04

29 May '04

""" Implementation of interpreter-level builtins. """ import os from pypy.interpreter.module import Module from pypy.interpreter.pycode import PyCode from pypy.interpreter.error import OperationError _noarg = object() import __builtin__ as cpy_builtin w_file = space.wrap(cpy_builtin.file) # import useful app-level functions from __applevel__ import execfile, callable, _iter_generator def _actframe(position=0): return space.getexecutioncontext().framestack.top(position) def globals(): return _actframe().w_globals def locals(): return _actframe().getdictscope() def _caller_globals(w_index=None): position = space.unwrapdefault(w_index, 1) return _actframe(position).w_globals def _caller_locals(w_index=None): position = space.unwrapdefault(w_index, 1) return _actframe(position).getdictscope() def __import__(w_modulename, w_globals=None, w_locals=None, w_fromlist=None): modulename = space.unwrap(w_modulename) if not isinstance(modulename, str): try: helper = ', not ' + modulename.__class__.__name__ except AttributeError: helper = '' raise OperationError(space.w_TypeError, space.wrap("__import__() argument 1 must be string" + helper)) w = space.wrap try: w_mod = space.getitem(space.sys.w_modules, w_modulename) except OperationError,e: pass else: return w_mod if not e.match(space, space.w_KeyError): raise w_mod = space.get_builtin_module(modulename) if w_mod is not None: return w_mod import os for path in space.unpackiterable(space.sys.w_path): f = os.path.join(space.unwrap(path), modulename + '.py') if os.path.exists(f): w_mod = space.wrap(Module(space, w_modulename)) space.sys.setmodule(w_mod) space.setattr(w_mod, w('__file__'), w(f)) w_dict = space.getattr(w_mod, w('__dict__')) execfile(w(f), w_dict, w_dict) return w_mod w_exc = space.call_function(space.w_ImportError, w_modulename) raise OperationError(space.w_ImportError, w_exc) def compile(w_str, w_filename, w_startstr, w_supplied_flags=None, w_dont_inherit=None): str_ = space.unwrap(w_str) filename = space.unwrap(w_filename) startstr = space.unwrap(w_startstr) supplied_flags = space.unwrapdefault(w_supplied_flags, 0) dont_inherit = space.unwrapdefault(w_dont_inherit, 0) #print (str_, filename, startstr, supplied_flags, dont_inherit) # XXX we additionally allow GENERATORS because compiling some builtins # requires it. doesn't feel quite right to do that here. try: c = cpy_builtin.compile(str_, filename, startstr, supplied_flags|4096, dont_inherit) # It would be nice to propagate all exceptions to app level, # but here we only propagate the 'usual' ones, until we figure # out how to do it generically. except ValueError,e: raise OperationError(space.w_ValueError,space.wrap(str(e))) except TypeError,e: raise OperationError(space.w_TypeError,space.wrap(str(e))) return space.wrap(PyCode()._from_code(c)) def eval(w_source, w_globals=None, w_locals=None): w_codeobj = None w = space.wrap if space.type(w_source) == space.w_str: w_codeobj = compile(w_source, w("<string>"), w("eval")) elif type(space.unwrap(w_source)) == PyCode: w_codeobj = w_source else: raise OperationError(space.w_TypeError, w('eval() arg 1 must be a string or code object')) if w_globals == None: w_globals = globals() w_locals = locals() elif w_locals == None: w_locals = w_globals return space.unwrap(w_codeobj).exec_code(space, w_globals, w_locals) def abs(w_val): return space.abs(w_val) def chr(w_ascii): w_character = space.newstring([w_ascii]) return w_character def len(w_obj): return space.len(w_obj) def delattr(w_object, w_name): space.delattr(w_object, w_name) return space.w_None def getattr(w_object, w_name, w_defvalue = _noarg): try: return space.getattr(w_object, w_name) except OperationError, e: if e.match(space, space.w_AttributeError): if w_defvalue is not _noarg: return w_defvalue raise def hash(w_object): return space.hash(w_object) def oct(w_val): # XXX does this need to be a space operation? return space.oct(w_val) def hex(w_val): return space.hex(w_val) def round(w_val, w_n=None): if w_n is None: w_n = space.wrap(0) return space.round(w_val, w_n) def id(w_object): return space.id(w_object) #XXX works only for new-style classes. #So we have to fix it, when we add support for old-style classes def issubclass(w_cls1, w_cls2): return space.issubtype(w_cls1, w_cls2) def iter(w_collection_or_callable, w_sentinel = _noarg): if w_sentinel is _noarg: return space.iter(w_collection_or_callable) else: if not space.is_true(callable(w_collection_or_callable)): raise OperationError(space.w_TypeError, space.wrap('iter(v, w): v must be callable')) return _iter_generator(w_collection_or_callable, w_sentinel) def ord(w_val): return space.ord(w_val) def pow(w_base, w_exponent, w_modulus=None): if w_modulus is None: w_modulus = space.w_None return space.pow(w_base, w_exponent, w_modulus) def repr(w_object): return space.repr(w_object) def setattr(w_object, w_name, w_val): space.setattr(w_object, w_name, w_val) return space.w_None def _pypy_get(w_value, w_self, w_class=None): # XXX temporary if w_class is None: w_class = space.w_None return space.get(w_value, w_self, w_class)

1 0

From Jiwon -- what is not getting to pypy-dev
by Laura Creighton 29 May '04

29 May '04

What he would like as a patch Index: module/__builtin__module.py =================================================================== --- module/__builtin__module.py (revision 4699) +++ module/__builtin__module.py (working copy) @@ -427,7 +427,7 @@ from __interplevel__ import hash, oct, hex, round from __interplevel__ import getattr, setattr, delattr, iter, hash, id from __interplevel__ import issubclass, _pypy_get -from __interplevel__ import compile +from __interplevel__ import compile, eval from __interplevel__ import globals, locals, _caller_globals, _caller_locals from __interplevel__ import file Index: module/__builtin__interp.py =================================================================== --- module/__builtin__interp.py (revision 4699) +++ module/__builtin__interp.py (working copy) @@ -92,7 +92,26 @@ raise OperationError(space.w_TypeError,space.wrap(str(e))) return space.wrap(PyCode()._from_code(c)) +def eval(w_source, w_globals=None, w_locals=None): + w_codeobj = None + w = space.wrap + if space.type(w_source) == space.w_str: + w_codeobj = compile(w_source, w("<string>"), w("eval")) + elif type(space.unwrap(w_source)) == PyCode: + w_codeobj = w_source + else: + raise OperationError(space.w_TypeError, + w('eval() arg 1 must be a string or code object')) + + if w_globals == None: + w_globals = globals() + w_locals = locals() + elif w_locals == None: + w_locals = w_globals + + return space.unwrap(w_codeobj).exec_code(space, w_globals, w_locals) + def abs(w_val): return space.abs(w_val)

1 0

Debugging aid
by Armin Rigo 28 May '04

28 May '04

Hello, There are a few "para-PyPy" tasks that we should consider for the near future too (like, during the sprint): it would be extremely helpful for example to have better debugging tools. A PyPy traceback is, as you know, a lots of pages of unhelpful data. The kind of thing that would help is a shell-like window into which the debugged program can "print" quite a lot of information, which can be expanded or contracted by a mouse click or keystroke; e.g. only show the app-level traceback, but each step in there can expand to the corresponding interp-level traceback; each step in there expands in the local variables, the objects expand into their attributes, etc... I'm sure this already exists, but there is still a bit of work to integrate something like that with PyPy (e.g. know about the two app- and interp- levels). It should also get integrated with the (new) test suite, to directly inspect failing tests. If you are more graphically oriented, there is the control flow viewer at pypy.translator.tool.pygame.graphviewer that needs more work. I am pretty sure we will need a good debugging tool to understand what is going on when we start annotating larger programs. I bet it should have a history, e.g. record all the annotation steps as they progress and redo previous blocks and allow browsing through these "revisions". It should also have "zooming", at least to switch between a program-wide view of the function call graph and the control flow graph inside of a particular function. These are at least the basic tools that would help quite a bit in PyPy debugging... A bientôt, Armin.

1 0

new mailman / spam configuration
by holger krekel 28 May '04

28 May '04

Hi, eventually codespeak.net's mailman 2.1.5 is now using spambayes 1.0_rc1 to drop spams to all mailing lists. This is done by a small patch of mine and with a 1-year trained database from Michael Hudson (thanks!). If anything goes wrong, that will be my fault so please mail me privately, or better yet, always mail root(a)codespeak.net in case of problems with codespeak. It would also be nice to get feedback from list admins that everything works well. Hope to see you all at EuroPython, where I will be looking for additional admins (currently it's Jens-Uwe Mager and me) not the least because there are a number of projects interested to move to codespeak ... cheers, holger

1 0

Pygame graph viewer
by Armin Rigo 27 May '04

27 May '04

Hello, I've been hacking on a Pygame-based viewer for the control flow graphs. See pypy/translator/tool/pygame/graphviewer.py. The idea is to display the graph as computed by 'dot', but more interactively. The hard part was to figure out where, in the image, each variable name actually is on the screen; now you can move the mouse around and when it is over a variable name you see the corresponding annotation, inferred by the new stuff in pypy/annotation/. The goal is to clean up and link it to the annotator a bit more, so that you can see it while it progresses (as if doing a step-by-step debugging). I guess it would be quite a useful debugging tool, aside from being presentation-friendly :-) A bientot, Armin.

3 3

mailman upgrade train
by holger krekel 26 May '04

26 May '04

hi folks, I am going to do some upgrading on mailman (to 2.1.5), so please stand by while the train is approaching ... holger

1 1

Re: [pypy-sprint] sprint quickly approaching
by Armin Rigo 24 May '04

24 May '04

Hello, Here are some info about the state of PyPy and what we expect to work on during the upcoming sprint. On annotations -------------- There isn't much more than already described on the "Brainstorming" thread. The annotations are implemented just as I wrote they should be. It just works, basically. There are a few more SomeXxx classes than described in the e-mails, like SomeClass, SomeInstance, and SomeMethod to analyse OOP programs. It should be quite easy to have an overview of what these mean just by reading pypy.annotation.model. So the current status is that we can analyse simple RPython programs. The next two things do be done in this direction and that should be put on the sprint's schedule are: * complete the Pyrex code writer; we are in the unlikely state where we can analyse more stuff than we can actually write code for (e.g. methods in classes). * try to analyse larger programs, seeing if the time we need for the analysis remains reasonable or explodes. We should give a try at analysing py.py's entry point itself and moving on as numerous hard and unexpected problems pop up. For example, we'll need a way to tell the analysis/translator that some bits of PyPy are only lazy computations of stuff that gets cached into a dictionary after the first use (so that the translator should trigger the computation and just pick the value from the cache instead of analysing the cache-populating code). On objspace.std --------------- The other thing we might put on our agenda is refactoring the object model (i.e. objspace.std). The multimethod thing is great but really hard to match to the Python semantics of new-style classes and descriptors. As far as I can see, a reasonable way to rethink the problem would be to start from the usual type-based semantics of Python, e.g. really defining a+b to mean a.__add__(b) or if it fails b.__radd__(a). The multimethod declarations would not be used for dispatching, but only to initialize the proper __add__ and __radd__ methods on the proper classes. This would give the cleanest result. This would probably be slower than the current multimethod dispatch hack, but being able to remove multimethod.py altogether is no small achievement in the direction of clarity :-) Then we could consider if we could reintroduce direct multimethod-style dispatching as an optional optimization. Well, just a thought. Maybe it's not worth the effort right now. There are only a few constructs missing to be able to run most "common" programs, for example super(). Defining super() at app-level Python should be possible, but is not currently because the required details don't work as expected. But we could define super() at interp-level and just forget about the whole issue for some time. On modules ---------- As always there is the open goal of implementing more built-in functions and modules, and making sure that more of the implemented features actually work. As always, we have two big missing features: the bytecode compiler and the import mechanism. Note that an easy but interesting goal would be to isolate a version of py.py that can be moved anywhere (as long as pypy is in the PYTHONPATH) and used as a replacement for the python executable. The first thing that usually fails whenever I try to start py.py on some program is an import statement. I'm not sure what the state of sys.path & co is. On everything I forget ---------------------- There are a lot of areas to work on too. For example writing docs, the trace object space, writing docs, more debugging support (kill these huge tracebacks!), porting the tests to 'std.utest' (I'll let Holger introduce this one to pypy-dev), organizing docs, cleaning up the wiki and replacing it with ReST docs ... A bientôt, Armin

2 1

Re: [pypy-dev] new autopath logic?
by Laura Creighton 14 May '04

14 May '04

In a message of Wed, 05 May 2004 18:42:37 +0200, holger krekel writes: >Hi, > >as many of you may know, we are using copies of pypy/tool/autopath.py in >a couple of places in order to insert a correct Python search path for >'import pypy.xxx.yyy' to succeed. With "import autopath" as the first li >ne >all the test_*.py can be invoked directly from the commandline and >directly run. However, autopath.py needs the information about the >top-directory ('pypy' in our case) to be encoded. It would be nicer >to have an autopath.py that is independent from a particular project. > >So what about trying to automize it completly like this: Start from the >directory where the invoked script/test is in and look upwards for a >directory *not* containing __init__.py anymore: This would be the >directory that needs to be ensured to be in sys.path. The last >one would we the autopath.projectdir so you can reference non-python >resource files in the project. > >I checked a bit and for pypy this should work as well as for >the other projects that use a clone of autopath.py. Opinions? > >cheers, > > holger Sounds good. Maybe we write a PEP and get it into the standard library, too. Laura

3 3

Is Rocco Moretti coming to EuroPython?
by Laura Creighton 14 May '04

14 May '04

Haven't heard anything from him recently. I was hoping he would be around for some Sprinting ... Laura

2 1

svn up: "object with the same name already exists"
by Armin Rigo 08 May '04

08 May '04

Hello, If you do an "svn up" it is going to fail. To solve that, delete the following two directories from your working copy: Pyrex Plex (These directories are at the same level as the one called "pypy".) Then do svn up again. The cause is that we switched to a new version of Pyrex and reorganized the repository to make it easier to switch to new versions in the future: Pyrex is now tracked in http://codespeak.net/svn/vendor/Pyrex/. It is copied from there and modified as needed for PyPy. See the svn commit message for details. As a result, the directory pypy/trunk/src/Pyrex, which used to be an external link, is now a real directory. Subversion doesn't realize the external link is gone before it tries to create the directory, and complains because a directory of the same name already exists in your working copy. Armin

1 0