[gugs] Fw: Re: [htdig] Bug in startday code, v. 3.1.6 (patched) (fwd)
Martin Zelaia
martintxo en sindominio.net
Jue Ene 23 20:26:35 CET 2003
Aupa gentes:
Pues ya me imagino que esto interesara poco, pero bueno, porsia.
Resulta que hace un monton de tiempo (igual 6 meses), cuando anduve con el
tema del buscador htdig, encontre un bug. Ni corto ni perezoso lo
"reporte", pero me dijeron algo asi como que ellos no veian el bug por
ninguna parte y que les diera alguna URL donde se viera el bug para que lo
investigaran. Y estuve tentado de hacer algo en mi espacio web para que se
viera, pero al final era mucho curro para mi y lo deje...
Pues ahora resulta "que si que era un bug" :-) y que ya han sacado un
parche (o algo) para arreglarlo. El problema estaba en las busquedas
especiales que se realizaban con periodos de tiempo relativos al dia.
Parecia que htdig no entendia bien lo de "ayer = -1", "hace 10 dias = -10",
"hace un mes = -30", etc. Por ello, yo en el formulario para las busquedas
avanzadas que pusimos en sindominio (o solo en la pagina de fundamento, no
recuerdo si son iguales), puse que las busquedas relativas al tiempo fueran
relativas al mes, que es lo que a mi me iba bien (osea "hace un mes = -1",
"hace medio año = -6" ...).
Vamos que no creo que tengamos problemas al respecto, ni que tampoco nos
merezca la pena hacer nada con nuestro htdig (uff!!, dira alguno por ahi
:-P). Pero por si acaso, aqui os lo cuento. Y de paso quedo guay :-D. Pego
lo que me dicen los de htdig, por si lo entendeis :-).
Pos eso. Saludos. Martintxo.
--> Berbidalitako emaila hemendik aurrera agertzen da:
Data: Wed, 22 Jan 2003 16:57:46 -0600 (CST)
Nondik: Gilles Detillieux <grdetil en scrc.umanitoba.ca>'tik
Nora: wknox en mitre.org (William R. Knox)'ra
Cc: fundamento en sindominio.net, htdig-general en lists.sourceforge.net
(ht://Dig mailing list)
Asuntoa: Re: [htdig] Bug in startday code, v. 3.1.6 (patched) (fwd)
According to William R. Knox:
> I am still seeing this problem, and have come across another clue. It
> works fine if a relative endday, such as -1, is also passed. In reading
> the bugs database closer, it also appears that bug 578570 may also be
> related.
>
> I have confirmed this bug by searching on the htdig site with the
> following three GET strings sent via a telnet session - note how the
> final two hit counts differ:
>
> Search for 'startday', no date range (returns 50 hits)
> ---
> GET /cgi-bin/htsearch?method=and&words=startday HTTP/1.1
> Host: www.htdig.org
>
> Search for 'startday', set startday to -60 (returns 0 hits)
> ---
> GET /cgi-bin/htsearch?method=and&words=startday&startday=-60 HTTP/1.1
> Host: www.htdig.org
>
> Search for 'startday', set startday to -60 and endday to -1 (returns 1
> hit)---
> GET /cgi-bin/htsearch?method=and&words=startday&startday=-60&endday=-1
> HTTP/1.1 Host: www.htdig.org
>
> Unfortunately, my C++ coding is non-existent, but the line which seems to
> me to be suspect is in Display.cc, line 1295-6:
> else if (!reldate)
> enddate.tm_year = endoftime->tm_year;
>
> Could this somehow be getting set to the same year as the
> startdate.tm_year?
... and on Tue, 7 Jan 2003 ...
> I believe that I have come across a bug in the startday code in version
> 3.1.6 (I have applied the metadate.0 patch and the timet_enddate.1
> patch). Briefly, using a negative number in the startday that overlaps a
> year boundary (i.e. using a number greater than -7 today, 1/7/03) causes
> only entries for the previous year to be displayed. Here is an example:
Whoops! Mea culpa. When I added the support for relative dates, I
didn't realize that the added localtime() calls would clobber the data
structure that endoftime is set to point to. Surprisingly, this doesn't
affect all systems, but I guess some implementations of localtime share
the same return data structure as gmtime, and some don't.
Here's a fix, which I'll call timet_enddate.2, and which overrides
the timet_enddate.1 patch in the archives. It saves a copy of the
gmtime return structure so it's not clobbered. Plus it includes
Robert Marchand's earlier fix for the problem in 3.1.6's handling of
the end date in the date range support. (The test to see if the end
date was set was wrong, so htsearch assumed it always had to check
the date for each match, which caused the extra overhead described in
http://www.htdig.org/FAQ.html#q5.10)
Apply this patch in your main htdig-3.1.6 source directory using the
command: patch -p0 < this-message-file
If you've already applied timet_enddate.1, don't worry: the second hunk
of this patch will fail (because it's already been applied), but the
first should apply fine and all should work fine after that.
--- htsearch/Display.cc.orig Thu Jan 31 17:47:18 2002
+++ htsearch/Display.cc Tue Jan 21 15:46:19 2003
@@ -1148,6 +1148,8 @@ Display::buildMatchList()
// find the end of time
endoftime = gmtime(&eternity);
+ tm eterni_tm = *endoftime;
+ endoftime = &eterni_tm;
if(dategiven) // user specified some sort of date information
{
@@ -1407,7 +1409,7 @@ Display::buildMatchList()
// New check added on whether or not we need to check date ranges -
MG
if (date_factor != 0.0 || backlink_factor != 0.0 || typ !=
SortByScore
- || timet_startdate > 0 || enddate.tm_year < endoftime->tm_year)
+ || timet_startdate > 0 || timet_enddate < eternity)
{
DocumentRef *thisRef = docDB.FindCoded(thisMatch->getURL());
if (thisRef) // We better hope it's not null!
--
Gilles R. Detillieux E-mail: <grdetil en scrc.umanitoba.ca>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)
--> Berbidalitako emaila hemen bukatzen da
Ondo segi. Martintxo.
==========================================================================
| Martin Zelaia |
| Fundamento Orain Taldea |
| www.sindominio.net/fundamento/ |
==========================================================================
La esclavitud no se abolió, se cambió a 8hs diarias.
Les Luthiers.
Más información sobre la lista de distribución Gugs