http://blog.gmane.org/gmane.comp.search.xapian.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.search.xapian.general/9377 <pre>Hello, first post. I searched through docs and examples but did not see this particular problem answered. I have thousands of text files total size about 17GB. Within a file I need for find a phrase (typically up to 3 words together separated by spaces, commas, and non period punctuation mark). I have a dictionary of about 3 million phrases and their replacement. So I need to replace all of the matching phrases from the dictionary with their replacements The most brute force approach I though was a) build an index on all of the 17GB of documents b) for every one of the 3 million search phrases do search c) expect to return from ( b ) xapian match where I would get the start and end byte location in a file for every search remember that location, and the found phrase in a 'future replacement list' d) when done , use the 'future replacement list' -- to perform the replacement operation Obviously couple of problems 3 million times search 17GB worth of text Second -- I do not understand how (if at all possible) to get the start/end offset of the found phrase within the source file Third how do I insure that the phrase words are together (and the one with period between them is not concidered a find). thank you in advance for any suggestions, vsp </pre> V S P 2012-05-21T02:59:11 http://comments.gmane.org/gmane.comp.search.xapian.general/9374 <pre>As Xapian's been dropped from the Ubuntu repositories, I'm attempting to build my own .deb from the instructions here: http://article.gmane.org/gmane.comp.search.xapian.general/8855 http://beeznest.wordpress.com/2011/07/06/howto-build-your-own-binaries-of-ph p-xapian-bindings-for-debian/ I can only get things to progress beyond the first few seconds by leaving out 'rm debian/control', but if I do, it looks as if the Python and Ruby bindings are building and passing their versions of smoketest correctly. However, the PHP part of the build is failing with this error: /home/charlie/xapian-bindings-1.2.8/php/smoketest.php:38: include(xapian.php): failed to open stream: No such file or directory FAIL: smoketest.php There's a xapian.php file in /home/charlie/xapian-bindings-1.2.8/php/php5/ but if I copy it to /home/charlie/xapian-bindings-1.2.8/php/ or change the path to it in smoketest.php, the build fails right near the start with: dpkg-source: error: aborting due to unexpected upstream changes Unfortunately I'm out of my comfort zone building from source. Anyone got any ideas? </pre> Rowan < at > Jetboy 2012-05-20T11:27:53 http://comments.gmane.org/gmane.comp.search.xapian.general/9369 <pre>Hello, I'm trying to build the xapian bindings to use with php, i've installed using MAMP to make it easier to set up the apache/php/myssql stuff (http://www.mamp.info/en/mamp/index.html), but when I try to configure the bindings, i get this: configure: error: '/usr/bin/php-config --includes' reports '-I/Applications/MAMP/bin/php/php5.3.6/include/php -I/Applications/MAMP/bin/php/php5.3.6/include/php/main -I/Applications/MAMP/bin/php/php5.3.6/include/php/TSRM -I/Applications/MAMP/bin/php/php5.3.6/include/php/Zend -I/Applications/MAMP/bin/php/php5.3.6/include/php/ext -I/Applications/MAMP/bin/php/php5.3.6/include/php/ext/date/lib' but zend.h can't be included from there I made it so its using the php-configure from MAMP, so its reporting the correct paths, those paths did not exist, but I downloaded the header files for the correct php version and stuck them in there, but its still claiming it can't find them. I've tried a lot of things and nothing work =( I read this blog post: http://blog.geertvd.be/2011/04/15/using-xapian-on-os-x-with-mamp/ but he doesn't list a solution, other then just use php 5.2 (which i really don't want to do since i'm using some features that are only in 5.3) Any ideas? ~Mark </pre> Mark Grandi 2012-05-17T23:29:09 http://comments.gmane.org/gmane.comp.search.xapian.general/9363 <pre>I've uploaded Xapian 1.2.10 (including Search::Xapian 1.2.10.0). Unsurprisingly, you can download it from: http://xapian.org/download You can read an overview of the release here: http://trac.xapian.org/wiki/ReleaseOverview/1.2.10 The full lists of user-visible changes are linked to from there, and also from the "[news]" links on the download page. As always, if you encounter problems, please report them here, or to the bug-tracker: http://xapian.org/bugs Here are the SHA1 checksums of the released files: 121e0ab529a3e5a70931f61463a56e944805ae10 Search-Xapian-1.2.10.0.tar.gz 631c7650ac2ca47f8a72434a06d463da5b7596f4 xapian-bindings-1.2.10.tar.gz 1be1896ab11a3a66c6c0ade962c700d96678116e xapian-core-1.2.10.tar.gz 59fca635728d5ce2ca18e5f39b8d3ef081e46f6c xapian-omega-1.2.10.tar.gz And SHA256 checksums (more secure, but sha256sum is less widely installed): 9695b45b978ef41b367fc5ea2bcf5ecbc2b4c5aff6d138d7dbc31946fdb86bc7 Search-Xapian-1.2.10.0.tar.gz dd191ad2e1134b7008b3b71c7cab41d2d80df2fe82ecdb9ad68c11209ba19382 xapian-bindings-1.2.10.tar.gz 05cf0c374cdda2b0a655f4d8897b37729a0d0d6887fd12bf86c778b486ef874f xapian-core-1.2.10.tar.gz 464a681647c1348fe7ab7ab5d8e32c27dc0d48a863ce5d78881e18334dfaad4f xapian-omega-1.2.10.tar.gz Cheers, Olly _______________________________________________ Xapian-discuss mailing list Xapian-discuss&lt; at &gt;lists.xapian.org http://lists.xapian.org/mailman/listinfo/xapian-discuss </pre> Olly Betts 2012-05-10T01:31:34 http://comments.gmane.org/gmane.comp.search.xapian.general/9361 <pre>Hi, Could you please clarify a query regarding full text search in Xapain? I have installed LXRng (cross-referencer), which internally uses Xapain for text search. I am using CentOS 6 &amp; have installed the following Xapian packages: $ yum list installed | grep -i xapian perl-Search-Xapian.x86_64 1.2.9.0-1.el6 &lt; at &gt;rpm-eprints-org-xapian perl-Search-Xapian-debuginfo.i686 1.2.7.0-1.el6 &lt; at &gt;rpm-eprints-org-xapian perl-Search-Xapian-debuginfo.x86_64 1.2.7.0-1.el6 &lt; at &gt;rpm-eprints-org-xapian rpm-eprints-org-xapian.noarch xapian-bindings.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-bindings-perl.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-bindings-php.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-core.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-core-debuginfo.x86_64 1.2.7-1 &lt; at &gt;rpm-eprints-org-xapian xapian-core-devel.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-core-libs.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-omega.x86_64 1.2.9-1 &lt; at &gt;rpm-eprints-org-xapian xapian-omega-debuginfo.x86_64 1.2.7-1 &lt; at &gt;rpm-eprints-org-xapian $ However, when I search for more than one word with double quotes, displayed line numbers are incorrect (but, displayed file names are correct). Please help me how I go about solving this issue. Thanks, Babu </pre> Babu Neelam 2012-05-03T02:34:04 http://comments.gmane.org/gmane.comp.search.xapian.general/9360 <pre>The accepted students were announced earlier this week. I wrote a blog post yesterday with the details, which I'll link to rather than repeat here: http://survex.com/~olly/blog/xapian/xapian-gsoc-2012-projects.html We're intending to use the xapian-devel mailing list for development discussion of the projects - if you want to follow along, please subscribe, or follow it on gmane, or similar. We'll also be using the #xapian IRC channel on Freenode. Please help answer questions where you feel able, and if you're interested in the projects, do try them out and offer constructive feedback. Cheers, Olly </pre> Olly Betts 2012-04-27T06:06:04 http://comments.gmane.org/gmane.comp.search.xapian.general/9356 <pre>We've had some catastrophic filesystem failures that have left us with corrupted databases with empty files and no backup for about 15TB of our data. Recreating the 15TB from source data backups is possible but will take a very very long time. I'm hoping that, given all of the .DB files are still intact, there my be some way to extract their contents and rebuild the other tables. This is one of our 800 databases that has been corrupted and you can see which files are empty: drwxr-xr-x 1152 search search 40960 Apr 15 23:06 .. drwxr-xr-x 2 search search 4096 Jan 31 17:39 . -rw-r--r-- 1 search search 0 Jan 31 17:39 iamchert -rw-r--r-- 1 search search 0 Jan 31 17:39 position.baseB -rw-r--r-- 1 search search 2191785984 Jan 31 17:39 position.DB -rw-r--r-- 1 search search 0 Jan 31 17:37 position.baseA -rw-r--r-- 1 search search 0 Jan 31 17:37 termlist.baseB -rw-r--r-- 1 search search 3953393664 Jan 31 17:37 termlist.DB -rw-r--r-- 1 search search 0 Jan 31 17:37 record.baseB -rw-r--r-- 1 search search 10681057280 Jan 31 17:37 record.DB -rw-r--r-- 1 search search 0 Jan 31 17:37 termlist.baseA -rw-r--r-- 1 search search 0 Jan 31 17:15 postlist.baseB -rw-r--r-- 1 search search 5559812096 Jan 31 17:15 postlist.DB -rw-r--r-- 1 search search 0 Jan 31 17:15 record.baseA -rw-r--r-- 1 search search 0 Jan 31 17:10 postlist.baseA I have already tried recreating the .baseA and iamchert files from copying similar databases (as these seem to be identical save for the UUID in iamchert) but can't get it to be usable without the .baseB files. I've also tried using copy database but that doesn't work. Can someone tell me what is in the .baseB files and if their contents can be recreated from the .DB files if I were to write something that can read and process the files at a low level. </pre> Graham Jones 2012-04-16T00:15:08 http://comments.gmane.org/gmane.comp.search.xapian.general/9354 <pre>Hello :-) Does omega support favicon.ico files? If so, how can they be set up? If not, please consider enhancing Omega to do so and providing a default favicon.ico file. There are two reasons for wanting favicon.ico support: 1. Apache generates 404 errors for /favicon.ico when serving an Omega-generated page. 2. It would provide a more complete UI appearance. Best Charles </pre> Charles 2012-04-14T03:14:51 http://comments.gmane.org/gmane.comp.search.xapian.general/9350 <pre>Hi there, I'm looking for a full-text-search engine/library and find xapian after googling. The application I'm working on get some specific characteristic: 1.The current data-set are already quite huge: multi-tera bytes, even after compression. 2.Existing data are mostly read-only. 3.New data is coming every minute. The daily total could be several gigabytes (before compressing). 4.Query rate are not huge, yet. But I do expect a real-time search, that's, new data is expected to be available for searching after a few minutes. Could you share some thought about xapian with regard to above aspects? Especially on incremental index update. Best Regards! Jaguar </pre> Jaguar Xiong 2012-04-04T02:26:19 http://comments.gmane.org/gmane.comp.search.xapian.general/9346 <pre>I'm using PHP. Xapian is giving me this: Fatal error: No matching function for overloaded 'Enquire_set_sort_by_key' in PATH/xapian.php line 1068 Confirmed that the xapian.so extension is loaded successfully. var_dump(function_exists('Enquire_set_sort_by_key') outputs true. in xapian.php line 1068 : case 1: Enquire_set_sort_by_key($this-&gt;_cPtr,$sorter); break; As the source code of the function suggests, it has to be passed a third parameter so I did: case 1: Enquire_set_sort_by_key($this-&gt;_cPtr,$sorter, FALSE); break; but after this, I got 'segmentation fault from the apache error log and no response is processed and sent back to browser. Is it a but in xapian.so or what, how to solve this? Thanks. </pre> Xiao-Wei (Shawn) Xu 2012-04-01T03:51:10 http://comments.gmane.org/gmane.comp.search.xapian.general/9338 <pre>Hi All, I 'm trying to build Omega 1.2.9, configure ran through, but when I do make I get error below. Any thoughts what I am missing? Thanks Noel make all-recursive make[1]: Entering directory `/xapian/xapian-omega-1.2.9' Making all in . make[2]: Entering directory `/xapian/xapian-omega-1.2.9' /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I./commo n -I/usr/local/include -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual - Wcast-align -Wno-long-long -Wformat-security -fno-gnu-keywords -Wundef -Wstrict- null-sentinel -Wshadow -Wstrict-overflow=1 -Winit-self -Wlogical-op -Wmissing-de clarations -fvisibility=hidden -I/xapian/xapian-core-1.2.9/include -g -O2 -MT li btransform_la-transform.lo -MD -MP -MF .deps/libtransform_la-transform.Tpo -c -o libtransform_la-transform.lo `test -f 'transform.cc' || echo './'`transform.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I./common -I/usr/local/include -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -W format-security -fno-gnu-keywords -Wundef -Wstrict-null-sentinel -Wshadow -Wstri ct-overflow=1 -Winit-self -Wlogical-op -Wmissing-declarations -fvisibility=hidde n -I/xapian/xapian-core-1.2.9/include -g -O2 -MT libtransform_la-transform.lo -M D -MP -MF .deps/libtransform_la-transform.Tpo -c transform.cc -DDLL_EXPORT -DPI C -o .libs/libtransform_la-transform.o libtool: compile: g++ -DHAVE_CONFIG_H -I. -I./common -I/usr/local/include -Wall -W -Wredundant-decls -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -W format-security -fno-gnu-keywords -Wundef -Wstrict-null-sentinel -Wshadow -Wstri ct-overflow=1 -Winit-self -Wlogical-op -Wmissing-declarations -fvisibility=hidde n -I/xapian/xapian-core-1.2.9/include -g -O2 -MT libtransform_la-transform.lo -M D -MP -MF .deps/libtransform_la-transform.Tpo -c transform.cc -o libtransform_la -transform.o &gt;/dev/null 2&gt;&amp;1 mv -f .deps/libtransform_la-transform.Tpo .deps/libtransform_la-transform.Plo /bin/sh ./libtool --tag=CXX --mode=link g++ -Wall -W -Wredundant-decls -Wpoin ter-arith -Wcast-qual -Wcast-align -Wno-long-long -Wformat-security -fno-gnu-key words -Wundef -Wstrict-null-sentinel -Wshadow -Wstrict-overflow=1 -Winit-self -W logical-op -Wmissing-declarations -fvisibility=hidden -I/xapian/xapian-core-1.2. 9/include -g -O2 -no-undefined -o libtransform.la libtransform_la-transform.l o -L/usr/local/lib -lpcre libtool: link: rm -fr .libs/libtransform.a .libs/libtransform.la libtool: link: ar cru .libs/libtransform.a .libs/libtransform_la-transform.o libtool: link: ranlib .libs/libtransform.a libtool: link: ( cd ".libs" &amp;&amp; rm -f "libtransform.la" &amp;&amp; cp -p "../libtransform .la" "libtransform.la" ) g++ -DHAVE_CONFIG_H -I. -I./common -DCONFIGFILE_SYSTEM=\"/usr/local/etc/omega.co nf\" -DPKGLIBBINDIR=\"/usr/local/lib/xapian-omega/bin\" -Wall -W -Wredundant-de cls -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wformat-security -f no-gnu-keywords -Wundef -Wstrict-null-sentinel -Wshadow -Wstrict-overflow=1 -Win it-self -Wlogical-op -Wmissing-declarations -fvisibility=hidden -I/xapian/xapian -core-1.2.9/include -g -O2 -MT freemem.o -MD -MP -MF .deps/freemem.Tpo -c -o fre emem.o freemem.cc freemem.cc: 関数 'long int get_free_physical_memory()' 内: freemem.cc:111:5: エラー: 'MEMORYSTATUSEX' was not declared in this scope freemem.cc:111:20: エラー: expected ';' before 'statex' freemem.cc:112:5: エラー: 'statex' was not declared in this scope freemem.cc:113:33: エラー: 'GlobalMemoryStatusEx' was not declared in this scope freemem.cc:116:1: [-Wreturn-type] make[2]: *** [freemem.o] Error 1 make[2]: Leaving directory `/xapian/xapian-omega-1.2.9' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/xapian/xapian-omega-1.2.9' make: *** [all] Error 2 </pre> Noel Huebers 2012-03-28T01:54:00 http://comments.gmane.org/gmane.comp.search.xapian.general/9333 <pre>Hello. Xapian 1.2.9 uses UNIVERSAL-&gt;import, deprecated in perl-5.14.2 We noticed that we could not get our perl tests to pass since UNIVERSAL-&gt;import is deprecated in perl-5.14.2. The message given was: UNIVERSAL-&gt;import is deprecated and will be removed in a future perl at /usr/local/share/perl/5.14.2/Search/Xapian.pm line 3158 Johan Sydseter ABCStartsiden </pre> Johan Sydseter 2012-03-22T09:34:33 http://comments.gmane.org/gmane.comp.search.xapian.general/9326 <pre>I would like to write a MatchDecider in C++ and expose it to PHP. I'm able to compile a simple extension and use SWIG to expose a simple function to PHP, but I can't seem to hit upon the right incantation to expose my MatchDecider class. I have a header file declaring my decider, MyDecider.h #ifndef _INC_MYDECIDER_H #define _INC_MYDECIDER_H #include &lt;xapian/enquire.h&gt; #include &lt;xapian/types.h&gt; class MyDecider : public Xapian::MatchDecider { Xapian::valueno valuenum; bool inclusive; public: MyDecider  (Xapian::valueno slot, bool inclusive_) : valuenum(slot), inclusive(inclusive_) { } bool operator()(const Xapian::Document&amp; doc) const; }; #endif I have a very simple SWIG interface file, MyDecider.i %module mydecider %{ extern int demo_function(int x); #include &lt;xapian.h&gt; #include "mydecider.h" %} extern int demo_function(int x); #include &lt;xapian.h&gt; #include "mydecider.h" This successfully exports my 'demo_function' to PHP, but not the MyDecider class ($d=new MyDecider fails with a class not found error) I'm sure I'm doing something wrong in my SWIG interface file, but I'm very new to it...clues welcomed! </pre> Paul Dixon 2012-03-20T11:16:42 http://comments.gmane.org/gmane.comp.search.xapian.general/9323 <pre>Hi all, I am trying to implement an Incremental indexing scheme. The problem is that usually the modified documents are large but the modifications are limited. Ideally, I would like to reindex only the modified parts of these documents. If I am not mistaken, xapian cannot do that. Are there any other approaches? It would be nice if xapian supported something like the SQL "group by". If it did, then it would be possible to break large documents into several pieces which could be indexed independently. When querying, these pieces would be then combined again using some aggregate function similar to the SQL function sum. Thanks </pre> Marios Titas 2012-03-20T06:01:07 http://comments.gmane.org/gmane.comp.search.xapian.general/9320 <pre>I'm seeing some rather odd behavior with respect to the match percent that is returned when performing a simple query. It appears that the addition of a filter to a simple OR query will not affect the weight of the match, but will increase the percent of the resulting match. According to the documentation for MSetIterator::get_percent ( http://xapian.org/docs/apidoc/html/classXapian_1_1MSetIterator.html#99514c11a9291175d20fafa73a0839fd) a match should only get 100% if it matches all of the weight contributing terms in the query. I've attached a test case that shows the odd behavior that I am seeing. I had a database with 2 documents, each with one term 'cold' and 'kid'. Each document also has a boolean term for the owner of the document 'Ome'. Below are the results for a search for 'cold kids' on that set with and without the owner filter. The weight 0.405465108108 stays the same for both queries, but the percentage increases from 50 to 100 with the addition of the filter. Query: Xapian::Query((cold OR kids)) 1 - 0.405465108108 - 50 - Ome, cold 2 - 0.405465108108 - 50 - Ome, kids Query: Xapian::Query(((cold OR kids) FILTER Ome)) 1 - 0.405465108108 - 100 - Ome, cold 2 - 0.405465108108 - 100 - Ome, kids Is this the expected behavior here, or have I encountered a bug? </pre> Michael Henson 2012-03-16T20:04:58 http://comments.gmane.org/gmane.comp.search.xapian.general/9318 <pre>Xapian 1.3.0 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 so that 1.4.0 can both happen sooner and be better than otherwise. 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 minimising risk of accidental breakage, sticking with 1.2.x would be prudent, at least for deployment. The 1.3.x development series will lead to a stable 1.4.x release series. We don't have a date set, but I'd expect it to be later this year. If you make binary packages of this release, please make sure that they are very clearly labelled as not being a stable version, and if possible ensure that they can be installed in parallel with the stable version (the default paths and program suffix are set to help make this easier). I would probably recommend not rushing to package this right away. I've not yet put together release notes or a download page yet, but you can read the full lists of user-visible changes here: http://svn.xapian.org/*checkout*/tags/1.3.0/xapian-core/NEWS http://svn.xapian.org/*checkout*/tags/1.3.0/xapian-applications/omega/NEWS http://svn.xapian.org/*checkout*/tags/1.3.0/xapian-bindings/NEWS As always, if you encounter problems, please report them here, or to the bug-tracker: http://xapian.org/bugs The source tarballs are available from here: http://oligarchy.co.uk/xapian/1.3.0/ Here are the SHA1 checksums of the released files: bfb4639e968b012e5780c2a3d673963afa90b6fe xapian-bindings-1.3.0.tar.gz 28f414b1cd71b22868285da8fa15bd9713db1afd xapian-core-1.3.0.tar.gz 3272b6131cdcac0aca41304f083ab6d9eaf21699 xapian-omega-1.3.0.tar.gz And SHA256 checksums (more secure, but sha256sum is less widely installed): e73262d465444e035ef6e20b47e6149785845137b6ab2800af636019139c12fd xapian-bindings-1.3.0.tar.gz 6fc316491517049baf04d7b8568681fc851eda4dff8d61cc78561ddaf811c0aa xapian-core-1.3.0.tar.gz 9ccdb4689a40b4ad458136cb5aa4ef430fc61d48ee7abfdeb92623ae95f3066d xapian-omega-1.3.0.tar.gz Cheers, Olly _______________________________________________ Xapian-discuss mailing list Xapian-discuss&lt; at &gt;lists.xapian.org http://lists.xapian.org/mailman/listinfo/xapian-discuss </pre> Olly Betts 2012-03-14T06:14:07 http://comments.gmane.org/gmane.comp.search.xapian.general/9314 <pre>I apologize for what may be a sore subject. 4 billion documents is a heck of a lot. 64 bit vs 32 bit would be an incredibly large database with an average document and term size. Why 128 bit? Simply for address space. Mapping a UUID (128 bit) or MongoDB ObjectID (96 bit) directly into the Xapian document space removes the need for referencing one or the other from one or both. I see a common tendency to write a document to the Xapian, return the document ID, and then write to the database backing the document in some way. This is nothing new.. but I really would like to remove that extra write and optionally throw a way the Xapian response by specifying the document ID as the UUID associated to the document. This is starting to become much more important as people are walking away from auto-increment fields and aiming more toward universal identification which, from a sparseness standpoint, is amazingly wasteful but incredibly useful. Thanks for your consideration. I have no idea how complicated it would be to make this change to Xapian, however I'd imagine migrating the document ID into a binary like value rather than an integer value would allow for very large document ID widths. This probably means adding a 16 bit length to every document ID which is pretty wasteful. For now I'm just storing the UUID as a serialized large integer through python-xapian and then writing the xapian document ID to my database documents as they become indexed. Thanks for your consideration, Shane Spencer </pre> Shane Spencer 2012-03-09T23:39:48 http://comments.gmane.org/gmane.comp.search.xapian.general/9313 <pre>I've uploaded Xapian 1.2.9 (including Search::Xapian 1.2.9.0). As usual you can download from: http://xapian.org/download You can read an overview of the release here: http://trac.xapian.org/wiki/ReleaseOverview/1.2.9 The full lists of user-visible changes are linked to from there, and also from the "[news]" links on the download page. As always, if you encounter problems, please report them here, or to the bug-tracker: http://xapian.org/bugs Here are the SHA1 checksums of the released files: 911f3b0aede0ad323d8c0570691ffa1ec13a9502 Search-Xapian-1.2.9.0.tar.gz 3cd457058ae89ff62588c56308fdba0c311afbc0 xapian-bindings-1.2.9.tar.gz ce66725d74790639e0703db4b117b7ab5b326216 xapian-core-1.2.9.tar.gz 6340a83621822e6b2adcdebe282cce84c2ae075b xapian-omega-1.2.9.tar.gz And SHA256 checksums (more secure, but sha256sum is less widely installed): 9d608cd4afabe24323cffa1a96526fd0adcd99a5ed7c07a6845abcdb854f9485 Search-Xapian-1.2.9.0.tar.gz 49a4555313cd03afc8a969b6939d275fe651604af0825f3fcc52a2cc8a34f13b xapian-bindings-1.2.9.tar.gz c906b80f92c6ecfc931df6dabbe1a3fc78126e1e89661168c468d4f5d6f4b5dd xapian-core-1.2.9.tar.gz 317e145752fc31ca5875d169a0d979506dbe3d9a0ae5f8a2e44d990929771aff xapian-omega-1.2.9.tar.gz Cheers, Olly _______________________________________________ Xapian-discuss mailing list Xapian-discuss&lt; at &gt;lists.xapian.org http://lists.xapian.org/mailman/listinfo/xapian-discuss </pre> Olly Betts 2012-03-09T12:50:29 http://comments.gmane.org/gmane.comp.search.xapian.general/9306 <pre>Ciao, sorry for the silly question, but how do you enable debugging in xapian? I'm using xapian-tpcsrc and would like it to print debugging info (connections, queries, etc). I'm configuring xapian 1.2.8 on OSX with "./configure --enable-debug-verbose", then $ export XAPIAN_DEBUG_FLAGS=-1 $ export XAPIAN_DEBUG_LOG=test.log $ sudo xapian-tcpsrv /path/to/db --port 972 Starting server on port 972 Listening... Connection from 127.0.0.1, port 48102 Connection from 127.0.0.1, port 48358 Got exception NetworkError: Received EOF (context: /path/to/db) Closing connection. Connection from 127.0.0.1, port 48614 Got exception NetworkError: Received EOF (context: /path/to/db) Closing connection. The client can connect and make queries but I can't find the expected test.log. I read NEWS and HACKING but they seem to have conflicting information Thanks, Matteo PS: what are those NetworkError exceptions? </pre> Matteo Zandi 2012-03-05T23:11:25 http://comments.gmane.org/gmane.comp.search.xapian.general/9299 <pre>The recent thread about http://restpose.org/ (which looks like a cool project) reminded me that I had not yet announced the existence of Dezi[0] to this group. Dezi is a search server similar to RestPost and Apache Solr that supports OpenSearch[1] XML and JSON response types. You can index any format of document supported by SWISH::Filter[3] via a REST API. Clients are available already in Perl and PHP. The Xapian backend[2] is available via Search::OpenSearch::Engine::Xapian, which relies on the Search::Xapian Perl bindings. Contributors, users, critics all welcome. cheers, pek [0] http://dezi.org/ [1] http://www.opensearch.org/ [2] http://dezi.org/node/4 [3] https://metacpan.org/module/SWISH::Filter </pre> Peter Karman 2012-02-24T03:41:31 http://comments.gmane.org/gmane.comp.search.xapian.general/9288 <pre>Hi, I have previously had a problem with getting this error on a get_mset call, and solved it by subclassing XapianEnquire with a backoff-and-retry algorithm (as suggested by this list, many thanks!). However, I now get it intermittently when calling get_data on a XapianDocument. The same solution doesn't seem to be quite as easy in this case, because: 1. The document is not instantiated by my code, it's returned from the Iterator, so I can't easily subclass it without editing the bindings. 2. The document doesn't have a reference to the database, so I can't reopen it from that scope. So, first is it necessary to reopen the database in these situations, or could I simply call get_data on the same document object after a brief delay? And second, how/where would you suggest I insert the retry procedure? Currently I can only see a few options, none of which seem very good, and the first two don't solve the reopen problem): A) Subclass XapianDocument, and in order to make the bindings use the subclass, also subclass the iterator, matchset and enquire. B) Hack the bindings to insert the retry into the existing XapianDocument::get_data method. C) Add retry at the application level (need to add to several dozen projects!) Any ideas much appreciated. Cheers, Andrew ********************************************************************************** This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL. Registered in England and Wales with company number 53723 </pre> Andrew Betts 2012-02-17T12:54:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.search.xapian.general