Displaying 6 results from an estimated 6 matches for "yanniko".
Did you mean:
yannikos
2010 Oct 24
1
Cannot index with dynamic spelling data (Perl/Search::Xapian)
This is my test case, what am I doing wrong? It seems that the API is used
incorrectly, but I cannot find the problem...
--- 8< ---
#!/usr/bin/perl
use Search::Xapian qw(:all);
use strict;
my $xa = new Search::Xapian::WritableDatabase ("/tmp/xapian",
DB_CREATE_OR_OVERWRITE);
my $indexer = Search::Xapian::TermGenerator->new();
2011 Aug 29
1
Incremental updates and disk space ...
Hi,
we've been using Xapian in production for several months now and update
our (chert) databases continuously. A freshly generated index occupies
only around ~35% of the disk space compared to what it becomes after a
few days. This is not a huge concern (we use SSDs), but I've been
wondering whether there is a way to fine-tune this (other than
recreating the index frequently), so
2013 Feb 14
1
Go (golang) bindings for Xapian?
Hi,
is anyone working on Xapian bindings for Go? SWIG supports Go since
version 2.0 (http://www.swig.org/Doc2.0/Go.html), but there's some
Go-specific code that needs to be written.
Unfortunately, I have 0 experience both with SWIG and hacking on the
Xapian bindings, so I probably cannot do this as a weekend project. It
would come in very handy though.
Regards,
Marinos
2010 Aug 30
1
getdents() with 4KB buffer - seems slow (Maildir, large inbox)
Hi,
I have a very large inbox (~146K mails) in Maildir format and dovecot
seems to spend a lot of time rescanning the directory, especially when
the server is loaded. I'm not sure whether this is triggered by
Thunderbird or done regularly, but it takes longer when the server is
loaded, so sometimes it seems that it is scanning continuously. Since
it takes around 2000 getdents64() syscalls to
2010 Nov 01
1
floating-point issues with set_sort_by_relevance_then_value? (1.2.3, BM25 k1=0)
I am using BM25 with k1=0 and min_normlen=1 to get weights unaffected by
document length and term frequency in the document (min_normlen=1 isn't
necessary I guess) and am expecting single-term weights to be identical for all
matches. I have added a document value to steer such general search queries and
it works fine, except that for some search terms, I get results like:
2010 Oct 28
1
hypens in words + NEAR + 3 terms + AND_MAYBE => crash
Probably an uncaught malformed query - the following form of search queries
causes a crash for me (core 1.2.3, Perl API, 64bit Debian Lenny, self-compiled):
x-y NEAR test NEAR test
The first term can be anything with a hyphen in it but word characters at the
beginning and end ("3--3" will do). The other 2 terms can be anything.
"test NEAR x-y NEAR test" will not cause a