similar to: Future of the xapian-commits list

On Tue, Jun 30, 2015 at 12:30:35PM -0700, Eric Lindblad wrote: > I don't know if it would be of any use - and I know that > the configure script searches for gawk, sed and grep - > but Watcom has free 32 and 64 bit compilers, and > the msvc files for Xapian no longer appear to be > maintained, so perhaps Xapian build files written for > [Open] Watcom could be made, as such

Xapian Developers, [I initially thought to install xapian on SFU (Interix 3.5) on MS XP but could not compile libuuid] [getopt.h, inttypes.h, and stdint.h taken from SUA (for Vista) and installed in SFU (Interix 3.5)] If someone is inclined to write a modified libuuid and label it for use with Interix <version(s)> to satisfy the dependency for an xapian <version(s)> install on

Dear Olly Betts, same 32 bit compiler version hardware OS OS version as here (where remotetcp_chert passed and skipped 3) xapian-core-1.2.21.tar.xz http://nurmi-labs.blogspot.com/2015/10/xapian.html ./apitest backend remoteprog_brass: All 225 tests passed, 3 skipped. ./apitest backend remotetcp_brass: All 225 tests passed, 3 skipped. ./apitest backend remoteprog_chert: All 225 tests passed,

Carrying on this conversation: http://lists.tartarus.org/pipermail/xapian-discuss/2007-March/003513.html void TermGenerator::set_stopper(stopper) Stopper * stopper CODE: // FIXME: no corresponding SvREFCNT_dec(), but a leak seems better than // a SEGV! SvREFCNT_inc(ST(1)); THIS->set_stopper(stopper); It would be good to fix these FIXMEs. A class-level HASH could be

Hi All, When are the XS-based Perl bindings going to be deprecated in favour of the SWIG bindings? Please remove the dead RHEL RPMs from: http://xapian.org/download I've built RPMs for RHEL5/CentOS5 (with a different signing key) here: http://rpm.eprints.org/xapian/5/ RHEL4 is eol and shouldn't be used. For my own convenience I have written an RPM for the repository: rpm -ivh

I'm happy to be able to announce that Xapian 1.3.4 is now available. Please note that 1.3.x releases are development releases - they are made to encourage earlier and wider use and testing of new and changed code. Our record with 1.1.x was very good - all the bugs I am aware of were either in new features, or were also present in the corresponding 1.0.x release. But if you main concern is

On Tue, May 11, 2004 at 05:41:58PM +0100, Richard Boulton wrote: > * If the queryserver can't parse a query, strip out all special > characters, and then retry. This means that we get some kind of > result even if the query is broken. That's probably a feature worth pushing down into Xapian::QueryParser... Cheers, Olly

Dear Olly Betts, I think the tests for the perl module Search-Xapian-1.2.21.0 might be fewer in number than the perl tests included with xapian-bindings-1.2.21. If some of the tests have similar but modified content I do not know. I am not so skilled as to interpret the compared test results. If you want to suggest a paired earlier version of Xapian to a specific xapian.bindings version, I might

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

On Tue, Jan 02, 2007 at 03:55:59PM +0000, richard wrote: > * backends/quartz/btree.cc,backends/flint/flint_io.h: Patches from > Charlie Hull to allow 2GB+ index files work when compiled using > Visual C++. I suspect that xapian-compact.cc (and quartzcompact.cc if you can be bothered) will also need fixing since they use off_t. You need to make sure that the stat() function called

Report by Eric Lindblad 30-09-2015 http://www.ericlindblad.blogspot.com The xapian-core-1.2.21 'ambiguous overload' error on the files /backends/brass/brass_check.cc and /backends/chert/chert_check.cc appear to be resultant of a bug reported in gcc-3.3.4, which was fixed for 3.4.2 [Sept. 6, 2004] and 3.5. Bug 16854 - streams missing "long long" specializations on Tru64

Hi I'm trying to configure and install XAPIAN for hacking. The problem it's the current XAPIAN-Master of github it's not working. I try to configure the XAPIAN-CORE and he don´t recognize ./configure or if I run from a build folder ../configure I'm working in a CENTOS 7 and i installed this prerequisits: yum group install "Development Tools" #for GCC 4.8.5 and make

Report by Eric Lindblad 11-09-2015 http://www.ericlindblad.blogspot.com I compiled xapian-core-1.0.23 today on Interix. 'gmake check' summary PASS: btreetest, quartztest, stemtest, termgentest FAIL: apitest, internaltest, queryparsertest MS XP SP3 HOME modified SFU Interix 3.5 w/ getopt.h, inttypes.h, & stdint.h copied over from SUA Interix for Vista (and newer) into

On Wed, 24 Feb 2016 03:17:35 +0000, Olly Betts <olly at survex.com> wrote: >On Mon, Feb 22, 2016 at 12:26:27PM +0100, Eric wrote: >> On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: >>> On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: >>>> I discovered, while trying to set up Tcl bindings for Notmuch >>>>

I've uploaded Xapian 1.0.7, which as usual you can download from: http://xapian.org/download This release fixes an assortment of bugs, and improves efficiency in a few cases. It's intended to be a relatively safe incremental update over 1.0.6. For a more detailed overview see: http://trac.xapian.org/wiki/ReleaseOverview/1.0.7 The full lists of user-visible changes are linked to from

hi~ OS: Windows Server 2008 R2 <http://code.google.com/p/djapian/source/detail?r=2>, 64-bit xapian version: 1.0.15, just installed the package from http://www.flax.co.uk/xapian/1015/xapian-python-bindings%20for%20Python%202.6.2%20-1.0.15.win32.exe dapian version: 2.2.4, use xapian in dapian. When running the rebuild, got the error, like: >python manage.py index --rebuild [Error 126]

On Mon, Oct 01, 2007 at 01:13:07PM +0100, richard wrote: > Log message (3 lines): > net/remoteconnection.cc: After calling read(), check for received > == 0 after checking for errors, so that if an EINTR occurs in > read, we don't report EOF instead of retrying. > [...] > http://xapian.org/C?9389?trunk/xapian-core/net/remoteconnection.cc I don't think this change is

On Wed, Mar 07, 2007 at 11:22:36PM +0000, olly wrote: > docs/Makefile.am: Stop shipping docs/apidoc/latex/* in the > xapian-core tarballs since it's just useless bloat. Removing it > more than halves the size of the tarball (55% reduction!) Hmm, this is very odd. I tried unpacking the last xapian-core snapshot tarball, deleting the junk files, and rebuilding the tarball, and I got

On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: > On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: > > I discovered, while trying to set up Tcl bindings for Notmuch > > (https://notmuchmail.org/), which uses Xapian, that flintlock was not > > being locked (I had lost updates). > > It seems to work for me, testing with this: >

Sorry ,it's not bugzilla it's trac software and i have asked about this on irc but i didn't get any reply. On Thu, Jun 15, 2017 at 1:40 AM, Olly Betts <olly at survex.com> wrote: > On Wed, Jun 14, 2017 at 09:26:37AM +0000, Eric Lindblad wrote: > > > I am not able to register on bugzilla due to spam error.can someone > help me with this issue? > > > >