[Xapian-devel] Re: [Xapian-discuss] Xapian 1.0.1 released

Olly Betts olly at survex.com
Mon Jun 11 20:11:58 BST 2007


On Mon, Jun 11, 2007 at 08:11:11PM +0200, Daniel M?nard wrote:
> 1. In xapian.php (php5), class XapianQuery, constants OP_AND and 
> OP_ELITE_SET are defined as integers (0 and 10) and not as aliases of 
> "flat constants" (query_OP_AND, query_OP_ELITE_SET) like others do.

I think that's just because the code in SWIG which generates that file
uses SWIG's parse tree which knows that OP_AND is 0 (because it's first)
and OP_ELITE_SET is 10 (because it is explicitly set to that).  The
parse tree doesn't have explicit values for enum values allocated
sequentially.

So while this looks odd, it's harmless really.  Currently we don't parse
xapian-core's query.h (the long term aim is to just parse xapian-core
headers in all cases, with SWIG directives in the master file to ignore
things we don't want to wrap), so xapian.i currently duplicates the enum
from query.h, but we can't change these values without breaking the C++
ABI anyway.

> 2. On windows, from the php bindings, I can't use SimpleStopper (apache 
> hangs).
> Defining the stopper works fine:
> XapianQueryParser->setStopper($simpleStopper)
> but then if I try to parse a query, apache hangs the first time it 
> access the stopper.
> I guess it is very windows specific, perhaps something similar to the 
> strings allocation problem we got with join(get_matching_terms()) in the 
> past.
> I don't use the queryparser anymore but please let me know if I can help 
> debugging this one...

Do you have a complete (but ideally not too large) script which
demonstrates this?

> 3. I was surprised by the precedence of the "NOT" operator:
> QueryParser parses "a OR b NOT c" as "(a OR b) AND_NOT c"
> I thought it would have been "a OR (b AND_NOT c)" but I'm probably wrong 
> as queryparser.lemony states that NOT has lower priority than OR...

I think you've misunderstood the comment - I believe it gives equal
priority to NOT, OR, and XOR.  All these are lower than AND.

Perhaps that's wrong - it seems like NOT should probably bind more
tightly, especially as "AND NOT" is a synonym for it.  Perhaps the same
as AND.  It has been the same for nearly 7 years though - since the
original queryparser (written in bison):

http://cvs.xapian.org/xapian/xapian-examples/omega/Attic/parsequery.yy?rev=1.1&view=markup

So either most people don't notice (or care), or it's working as most
people expect.  I suspect the former, so it's probably OK to change
this.

> 4. Broken link
> On the page
> http://www.xapian.org/docs/
> the link to "documentation of Xapian's internals" is broken.

Fixed - the new file internals.html wasn't being shipped.  I've fixed
that and copied it over to the website by hand for now.

> 5. Typo
> In
> http://www.xapian.org/docs/overview.html
> paragraph which starts with "A Xapian::Query::OP_MAYBE node transmits 
> the documents" should read OP_AND_MAYBE

Fixed.

Cheers,
    Olly



More information about the Xapian-devel mailing list