similar to: Website

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 --

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

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

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 --

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,

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 >

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_

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

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

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

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:

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

bugzilla-daemon@ixion.tartarus.org wrote: > http://www.xapian.org/cgi-bin/bugzilla/show_bug.cgi?id=117 > > ------- Additional Comments From olly@survex.com 2007-04-05 13:52 ------- > I've actually already implemented a fix. If bugzilla stops sending me mail, I > might even manage to check it in soon! Sorry Olly - just about finished sorting things out now! For everyone

I've been wondering if we should consider migrating from CVS to Subversion (aka SVN) for version control. There's a utility (cvs2svn) to convert a CVS repository while keeping full history. And SVN is supported by viewcvs (as used by http://cvs.xapian.org/) The main motivations are: * CVS doesn't really handle renaming files well. Either you "cvs rm" then "cvs

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 --

Can't configure on Solaris 9 Sparc, on a volume mounted over NFS from Debian 3.0 linux 2.2 IA32. For some reason, cc1plus thinks _versionh.cc is a directory. Changing the ``ln -s'' to a ``cp'' solves this problem. Is there any reason not to cp? Solaris->Solaris NFS, and Solaris local file system are both quite happy without this change. J --

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

Please keep replies on the mailing list — more people can help (and benefit) that way :) So OP_NEAR looks for its terms close to each other (hence "near"). The window is how far away they can be. Probably the easiest way to play with this is using the NEAR syntax in the query parser. So if you had a plain text document: I am walking, always walking. And index it in a very simple

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