In article <fVh*uF6do at news.chiark.greenend.org.uk>,
Tim Cutts <timc at chiark.greenend.org.uk> wrote:
>I have now fixed SRS 5.1 so it *does* work. It's a relatively simple
>set of patches to $SRSSOU/library.c. The alternative query form still
>doesn't work quite right, but I'm working on that, and will submit the
>complete set of patches to this newsgroup when I'm done. wgetz is quite
>a lot harder to debug, because it's a CGI program. I'm having to write
>a test C program which incorporates some of wgetz' functionality to test
>with...
Hmm. Looks like my initial optimism was somewhat misplace. I got as
far as convincing SRS to build indices for the second type of subentry,
and to display the details with getz -info, but fetching the results of
the query was extremely hard; I found a number of bits of code which
assumed there was only one subentry database. Take for example,
LibGetSubEntryName, which has the code:
subLib = LibIs (lib, "subentries") ? lib : LibGetSubEntryLib (lib, 0);
and LibGetSubEntryLib itself, which despite taking a parameter for the
subEntry number, ignores it:
SLBo *LibGetSubEntryLib (SLBo *lib, Int4 subEntryN)
{
return lib->subEntries[0];
}
Making the obvious changes here causes getz to crash in a major way, and
I got this down to IdSplit() filling in the wrong number (or at least,
not what I expected) in the subentry_n field. This pointed to detailed
involvement in the structure of the indexes and $IdType objects. At
this point I conceded defeat due to the lack of documentation and source
code comments.
Tim.
