Bug#397469: #397469 was a bug in python-adns
On Fri, 17 Nov 2006, Yavor Doganov wrote: Perhaps the maintainer should revert this NMU with the next upload, I don't know whether Tuukka's patch is harmless. It's also fairly easy to see that the patch is harmless, because timeout only affects the time select waits, and we wait the remaining time in the following lines of URLFetch.py anyway, before the next run. Sorry, I didn't mean to offend you. I'm very grateful for what you did. I meant that if really the bug was in python-adns (which is not the case), [maybe] the patch should be reverted. Also, it's not easy for me to judge as my Python knowledge is zero. No harm done, I just wanted to explain the thinking behind the patch. Thank you for the report so we finally got this long-standing issue fixed, and thank you to Sesse for the quick upload. -- -- Trying to catch me? Just follow up my Electric Fingerprints -- To help you: [EMAIL PROTECTED] http://www.iki.fi/Tuukka.Hastrup/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397469: #397469 was a bug in python-adns
Hi Yavor, On Thu, 16 Nov 2006, Yavor Doganov wrote: It seems that this was a bug in python-adns, since today 1.1.0-2 entered testing and straw behaves as expected (without your patch). I'm so sorry that I didn't test it with python-adns from unstable. python-adns 1.1.0-2 doesn't fix the problem in my tests. There is only a fix to make it build from source again, and libadns1 version remains the same. A fix in python-adns would need to change ADNS.py method run or adnsmodule.c method ADNS_State_select. It's easy to see that when no adns IO is happening, it sleeps the given time because it calls select. As the problem is a kind of starvation issue and it mostly just slows things down, I can accept that something has changed in your system which alleviates the symptoms. In any case, you might want to double-check that you really are testing with the unpatched straw 0.26.dsfg.1-2. Perhaps the maintainer should revert this NMU with the next upload, I don't know whether Tuukka's patch is harmless. It's also fairly easy to see that the patch is harmless, because timeout only affects the time select waits, and we wait the remaining time in the following lines of URLFetch.py anyway, before the next run. -- -- Trying to catch me? Just follow up my Electric Fingerprints -- To help you: [EMAIL PROTECTED] http://www.iki.fi/Tuukka.Hastrup/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397469: straw: Does not work with python-adns installed
tags 397469 patch thanks I think I found out what this bug is about. If I'm wrong, I hope the original submitter or someone else can provide more info. I'm testing with the latest versions of straw and python-adns, just as the submitter. In my tests, refreshing and subscribing work, but they take intolerably long (at least ten minutes). For me, this has been the case with the versions in Sarge too. The following change makes refreshing and subscribing work quickly for me: --- LookupManager.py.orig 2006-02-18 18:22:44.0 +0200 +++ LookupManager.py2006-11-13 17:04:24.0 +0200 @@ -161,7 +161,7 @@ cbwrapper.cb(ip) def poll(self, timeout=0.1): -self.queryengine.run(timeout) +self.queryengine.run(0) # Blocking version: use normal lookups, no threads class BlockingLookupManager: The problem is that without the change this function will use up all of the given time and leave no time for other network IO as seen in URLFetch.py lines 165-170: # keep the network running now = time.time() lookup_manager.poll(timeout) timeout -= (time.time() - now) if timeout 0.0: asyncore.poll(timeout) The change is also in line with how the ThreadLookupManager is implemented: if there are no results pending, poll doesn't take time at all. Hope this helps, Tuukka -- -- Trying to catch me? Just follow up my Electric Fingerprints -- To help you: [EMAIL PROTECTED] http://www.iki.fi/Tuukka.Hastrup/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392774: wormux: blocks the whole X session when GNU touches the first object
Hi, I had a look at this bug and one simple fix you could at least do is switch the possibly endless loops into an fmod function call. This would reduce the severity of this bug significantly. --- src/weapon/gnu.cpp.orig 2006-11-12 01:08:13.0 +0200 +++ src/weapon/gnu.cpp 2006-11-12 01:12:57.0 +0200 @@ -80,8 +80,7 @@ //sometimes, angle==infinite (according to gdb) ?? GetSpeed(norme, angle); - while(angle -M_PI) angle += M_PI; - while(angle M_PI) angle -= M_PI; + angle = fmod(angle, M_PI); angle *= 180.0 / M_PI; angle /= 2.0; And #include math.h By the way, there seem to be similarily unnecessary loops in src/graphic/sprite.cpp, src/map/ground.cpp, src/map/water.cpp Regards, Tuukka Hastrup -- -- Trying to catch me? Just follow up my Electric Fingerprints -- To help you: [EMAIL PROTECTED] http://www.iki.fi/Tuukka.Hastrup/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
