similar to: More weirdness with PHP bindings

I'm having trouble translating from C++ to perl objects. The TermIterator class looks like to get a set of terms in a document you might have C++ code like: Enquire::TermIterator termIt =enquire->get_matching_terms_begin(id); for(;termIt != enquire->get_matching_terms_end(id);termIt++) { string term = *termIt; } Or something similar. However when I attempt to translate that

At least it isn't working the way it used to. Code: $db = Search::Xapian::Database->new( $dx ); my $qp = Search::Xapian::QueryParser->new(); my $dbSize=$db->get_doccount(); # $qp->set_stemmer(new Search::Xapian::Stem("english")); # $qp->set_stemming_strategy(STEM_SOME); # $qp->set_default_op($defaultop); my $par =

On 08/25/2013 05:02 PM, Olly Betts wrote: > So the simple fix is > probably just to install the perl-Search-Xapian RPM instead. Thanks, the Centos 6 repos don't have that rpm and the http://xapian.org/download page seems to only cover the XS bindings, if I am reading this correctly: But I was able to remove the rpm packages and compile and install the core and swig from source.

Hi All, I've installed Xapian and the php module. I've set up a script for use with scriptindex and dbi2omega for getting data from the db into the index easily, the script file is as follows: =============================== id : field=id title : index title: field=title description : index description : truncate=50 field=content ============================= However, when querying

In the Ruby bindings, set_X and get_X are renamed to remove the get/set, so MSet::get_matches_estimated() becomes a read-only property (if I have my terminology right) of the Ruby MSet class called matches_estimated. This matches how a Ruby programmer would expect a class to be designed. I was looking through the getters and setters list. I wonder if a few entries shouldn't be there, (the

Dear Xapian developers, I am happy to announce that the Xapian-Ruby bindings now pass all tests defined in smoketest.rb. (These tests are mostly drawn from smoketest.py; a few tests that are not applicable to the Ruby version have been removed.) I have also added Olly's patch to integrate the Ruby bindings into the automake/configure scripts. The latest version is available by anonymous

Oh, by the way, just running `make all` works fine too, which is what I am now doing in the gem.. but fixing the makefile would retain the existing working behaviour of `make clean all` which was fine in 1.2.x On 16 January 2017 at 14:21, Samuel Williams <space.ship.traveller at gmail.com> wrote: > I'm posting this here to help others who might be having the same issue. > > I

Hi all, I'm getting an error in the smoketest. I'm using latest Swig and Python bindings from SVN-HEAD: File "smoketest.py", line 23, in <module> import xapian File "C:\work\xapian\xapian-SVN\xapian-core\win32\Release\Python\xapian.py", line 2099, in <module> ValueRangeProcessor.__call__ = ValueRangeProcessor.__call AttributeError: type

I'm posting this here to help others who might be having the same issue. I maintain xapian-core ruby gem. I was trying to upgrade to 1.4.2 and had some issues. The generated makefile doesn’t work because of the following: docs/rdocs/index.html: docs/xapian.rb rm -rf docs/rdocs $(MKDIR_P) docs cd docs && $(RDOC) --op rdocs `test -f xapian.rb||echo '$(abs_srcdir)/'`xapian.rb

On Wed, Apr 11, 2007 at 10:31:39AM +0100, richard wrote: > python/smoketest.py: Replace cut-and-pasted test checking code > with functions, to simplify tests. It might be simpler, but mostly because functionality has gone - you've thrown away all my carefully written failure messages! Now if a test fails, the message is very generic and you have to read the code to find out what's

Hello, I am attempting to run the smoketest.php file from my devserver and am getting nothing but errors. It looks like it did not install correctly. Yesterday I compiled the source on os x and it appeared to install just fine, but now it is not working at all. I tried to replace the location of the xapian.php file with a hardcoded located and got a different set of errors. Here are

On 08/24/2016 07:53 PM, Peter wrote: > On 25/08/16 13:21, Kay Schenk wrote: >> To all...yes I meant glibc, not glib. Target environment -- could be any >> version of Linux. This is for Apache OpenOffice. The buildbots we've been >> using are being decommisioned due to EOL. As a developer on that project, I >> need to be able to test and use the builds. We'll be

Hey Guys, Just making some enquieres for a project i'm goign to be starting using xapian. When searching over a indexed document will i be able to get a list of hits, how many hits and the location fo the hits. I will have boolean searches like eg ("Mysql" AND ("Linux" OR "Windows")) On each hit i will be wanting teh location of the word found and how many

I thought that I installed all the bindings but seems to me that I am missing xapian.so when I try to run smoketest.php Warning: dl(): Unable to load dynamic library '/usr/lib/php/extensions/xapian.so' - /usr/lib/php/extensions/xapian.so: cannot open shared object file: No such file or directory Can somebody send me the link to the module that I need to install? Thanks, Kevin

On 08/25/2016 10:44 AM, Gordon Messmer wrote: > On 08/25/2016 09:49 AM, Kay Schenk wrote: >> I do realize the sane thing to do is to have the builbots -- >> smoketest environments -- match the production environment > > > I think the sane thing to do would be to use buildbots that support LSB: > > http://www.ludism.org/~rwhe/LSB/tutorial/tut.html Great resource!

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

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

Yesterday I updated the deprecation.rst document such that I think it contains all the items which are slated for deprecation (and also contains full details of the upgrade suggestions, as Olly suggested). I've marked several things which have been deprecated for a long period of time (ie, since 0.9.0 or earlier) for removal in 1.0.0, in line with the policy outlined in the document. If

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

I've now uploaded Xapian 1.0.1, which you can download from the usual place: http://www.xapian.org/download.php This release mainly comprises bug fixes and performance improvements. The "simple" examples (for both C++ and the bindings) have also been overhauled and now use the QueryParser and TermGenerator classes, which makes for simpler examples and should better reflect