Hi all, hi Aurelien, The stackless-related tests are all consistently failing nowadays. Some have been failing for 4 days and others for 9 days. See http://snake.cs.uni-duesseldorf.de/pypytest/summary.html Given that you appear to continue to work on it, but without making tests pass again, I'm a bit worrying exactly about what you are doing? That doesn't seem too much in line with the "test-driven development" approach. A bientot, Armin
On Fri, Jul 21, 2006 at 10:36:13PM +0200, Armin Rigo wrote:
First, I did some (superficial, nothing related to the translation aspect itself) changes that allowed me to build a (somewhat non-crashing) translated pypy-logic using clonable coroutines. These changes indeed broke some tests, in ways that I don't understand. Please note that indeed most failing tests in /modules/_stackless/test are due to run-time failures, after a successful translation. Michael put in a fix last week which, strangely, yielded a working version on ... PPC arch only. IOW, wizards needed for these cases. I'll have a look at the applevel stuff in /lib/test2 (the 3 tests pass all independantly but fail when executed in sequence), since I'm more likely directly responsible for breakage there.
That doesn't seem too much in line with the "test-driven development" approach.
Yes. Otoh, it seems that I'm currently the only consummer of these features, so I didn't feel the urge to rush to fix them immediately. I will look at them today. Regards, Aurélien.
Hi! Aurélien Campéas wrote:
It's just not good to have failing tests checked in. If they fail for good reasons and will probably work soon again, just skip them with an appropriate message. Otherwise it becomes impossible for somebody working in a related area to find out whether his changes were responsible for the breakage.
Well, that's not true. People wanted to try out stackless and couldn't because it didn't translate. I needed to do benchmarks and couldn't either. It's just a good general policy to have tranlations working all the time. Cheers, Carl Friedrich
Hi Aurelien, On Mon, Jul 24, 2006 at 12:21:52PM +0200, Aur?lien Camp?as wrote:
I did not look closely, so I cannot comment, but it seems to me that the tests and the demo we fixed during the post-EuroPython sprint all translated correctly, so I'm a bit surprized that you had to hack so much on the existing stackless code only for translatability reasons. This said, there were not many tests so far. That's also why I'm not happy to see half of them fail nowadays. The "agreed" development procedure for PyPy is to write more tests when a bug is identified or existing code doesn't translate in some context, and then make the test pass without breaking the previous tests (which are all valid, so again I'm surprized that you can compile anything at all when half of the basic tests fail). A bientot, Armin
On Mon, Jul 24, 2006 at 03:33:59PM +0200, Armin Rigo wrote:
svn blame currently shows how incredibly little I had to play with the code (to break it ... and have it fit my needs, and later make it translatable again). Apart from some temporary uncautious changes in interp_clonable from which one can trace back the first breakage, and that were fixed since, there is something else going on, that happened some time after. 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. I am tracking every change concerning stackless, now. Then, again, please consider that the current module/_stackless tests fail at RUNTIME. They translate perfectly well.
I am surprised, too. But I can exhibit the binary :) Regards, Aurélien.
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...
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
On Mon, Jul 24, 2006 at 08:32:35PM +0200, Armin Rigo wrote:
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
Sometimes people are on vacation. I apologize for the nuisance. Given the time to learn enough of subversion, I'll try to replay versions up to what caused these failures.
On 7/21/06, Armin Rigo <arigo@tunes.org> wrote:
I'll point out that Twisted has been avoiding issues such as these in the past 8 months or so by using a process that involves always branching the repository for developments and always getting a review before merging to trunk. The administrative overhead has definitely paid off in much, much higher code and test coverage. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/
On Fri, Jul 21, 2006 at 10:36:13PM +0200, Armin Rigo wrote:
First, I did some (superficial, nothing related to the translation aspect itself) changes that allowed me to build a (somewhat non-crashing) translated pypy-logic using clonable coroutines. These changes indeed broke some tests, in ways that I don't understand. Please note that indeed most failing tests in /modules/_stackless/test are due to run-time failures, after a successful translation. Michael put in a fix last week which, strangely, yielded a working version on ... PPC arch only. IOW, wizards needed for these cases. I'll have a look at the applevel stuff in /lib/test2 (the 3 tests pass all independantly but fail when executed in sequence), since I'm more likely directly responsible for breakage there.
That doesn't seem too much in line with the "test-driven development" approach.
Yes. Otoh, it seems that I'm currently the only consummer of these features, so I didn't feel the urge to rush to fix them immediately. I will look at them today. Regards, Aurélien.
Hi! Aurélien Campéas wrote:
It's just not good to have failing tests checked in. If they fail for good reasons and will probably work soon again, just skip them with an appropriate message. Otherwise it becomes impossible for somebody working in a related area to find out whether his changes were responsible for the breakage.
Well, that's not true. People wanted to try out stackless and couldn't because it didn't translate. I needed to do benchmarks and couldn't either. It's just a good general policy to have tranlations working all the time. Cheers, Carl Friedrich
Hi Aurelien, On Mon, Jul 24, 2006 at 12:21:52PM +0200, Aur?lien Camp?as wrote:
I did not look closely, so I cannot comment, but it seems to me that the tests and the demo we fixed during the post-EuroPython sprint all translated correctly, so I'm a bit surprized that you had to hack so much on the existing stackless code only for translatability reasons. This said, there were not many tests so far. That's also why I'm not happy to see half of them fail nowadays. The "agreed" development procedure for PyPy is to write more tests when a bug is identified or existing code doesn't translate in some context, and then make the test pass without breaking the previous tests (which are all valid, so again I'm surprized that you can compile anything at all when half of the basic tests fail). A bientot, Armin
On Mon, Jul 24, 2006 at 03:33:59PM +0200, Armin Rigo wrote:
svn blame currently shows how incredibly little I had to play with the code (to break it ... and have it fit my needs, and later make it translatable again). Apart from some temporary uncautious changes in interp_clonable from which one can trace back the first breakage, and that were fixed since, there is something else going on, that happened some time after. 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. I am tracking every change concerning stackless, now. Then, again, please consider that the current module/_stackless tests fail at RUNTIME. They translate perfectly well.
I am surprised, too. But I can exhibit the binary :) Regards, Aurélien.
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...
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
On Mon, Jul 24, 2006 at 08:32:35PM +0200, Armin Rigo wrote:
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
Sometimes people are on vacation. I apologize for the nuisance. Given the time to learn enough of subversion, I'll try to replay versions up to what caused these failures.
On 7/21/06, Armin Rigo <arigo@tunes.org> wrote:
I'll point out that Twisted has been avoiding issues such as these in the past 8 months or so by using a process that involves always branching the repository for developments and always getting a review before merging to trunk. The administrative overhead has definitely paid off in much, much higher code and test coverage. -- Christopher Armstrong International Man of Twistery http://radix.twistedmatrix.com/ http://twistedmatrix.com/ http://canonical.com/
participants (4)
-
Armin Rigo -
Aurélien Campéas -
Carl Friedrich Bolz -
Christopher Armstrong