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,
holger
P.S.: i have set your date on the sprint wiki pages, please check
http://codespeak.net/moin/pypy/moin.cgi/VilniusSprintAttendants
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 :-)
_______________________________________________
[EMAIL PROTECTED]
http://codespeak.net/mailman/listinfo/pypy-dev
