Dmitri Nikulin wrote:
> Teemu Rinta-aho wrote:
> 
>> anyone have an idea how big effort would it be to implement
>> a progress bar to "make install" in pkgsrc? Now, for example,
>> installing gmplayer I have no idea whether I have to wait
>> for one or two more hours for it to complete... Even an
>> estimate with M$-precision would be better than nothing.
>>
> This doesn't actually belong in current-users@, but I'll answer anyway.

Sorry, my fault. It should have been posted on tech-pkg.

> It would be a silly effort. To measure compile progress, you'd need a 
> pre-set 'workload' (say, expected CPU cycles, or something equally 
> stupid), and then measure this resource usage during the compile and 
> hence determine the progress. This is impossible because of different 
> CPUs, optimizations, compilers, options, etc...

No, as I wrote, anything more than just seeing compiler
messages floating in front of my eyes would be nice.
I have no need to know how many milliseconds there are
left, but rather something like how many packages are left:

"Installing gmplayer: pkg 17 of 523 (win32codecs)"

I perfectly understood before stating the initial question
that anything more precise than that is very difficult
and/or unreasonable to implement, if you don't accept
M$ tolerances..

> Your best bet, which I find works for me, is to stop caring how long 
> something will go for. Leave the machine on and get on with life. The 
> annoying part is when something fails to compile at all, but that's part 
> of using a 'minority' OS :(

So the OS is complete now? And it's evil to propose something
you feel would improve it, or even to start discussion? Well,
maybe I should just patch stuff myself and keep my mouth shut..

Teemu

-- 
teemu@rinta-aho.org       ||  teemu.rinta-aho@iki.fi
http://www.rinta-aho.org  ||  http://www.iki.fi/teemu.rinta-aho