On Apr 19, 7:21 pm, Piet van Oostrum wrote:
> while time.time() - t < 0.5 or not self._modified:
> print >> sys.stderr, "Going to sleep\n"
> self._mod_lock.wait(timeout=1)
> print >> sys.stderr, "Ok time to see if we must
On Apr 19, 4:50 pm, a...@pythoncraft.com (Aahz) wrote:
> The redraw thread should keep track of the last time it did a redraw;
> each time it receives an update event, it should check to see whether it
> has been more than a specified period of time since the last redraw.
That's what I do ;)
--
ht
On Apr 19, 3:14 pm, stephane.bisin...@gmail.com wrote:
> Ok here's the deal: I'm not ending up in the gtk frontend. My code is
> for the ncurses frontend, so there is no "import gtk" and "gtk.main()"
> that gets executed in that case. But it is definitely around the
> gobject thing, I'll try to sea
On Apr 19, 2:31 pm, Piet van Oostrum wrote:
> It appears that GTK and Python threads are incompatible UNLESS you call
> gtk.gdk.threads_init() before gtk.main(). In your case you can do it
> after the import gtk in contact_list.py. Then it should work.
Ok here's the deal: I'm not ending up in the
On Apr 18, 8:29 pm, Piet van Oostrum wrote:
> 2. Importing in a thread is discouraged. I think it is cleaner to put
> the import sys in the top of the module.
Yes I know I shouldn't import inside of threads, but that is something
that is going away, it's just for debugging this issue.
On Apr
On Apr 18, 5:54 pm, Filip Gruszczyński wrote:
> Yep, I have heard a lot about test driven development. I am now
> programming a lot using DJango and I would like to use its test
> framework to try it. However, I have little experience with this (as
> most people I know). I also have no idea, how t
On Apr 18, 4:44 pm, a...@pythoncraft.com (Aahz) wrote:
> This observation was originally made in _The Mythical Man-Month_ by Fred
> Brooks, which ought to be required reading for all programmers.
I miss that one, yet :( Nice to know, though
--
http://mail.python.org/mailman/listinfo/python-list
On Apr 18, 4:28 pm, a...@pythoncraft.com (Aahz) wrote:
> Essentially, you use the Queue instead of the Condition. When you want
> to explicitly give up control in a thread, you get() on the Queue until
> you get an object (with the optional timeout). When the other thread is
> done processing, it
On Apr 18, 12:48 pm, Filip Gruszczyński wrote:
> So, do you know some good methods to prevent myself from just starting
> coding (which I like very much) and do some thinking about the problem
> (which I like a little less ;-))?
Well you know, the thing is that according to Pike & Kernighan in "T
On Apr 18, 2:05 pm, a...@pythoncraft.com (Aahz) wrote:
> Whether or not there's a bug, you likely will simplify your code if you
> switch to using a Queue().
I'm sorry, but I can't see how the queue would help me on this, since
I only have 2 threads and the documentation esplicitly states that it
On Apr 18, 10:24 am, Piet van Oostrum wrote:
>
> I haven't run it (too much hassle to setup) but I noticed one strange
> thing in your code:
>
> ,
> | def groupUpdated(self, gView):
> | # Acquire the lock to do modifications
> | self._mod_lock.acquire()
> |
> | if not
Hi all,
I have a problem with Condition.wait(), it doesn't return after the
given timeout. The thing is that if I try to create a simple program,
it works as expected, but in the actual code, the timeout is not
respected (albeit the notify()s work as expected).
You can find the code I am talking ab
12 matches
Mail list logo
