h a l f b a k e r yRight twice a day.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
I would like a version of the Unix
'make' utility that (in addition to,
or instead of, the usual
command/output chatter) displays a
progress meter showing the percentage
of the build finished and the
estimated time to completion.
This would be particularly useful
when building large projects
(such as
the Linux kernel). Sure, a
quad-processor gigahertz Athlon can
probably build the whole thing in a
few seconds, but some of us have to
wait a while for our lesser hardware
to crunch through the process.
File-by-file variations in compile
times and recursive invocations of
'make' and other tools may make this
more difficult, but surely these
problems could be solved. (Recursive
make is harmful anyway!)
(Perhaps the right answer is a
universal progress meter that watches
the output from any command, and
learns over time how to recognize
progress?)
[link]
|
| |
If this involves a complete re-design and re-write of make, then i'm all for it! |
|
| |
(i'll spare you my rant on make.) |
|
| |
You're right, the recursive nature of make is the main obstacle with this idea. The top level makefile has no idea how many makefiles exist underneath it. |
|
| |
In general, an accurate progress bar (i.e. a one based on time) is a rare occurance. I'm not sure if it is that difficult to do, but i expect it is just programmer laziness. Every windows installer I've ever seen counts the numbers of operations, not the time it takes to complete an operation. |
|
| |
So, a installing a 4 meg file and a 4 byte file are considered equal. |
|
| |
I think we need a progress meter design pattern that considers time, not just number of operations. |
|
| |
Combined with your universal progress meter that times all commands and i think you've got something pretty tasty. |
|
| |
I was chosen to implement a time wise progress bar, and it is exceedingly difficult to get it to any level of accuracy. The best I came up with was to take ten samples of time for say 10 ops, skip 100, then take ten samples. Taking the average time for the most recent ten samples, I subtracted the average time from the older ten samples. This gave me an idea of performance improvement or degradation over time. Since I knew how many records I had to process (I'm calling them ops to keep the language as simples as possible) I could figure out what the ultimate improvement in time would be for the final records, and apply the gradual change to the records in between. These samples were done repeatedly as processing continued. It was accurate to within a minute for a two hour project, so I was pretty pleased with the result. |
|
| |
Unfortunately, the interceptor missed the incoming missle by 36 seconds, and it blew Harfy Island (off South Carolina) into several small bits. We said it was an earthquake. :) |
|
| |
Yes, yes, yes! Even a proportion
of files done bar, rather than a
time bar, would be useful. |
|
| |
"Wasted time..." -- Dishwalla |
|
| |
That universal progress meter sounds *very* useful. How would it be done? Surely to comply with it and give it something to work with, programs would have to feed it huge amounts of information - in a fairly generic format. |
|
| |
I see no excuse why recursive processes like make shouldn't have useful information - it just needs to bother looking in advance and adding the files up. |
|
| |
Imagine no longer. The Eclipse 3.0m7 IDE display a build progress meter for Java projects. |
|
| |
However, as Eclipse compiles each file after each file save, you only need this progress meter when Eclipse opens the project the very first time(!). |
|
| |
Download Eclipse from <http://www.eclipse.org/> |
|
| |