similar to: Solaris (and stuff) build issue

Question for people who have successfully used these bindings - how do I create a database object? I can't use open(), because it doesn't like the number of arguments, presumably because it's an overloaded method and hence we should rename it in PHP. So how do others do it? Or am I the only person trying to create a writable database object in PHP? :) J --

I think we want to apply the following patch to make the NumberValueRangeProcessor documentation (a) make sense, and (b) accurate: ---------------------------------------------------------------------- --- include/xapian/queryparser.h (revision 9993) +++ include/xapian/queryparser.h (working copy) @@ -213,7 +213,7 @@ * * For example, if str_ is "$" and prefix_

This is going to be a problem. I don't appear to be able to rename a method once it's declared. So if the core bindings file declares some overloaded operators, functions or constructors, it's impossible to move them out of the way in only some of the bindings. Since Python supports overloading, I can't think of any solution to this other than maintaining two different xapian.i

We've lost tinderbox (last build 25th), which is presumably why the following wasn't caught: ---------------------------------------------------------------------- /s1/james/projects/xapian/xapian/xapian-core/extra/queryparser.yy: In function `int yylex()': /s1/james/projects/xapian/xapian/xapian-core/extra/queryparser.yy:443: `class std::basic_string<char,

On Thu, Oct 21, 2004 at 05:45:42PM +0100, Olly Betts wrote: > Log message: > python/docs/bindings.html: Remove documentation explicitly saying > how we wrap Xapian::QueryParser and Xapian::Stem since we wrap them > exactly as we wrap everything else we don't mention! Also mention > simpleexpand example. The point of this comment was to highlight that they exist within the

Hi - I've been fixing up the bindings to match the latest API. Should be able to commit later today or tomorrow. The smoketest on PHP isn't working any more, apparently because the inmemory backend isn't accessible (I haven't looked in detail - I fixed them for something I was doing). (Also some more magic iterators for the Python bindings.) J --

This doesn't build on G++ 3.0 - are we still trying to support that? If not, I'll have to get a more recent toolchain sorted out. J -- /--------------------------------------------------------------------------\ James Aylett xapian.org james at tartarus.org uncertaintydivision.org

There are various other situations where we create symlinks instead of copying, and as some of these are used in libtool I've given up trying to build in the way I was doing. It's a little unfortunate, but as it's probably a bug in the linux NFS server, which isn't the best in the world anyway, let's just ignore everything there for the time being. However ``make

I'm getting remotetest and apitest failing for me on ixion on SVN HEAD-ish. I can't find a link to tinderbox anywhere obvious (I expected it to be linked from bleeding edge, and possibly the bugzilla start page), so I don't know if it's something dumb I've done to my setup and checkout, or a genuine problem. Any ideas? J --

Tinderbox is showing failures in Search::Xapian on atreus with g++ 4.1 (which looks like tests out of date at a *very* cursory examination, and in any case everyone should know about); I'm also getting different test failures on the same system -- valgrind (I assume) is finding potential memory leaks for every test against the remotetcp backend. (Incidentally, I've just installed

Kevin Burton has posted about poor ranking in Lucene preferring shorter documents over longer ones[1]. A similar search in Xapian returns documents in the expected order: Performing query `Xapian::Query(foo)' 3 results found ID 3 99% [foo foo foo] ID 2 94% [foo foo] ID 1 80% [foo] Anyone know what Lucene is doing here? Their FAQ doesn't mention what weighting scheme they use, and I

Finally had a chance to read this - looks great, thanks Jim! I think we can improve it ever so slightly by being a little more explicit at the end: > {{{ > /usr/local/bin/omindex --db /var/lib/omega/data/default > --url /book /var/www/book > }}} [...] > The --url parameter identifies the url prefix that corresponds to > the directory we start indexing from. Since we put the

We have: ---------------------------------------------------------------------- typedef unsigned long uint4; ---------------------------------------------------------------------- which on an LP64 system is a lie. If uint4 is used on disk (and it's used in the btree implementation) then it would make the databases unportable, which probably isn't a good idea (unless we already have

Please keep conversations on-list so that everyone can help and benefit :-) On Sun, Jul 29, 2007 at 09:15:01PM +0800, Hightman(???) wrote: > James Aylett,??? > > Even if I split the two operator into different transaction one > after another, It cause DatabaseModifiedError Also ... It seems > that if I update one document by unique term frequently (within >

Questions are threaded into the output: ******************** #./configure --without-python checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking

As discussed on IRC. The naming conventions aren't ideal, but the intent feels right and it works for me. J -- /--------------------------------------------------------------------------\ James Aylett xapian.org james at tartarus.org uncertaintydivision.org -------------- next part -------------- Index:

Periodically I notice something caught in the spam filter for one of the lists, and go through and dig out all the things that look like genuine email. There usually aren't that many, but there are a few this time going back to May. I thought it'd be better to push them all out, even thought some may not be relevant any more, and some may have been reposted by people who have since joined

Periodically I notice something caught in the spam filter for one of the lists, and go through and dig out all the things that look like genuine email. There usually aren't that many, but there are a few this time going back to May. I thought it'd be better to push them all out, even thought some may not be relevant any more, and some may have been reposted by people who have since joined

I've had to move the website onto a different partition on ixion. It should all be running happily off the new one, and existing scripts etc. should work fine. Let me know if there are any problems. J -- /--------------------------------------------------------------------------\ James Aylett xapian.org james at tartarus.org

Oh. The diff file doesn't seem to include the two new files. We're outside right now. I'll send you the files as soon as we reach in 30-40 minutes. Also, we're moving to git. Thanks On Apr 13, 2014 9:12 PM, "James Aylett" <james-xapian at tartarus.org> wrote: > On 13 Apr 2014, at 16:16, Siddhant Mutha <siddhantmutha at gmail.com> wrote: > > > We