htdig-dev

[htdig-dev] 3.2.0b5

[Jim C. <li...@yg...>]

Hi - I am to a point where I might actually have a few extra minutes a 
day free to apply toward the next release. I have more or less kept 
track of where things stand but thought I would seek input on how my 
time might most effectively be spent. I have OS X and Linux boxes handy 
and an old Sparc that I could dust off if necessary. I picked up a copy 
of Sleepycat Software's Berkely DB book the other day, if that is of 
any help to anyone; hard to turn something like that down when you find 
it on the discount rack for six bucks.

Jim

[htdig-dev] Re: 3.2.0b5

[Lachlan A. <lh...@us...>]

On Sat, 19 Apr 2003 06:16, Jim Cole wrote:
> I might actually have a few extra
> minutes a day free to apply toward the next release.

I've just fixed the database bug that was causing me grief with
'make check'.  It was simply that  htdig -i  wasn't removing=20
db.words.db_weakcmpr (which I had reported earlier but not fixed --=20
Doh!!) which was corrupting the free-list of pages used when=20
compression was not as efficient as predicted.

The only other DB problem I know of is the problem of infinite=20
recursion when "weak compression" needs to allocate a page, but=20
mp_alloc needs to write out a dirty page.  Have you tried the hack I=20
suggested a couple of months ago?

Getting  make check  to work under RedHat and OSX would also be great.

> I picked up a copy of Sleepycat Software's Berkely DB
> book on the discount rack for six bucks.

Bargain!

[htdig-dev] Compression bug(s)

[Lachlan A. <lh...@us...>]

Greetings all,

Attached is a patch to the database code which *should* fix the=20
infinite loop problem Jim reported a couple of months ago.

It is a combination of explicitly denying excess recursion in =20
CDB___memp_alloc(),  a patch from BDB 3.3.11 which handles failure of=20
writing a dirty page in  CDB___memp_alloc(),  and a new function =20
CDB___memp_clean_page()  to ensure that there are sufficient clean=20
pages to allow dirty compressed pages to be written.

Before I commit the patch, could people please test and/or read it,=20
and give me feedback?

I *hope* that this is the final problem fixed (until we tackle the=20
native compression...)

Cheers,
Lachlan