Hello pypy-dev,
i just noticed that Jonathan David Riehl has sent a message
to pypy-dev(a)codespeak.com
^^^^^
which didn't work (codespeak.NET would be right). So i resent
my reply to his message which actually cites all of his mail.
cheers,
holger
----- Forwarded message from holger krekel <hpk(a)trillke.net> -----
Date: Wed, 2 Jul 2003 21:29:59 +0200
From: holger krekel <hpk(a)trillke.net>
To: Jonathan David Riehl <jriehl(a)cs.uchicago.edu>
…
[View More]Cc: pypy-dev(a)codespeak.com
Subject: Re: Greetings
In-Reply-To: <Pine.LNX.4.44.0307021343060.19507-100000(a)pennsylvanian.cs.uchicago.edu>; from jriehl(a)cs.uchicago.edu on Wed, Jul 02, 2003 at 01:45:30PM -0500
Hello Jonathan!
[Jonathan David Riehl Wed, Jul 02, 2003 at 01:45:30PM -0500]
> Hi everyone,
> I noticed Christian was trying to steer a newbie over on
> python-dev over to PyPy, and I was thinking that I might be able to help
> as well. Chris suggested I formally introduce myself to the group and see
> what can be done.
Good idea :-)
> I've done work on translation of Python to C, as well as creating
> other static analysis tools. Most of that work was done while I was at
> NASA, where political kinks halted my work. Five years later, I have
> finally managed to get back into a research environment, and I am now
> working on a PhD at the University of Chicago, studying under Dave
> Beazley.
Makes me envious.
> Instead of restarting work on my own Python compiler (Python to
> C translation style), I figure I would see if we could work together.
Right. That certainly makes sense.
> The only problem I see is that I'm in the US, and attending
> sprints may be difficult on a student's budget. Hopefully, we can still
> have a tight development loop via IRC.
After the last sprints and EuroPython everyone needs to catch some
breath, i guess. I am usually hanging out on #pypy on irc.freenode.net.
You are welcome :-)
> So now to ask the obvious newbie questions: What needs to be
> done? What is cool that could be done? How can I help? I'm also more
> than happy to talk about what I have done as well, if anyone is curious.
I can't answer too long because i am currently cooking :-)
And probably Armin (Rigo) or others might give a more detailed answer, anyway.
But it's always a good idea to check out the source code. Therefore
you need a "subversion" client. Jens-Uwe Mager has prepared some
client side installs:
http://codespeak.net/pypy/doc/devel/howtosvn.html
In this doc-directory (http://codespeak.net/pypy/doc) you'll also find some
unsorted documentation which might help in understanding what we have been
doing this year.
Also, at least i am quite interested to get to know what you have done
or what you found out about Python-to-C translators.
cheers,
holger
----- End forwarded message -----
[View Less]
At 12:29 02.07.2003 -0400, Guido van Rossum wrote:
> > I have committed a different fix: a cycle doesn't reach a fix point as
> long
> > as there's a W_ConstantIterator which is being consumed.
>
>This works now, but it makes me worry. I think that the symbolic
>execution framework doesn't really cope very well with mutable
>objects; I expect that we'll get other problems like this.
>
>I wonder if you or Armin have a better idea on how to deal with this?
>I'…
[View More]d think that maintaining a 'changed-since-last-clone' flag in each
>object seems a pretty ad-hoc solution...
the problem is our fix-point condition which is mostly based purely on types,
and that we are trying to have it both ways, doing some mixture of constant
propagation (normal eval) and type propagation, if you consider code like this:
x = 0
while True:
x = x + 2
type propagation can end, but constant evaluation will give an infinite loop.
So we should clarify what we really want.
One possibility is optinally instead of using types to decide fix-points,
we stop if some bytecode (position) has been encountered more than N times.
regards.
[View Less]
At 07:54 01.07.2003 -0400, Guido van Rossum wrote:
>I'm hoping Armin has some time to look into this; I probably won't.
>
>There's this test that doesn't work any more:
>
> def dont_test_assign_local_w_flow_control(self):
> # XXX This test doesn't work any more -- disabled for now
> code = """
>def f(n):
> total = 0
> for i in range(n):
> total = total + 1
> return n
>"""
> x = self.codetest(code, 'f', […
[View More]self.space.wrap(3)])
> self.assertEquals(type(x), W_Integer)
'self.assertEquals(type(x), W_Integer)' should be
'self.assertEquals(type(x), W_Constant)'
or we should have a 'return total' instead of 'return n'
>It worked before, when range(n) was enough to befuddle the symbolic
>interpretation, but now, when you enable it (remove the "dont_" from
>the name) it raises "TypeError: no result at all?!?!"
>
>This seems to be because the next() call implicit in the for loop
>doesn't ever raise IndeterminateCondition, because it is iterating
>over a constant list (the list [0, 1, 2] returned by range(3)). But
>somehome frame unification decides to unify states after the 2nd time
>through the loop -- and the alternative branch (to the end of the
>loop) is never taken, so there is never a return value.
>
>What's wrong here???
this should fix it:
Index: pypy/objspace/ann/objspace.py
===================================================================
--- pypy/objspace/ann/objspace.py (revision 1076)
+++ pypy/objspace/ann/objspace.py (working copy)
@@ -285,16 +285,16 @@
force = w_iterator.force
w_iterator.force = None
if force:
+ if isinstance(w_iterator, W_ConstantIterator):
+ try:
+ value = w_iterator.next()
+ except StopIteration:
+ raise NoValue # XXX could be also ExitFrame?
+ else:
+ return self.wrap(value)
return W_Anything()
else:
raise NoValue
- if isinstance(w_iterator, W_ConstantIterator):
- try:
- value = w_iterator.next()
- except StopIteration:
- raise NoValue
- else:
- return self.wrap(value)
raise IndeterminateCondition(w_iterator)
def call(self, w_func, w_args, w_kwds):
[View Less]
I'm hoping Armin has some time to look into this; I probably won't.
There's this test that doesn't work any more:
def dont_test_assign_local_w_flow_control(self):
# XXX This test doesn't work any more -- disabled for now
code = """
def f(n):
total = 0
for i in range(n):
total = total + 1
return n
"""
x = self.codetest(code, 'f', [self.space.wrap(3)])
self.assertEquals(type(x), W_Integer)
It worked before, when range(n) was enough to …
[View More]befuddle the symbolic
interpretation, but now, when you enable it (remove the "dont_" from
the name) it raises "TypeError: no result at all?!?!"
This seems to be because the next() call implicit in the for loop
doesn't ever raise IndeterminateCondition, because it is iterating
over a constant list (the list [0, 1, 2] returned by range(3)). But
somehome frame unification decides to unify states after the 2nd time
through the loop -- and the alternative branch (to the end of the
loop) is never taken, so there is never a return value.
What's wrong here???
--Guido van Rossum (home page: http://www.python.org/~guido/)
[View Less]
