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

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

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,

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

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"

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

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

On Thu, 25 Feb 2016 02:24:51 +0000, Olly Betts <olly at survex.com> wrote: > 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 >>> >>>

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

Xapian Developers, [I initially thought to install xapian on SFU (Interix 3.5) on MS XP but could not compile libuuid] [getopt.h, inttypes.h, and stdint.h taken from SUA (for Vista) and installed in SFU (Interix 3.5)] If someone is inclined to write a modified libuuid and label it for use with Interix <version(s)> to satisfy the dependency for an xapian <version(s)> install on

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

On Thu, 25 Feb 2016 23:37:52 +0000, Olly Betts <olly at survex.com> wrote: > 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

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

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

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

Eric J <eric <at> deptj.eu> writes: > >> eric <at> bruno [ ~ ]$ tclsh > >> % info patchlevel > >> 8.6.1 > >> % package require Tcl 8 > >> 8.6.1 > >> % package require xapian 1.0.0 > >> 1.2.18 Does the problem occur with both Tcl 8.6.1 and the 8.5 series?

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