From: Jim C. <li...@yg...> - 2003-07-30 03:28:52
|
Hi - As someone already mentioned with regard to their Red Hat install, the configuration changes to the 3.2 code base require auto* tools more recent than those provided with the distribution. The same is true for OS X, which currently provides autoconf 2.52 and automake 1.6.1. It looks like the minimum requirements are currently autoconf 2.54 and automake 1.7. For the time being at least, I am unable to fully test the changes. It appears that the required version of automake is even ahead of what is available via fink, so it would have to be installed manually. Not to say that installing it manually is any great chore, but I do wonder if we are getting ahead of ourselves here. If upgrading auto* tools is going to become a prerequisite for the typical ht://Dig install, that is probably a bad thing. Are the relevant enhancements only available via the newer auto* tools? Jim |
From: Gilles D. <gr...@sc...> - 2003-07-30 16:50:19
|
According to Jim Cole: > Hi - As someone already mentioned with regard to their Red Hat install, > the configuration changes to the 3.2 code base require auto* tools more > recent than those provided with the distribution. The same is true for > OS X, which currently provides autoconf 2.52 and automake 1.6.1. It > looks like the minimum requirements are currently autoconf 2.54 and > automake 1.7. > > For the time being at least, I am unable to fully test the changes. It > appears that the required version of automake is even ahead of what is > available via fink, so it would have to be installed manually. Not to > say that installing it manually is any great chore, but I do wonder if > we are getting ahead of ourselves here. If upgrading auto* tools is > going to become a prerequisite for the typical ht://Dig install, that > is probably a bad thing. > > Are the relevant enhancements only available via the newer auto* tools? I don't know if it's still the case now, but in the past the auto* tools were only needed when you needed to develop/update the Makefiles, and weren't needed just to compile the code. Now I think that with the snapshots, the modtimes of the files aren't always set correctly so make thinks it needs to rerun some of the auto* tools. If things are set up correctly, you should normally be able to compile and install an htdig distribution without using the auto* tools, unless the packaged Makefiles don't work on your system. It may be, though, that with the new auto* tools the Makefiles end up being more system dependent than in the past. Can anyone with more automake/autoconf experience comment on the feasibility of this? It would be nice if installation of ht://Dig continued not to require the auto* tools. -- Gilles R. Detillieux E-mail: <gr...@sc...> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) |
From: Gabriele B. <bar...@in...> - 2003-07-30 18:21:23
|
Ciao guys, I am sorry if the patch is causing problems. But ... with the word 'test' I meant exactly this. Try it and discover some problems. >I don't know if it's still the case now, but in the past the auto* >tools were only needed when you needed to develop/update the Makefiles, >and weren't needed just to compile the code. That's what I believe too. AFAIK autotools are needed only if you want to rebuild configure scripts and Makefile.in files. I have not run on this problem on my laptop (where I generated it all). But ... I came into this problem when trying with an older Red Hat distribution. I found the problem with the 'db' subdirectory to be exact. >Can anyone with more automake/autoconf experience comment on the >feasibility of this? It would be nice if installation of ht://Dig >continued not to require the auto* tools. That's a *must* Gilles. And my (and Marco's) patch was in this direction. -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Prato, Tuscany, Italy bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Jim C. <li...@yg...> - 2003-07-30 18:39:36
|
On Wednesday, July 30, 2003, at 12:20 PM, Gabriele Bartolini wrote: > That's what I believe too. AFAIK autotools are needed only if you want > to rebuild configure scripts and Makefile.in files. I have not run on > this problem on my laptop (where I generated it all). But ... I came > into this problem when trying with an older Red Hat distribution. I > found the problem with the 'db' subdirectory to be exact. Well the messages involving automake appeared that they might be more of a warning nature than an outright error. However the autoconf version was definitely resulting in errors; the problem seemed to originate from the processing of aclocal.m4. At this point I don't know enough about the auto* tools to know if/why aclocal.m4 should be processed under normal circumstances. What problem exactly did you run into with the 'db' directory? I did a make distclean intending to chase the problem I ran into a little further, but then ended up in a state where make fails in the 'db' directory due to there being no rule for target 'all' (I did rerun configure with no obvious errors). Jim |
From: Gabriele B. <g.b...@co...> - 2003-07-31 06:22:17
|
Il mer, 2003-07-30 alle 20:39, Jim Cole ha scritto: > What problem exactly did you run into with the 'db' directory? I did a > make distclean intending to chase the problem I ran into a little > further, but then ended up in a state where make fails in the 'db' > directory due to there being no rule for target 'all' (I did rerun > configure with no obvious errors). Thanks to Marco, I think we discovered the problem. We should get rid of 'AM_MAINTAINER_MODE' in the configure.in file. I can't run it now (as I am leaving for Australia today) but I will do it hopefully at the end of the week (early next week - if I am jet lag). :-) Ciao ciao -Gabriele -- Gabriele Bartolini - Web Programmer Comune di Prato - Prato - Tuscany - Italy g.b...@co... | http://www.comune.prato.it > find bin/laden -name osama -exec rm {} ; |
From: Ted Stresen-R. <ted...@ma...> - 2003-07-31 15:56:10
|
My experience on OS X has been that you need the latest version of the =20= auto* tools if you want to build dynamic shared libraries. In fact, =20 there is a version of the automake file that comes on Mac OS X (Jaguar) =20= that has been specially tuned by Apple and that they recommend you use =20= when building UNIX software on OS X. Specifically, they state: --- start quote --- If Autoconf fails because it doesn=92t understand the architecture, try =20= replacing the project=92s config.sub and config.guess files with those =20= available in /usr/share/automake-1.6. If you are distributing =20 applications that use Autoconf, you should include an up-to-date =20 version of config.sub and config.guess so that Mac OS X users don=92t =20= have to do anything to get your project to build. You may also need to run /usr/bin/autoconf on your project before it =20 works. Mac OS X includes Autoconf in the BSD tools package. Beyond =20 these basics, if the project does not build, you may need to modify =20 your makefile according to some of the tips provided in the following =20= sections. =46rom that point, more extensive refactoring may be required. Some programs may use Autoconf macros that are not supported by the =20 version of Autoconf that shipped with Mac OS X. Autoconf changes =20 periodically, so you may actually need to get a new version of Autoconf =20= if you need to build the very latest sources for some projects. In =20 general, most projects include a pre-built configure script with =20 releases, so this is usually only necessary if you are building an open =20= source project using sources obtained from CVS or from a daily source =20= snapshot. ( =20 http://developer.apple.com/documentation/Porting/Conceptual/=20 PortingUnix/compiling/chapter_4_section_3.html ) --- end quote --- I'm fairly certain htdig will build with dynamic shared libraries and =20= without error on OS X if you run version 1.5 of GNU libtool on it =20 first. Here's a link to an email from Peter O'Gorman (one of the =20 developers for libtool who focuses on Mac OS X) in which he points to =20= one of the typical problems of building on OS X and suggests a =20 workaround, of sorts. http://sourceforge.net/mailarchive/message.php?msg_id=3D5113486 As I said in a prior email. I'm doing everything I can to learn about =20= the auto* tools, how they work, and how they work on OS X. This email =20= indicates how far I've gotten (not very...) and hopefully, those with =20= more background can make sense of the data provided here... Best of luck. Off until mid-august on vacation. Yeah! Ted Stresen-Reuter On Wednesday, July 30, 2003, at 11:42 AM, Gilles Detillieux wrote: > According to Jim Cole: >> Hi - As someone already mentioned with regard to their Red Hat =20 >> install, >> the configuration changes to the 3.2 code base require auto* tools =20= >> more >> recent than those provided with the distribution. The same is true = for >> OS X, which currently provides autoconf 2.52 and automake 1.6.1. It >> looks like the minimum requirements are currently autoconf 2.54 and >> automake 1.7. >> >> For the time being at least, I am unable to fully test the changes. = It >> appears that the required version of automake is even ahead of what = is >> available via fink, so it would have to be installed manually. Not to >> say that installing it manually is any great chore, but I do wonder = if >> we are getting ahead of ourselves here. If upgrading auto* tools is >> going to become a prerequisite for the typical ht://Dig install, that >> is probably a bad thing. >> >> Are the relevant enhancements only available via the newer auto* =20 >> tools? > > I don't know if it's still the case now, but in the past the auto* > tools were only needed when you needed to develop/update the = Makefiles, > and weren't needed just to compile the code. Now I think that with = the > snapshots, the modtimes of the files aren't always set correctly so =20= > make > thinks it needs to rerun some of the auto* tools. > > If things are set up correctly, you should normally be able to compile > and install an htdig distribution without using the auto* tools, = unless > the packaged Makefiles don't work on your system. It may be, though, =20= > that > with the new auto* tools the Makefiles end up being more system =20 > dependent > than in the past. > > Can anyone with more automake/autoconf experience comment on the > feasibility of this? It would be nice if installation of ht://Dig > continued not to require the auto* tools. > > --=20 > Gilles R. Detillieux E-mail: <gr...@sc...> > Spinal Cord Research Centre WWW: = http://www.scrc.umanitoba.ca/ > Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/=20 > direct;at.aspnet_072303_01/01 > _______________________________________________ > ht://Dig Developer mailing list: > htd...@li... > List information (subscribe/unsubscribe, etc.) > https://lists.sourceforge.net/lists/listinfo/htdig-dev > |
From: Lachlan A. <lh...@us...> - 2003-08-23 13:57:24
|
Greetings all, Ever the impatient one, can I suggest that this patch be backed out=20 until after 3.2.0b5 is released? Is it providing any *vital*=20 functionality that couldn't wait until after the release? Weren't we=20 just about ready for a code freeze? If there are still problems with my hacking of the database then I'll=20 gladly back them out too, but only if it means 3.2.0b5 will actually=20 get out the door. (I plan to fix it properly after the release.) Currently, I'm assuming that 3.2 is destined to remain vapourware, and=20 I don't plan to work on ht://Dig until there are signs it isn't :( =20 It was nice getting to know you all :) Good luck, Lachlan On Thu, 31 Jul 2003 02:42, Gilles Detillieux wrote: > If things are set up correctly, you should normally be able to > compile and install an htdig distribution without using the auto* > tools, unless the packaged Makefiles don't work on your system. It > may be, though, that with the new auto* tools the Makefiles end up > being more system dependent than in the past. --=20 lh...@us... Despairing ht://Dig developer DownUnder (http://www.htdig.org) |
From: Gabriele B. <bar...@in...> - 2003-08-24 11:31:16
|
>Ever the impatient one, can I suggest that this patch be backed out >until after 3.2.0b5 is released? Is it providing any *vital* >functionality that couldn't wait until after the release? Weren't we >just about ready for a code freeze? Sorry about it guys. I had the connection only a few days ago here in Melbourne. This morning I could fix the configuration problem by using the autotools provided with my Debian SID, that is to say autoconf 2.57, automake 1.7.6 and libtool 1.5.0a. I don't know why it was broken, whereas when I did it at commit time it worked for me; it's just that before leaving for Australia I had to set up many things and I lost all the contents of my hard drive 2 days before taking off!!! For sure I forgot to upload the htconfig.h file which prevented the code to be correctly compiled. The changes will be part of next snapshot code and hopefully things will go better. Also I put the 'AM_MAINTAINER_MODE' string into the db/configure.in file which prevented code from be compiled when users did not have autoconf (at least 2.57), automake and friends installed. Ciao and thanks -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Jim C. <li...@yg...> - 2003-08-24 23:07:08
|
On Sunday, August 24, 2003, at 05:31 AM, Gabriele Bartolini wrote: > Also I put the 'AM_MAINTAINER_MODE' string into the db/configure.in > file which prevented code from be compiled when users did not have > autoconf (at least 2.57), automake and friends installed. No change for me. Running make fails almost immediately with the following. Making all in db cd . && \ /bin/sh /Users/greyleaf/build/htdig-current/htdig/missing --run automake-1.7 --foreign Makefile /Users/greyleaf/build/htdig-current/htdig/missing: automake-1.7: command not found WARNING: `automake-1.7' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.in'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . && /bin/sh /Users/greyleaf/build/htdig-current/htdig/missing --run autoconf ./aclocal.m4:758: error: Autoconf version 2.54 or higher is required for this script ./aclocal.m4:758: the top level make[1]: *** [configure] Error 1 make: *** [all-recursive] Error 1 I am using code pulled from CVS on Sunday (Aug 24) evening. Jim |
From: Gabriele B. <bar...@in...> - 2003-08-26 12:48:05
|
At 17.06 24/08/2003 -0600, Jim Cole wrote: >On Sunday, August 24, 2003, at 05:31 AM, Gabriele Bartolini wrote: > >>Also I put the 'AM_MAINTAINER_MODE' string into the db/configure.in file >>which prevented code from be compiled when users did not have autoconf >>(at least 2.57), automake and friends installed. > >No change for me. Running make fails almost immediately with the following. I think this is due to a sync problem of the Sourceforge CVS source. It is working for me and I am currently checking the code with the compile farm provided by SF.net. No problems so far on RedHat Linux 7.3, Debian Linux SID, Linux SuSE 8 ES on AMD64 Opteron. I found two problems: - one was the AM_MAINTAINER_MODE missing in the db/configure.in file - the other was the buggy AC_FUNC_MKTIME macro provided with autoconf - I made a backstep and I re-put the previous situation on stage. It seems to work now, but I dread that other problems will occur for other functions that are difficult to port (lstat in particular as "Sylvie JOUHANET" <sylvie.jouhanet at gazdefrance.com> posted in the htdig-general list. Ciao -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Jim C. <li...@yg...> - 2003-08-28 04:40:49
|
FYI - I tried pulling another copy from CVS this morning and was able to get past the auto-tool versioning issues; however I ran into another problem during the build. The output is shown below. This problem is still present in a fresh copy that I pulled from CVS just a few minutes ago. Any ideas? It appears that error.c is a relatively recent addition to htlib. Unless it is hiding in some unusual place, libintl.h is not a standard include file on OS X. Jim /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../include -DDEFAULT_CONFIG_FILE=\"/Users/greyleaf/local/htdig_cvs/conf/ htdig.conf\" -I../include -I../htlib -I../htnet -I../htcommon -I../htword -I../db -I../db -g -O2 -Wall -c -o error.lo `test -f 'error.c' || echo './'`error.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -DDEFAULT_CONFIG_FILE=\"/Users/greyleaf/local/htdig_cvs/conf/ htdig.conf\" -I../include -I../htlib -I../htnet -I../htcommon -I../htword -I../db -I../db -g -O2 -Wall -c error.c -fno-common -DPIC -o .libs/error.o error.c:28: header file 'libintl.h' not found cpp-precomp: warning: errors during smart preprocessing, retrying in basic mode make[1]: *** [error.lo] Error 1 make: *** [all-recursive] Error 1 On Tuesday, August 26, 2003, at 06:46 AM, Gabriele Bartolini wrote: > At 17.06 24/08/2003 -0600, Jim Cole wrote: >> On Sunday, August 24, 2003, at 05:31 AM, Gabriele Bartolini wrote: >> >>> Also I put the 'AM_MAINTAINER_MODE' string into the db/configure.in >>> file which prevented code from be compiled when users did not have >>> autoconf (at least 2.57), automake and friends installed. >> >> No change for me. Running make fails almost immediately with the >> following. > > I think this is due to a sync problem of the Sourceforge CVS source. > It is working for me and I am currently checking the code with the > compile farm provided by SF.net. > > No problems so far on RedHat Linux 7.3, Debian Linux SID, Linux SuSE 8 > ES on AMD64 Opteron. > > I found two problems: > > - one was the AM_MAINTAINER_MODE missing in the db/configure.in file > - the other was the buggy AC_FUNC_MKTIME macro provided with autoconf > - I made a backstep and I re-put the previous situation on stage. > > It seems to work now, but I dread that other problems will occur for > other functions that are difficult to port (lstat in particular as > "Sylvie JOUHANET" <sylvie.jouhanet at gazdefrance.com> posted in the > htdig-general list. > > Ciao > -Gabriele > -- > Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, > ht://Check maintainer > Current Location: Melbourne, Victoria, Australia > bar...@in... | http://www.prato.linux.it/~gbartolini | > ICQ#129221447 > > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, > The Inferno > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines > at the same time. Free trial click > here:http://www.vmware.com/wl/offer/358/0 > _______________________________________________ > ht://Dig Developer mailing list: > htd...@li... > List information (subscribe/unsubscribe, etc.) > https://lists.sourceforge.net/lists/listinfo/htdig-dev |
From: Gabriele B. <bar...@in...> - 2003-08-28 05:08:24
|
Hi Jim, At 22.39 27/08/2003 -0600, Jim Cole wrote: >FYI - I tried pulling another copy from CVS this morning and was able >to get past the auto-tool versioning issues; however I ran into another >problem during the build. The output is shown below. This problem is >still present in a fresh copy that I pulled from CVS just a few minutes >ago. Any ideas? It appears that error.c is a relatively recent addition >to htlib. Unless it is hiding in some unusual place, libintl.h is not a >standard include file on OS X. I just removed all the '.c' files (lstat.c, stat.c and error.c - which should have been rewritten in order to contain function replacements - we skip this part for now) from htlib. I removed configure checks for these functions and rebuilt Makefiles. I was getting similar errors yesterday on cf.sourceforge.net (the compile farm) with Solaris but now it is fixed. You are still getting an old version. You are using anonymous CVS, aren't you? I guess the anonymous CVS tree it is not synced with the developers' one all the time. Ciao -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Gilles D. <gr...@sc...> - 2003-08-27 20:39:34
|
According to Gabriele Bartolini: > I don't know why it was broken, whereas when I did it at commit time it > worked for me; it's just that before leaving for Australia I had to set up > many things and I lost all the contents of my hard drive 2 days before > taking off!!! For sure I forgot to upload the htconfig.h file which > prevented the code to be correctly compiled. I believe a big part of the problem is file modification times. When you do the commit on your system, after running the autotools, then all the file modification times make sense and make works as it should. Unfortunately, CVS doesn't properly maintain modification times when you check out the source tree, so other users don't get the same view of the source tree as you have on your end, as far as mod times are concerned. The weekly snapshots have the same problem, as the snapshot script just does a cvs check-out of the source and archives it, without fixing the mod times. For final releases, Geoff has a script that's supposed to set everything right, but for some reason he doesn't use this script for the snapshots (too much load on the sf.net server, perhaps?), so this doesn't help us in the meantime. I also don't know if this fixup script will need to be changed to adapt to the recent changes to the autotools setup in 3.2. Geoff, can you please comment on this? This seems to be shaping up to be a big showstopper, and we could really use the benefit of your wisdom. -- Gilles R. Detillieux E-mail: <gr...@sc...> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) |
From: Gabriele B. <bar...@in...> - 2003-08-28 05:12:49
|
Ciao Gilles! At 10.24 27/08/2003 -0500, Gilles Detillieux wrote: >The weekly snapshots have the same problem, as the snapshot script just >does a cvs check-out of the source and archives it, without fixing the >mod times. I see. >For final releases, Geoff has a script that's supposed to set everything >right, but for some reason he doesn't use this script for the snapshots >(too much load on the sf.net server, perhaps?), so this doesn't help us >in the meantime. I also don't know if this fixup script will need to >be changed to adapt to the recent changes to the autotools setup in 3.2. Hopefully Geoff could give us an answer. Also, I have almost finished fixing the 'make dist' process, which should build a tar.gz of the project for distribution (that's what I use for ht://Check). There are small problems with the 'test' and 'libhtdig' directories as I said in the previous e-mail. >Geoff, can you please comment on this? This seems to be shaping up to >be a big showstopper, and we could really use the benefit of your wisdom. Yes ... We need your wisdom now, Geoff! (especially me!) :-) Ciao and thanks, -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Neal R. <ne...@ri...> - 2003-08-26 14:05:06
|
Hey all, McGill University recently contacted the one of the HtDig Board members to inquire about making some kind of financial arrangement with HtDig to get 3.2 finished, tested and working with Phrase Searching -- ie quoted strings. There are various issues to us accepting any money.. we don't have a bank account or tax exempt status... but it is possible to get 'retired' hardware to individual developers. They mentioned in particular a few Mac G4s. So here is the question: What do we need to get 3.2 finished and would hardware incentives help? I myself have a couple of things to check in... I apologize for delaying them. Here's my short todo list for 3.2: Back out recent changes to mp_alloc.c (Quick) Redo the memory leak check & fixes (1-2 Days) Please post your TODO list and I'll compile them and post them on a web-page prioritized for release. We can then have a short debate and get to work. My personal opinion is that we limit the TODOs to the absolutely necessary (ie satisfy Geoff's weekly status email) and get it working and call it 3.2. Everything else is a new release. I'll get my work done this week. Thanks. Neal Richter Knowledgebase Developer RightNow Technologies, Inc. Customer Service for Every Web Site Office: 406-522-1485 |
From: Lachlan A. <lh...@us...> - 2003-09-14 11:00:49
|
Greetings Neal, Thanks for your work in pushing 3.2 out. What is the URL of the ToDo=20 list? As an alternative, you could modify the STATUS file in CVS,=20 which is the basis of Geoff's weekly posts. The only ToDo I would add concerns backlink weights. Below (and at=20 <http://www.mail-archive.com/htd...@li.../msg01881.htm= l>)=20 is my original email from June, and Geoff's reply. The basic problem=20 is that the score based on a document is (sensibly) divided by the=20 number of words in a document, but the score for links *to* the=20 document isn't. Before releasing 3.2, we should either (1) remove the division by document size or (2) change the weightings in defaults.cc to balance this. The potential disadvantage with (2) is breaking compatibility with old=20 configurations. Opinions? Cheers, Lachlan > The base score of documents I search for is typically 0.0001, while > the backlink factor is typically 2000. Since these are added, the > weight given to the document itself is approximately zero! > >Does anyone know how this came about?=20 Well, that makes some sense. We haven't "recalibrated" the scoring,=20 though we trimmed out the whole "words in the front get higher score"=20 bit. And since I assumed that somewhere along the 3.2 development,=20 we'd add in some sort of "proximity weighting," I didn't really worry=20 about it. =20 As far as changing the weightings, I don't think anyone minds as long=20 as it's explained up-front in release documentation. In particular,=20 now that you don't have to reindex to change weightings, it's an easy=20 change to your config file. =20 -Geoff =20 On Wed, 27 Aug 2003 00:04, Neal Richter wrote: > =09McGill University recently contacted the one of the HtDig Board > members to inquire about making some kind of financial arrangement > with HtDig to get 3.2 finished, tested and working with Phrase > Searching -- ie quoted strings. > > =09Please post your TODO list and I'll compile them and post them on > a web-page prioritized for release. We can then have a short > debate and get to work. > > =09My personal opinion is that we limit the TODOs to the absolutely > necessary (ie satisfy Geoff's weekly status email) and get it > working and call it 3.2. Everything else is a new release. --=20 lh...@us... ht://Dig developer DownUnder (http://www.htdig.org) |
From: Neal R. <ne...@ri...> - 2003-09-15 18:51:42
|
I rolled back the mp_alloc changes, and the Mac OS X people reported no problems. I just got back from vacation and will make every effort to redo the memory leak fixes. I am using both Insure++ (commercial) and Valgrind (open source). As for the URL/TODO, no one really responded with outstanding tasks. I'd vote for (2) below. (1) will destroy the normalization of scores. Thanks! On Sun, 14 Sep 2003, Lachlan Andrew wrote: > Greetings Neal, > > Thanks for your work in pushing 3.2 out. What is the URL of the ToDo > list? As an alternative, you could modify the STATUS file in CVS, > which is the basis of Geoff's weekly posts. > > The only ToDo I would add concerns backlink weights. Below (and at > <http://www.mail-archive.com/htd...@li.../msg01881.html>) > is my original email from June, and Geoff's reply. The basic problem > is that the score based on a document is (sensibly) divided by the > number of words in a document, but the score for links *to* the > document isn't. Before releasing 3.2, we should either > (1) remove the division by document size or > (2) change the weightings in defaults.cc to balance this. > The potential disadvantage with (2) is breaking compatibility with old > configurations. Opinions? > > Cheers, > Lachlan > > > The base score of documents I search for is typically 0.0001, while > > the backlink factor is typically 2000. Since these are added, the > > weight given to the document itself is approximately zero! > > > >Does anyone know how this came about? > > Well, that makes some sense. We haven't "recalibrated" the scoring, > though we trimmed out the whole "words in the front get higher score" > bit. And since I assumed that somewhere along the 3.2 development, > we'd add in some sort of "proximity weighting," I didn't really worry > about it. > > As far as changing the weightings, I don't think anyone minds as long > as it's explained up-front in release documentation. In particular, > now that you don't have to reindex to change weightings, it's an easy > change to your config file. > > -Geoff > > > > On Wed, 27 Aug 2003 00:04, Neal Richter wrote: > > McGill University recently contacted the one of the HtDig Board > > members to inquire about making some kind of financial arrangement > > with HtDig to get 3.2 finished, tested and working with Phrase > > Searching -- ie quoted strings. > > > > Please post your TODO list and I'll compile them and post them on > > a web-page prioritized for release. We can then have a short > > debate and get to work. > > > > My personal opinion is that we limit the TODOs to the absolutely > > necessary (ie satisfy Geoff's weekly status email) and get it > > working and call it 3.2. Everything else is a new release. > > > -- > lh...@us... > ht://Dig developer DownUnder (http://www.htdig.org) > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > ht://Dig Developer mailing list: > htd...@li... > List information (subscribe/unsubscribe, etc.) > https://lists.sourceforge.net/lists/listinfo/htdig-dev > Neal Richter Knowledgebase Developer RightNow Technologies, Inc. Customer Service for Every Web Site Office: 406-522-1485 |
From: Gabriele B. <bar...@in...> - 2003-08-26 23:01:25
|
> Please post your TODO list and I'll compile them and post them on >a web-page prioritized for release. We can then have a short debate and >get to work. Well ... I have to fix some problems with the new autotools procedure. Ciao -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Neal R. <ne...@ri...> - 2003-08-27 15:00:16
|
On Wed, 27 Aug 2003, Gabriele Bartolini wrote: > > > Please post your TODO list and I'll compile them and post them on > >a web-page prioritized for release. We can then have a short debate and > >get to work. > > Well ... I have to fix some problems with the new autotools procedure. OK. Do you have an ETA? Note: Please leave libhtdig out of the autotols process for now. I'll work on it after you get the main codebase fixed. Thanks! Neal Richter Knowledgebase Developer RightNow Technologies, Inc. Customer Service for Every Web Site Office: 406-522-1485 |
From: Gabriele B. <bar...@in...> - 2003-08-28 04:32:23
|
> OK. Do you have an ETA? see next message. :-) -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Gabriele B. <bar...@in...> - 2003-08-28 04:41:53
|
Hi Neal, > Note: Please leave libhtdig out of the autotols process for >now. I'll work on it after you get the main codebase fixed. OK. I only have one question for you. The 'filecopy.cc' and 'filecopy.h' are part of htlib or not? They are not within htlib/Makefile.am and I was wondering if there is a reason for this. Indeed, when I try to run 'make dist' I get an error because these files can't be found. Consider that I perform 'make dist' outside of the source directory. Also I got another error, in the test directory, as far as the 'benchmark' target is concerned. Any hints on how we should manage this in Makefile.am? Thank you -Gabriele -- Gabriele Bartolini: Web Programmer, ht://Dig & IWA/HWG Member, ht://Check maintainer Current Location: Melbourne, Victoria, Australia bar...@in... | http://www.prato.linux.it/~gbartolini | ICQ#129221447 > "Leave every hope, ye who enter!", Dante Alighieri, Divine Comedy, The Inferno |
From: Neal R. <ne...@ri...> - 2003-08-28 15:23:56
|
On Thu, 28 Aug 2003, Gabriele Bartolini wrote: > Hi Neal, > > > Note: Please leave libhtdig out of the autotols process for > >now. I'll work on it after you get the main codebase fixed. > > OK. I only have one question for you. The 'filecopy.cc' and 'filecopy.h' > are part of htlib or not? They are not within htlib/Makefile.am and I was > wondering if there is a reason for this. Indeed, when I try to run 'make > dist' I get an error because these files can't be found. I have a small patch to EndingsDB.cc & Synonym.cc that used a function-based filecopy rather than the 'system()' call we do now. I can commit this anytime. When I initially proposed this change there was some push-back w.r.t 'if-it-aint-broke-dont-fix-it'. I changed it in my personal tree to fix an issue with native Win32 support. If there is no opposition I will commit the patch. > Consider that I perform 'make dist' outside of the source directory. > > Also I got another error, in the test directory, as far as the 'benchmark' > target is concerned. Any hints on how we should manage this in Makefile.am? Not sure about this one.. I'll investigate. Thanks! Neal Richter Knowledgebase Developer RightNow Technologies, Inc. Customer Service for Every Web Site Office: 406-522-1485 |