Open adityagupta1089 opened 3 years ago
@roelvandijk seems about right. I missed that part. But I am not sure why I was getting a divide by zero error: I was working on a project where the total tasks was say 300, but it's depth-first search, so each task can add more tasks, I tried to use updateProgressBar to set progressTodo += n. So in this case progress can move from 0/300 to 0/(300+n) which makes estimatedtotalTime = recip 0 giving an exception. Let me know if there would've been a better way to handle this.
@roelvandijk This is the MWE that I came up with.
module Main where
import Control.Concurrent
import Control.Monad
import Control.Monad.IO.Class
import Control.Monad.Trans.State
import System.ProgressBar
import System.Random
main :: IO ()
main = evalStateT go 0
where
go :: StateT Int IO ()
go = do
pb <- liftIO $ newProgressBar pbStyle 10 (Progress 0 300 ())
forM_ [0 .. 10] $ \i -> do
when (mod i 3 /= 2) $ do
liftIO $ threadDelay 1000000 -- some time spent in getting child task count
(extra, _) <- liftIO $ randomR (0, 10) <$> getStdGen -- children tasks count
liftIO $ updateProgress pb $ \p ->
p { progressTodo = extra + progressTodo p } -- add to work todo
modify (+ extra) -- store tasks
when (mod i 3 == 2) $ do
v <- get -- get child tasks
liftIO $ threadDelay 1000000 -- complete them
liftIO $ incProgress pb (3 + v) -- update progress for both
put 0 -- reset pending child tasks count
Why is this check necessary? There is already a guard against
progressDone progress <= 0
: https://github.com/roelvandijk/terminal-progress-bar/blob/1035be45476c72e6bb2c6d73040c4e0d24e784b9/lib/src/System/ProgressBar.hs#L572 SettingprogressFraction
to 1 whenprogressDone progress <= 0
would prevent the alternative message from being shown in some circumstances.