According to Geoff Hutchison:
> At 12:02 PM +0200 8/17/00, abel deuring wrote:
> >I discovered a few problems with the score calculation and with mutliple
> >config files in htsearch/Display.cc in ht://dig, version htdig-3.2.0b3,
> >CVS snapshot 080600.
>
> First off, thanks for your patch! I'll take a look at it, though I
> should say up front that due to an unfortunate bug, the snapshots
> weren't being updated with the latest CVS code. I believe most, if
> not all, of your bugs were fixed by a previous patch (that because of
> the bug, never hit the snapshots).
That was a long-standing bug. The scoring fixes were done June 8 & 11.
> >A comment to my patch: I don't have very much experience with the
> >"scoring system" of ht://dig (or ht://dig in general), but I don't
> >think, that it is a good idea to give relative ranking information for a
> >result set with minScore = 11000.090909 and maxScore = 11000.636364.
> >(real example :)
> >
> >Therefore, with the attached patch, Display::generateStars does not
> >return any stars, if minScore and maxScore are too close. The chosen
> >threshold MINSCOREDIFF probably needs to be adjusted.
>
> This is a good point. Certainly this could be an attribute.
Yikes! I can see the flood of "what happened to the stars?" complaints
right now! If this change goes in, it should definitely be optional,
and off by default.
> > 4. In Display.cc, line 680, the "config=some_file_name" (as parsed from
> >the program input) is appended to the URL that is used to select
> >different result pages, but a few lines later, "config=..." is added
> >again, this time from collectionList. Thus, we get the config parameter
> >twice in the URL.
>
> Whoops!
Yes, this was pointed out last week, and I made a mention of the code
section at fault, but didn't get around to making and committing the
change.
> >5. If two config files specified (for searches in in two databases, or
> >accidentally by the bug mentioned above), and if the second config file
> >contains an "include" statement, the lines following this include
> >statement are not used.
>
> Hmm, I'll try to reproduce that, though it may take some additional
> sleuthing to find the culprit code in the flex/bison code.
>
> Thanks again for your patch (and sorry that the snapshots were broken).
The flex code uses a stack to keep track of open config files for
includes. My guess is that code gets confused by multiple config files
in the collection support. The includes in the new flex code are also
broken in that include file names are now interpreted relative to the
current directory of the process, rather than the parent directory of
the current config file. The stack should also keep track of file names
and the code should be fixed to use them. In short, that code seems to
need a lot of debugging and testing.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
