[pypy-dev] Re: [pypy-sprint] vilnius sprint planning progress

holger krekel hpk at trillke.net
Mon Oct 18 11:47:40 CEST 2004

Hi Armin, 

[Armin Rigo Mon, Oct 18, 2004 at 10:19:30AM +0100]
> Hi Holger,
> I don't know why, but your answer never reached pypy-dev (as far as I can 
> tell) so I missed it.  Sorry for the delay.  I will answer with extensive 
> quotes, in case nobody else received it either.

the wonders of email systems and spam filtering at work i guess ... 
the email is in the pypy-dev archive, though. 
> On Mon, Oct 11, 2004 at 10:26:30PM +0200, holger krekel wrote:
> > > A. PyPy -> FlowGraph
> > > ====================
> > 
> > Because of the current way 'genc.py' is done we can mostly
> > forget about "module completeness" for this goal, right? But
> > for example, we need to properly get stdout/file interaction
> > working otherwise we will never get any output from our first
> > translated PyPy/C version. I am not quite clear on how far the
> > current genc.py goes in letting us use the CPython runtime.
> This is not a problem.  The extension module generated by genc.py manipulates
> PyObject* pointers borrowed from CPython.  In this respect genc.py is exactly
> like the old Python2C: if our quasi-RPython code currently uses 'file' or
> other borrowed objects then what you get in the C code is a lot of calls like
> PyObject_Call(&PyFile_Type) and PyObject_GetAttrString(f, "read").

ok, i was more refering to the fact that 'file' currently is a "faked type"
and i am not sure if that translates properly.  But given that we just
use the underlying cpython runtime API it should work. 
> > > The goal would be to get a complete graph, which the
> > > existing genc.py can (mostly) already translate to C and run, for testing.
> > 
> > Well, i consider the how-to-do-exceptions question still a major 
> > problem.
> It wasn't that complex.  I did it in a recent check-in :-)  Of course, it's
> cheating -- it uses CPython's exception mechanisms and conventions like
> returning NULL in case of error.  But it's just fine for now.

ah ok.  Are exceptions represented in the flow graph already? 
yes, i should read the code some more :-) 

> > > B. FlowGraph -> Optimized FlowGraph
> > > ===================================
> [some overview of what  other languages with respect to inlining]
> ... 
> Something else, I now know how to write down the graph transformation rules,
> in particular the new flow graph that should replace an operation.  Forget a
> new textual syntax for flow graphs, with a parser and everything.  We can use
> the plain RPython syntax and build flow graphs with the FlowObjSpace.  For 
> example:
> def inplace_add__List(lst, iterable):
>     for x in iterable:
>         lst.append(x)
>     return lst
> is a clear way to express that the operation 'inplace_add', when the first
> argument is a list, should be replaced by (the flow graph of) the body of this
> function.

good idea.  Obviously, we want to avoid cyclic transformation rules. 

cheers & looking forward to the sprint, 


P.S.: i have set your date on the sprint wiki pages, please check 
      i plan to arrive early 13th or even the 12th of Nov if there
      is no early flight on 13th. And i am going to invite everyone
      who is there on 14th of nov (my birthday) to a couple of beers 
      or whatevers :-) 

More information about the Pypy-dev mailing list