similar to: submitting a xapian entry to the FreeBSD ports collection

Just got this error when replacing (updating) a document in the xapian index (using php bindings): Fatal error: Uncaught exception 'Exception' with message 'DatabaseError: Error reading block 16908825: got end of file' Does anyone know what this means exactly? Alec

I posted this message first. But it was missing so I post again. I think there is a some bug in build configration files. Can you check up the following errors and fix it? The error has no concern with UTF-8 patch. Environment : CentOS 4.3 x86_64 Sungsoo Kim ---------------------------------- [root at saturn xapian-core-0.9.4_svn6707]# make ... ... mkdir .libs/libxapian.lax/libqueryparser.a

I seem to be seeing cases where I call db.delete_document(somedocid) with no error, then flush() and delete the database object, but the document is still there after process exit. The write lock is normally deleted, so it appears that the database close finished normally. If I then then call delete_document(somedocid) from another command/process, this time it goes away. I've been seeing

Greetings, I've been wondering about the index format and backwards compatibility. We're using the dev version (for chert) and each svn up means that any indexes created prior to this revision cannot be read. Is this purely a cautious move to prevent errors, and, barring any obvious index format changes, can I safely force the current revision to read existing indexes? eg, by

The issue is that delve was renamed to xapian-delve but documentation is still saying that delve is delve. Who has access to update the documentation? http://www.linuxfromscratch.org/blfs/view/svn/general/xapian.html Installed Programs: copydatabase, delve, quest, simpleexpand, simpleindex, simplesearch, xapian-check, xapian-chert-update, xapian-compact, xapian-config, xapian-inspect,

Hi, we are an email hosting provider and we are looking at xapian to improve our user experience about email search. So we staring to build xapian 1.4.15 on Centos 7 with your xapian-core.spec and move it and the source code in /root/rpmbuild/SPECS and SOURCE, but we have this error after run "rpmbuild -ba": [...] Elaborazione file: xapian-core-devel-1.4.15-1.x86_64 errore: File

I have installed the new Xapian 1.4.0 , during the installation, I haven't seen any problems, however, when I execute commands quest and delve I get different versions, and my Perl-based searches return Exception: Couldn't detect type of database ... and what are these glass things in the index directories? There is a no new version of Perl Search::Xapian. $ quest -version quest -

Dear community, has anyone managed to get SSOAP working with the ChemSpider Web APIs, using functions which need the security token? I use SSOAP 0.9-0 from the OmegaHat repository. In the example code from SSOAP there is a sample which uses a token function. Interestingly, it checks if(!is.character(token)) first (and proceeds if the token is NOT character.) I can't test that function since I

I am fairly confident that these issues are related to killing the scriptindex process ungracefully causing blocks that were queued for writing to disk to not get written. I mention to send you the file because it could be that you would see almost immediately with the situation is. Thanks > ----- Original Message ----- > From: oscaruser@programmer.net > To:

On Mon, Sep 02, 2013 at 09:21:48AM +0800, jiangwen jiang wrote: > TfIdfWeight and BM25(b=0) also need wdf_upper_bound, it is not exists in > Lucene backends. If you don't provide an implementation of wdf_upper_bound(), the default is to use the collection frequency of the term, so provided that information is available in the lucene files, the lack of wdf_upper_bound information

I have written a very simple function to return the match count based on the simplesearch.cc code. It fails with a seg fault. The relevant code is: -------------------- int ftQuery(char* qs, const char* dbname,char* results, int msize) { long docid; char* op; char fullDB[1024]; string queryString;

olly wrote: > Log message (6 lines): > backends/flint/flint_database.cc: Delete the corresponding entry > (if any) from doclens in delete_document(). Add assertion to > add_document_() that the corresponding entry in doclens isn't > already set, but in a non-debug build overwrite any existing > entry as that's more likely to be correct. >

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

Thanks Olly, I have given flint a go -and it is generally much quicker (once it has loaded the cache -that process still takes minutes). Flint actually seems tro do some caching whereas quartz just seemed to hit the disc constantly. Generally I've been running it on a machine with 5G of memory -but it has to contend with other processes for resources, I have also run it on its own on a 1G

Hi, I've a problem to integrate xapian in my web application. I've developed the code for index e for search the documents published through my application. The app is developed in PHP. I've created a file that contain some function for search (called simpleSearch and advSearch). The problem is that if i run the code through the IDE (Zend for Eclipse) as PHP script it work correctly,

olly wrote: > SVN root: svn://svn.xapian.org/xapian > Changes by: olly > Revision: 8351 > Date: 2007-04-23 01:44:44 +0100 (Mon, 23 Apr 2007) > > Log message (2 lines): > backends/flint/flint_version.cc: Update the flint format version > since older flint versions can't read compressed tags. Am I correct in assuming that this means that when

Hi, I have implemented initial prototype of the Xapian::Weight subclass for Unigram Language Modelling to support UnigramLM weighing in xapian.Other changes include adding collection_frequency to TermFreqs struct to store collection frequency of terms and some changes to support it xapian Framework,Changing simplesearch.cc to search using UnigramLMWeight class. Following issues have not being

Hi, I have already re-make the patch file, based on the trunk codes in SVN respo. But I can not build the xapian, because there are many errors when building 'languages/' for stemmer. Therefore, I could not test the new patching code. Patching code can be accessed from: http://www.xunsearch.com/download/xapian-scws-1.3.x-trunk.patch Need to install SCWS first as below steps: 1.

Flint failed to deliver indexing performance to Quartz. I am proposing to remove Flint as default database and place Quartz database back as default. The catch is not that Flint database is smaller and faster during searches then Quartz database as developers were concerning when were measuring and neglecting to measure performance when creating the large indexes. The truth is that Flint

Olly Betts writes: > On Mon, Apr 11, 2016 at 09:54:36AM +0200, Jean-Francois Dockes wrote: > > The question which remains for me is if I should run xapian-compact > > after an initial indexing operation. I guess that this depends on the > > amount of expected updates and that there is no easy answer ? > > I think it's not obvious whether it's a good plan