search for: fastmailteam

Hi! On behalf of team Cyrus, I'm trying to review and clean up old instances of Cyrus documentation around the web. It's a long lived OSS project and has left behind many old docs in its years on the earth. This is resulting in strange queries coming to us as people try to follow information that's years out of date. To this end I'd like to request removal of

On Sun, Oct 15, 2017 at 9:18 PM, Nicola Nye <nicola at fastmailteam.com> wrote: > Hi! > > On behalf of team Cyrus, I'm trying to review and clean up old instances > of Cyrus documentation around the web. It's a long lived OSS project and > has left behind many old docs in its years on the earth. This is resulting > in strange queries c...

On Tue, Feb 13, 2018, at 02:32, Peter Zhao wrote: > At 2018-02-12 20:00:02, xapian-discuss-request at lists.xapian.org wrote: > >There's also a patch to add support for using libicu to find word > >boundaries: > > > >https://github.com/xapian/xapian/pull/114 > > > >That'll get merged soon hopefully (mostly we need to sort out how to > >manage

We are a using a fork of Xapian for this at the Cyrus IMAP project [1], using the Unicode library word segmentation for Chinese, Japanese and Korean [2]. We are using it at FastMail in production since about 2 years and are generally happy with it, the search results improved over using ngrams. There's a pull request open to merge the patch upstream [3], but it's to be decided how to best

I'm preparing a pull request for the master branch and noticed that `make check` on a clone of the xapian repository fails badly. I haven't merged my changes and built from e24cc6018de0. Is is just me or is there something broken in the master branch? Running test './apitest' under valgrind Running tests with backend "none"... Running test: defaultctor1...

Olly, thanks for your feedback. On Mon, Jul 31, 2017, at 23:29, Olly Betts wrote: > On Mon, Jul 31, 2017 at 09:24:29AM +0200, Robert Stepanek wrote: > > We'd appreciate any hints on how to fix this. I've written up our > > findings and solution attempts below. Should we post this on trac? > > Yes, it'd be good to have a ticket to track this. I've created

On Sun, Jan 7, 2024, at 7:45 PM, Olly Betts wrote: > I've restarted trac. I now created a pull request: https://github.com/xapian/xapian/pull/329 Should I create a trac issue, too? > Assuming the latter is valid, just removing this block (or removing the > parts of it which are Lu or Ll) should fix the problem as then > tokenisation will switch mode - I tried this and it fixes

On Tue, Jan 9, 2024, at 3:28 AM, Olly Betts wrote: > Thanks, that looks good - now merged. Thanks! > Did you already check the other ranges for cased letters? I can but if > you have already there's not much point. I did not. If you find time, that'd be great. Otherwise I can make room for it in the next days. > > The fullwidth "????? ??????" tests suggests to

I think I found a bug in Xapian 1.5 when using FLAG_WORD_BREAKS for input that contains characters in Unicode Halfwidth and Fullwidth Forms (https://unicode.org/charts/PDF/UFF00.pdf). Since I am undecided yet if and how to fix this in Xapian I haven't come up with a pull request. Because trac currently is offline, I could not file a bug. I hope it's OK to post my analysis here first,

Since a couple of weeks we are experiencing occasional segmentation faults within Xapian 1.5. We can't reproduce the crashes, but we have strong hints that they are due to memory corruption. We have narrowed down our root cause analysis to phrase searches on multi-databases that fail on reading the `hint` field in the`QueryOptimiser`class [1]. We'd appreciate any hints on how to fix this.