Rick van Hattem

I love the multibar hack but I still think there is a need for a good multi progressbar solution. There are several limitations to this implementation which makes it hard/impractical...

As a reasonable workaround, I've wrote this little bit of script: ```python import sys import time import progressbar class LineOffsetStreamWrapper: UP = '\033[F' DOWN = '\033[B' def __init__(self, lines=0, stream=sys.stderr):...

I'm guessing that the issue is that you are using separate processes for the logging and the progress bar. The progressbar only redirects the stderr output while it's running and...

Think of it this way, you'll have a single process responsible for all user interaction. That is actually how most GUI libraries work as well., a single process for all...

The random part makes me wonder a bit, that could be due to a timing issue but it's still a bit weird. In any case, dill seems to call some...

Well... honestly, it's the first time it's come up so far. The module has currently no support for threads whatsoever. I suppose it would be possible with a bit of...

The current method effectively comes down to this simple bit of code: https://github.com/WoLpH/python-progressbar/blob/02164e1d6db4c047c625fe368d4aece3ff4403a0/progressbar/bar.py#L143-L146 So nothing too fancy, simply overwriting the line again. The method you're using is a lot more...

It took me a while to thoroughly read your very detailed message, I fully agree though! :) What I'm currently planning on doing is using your code to implement a...

How about this? :) ```python import random import sys import threading import time import progressbar output_lock = threading.Lock() class LineOffsetStreamWrapper: UP = '\033[F' DOWN = '\033[B' def __init__(self, lines=0, stream=sys.stderr):...

It's indeed a far better idea to have the background threads communicate the status back to the main thread instead of locking all the time, but that's why it's just...