htdig undead

htdig undead

[Hans-Peter Nilsson]

FYI, I'm trying out an N+1 kludge to compress the file that got
>2G (in summary: popen + gzip instead of fopen).  It leans well
to this kind of abuse because it's always accessed serially.  I
repeat, this is just a stop-gap, not a permanent solution.

brgds, H-P

htdig revived on the gcc side

[Hans-Peter Nilsson]

On Sat, 24 Apr 2004, Hans-Peter Nilsson wrote:
> FYI, I'm trying out an N+1 kludge to compress the file that got
> >2G (in summary: popen + gzip instead of fopen).  It leans well
> to this kind of abuse because it's always accessed serially.  I
> repeat, this is just a stop-gap, not a permanent solution.

Whaddayaknow, looks like it works, though of course I use bzip2
instead of gzip.  For reference, a full update from scratch
(definitely not time-invariant) on the gcc side now takes a
little more than ten hours (from /sourceware/htdig/gcc/update-log):

Starting database update at Sun Apr 25 18:09:20 UTC 2004
...
Finished database update at Mon Apr 26 04:14:33 UTC 2004

I've enabled htdig updates on the gcc side (muhahahahaa!) and
hope to do so soon on the sourceware side too.  I also (think I)
added stuff to track and stop impossible updates: no more
retrying after a failed update from scratch or after a "file
size limited exceeded" error.

brgds, H-P

Re: htdig revived on the gcc side

[Christopher Faylor]

On Mon, Apr 26, 2004 at 08:08:25AM -0400, Hans-Peter Nilsson wrote:
>I've enabled htdig updates on the gcc side (muhahahahaa!) and
>hope to do so soon on the sourceware side too.  I also (think I)
>added stuff to track and stop impossible updates: no more
>retrying after a failed update from scratch or after a "file
>size limited exceeded" error.

Thanks, H-P.  I know how much you enjoy working on this stuff
but your efforts are appreciated.

cgf