From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by krisdoz.my.domain (8.14.5/8.14.5) with ESMTP id q55Mh90a032671 for ; Tue, 5 Jun 2012 18:43:10 -0400 (EDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 5B59D14E26A; Wed, 6 Jun 2012 00:43:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id pY1eM5-j8FZE; Wed, 6 Jun 2012 00:43:01 +0200 (CEST) X-KTH-Auth: kristaps [77.72.97.36] X-KTH-mail-from: kristaps@bsd.lv Received: from macky.local (unknown [77.72.97.36]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 52A6314E0B0; Wed, 6 Jun 2012 00:43:00 +0200 (CEST) Message-ID: <4FCE8B74.10601@bsd.lv> Date: Wed, 06 Jun 2012 00:43:00 +0200 From: Kristaps Dzonsons User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 To: tech@mdocml.bsd.lv CC: Ingo Schwarze Subject: Re: sqlite3 mandocdb and apropos (etc.) References: <4FCE1871.90605@bsd.lv> <20120605221704.GA27160@iris.usta.de> In-Reply-To: <20120605221704.GA27160@iris.usta.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/06/2012 00:17, Ingo Schwarze wrote: > 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. Ingo, As mentioned, although important as a concept, this is a pretty insignificant part of the code---I used uthash simply because it was lightweight in terms of interfacing. It's not a final solution, nor is it, as I've found, reasonable for optimistic growth---it didn't let me control for allocation failure, which is a must for letting the string table fill memory then purge when it overgrows. So as said, I'll probably end up with espie@'s ohash, which from what I understand uses Knuth's AofP algorithm and lets me control the hash allocation. Best, Kristaps -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv