bashdb-devel

[Bashdb-devel] reading progress...

[Masatake Y. <je...@gy...>]

I've changed the reading progress notation to percentage style.
If we can show a progress bar, it may be the best.
But, I don't know how to erase written string on a terminal in a shell script.

Masatake YAMATO

Index: debugger/dbg-io.inc
===================================================================
RCS file: /cvsroot/bashdb/bashdb/debugger/dbg-io.inc,v
retrieving revision 1.8
diff -u -r1.8 dbg-io.inc
--- debugger/dbg-io.inc	12 Nov 2003 11:48:51 -0000	1.8
+++ debugger/dbg-io.inc	16 May 2004 17:27:53 -0000
@@ -109,6 +109,7 @@
     i=1
   else 
     local fullname=$(_Dbg_resolve_expand_filename $filename)
+    local line_count=`cat $fullname|wc -l`
     filevar=`_Dbg_file2var $filename`
     if [[ -r $fullname ]] ; then
       for (( i=1; 1 ; i++ )) ; do 
@@ -116,8 +117,8 @@
 	local readline_cmd="read -r $source_entry; rc=\$?";
 	local -i rc=1
 	if (( i % 1000 == 0 )) ; then
-	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename "
-	  _Dbg_msg_nocr "${i}... "
+	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename: \n"
+	  _Dbg_msg_nocr "\t$(( 100 * ${i} / ${line_count} ))%..."
 	fi
 	eval $readline_cmd
 	if [[ $rc != 0 ]]  ; then 

[Bashdb-devel] reading progress...

[R. B. <ro...@pa...>]

Masatake YAMATO writes:
 > I've changed the reading progress notation to percentage style.
 > If we can show a progress bar, it may be the best.
 > But, I don't know how to erase written string on a terminal in a shell script.

I have some reservations about the patch below. I'm not against giving
percentage versus lines read in per se. But here it comes with a some
cost and perhaps reliability. The patch assumes that "wc" and "cat"
are available commands and are in the path. (With extra work configure
could check this and hard-code in the paths).  I don't belive the rest
of the debugger makes use of either "cat" or "wc".  Perhaps the build
system does, but I suppose that's okay since it is for developers. I
don't know, I may be overly fussy here. 

And there's something I find weird about running a "cat | wc -l" just
to get the total number of lines in a file. Right now, For the simple
cases where the script is under a 1,000 lines, no extra work is done
no, wc'ing no cat'ing no line printing. In those cases where one
needs to print out status because the file is large, running 'cat | wc
-l' slows things down more.

But this is just my view. What do others think? If folks feel the
benefits outweigh whatever disadvantages, by all means add it.

If the patch is added, some small comments. 

 > +    local line_count=`cat $fullname|wc -l`

local -i might be better. I would be neat if there were a way to give
$fullname to wc rather than piple the whole file to wc.  Also, I think
it clear when the definition is put as close as possible to would be 
after the test on $fullname. 

 > +	  (( i==1000 )) && _Dbg_msg_nocr "Reading $filename: \n"
 > +	  _Dbg_msg_nocr "\t$(( 100 * ${i} / ${line_count} ))%..."

One should check that $line_count is not 0 before dividing. If it is
zero (perhaps something went wrong) then probably one should fall back
to giving line number counts. 

Re: [Bashdb-devel] reading progress...

[R. B. <ro...@pa...>]

Masatake YAMATO writes:
 > We can check the existence of wc at runtime.

Okay, that adds to reliability. 

 > We can use wc when if it exists. cat can be replaced with "<".

Good. I think it helps to reduce dependencies on external commands
when they are not necessary. And it looks like with a little extra
thought, it is not needed here. 

 > I should not call "wc -l < $file" when the script is under a 1,000 lines.

Good. 

 > If the lines over 1000, calling "wc -l < $file" once is just small overhead
 > against the total reading time.
 > 
 > BTW, I wrote a progress bar. Newer patch for bashdb will be based on this progress bar.

Great. 

- -

