Guido van Rossum | 1 Jul 13:54 2003

Annotating space status

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 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/)
(Continue reading)

Michael Hudson | 1 Jul 15:29 2003
Picon

Re: [pypy-svn] rev 1073 - in pypy/trunk/src/pypy: interpreter/test objspace/std tool

hpk <at> codespeak.net writes:

> Author: hpk
> Date: Mon Jun 30 17:41:07 2003
> New Revision: 1073
>
> Modified:
>    pypy/trunk/src/pypy/interpreter/test/test_interpreter.py
>    pypy/trunk/src/pypy/objspace/std/register_all.py   (props changed)
>    pypy/trunk/src/pypy/objspace/std/stringobject.py
>    pypy/trunk/src/pypy/tool/test.py
> Log:
> - improved the hack to perform specific objspace tests only when
>   actually running the tests with the respective objspace. 
>   (i.e. objspace.ann* tests are skipped for StdObjSpace and
>    objspace.std* for AnnObjSpace)

I think *a* way to do this nicely is to have test.objspace() raise a
"TestSkip" exception when asked for a specific object space that is
not the one currently being tested.  This probably means rewriting
more of unittest.py, though (we want four possible outcomes: pass,
fail, error, skip).

Cheers,
M.

--

-- 
  same software, different verbosity settings (this one goes to
  eleven)                             -- the effbot on the martellibot
_______________________________________________
(Continue reading)

holger krekel | 1 Jul 21:58 2003
Picon

Re: unittest-module (was: some pypy-svn checkin)

[Michael Hudson Tue, Jul 01, 2003 at 02:29:00PM +0100]
> hpk <at> codespeak.net writes:
> > Log:
> > - improved the hack to perform specific objspace tests only when
> >   actually running the tests with the respective objspace. 
> >   (i.e. objspace.ann* tests are skipped for StdObjSpace and
> >    objspace.std* for AnnObjSpace)
> 
> I think *a* way to do this nicely is to have test.objspace() raise a
> "TestSkip" exception when asked for a specific object space that is
> not the one currently being tested.

I agree this is a good way. Also the "shouldStop" stuff would probably
be better implemented by a Control-Flow Exception. 

> This probably means rewriting
> more of unittest.py, though (we want four possible outcomes: pass,
> fail, error, skip).

yep, looking at the unittest.py source this probably means overriding
even more methods. To be honest IMO we should make our life easier and 
just drag unittest.py from python-2.3, add "skips", remove the
leading "__" from some names plus probably do some other
cleanups/niceties.  Doesn't seem like incredibly hard work
and we may offer it back to cpython, later :-)
What do you think? 

cheers,

    holger
(Continue reading)

Samuele Pedroni | 1 Jul 22:17 2003
Picon

Re: Annotating space status

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', [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
(Continue reading)

Samuele Pedroni | 2 Jul 00:35 2003
Picon

Re: Annotating space status

At 22:17 01.07.2003 +0200, Samuele Pedroni wrote:

>this should fix it:

truth to be told no, it would break the special helper function 
evalutation, which is (indirectly) tested by test_build_class only for the 
moment, a test that works only under 2.3 btw.

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.

regards.

_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Michael Hudson | 2 Jul 12:34 2003
Picon

Re: unittest-module

holger krekel <hpk <at> trillke.net> writes:

> [Michael Hudson Tue, Jul 01, 2003 at 02:29:00PM +0100]
>> hpk <at> codespeak.net writes:
>> > Log:
>> > - improved the hack to perform specific objspace tests only when
>> >   actually running the tests with the respective objspace. 
>> >   (i.e. objspace.ann* tests are skipped for StdObjSpace and
>> >    objspace.std* for AnnObjSpace)
>> 
>> I think *a* way to do this nicely is to have test.objspace() raise a
>> "TestSkip" exception when asked for a specific object space that is
>> not the one currently being tested.
>
> I agree this is a good way. Also the "shouldStop" stuff would probably
> be better implemented by a Control-Flow Exception. 

?  Not sure I follow.  The same sort of control flow exceptions the
annotation object space uses?

>> This probably means rewriting
>> more of unittest.py, though (we want four possible outcomes: pass,
>> fail, error, skip).
>
> yep, looking at the unittest.py source this probably means
> overriding even more methods. To be honest IMO we should make our
> life easier and just drag unittest.py from python-2.3, add "skips",
> remove the leading "__" from some names plus probably do some other
> cleanups/niceties.

(Continue reading)

holger krekel | 2 Jul 13:04 2003
Picon

Re: Re: unittest-module

[Michael Hudson Wed, Jul 02, 2003 at 11:34:31AM +0100]
> holger krekel <hpk <at> trillke.net> writes:
> 
> > [Michael Hudson Tue, Jul 01, 2003 at 02:29:00PM +0100]
> >> hpk <at> codespeak.net writes:
> >> > Log:
> >> > - improved the hack to perform specific objspace tests only when
> >> >   actually running the tests with the respective objspace. 
> >> >   (i.e. objspace.ann* tests are skipped for StdObjSpace and
> >> >    objspace.std* for AnnObjSpace)
> >> 
> >> I think *a* way to do this nicely is to have test.objspace() raise a
> >> "TestSkip" exception when asked for a specific object space that is
> >> not the one currently being tested.
> >
> > I agree this is a good way. Also the "shouldStop" stuff would probably
> > be better implemented by a Control-Flow Exception. 
> 
> ?  Not sure I follow.  The same sort of control flow exceptions the
> annotation object space uses?

No, sorry, that was unclear.  I just meant *a* control-flow exception
(not the interpreter ones) and more specifically, that the attribute 
"shouldStop" which is set on a TestResult instance and checked for at 
upper layers.  I think the generally cleaner way is to define an exception 
hieararchy like

    TestFlowException
    |
    |-- TestSkipException
(Continue reading)

Guido van Rossum | 2 Jul 18:29 2003

Re: Annotating space status

> 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'd think that maintaining a 'changed-since-last-clone' flag in each
object seems a pretty ad-hoc solution...

--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev

Samuele Pedroni | 2 Jul 19:09 2003
Picon

Re: Annotating space status

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'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. 

(Continue reading)

Guido van Rossum | 2 Jul 21:18 2003

Re: Annotating space status

> 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.

Right.  We could differentiate this by using the differentiation of
object space and execution context for evaluation of internal helpers.

Those helpers want constant evaluation, and they already get a
different object space (a subclass of the annotating object space).
The space controls the execution context, and the execution context
controls whether we check for fix-point conditions.

The "real" code would continue to use the "normal" annotation space
and would do full type propagation.

Unfortunately I won't have time to work on this...
(Continue reading)


Gmane