[Gambas-user] Some file/use or progress bar questions.

[Doriano Blengino]

richard terry ha scritto:

(about the speed penalty)
Yes, updating the screen is sometimes a speed penalty, depending on the 
complexity of the update, and the underlying hardware/software.
For a X console (xterm), it is a *big* job to scroll the text - 
something less if the text does not scroll.
For X itself, it depends; anyway, in long computations, one should 
update the screen at timed intervals, or at least every N loops done. 
One could do it every 100 lines read, or every 1000, or every 200 
records inserted, or something similar.

> 1) I have a file with some 30,000 lines, but I want to know how many lines are 
> in the file before I do anything to it - is this possible. I couldn't see how 
> just looking at the syntax for files.
>   
It is simply not possible. You cat stat() the file to see how much it is 
big, and then, having a rough idea about how much the lines are long, 
divide the length of the file by the lenght of the lines. You can use 
/usr/bin/wc, which is fast, but anyway it does nothing else than opening 
the file and read it line by line to count them - probably wc can do it 
faster than gambas, but it would do the same thing.
If the files are generated by you, you can store somewhere the number of 
lines, or write it in the first line of the file, or in the last one 
(tricky).
>
> 2) Given that I could figure out how many lines, I wondered if someone could 
> give me some tips on how to use the progress bar and how one moves it along 
> in any situation in response to how long something takes - I mean - does one 
> just "guess" the time it will take and move the pointer accordingly?
>   
The majority of software around does not care about the time, but only 
about the amount of work to do. Again, you stat() the file, so you know 
how many characters are in there. Then, you read the file line by line, 
counting (ie, adding) how many bytes you read (+1 for the LF). The ratio 
bytes_read/length_of_file gives you the point where you are in the work. 
Every 100, or 1000 lines, or 8000 bytes, or so, you can execute a wait 
to update the screen (if you modify something on the screen, it will be 
updated only when your program is idle, or when you execute a wait() 
instruction. The WAIT is slow, not the instruction which update the screen).

If you want to guess the time it will take, you count the number of 
seconds (or milliseconds) elapsed from the start of work; at any given 
time, the ratio bytes_read/elapsed_seconds gives you the throughput of 
your program, in bytes/sec; the formula 
(SizeOfFile-BytesRead)/Throughput gives you the time remaining to do the 
rest of work. If every 100 lines read, or every second elapsed, or every 
100 milliseconds, you update a progress bar and call WAIT(), you get a 
fair job (see this pseudocode):

FileSize = stat(MyFile).Size
BytesRead = 0
TimeElapsed = 0
open Myfile for input
StartTime = timer()
while not EOF(MyFile)
  read aline
  BytesRead += len(aline)+1
  ...process the line...
  if timer()-StartTime-TimeElapsed >= 0.1 then
    ' 100 milliseconds elapsed
    TimeElapsed += 0.1
    done_percent = (BytesRead / FileSize) * 100
    Throughput = BytesRead / TimeElapsed      ' beware for ThroughPut==0!
    RemainingTime = (FileSize - BytesRead) / Throughput
    ...set some progress bar or whatever
    WAIT
  END IF
wend

Cheers,

-- 
Doriano Blengino

"Listen twice before you speak.
This is why we have two ears, but only one mouth."