similar to: flintlock / tcl bindings

Comment by Eric Lindblad 23-02-2016 http://www.nurmi-labs.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9948 I would suspect the fork here, if there are any threads involved. What Tcl really needs is some pthread_atfork() triggers, but they aren?t exposed in any meaningful way, so you can lose things over a fork split.

On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: > On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: > > I discovered, while trying to set up Tcl bindings for Notmuch > > (https://notmuchmail.org/), which uses Xapian, that flintlock was not > > being locked (I had lost updates). > > It seems to work for me, testing with this: >

I recently wrote a post on installing "Git for Windows" on a legacy XP SP3 Home box. http://nurmi-labs.blogspot.com/2016/11/git.html I added some missing files from the MSYS2 packages which were removed for the downloadable "Git for Windows" installer and a compiler and some additional libraries. For other utilities (bison, flex, info, m4, make, and csh/tcsh), and code I

Dear Olly Betts, same 32 bit compiler version hardware OS OS version as here (where remotetcp_chert passed and skipped 3) xapian-core-1.2.21.tar.xz http://nurmi-labs.blogspot.com/2015/10/xapian.html ./apitest backend remoteprog_brass: All 225 tests passed, 3 skipped. ./apitest backend remotetcp_brass: All 225 tests passed, 3 skipped. ./apitest backend remoteprog_chert: All 225 tests passed,

On Wed, 24 Feb 2016 03:17:35 +0000, Olly Betts <olly at survex.com> wrote: >On Mon, Feb 22, 2016 at 12:26:27PM +0100, Eric wrote: >> On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: >>> On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: >>>> I discovered, while trying to set up Tcl bindings for Notmuch >>>>

On Mon, Feb 22, 2016 at 12:26:27PM +0100, Eric wrote: > On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: > > On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: > > > I discovered, while trying to set up Tcl bindings for Notmuch > > > (https://notmuchmail.org/), which uses Xapian, that flintlock was not > > > being locked (I

I discovered, while trying to set up Tcl bindings for Notmuch (https://notmuchmail.org/), which uses Xapian, that flintlock was not being locked (I had lost updates). I then found that opening a Xapian database for writing directly via the Xapian Tcl bindings also silently fails to lock flintlock. I have taken a copy of flint_lock.cc to play with, and I find that it locks the file when called

On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: > I discovered, while trying to set up Tcl bindings for Notmuch > (https://notmuchmail.org/), which uses Xapian, that flintlock was not > being locked (I had lost updates). It seems to work for me, testing with this: package require Tcl 8 package require xapian 1.0.0 xapian::WritableDatabase db "tmp.db"

gnu_getopt.h by Eric Lindblad 07-09-2015 http://www.ericlindblad.blogspot.com Subsequent to the compile of libxapian.so.22.6.8 and libxapian.a there are executable source files using gnu_getopt.h which has an #ifdef __CYGWIN__, perhaps that file would need attention in order for compile to proceed on my modified SFU Interix 3.5 setup The 1 'ambiguous overload' report on SFU Interix I

Report by Eric Lindblad 10-09-2015 http://www.ericlindblad.blogspot.com cf: http://comments.gmane.org/gmane.comp.search.xapian.general/9862 interix Yesterday I compiled cppunit-1.12.1 on the Interix g++ (3.3) compiler. xapian Subsequent to disabling the remote backend which caused gmake to skip over the /net/tcpclient.cc:77 error, resulting in xapian libs' compile, today I disabled the

Test 1 by Eric Lindblad 07-09-2015 http://www.ericlindblad.blogspot.com The 'ambiguous overload' error cited 28-08-2015 was unaffected from adding the below #ifdef following incidents of the string #include <sys/types> in all relevant xapian-core-1.2.21 files. http://sourceforge.net/projects/libuuid/ libuuid-1.0.3.tar.gz the following lines can be added to uuidP.h from the

System: Microsoft Windows XP Home Edition CPUs: Intel(R) Atom(TM) CPU N270 @1.60GHz setup for the 'Git for Windows' with MSYS2 gcc-6.1.0 plus utilties and libraries were added http://nurmi-labs.blogspot.com/2016/11/git.html obviously, with Home Edition, no network was setup http://nurmi-labs.blogspot.com/p/xapian-ms.html System: Slackware Linux (version 14.0) CPUs: Intel(R) Atom(TM)

Question by Eric Lindblad 05-09-2015 http://www.ericlindblad.blogspot.com I would enquire if anyone has an opinion on whether it might be a possibility that adding the following #ifdef in certain xapian-core-1.2.21 /common and/or /backends files following the string #include <sys/types.h> might move closer towards resolution the 'ambiguous overload' issue. +#ifdef __INTERIX +#

Dear Olly Betts, I think the tests for the perl module Search-Xapian-1.2.21.0 might be fewer in number than the perl tests included with xapian-bindings-1.2.21. If some of the tests have similar but modified content I do not know. I am not so skilled as to interpret the compared test results. If you want to suggest a paired earlier version of Xapian to a specific xapian.bindings version, I might

On Sat, 27 Feb 2016 19:39:11 +0100 (CET), Eric J <eric at deptj.eu> wrote: > On Thu, 25 Feb 2016 23:37:52 +0000, Olly Betts <olly at survex.com> wrote: 8>< -------- >> I'm testing with Tcl 8.6 (Debian package 8.6.4+dfsg-3), and it works for >> me. >> >> So it does seem it must be due to something your Tcl interpreter is >> doing, but I'm

If the subject of xapian-core apitests on MSYS/MINGW and MSYS2/MINGW is taken up it might be noted that the compiler version could be recorded, probably gcc 5.3.0 or newer, that closed pipes might be an issue, and also allocating for the location of xapian-tcpsrv. Not from my own tests but another man informed there was some problems with [MSYS2] python bindings. I am not knowledgeable of the

On Thu, Feb 25, 2016 at 05:21:17PM +0100, Eric J wrote: > On Thu, 25 Feb 2016 02:24:51 +0000, Olly Betts <olly at survex.com> wrote: > > It's clearly not as simple as execl() always releasing the lock, but I > > don't think we've ruled out the OS entirely yet - the above isn't > > exactly equivalent to the Tcl code, as the two databases are created by

On Wed, Feb 24, 2016 at 04:30:55PM +0100, Eric J wrote: > On Wed, 24 Feb 2016 03:17:35 +0000, Olly Betts <olly at survex.com> wrote: > >On Mon, Feb 22, 2016 at 12:26:27PM +0100, Eric wrote: > >> % package require xapian 1.0.0 > >> 1.2.18 > > > > I've tested with 1.2.18 and can't reproduce this with that version > > either (is that also

Comment by Eric Lindblad 21-02-2016 http://www.nurmi-labs.blogspot.com The xapian-core version number was upgraded to 1.2.22 on 30-Dec-2015 at 23:24. http://packages.slackware.com/ Slackware current 2016-02-14 20:50:07 Slackware64 current 2016-02-14 20:59:28

On Thu, Dec 08, 2016 at 10:08:40PM +0000, Eric Lindblad wrote: > Dear Olly Betts, > > same 32 bit > > compiler version > hardware > OS > OS version > > as here (where remotetcp_chert passed and skipped 3) > > xapian-core-1.2.21.tar.xz > > http://nurmi-labs.blogspot.com/2015/10/xapian.html That's over a year old - are you really running the exact