I know it might not seem so, but part of the purpose of this project
was to open bash development up more and encourage more people to be
more involved to do whatever things that may be of interest.  (My
desires were to have a debugger and a time-stamped history; the latter
is completly done and the former is functional even though it could
use a lot of improvement. My next big thing will probably be a
debugger for GNU make even if it is as flaky as this debugger
initially was.)

It always surprises and fascinates me what interests others, and what
they find and improve. Sometimes I don't initially see it, but I'm
always surprised and delighted over time at how things have become
much better with everyone's contributions, even in areas or aspects
that I didn't initially understand/appreciate. 

This is a long-winded way of saying - So go for it!

Re: [Bashdb-devel] reading progress...

[Masatake Y. <je...@gy...>]

I've installed my progress bar patch to the repository.
Please try and fix it if something is wrong.

I wrote about my change to NEWS file.
Masatake YAMATO

[Bashdb-devel] make debugger

[Masatake Y. <je...@gy...>]

> I know it might not seem so, but part of the purpose of this project
> was to open bash development up more and encourage more people to be
> more involved to do whatever things that may be of interest.  (My
> desires were to have a debugger and a time-stamped history; the latter
> is completly done and the former is functional even though it could
> use a lot of improvement. My next big thing will probably be a
> debugger for GNU make even if it is as flaky as this debugger
> initially was.)

You may use perl well. Look into makepp(http://makepp.sourceforge.net/).
It is make written in perl. I wrote a sample debugger code for makepp and
sent to makepp maintainer. I got positive reply from the maintainer.
It is worth to hack makepp because makepp is actively maintained. 

Masatake YAMATO

Re: [Bashdb-devel] reading progress...

[Masatake Y. <je...@gy...>]

> I have some reservations about the patch below. I'm not against giving
> percentage versus lines read in per se. But here it comes with a some
> cost and perhaps reliability. The patch assumes that "wc" and "cat"
> are available commands and are in the path. (With extra work configure
> could check this and hard-code in the paths).  I don't belive the rest
> of the debugger makes use of either "cat" or "wc".  Perhaps the build
> system does, but I suppose that's okay since it is for developers. I
> don't know, I may be overly fussy here. 

We can check the existence of wc at runtime.

   if wc -l < /dev/null >/dev/null 2>&1 ; then echo ok; else echo fail; fi

We can use wc when if it exists. cat can be replaced with "<".

> And there's something I find weird about running a "cat | wc -l" just
> to get the total number of lines in a file. Right now, For the simple
> cases where the script is under a 1,000 lines, no extra work is done
> no, wc'ing no cat'ing no line printing. In those cases where one
> needs to print out status because the file is large, running 'cat | wc
> -l' slows things down more.

I should not call "wc -l < $file" when the script is under a 1,000 lines.
If the lines over 1000, calling "wc -l < $file" once is just small overhead
against the total reading time.

BTW, I wrote a progress bar. Newer patch for bashdb will be based on this progress bar.

#!/bin/sh

progress_raw_erase() {
    echo -e -n "\r\b"
}

# progress_raw_show
# $1 prefix string
# $2 max length
# $3 current length
progress_raw_show () {
    local -i i=0

    progress_raw_erase
    
    echo -n "$1: ["
    for (( i=0; i < $3 ; i++ )); do
	echo -n "="
    done
    echo -n ">"

    for (( i=0; i < $2 - $3 ; i++ )); do
	echo -n " "
    done
    echo -n "]"

}

# progress_show
# $1 prefix string
# $2 max value
# $3 current value
progress_show () {
    local title=$1
    local -i max_value=$2
    local -i current_value=$3
    local -i max_length=40
    local -i current_length

    
    if (( max_value == 0 )) ; then
	# Avoid dividing by 0.
	current_length=${max_length}
    else
	current_length=$(( ${max_length} * ${current_value} / ${max_value} ))
    fi
    
    progress_raw_show "$1" ${max_length} ${current_length}
}

# progress_done
# $1 completion message
progress_done() {
    progress_raw_erase
    echo $1
}


title="Reading a file"
progress_show "$title" 4 1
sleep 1
progress_show "$title" 4 2
sleep 1
progress_show "$title" 4 3
sleep 1
progress_show "$title" 4 4
progress_done "file is loaded."