[pypy-dev] Failing stackless tests

Armin Rigo arigo at tunes.org
Mon Jul 24 20:32:35 CEST 2006


Hi Aurelien,

On Mon, Jul 24, 2006 at 03:56:27PM +0200, Aur?lien Camp?as wrote:
> svn blame currently shows how incredibly little I had to play with the
> code

Well, that's hardly an argument, is it?  I know that the code is
obscure, and you're welcome to ask questions here and on IRC.  I also
know from experience that making coroutines translatable can trigger
obscure problems.  It doesn't change the basic issue that breaking tests
without worrying about them is not a good way to go forward...

> The current breakage is, I think, unrelated to my
> misdoings. This fact is just masked by the insufficient granularity of
> http://snake.cs.uni-duesseldorf.de/pypytest/summary.html.

Well, at least one of these tests - test_coroutine_reconstruction - has
been breaking in the same way since your rev 30119.  For the other
tests, knowing exactly what is the cause of the current breakage is
difficult, and that's precisely because the tests were already failing.
This prevents us from easily tracking what breaks what.  For now "naive"
tracking tells me that you broke the tests first...

> Then, again, please consider that the current module/_stackless tests
> fail at RUNTIME. They translate perfectly well.

I don't see how that is an argument, either.

As far as I can tell, the only way out of this kind of mess is to revert
to the first revision before the first failure, and try to re-understand
the diff of that initial breaking revision, debug until we see what the
problem was, and then attempt to fix it in the head.  That's certainly
more work than needed because of the revision-juggling involved.

I'd appreciate it if you could tell us if you're going to do that, or if
there is something out of your scope going on.  I'd like this situation
to be resolved.


A bientot,

Armin



More information about the Pypy-dev mailing list