Thanks for your bug reports--there have been a few bugs reported in the
betas, but we're only starting to get a significant number of them. I'm
going to sit down tonight and see what progress I can make on a 3.2.0b3.
It would help if someone would start to work in the existing patches.
Have you tried later versions beyond 3.2.0b2?
> - some error conditions result in an error message followed by what seems to
> be an attempt to output an excerpt (when there are obviously no documents).
> This results in gibberish (sometimes fragments of htdig.conf, sometimes what
This is very strange--it sounds like a memory corruption bug, but it
hasn't been caught by any of the leak toolkits (e.g. Purify) we've used so
far. Further testing will be needed, especially after we're code complete.
> - when using long.html and short.html (as opposed to the built-in formats or
> a custom format) to display results, certain queries will say "results 1-x
> shown" but not show any results. Which query produces this seems
> unpredictable, but the same query will always either return a "blank list"
> or return normally.
This sounds quite bizzare, espcially since you say its not consistent. It
may be related to a memory leak.
> - a search for '"web and"' hangs htsearch when method=boolean (but not when
> method=and or method=or. Yes, 'and' is in my bad_words, but doesn't seem to
> be caught in this instance.)
When method=boolean, as you might expect, AND and OR and NOT are not
counted as bad_words. I can say quite confidently this will not hang the
new query parser--it's one of my tests. :-)
> - A search with multiple terms OR'd together (some of them strings) doesn't
> seem to highlight _all_ of the terms present in an excerpt, only one of
> them.
I believe this is also fixed in the snapshots, but an example (as a
separate bug report) would help.
> - a couple of really mangled query strings make $(SCORE) (for some
> badly-matching documents) end up at 0 or -1. As an example of a mangled
Try a snapshot--there were some bugs in the scoring that have been fixed.
> - This is more of a feature request... a search for '"phrase with prefix*"'
> doesn't currently get expanded like 'prefix*' does. This might seem to go
> against the whole idea of an exact phrase, but would be useful at least in
> one thing I'm doing.
For right now, phrase searching will not include fuzzy matching. However,
the new ParseTree system will make it easier for people to add this sort
of thing. Each match method will be a distinct class and will receive a
call to "expand" based on a list of fuzzy types.
> - Also, I've had some unreliable results with prefix searching in general.
> However, I don't remember the specifics. Has anyone run into something
> similar?
There were significant bugs in Prefix.cc even past 3.2.0b2. They should be
fixed now.
In general, it helps if bug reports are done separately so they can be
forwarded to the bug DB.
Thanks,
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
