progress_bar.. improving the accuracy

Manuel,

   I see you are trying to fine tune the delay variable,
compensate for 
bash overhead. I did not know you wanted a precise time
display so I 
never validated the timestamp.. it looked close enough for
government 
work 
However it lost time even on my machine.

   I have included a different concept for the progress bar.
Instead of 
counting seconds via timed loop just use the bash internal
variable 
$SECONDS.

   notes::
   Occasionally you will see an empty space in the progress
bar and that 
is due to the priority assigned to unpacking a large
package. Since we 
are using actual seconds and not counts the space will be
'missed' 
seconds.  The graphic chars are written to a cursor location
set by the 
'second' and not an incremented counter. Also, if we miss
the the magic 
60th second we will catch the rollover and reset the line
later.

   Does this method have holes.. possibly, I thought the
previous 
version was usable (and I was wrong)


   # initialize screen
write_or_exit "$$0 min. 0
sec. "
while true ; do  # loop forever..

       # Loop through the animation string
     for GRAPHIC_CHAR in $ ; do
       write_or_exit "$$((SEC +
3))G$"
       sleep .14  # This value MUST be less than .2 seconds.
     done

       # A BASH internal variable, the number of seconds the
script
       # has been running. modulo convert to 0-59
     SEC=$(($SECONDS % 60))

       # Detect rollover of the seconds..
     (( PREV_SEC > SEC )) && write_or_exit
"$"
     (( PREV_SEC = SEC ))

       # Display the accumulated time. div minutes.. modulo
seconds.
     write_or_exit "$$(($SECONDS / 60))
min. $SEC sec. "
done
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page

El Sábado, 10 de Junio de 2006 05:34, George Boudreau
escribió:
> Manuel,
>
>    I see you are trying to fine tune the delay
variable, compensate for
> bash overhead. I did not know you wanted a precise time
display so I
> never validated the timestamp.. it looked close enough
for government
> work  However it
lost time even on my machine.

Well, accuracy isn't the goal, but the previous version was
loosing 16 secs. 
each minute on my machine, and that looks excessive to me
 

>    I have included a different concept for the progress
bar. Instead of
> counting seconds via timed loop just use the bash
internal variable
> $SECONDS.

Great.

>    notes::
>    Occasionally you will see an empty space in the
progress bar and that
> is due to the priority assigned to unpacking a large
package. Since we
> are using actual seconds and not counts the space will
be 'missed'
> seconds.  

In my tests the blank space in printed aprox. each 30-80
seconds, depending on 
CPU load. Looks like it's auto-adjusting the cursor speed
and the time 
counter to the system clock. 

Using any sleep value <= .13 there is no blank spaces
(the same position is 
drawed two times when the adjusting occurs) and the time
counter keep 
accurate with system clock.

I will commit it with sleep .12, that looks more failsafe,
after build some 
more targets.

>    Does this method have holes.. possibly.

Don't found any hole yet 

-- 
Manuel Canales Esparcia
Usuario de LFS nº2886:       http://www.linuxfroms
cratch.org
LFS en castellano: http://www.escomp
oslinux.org/lfs-es http://www.lfs-es.com
TLDP-ES:                           http://es.tldp.org
-- 
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page