Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4BA51FE9.3040406@peknet.com>
Date: Sat, 20 Mar 2010 14:20:09 -0500
From: Peter Karman <peter@peknet.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: lucy-dev@lucene.apache.org
CC: "KinoSearch discussion list." <kinosearch@rectangular.com>
Subject: Re: ProximityQuery
References: <4B9F01A8.7030506@peknet.com>
 <20100316044907.GA27885@rectangular.com> <4BA04918.101@peknet.com>
 <20100317160459.GA1854@rectangular.com> <4BA2E9D1.6050207@peknet.com>
 <20100319160639.GB16099@rectangular.com> <4BA3AA66.5020803@peknet.com>
 <20100319193503.GA17046@rectangular.com> <4BA43C25.8040406@peknet.com>
 <20100320190919.GA24206@rectangular.com>
In-Reply-To: <20100320190919.GA24206@rectangular.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Marvin Humphrey wrote on 3/20/10 2:09 PM:

> Calc_Phrase_Freq() is documented in PhraseScorer.bp.  I thought about adding
> additional explanatory comments to PhraseScorer.c, but I think that might be
> overkill.  If you had seen this, would it have been enough?
> 
>     /** Calculate how often the phrase occurs in the current document.
>      */
>     float
>     Calc_Phrase_Freq(PhraseScorer *self);
> 

yes, it would have been enough. There is a convention in C of putting the
comments/documentation for functions in the .h file, which has an analog in the
.bp files in Lucy/KS. Mostly this just means needing to look in 2 places
more-or-less simultaneously, since the .bp files (like .h) mostly just hold the
signatures. It's fine; it's just something I have to remember since my
day-to-day is with languages that don't have separate .h/.bp and .c files.


>> All those GOTO calls are indeed "non-standard form" (wink wink, nudge nudge)
>> and were what sparked my initial question to the list.
> 
> I thought about commenting that section, but I couldn't really improve on
> Nate's code.  It's self-documenting and impressively compact.  The larger
> algorithm is described in the multi-line comment above.  So maybe leave it as
> is for now?

it's fine to leave it as it is. The terse-ness of the code just meant that the
late hour at which I first started looking at this was not a good time for
full-brain functioning. ;)

> parcel Lucy;
> 
> /** Quick-start guide to hacking on Lucy.

very clear and helpful. Wish I had it months ago. :) Now I understand the
function-vs-method capitalization.

thanks, Marvin.

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com