From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailout.scc.kit.edu (mailout.scc.kit.edu [129.13.185.202]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id q55MH5o8015934 for ; Tue, 5 Jun 2012 18:17:06 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by scc-mailout-02.scc.kit.edu with esmtp (Exim 4.72 #1) id 1Sc23k-0003KH-R9; Wed, 06 Jun 2012 00:17:04 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1Sc23k-0007JH-TS for tech@mdocml.bsd.lv; Wed, 06 Jun 2012 00:17:04 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.72) (envelope-from ) id 1Sc23k-00044o-QX for tech@mdocml.bsd.lv; Wed, 06 Jun 2012 00:17:04 +0200 Received: from schwarze by usta.de with local (Exim 4.77) (envelope-from ) id 1Sc23k-0005ZZ-IV for tech@mdocml.bsd.lv; Wed, 06 Jun 2012 00:17:04 +0200 Date: Wed, 6 Jun 2012 00:17:04 +0200 From: Ingo Schwarze To: tech@mdocml.bsd.lv Subject: Re: sqlite3 mandocdb and apropos (etc.) Message-ID: <20120605221704.GA27160@iris.usta.de> References: <4FCE1871.90605@bsd.lv> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FCE1871.90605@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) Hi Kristaps, Kristaps Dzonsons wrote on Tue, Jun 05, 2012 at 04:32:17PM +0200: > Enclosed [finally] is a patch against HEAD that uses sqlite3 for > mandocdb and apropos (getting the others to use it is quite easy). > It's a work in progress, but is the simplest possible implementation > before extensive polishing. I'd like to get this in to start > refining. I am interested in the sqlite3 integration and hope we get it going. Certainly, this will need a thorough review, and i hope to find some time for it. As i couldn't find the time for a full review right now, i'm sending comments on one aspect that became obvious at once. > First of all, you'll need uthash (in ports) and sqlite3 to build. I > chose uthash for hashtables just because I'm familiar with it. I'd > like to use espie@'s ohash stuff instead to reduce dependencies, but > since uthash is just a header file, I'm not that concerned. First point, the base system cannot ever use anything from ports. Thus, using uthash would require to import it into base and maintain it there. So i had a brief look at it - and even without understanding what it does, i think there is no way in hell to ever get that imported. The file uthash.h alone is 900 lines of abusing cpp(1) macro definitions instead of defining proper functions. I cannot imagine that you will find anybody willing to do the required code audit on code of that style, let alone build consensus to import such code; myself, i must say it feels positively revolting on first sight. Of course, i might be wrong in my first impression, but if you suspect i am wrong and this is actually code of sufficient quality to be considered for inclusion in base, i'd recommend you first verify with some of the usual suspects for userland library hacking (like millert@, otto@, guenther@, deraadt@, ...) before spending a lot of time integrating it and then being disappointed later. Otherwise, it's probably better to choose tools available in base first and use those, at least for now, to avoid changing too much in a single step. > There are a few significant differences between this and the last > mandocdb family of tools: > > 1. apropos_db.c -> mansearch.c (simplified search interface) > 2. UTF-8 encoding in database > 3. fts(3) in mandocdb > 4. for the time being, only OR'd expressions using IS/GLOB > 5. lots of hashing (uthash) in mandocdb > 6. only apropos/mandocdb/manpage are enabled (for now) I will have to look at that... Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv