search for: utf8iterator

...d to the terms, but what's the purpose of this? (2) add_posting method will add term to a documents. void add_posting (const std::string &tname, Xapian::termpos tpos, Xapian::termcount wdfinc=1) I noticed that Xapian::TermGenerator has follow method void index_text (const Xapian::Utf8Iterator &itor, Xapian::termcount weight=1, const std::string &prefix="") What's the differences and relationship between these two functions? Thanks a lot! Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/...

I'm new to Xapian and we just recently upgraded to version 1.0.0.0. However, something seems to have changed during the upgrade and I need help figuring out how my code should be written. In version 0.9.9.1 of Search::Xapian, the following code results in this output "Xapian::Query(pet:(pos=1))". my $qp = new Search::Xapian::QueryParser; $qp->set_stemmer(new

...arser/queryparser_internal.h @@ -74,6 +74,8 @@ class QueryParser::Internal : public Xapian::Internal::RefCntBase { string corrected_query; + long max_wildcard_expansion; + void add_prefix(const string &field, const string &prefix, bool filter); std::string parse_term(Utf8Iterator &it, const Utf8Iterator &end, @@ -81,7 +83,7 @@ class QueryParser::Internal : public Xapian::Internal::RefCntBase { public: Internal() : stem_action(STEM_NONE), stopper(NULL), - default_op(Query::OP_OR), errmsg(NULL) { } + default_op(Query::OP_OR), errmsg(NULL) { max_wildcard_expa...

...ing message: > > configure: WARNING: Xapian library is version 1.4.18 but the bindings > are version 1.4.22 - we strongly recommend using matching versions. The issue here is mostly that xapian-bindings wraps almost the entire C++ API (the main exception if the Unicode stuff like Xapian::Utf8Iterator as other languages generally have their own Unicode support which is a better option) so it's more tightly coupled to the xapian-core API than an application typically is. In your case, xapian-core 1.4.19 added a new `Xapian::QueryParser::FLAG_NO_POSITIONS` flag and xapian-bindings 1.4.19 and...

Dear xapian discussion, I was just installing xapian-bindings-1.4.22 on Ubuntu 22.04, but I got the following warning message: configure: WARNING: Xapian library is version 1.4.18 but the bindings are version 1.4.22 - we strongly recommend using matching versions. I tried to check my xapian core-1.4.22 for the library, but could not find that library. How do I fix this? I will appreciate your

...re: WARNING: Xapian library is version 1.4.18 but the bindings > > are version 1.4.22 - we strongly recommend using matching versions. > > > The issue here is mostly that xapian-bindings wraps almost the entire > C++ API (the main exception if the Unicode stuff like > Xapian::Utf8Iterator as other languages generally have their own > Unicode support which is a better option) so it's more tightly coupled > to the xapian-core API than an application typically is. > > In your case, xapian-core 1.4.19 added a new > `Xapian::QueryParser::FLAG_NO_POSITIONS` flag and xa...

...n't be a gap between search and indexing. Yet, I understand your concerns about having two Unicode implementations. Despite our specific experience, migrating Xapian's Unicode handling to ICU might be a good choice and I could support. Surely, its modules are far away from what Xapian's UTF8Iterator currently provides. Cheers, Robert

Hi All I was wondering if anyone had a solution for the following problem. I user QueryParser to stem my documents before adding them to a database. During the stemming process I would like to find a way of keeping proper nouns that span two or more words together as a phrase. For example "New York" or "Gordon Brown" or "Prime Minister" get spilt up. I see

On Fri, Aug 21, 2009 at 02:44:44PM +0200, emmanuel at engelhart.org wrote: >> I want to update my request. >> Is my question bad formulated? too trivial? ... or maybe pretty >> complicated/unclear? > >I think nobody answered as it was hard to follow your example because >the Burmese characters seem to have been mangled (at least the message I >received wasn't

On Tue, Sep 6, 2016, at 09:16, Olly Betts wrote: > I think my main concerns are about efficiency (since that a major > motivation for the current implementation, so slowing it down would be > annoying), and whether we can just make this the standard behaviour > rather than adding an option. The current implementation is O(n) and I took care to keep it at that. For the proposed term