Re: [PATCH] bindings/python: add bindings for notmuch_database_get_revision

2017-03-09 Thread David Bremner
Gaute Hope  writes:

> Database.get_revision () returns a tuple with the current database
> revision and the UUID string representing the database.

It would be great if you could add a test for the new API to
T390-python.sh. Probably just translating the C example from
T570-revision-tracking.sh into python would work.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [RFC PATCH] doc: add support for adding configure options as Sphinx tags

2017-03-09 Thread David Bremner
Jani Nikula  writes:

> Add the configure options specified in $(TAGS) that equal 1 as tags on
> the Sphinx command line using the -t option. The tags may be used to
> conditionally include documentation using the Sphinx "only" directive
> [1].
>
> As an example, indicate in the documentation whether the Xapian field
> processor is likely to be available (assuming the notmuch binary was
> built in the same environment as the documentation).
>
> [1] 
> http://www.sphinx-doc.org/en/stable/markup/misc.html#including-content-based-on-tags
>

It does seem like it could potentially help people find what optional
features are available.

A couple of observations

1) Many people read documentation on-line, even in cases where some of
   us might not think it makes sense.

2) We might eventually (per an outstanding request) provide a seperate
tarball of prebuilt docs.

Both of those suggest a need to build a "generic" version of the docs.

d

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [RFC PATCH 6] support make goals after initial {'', dist, data}clean goal(s)

2017-03-09 Thread David Bremner
Tomi Ollila  writes:

> Now make goal combinations starting with *clean goals,
> ending with *clean coals, and having non-*clean goals in between
> should work. What does not expected to work are
> non-*clean - *clean - *non-clean goal combinations.
>
> Also, if first goals are *clean goals, re-creation of Makefile.config
> is inhibited when Makefile.config exists and ./configure is newer.
> ---
>
> Now there is more probability I don't figure out anything that
> could be improved (but, if things go as usual, i know that
> tomorrow morning ;)

Hi Tomi;

No more improvements for this? Maybe we should call it non-RFC now?

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] bindings/python: test python Database.get_revision ()

2017-03-09 Thread Gaute Hope
Here is a test for Database.get_revision (), based on
the first part of T570-revision-tracking.sh.

---
 test/T390-python.sh | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/test/T390-python.sh b/test/T390-python.sh
index 4726bc36..b27f0740 100755
--- a/test/T390-python.sh
+++ b/test/T390-python.sh
@@ -38,4 +38,23 @@ print (db.find_message_by_filename("i-dont-exist"))
 EOF
 test_expect_equal "$(cat OUTPUT)" "None"
 
+test_begin_subtest "get revision"
+test_python ${MAIL_DIR} <<'EOF'
+import notmuch
+db = notmuch.Database(mode=notmuch.Database.MODE.READ_ONLY)
+(revision, uuid) = db.get_revision()
+print ("%s\t%lu" % (uuid, revision))
+EOF
+notmuch_uuid_sanitize < OUTPUT > CLEAN
+cat <<'EOF' >EXPECTED
+UUID   53
+EOF
+test_expect_equal_file EXPECTED CLEAN
+
+grep '^[0-9a-f]' OUTPUT > INITIAL_OUTPUT
+
+test_begin_subtest "output of count matches test code"
+notmuch count --lastmod '*' | cut -f2-3 > OUTPUT
+test_expect_equal_file INITIAL_OUTPUT OUTPUT
+
 test_done
-- 
2.11.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: add support for stashing formatted timestamp

2017-03-09 Thread David Bremner
Jani Nikula  writes:

> notmuch-show-stash-date stashes the Date: header of the message
> verbatim. While that is useful, sometimes more control of the output
> is desirable.
>
> Add support for stashing the message timestamp (as parsed by gmime at
> the lib level from the Date: header) according to a user customizable
> format. The user can use this to stash the message date in the
> preferred format, or perhaps as a date: range query, for example
> "date:@%s.." to find all messages since the current message.
> ---

I'm not opposed to this, but I'd like at least one vote from someone
other than Jani that would find it useful.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[David Bremner] Re: [PATCH] cli/new: Avoid printing "\033[K" to non-terminal output

2017-03-09 Thread David Bremner
--- Begin Message ---
Łukasz Stelmach  writes:

> ---
>  notmuch-new.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/notmuch-new.c b/notmuch-new.c
> index 1321263..44174ad 100644
> --- a/notmuch-new.c
> +++ b/notmuch-new.c
> @@ -905,10 +905,9 @@ print_results (const add_files_state_t *state)
>   state->processed_files == 1 ? "file" : "total files");
>   notmuch_time_print_formatted_seconds (elapsed);
>   if (elapsed > 1)
> - printf (" (%d files/sec.).\033[K\n",
> + printf (" (%d files/sec.)",
>   (int) (state->processed_files / elapsed));
> - else
> - printf (".\033[K\n");
> + printf(".%s\n", (state->output_is_a_tty) ? "\033[K" : "");
>  }

Other than missing a space after printf (which I can hopefully remember
to add when I commit it, this looks fine).

d
--- End Message ---
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] tests: add compatibility layer

2017-03-09 Thread David Bremner
From: Mikhail 

Make test-lib-common.sh load test-lib-<$PLATFORM>.sh to create
additional shim for platform specifics.

Use test-lib-FREEBSD.sh to call GNU utilities instead of native ones.

- amended by db following Tomi's suggestions
---

I haven't tested this, except to verify it doesn't crash under GNU/Linux

 configure|  3 +++
 test/README  | 11 +++
 test/test-lib-FREEBSD.sh |  9 +
 test/test-lib-common.sh  |  5 +
 4 files changed, 28 insertions(+)
 create mode 100644 test/test-lib-FREEBSD.sh

diff --git a/configure b/configure
index fa77eb8f..eb452a12 100755
--- a/configure
+++ b/configure
@@ -1186,6 +1186,9 @@ NOTMUCH_PYTHON=${python}
 # Are the ruby development files (and ruby) available? If not skip
 # building/testing ruby bindings.
 NOTMUCH_HAVE_RUBY_DEV=${have_ruby_dev}
+
+# Platform we are run on
+PLATFORM=${platform}
 EOF
 
 # Finally, after everything configured, inform the user how to continue.
diff --git a/test/README b/test/README
index 104a120e..ae22d6e0 100644
--- a/test/README
+++ b/test/README
@@ -33,6 +33,17 @@ chosen directory to your PATH before running the tests.
 
 e.g. env PATH=/opt/gnu/bin:$PATH make test
 
+For FreeBSD you need to install latest gdb from ports or packages and
+provide path to it in TEST_GDB environment variable before executing
+the tests, native FreeBSD gdb does not not work.  If you install
+coreutils, which provides GNU versions of basic utils like 'date' and
+'base64' on FreeBSD, the test suite will use these instead of the
+native ones. This provides robustness against portability issues with
+these system tools. Most often the tests are written, reviewed and
+tested on Linux system so such portability issues arise from time to
+time.
+
+
 Running Tests
 -
 The easiest way to run tests is to say "make test", (or simply run the
diff --git a/test/test-lib-FREEBSD.sh b/test/test-lib-FREEBSD.sh
new file mode 100644
index ..d1840b56
--- /dev/null
+++ b/test/test-lib-FREEBSD.sh
@@ -0,0 +1,9 @@
+# If present, use GNU Coreutils instead of a native BSD utils
+if command -v gdate >/dev/null
+   then
+   date () { gdate "$@"; }
+   base64 () { gbase64 "$@"; }
+   wc () { gwc "$@"; }
+   sed () { gsed "$@"; }
+   sha256sum () { gsha256sum "$@"; }
+   fi
diff --git a/test/test-lib-common.sh b/test/test-lib-common.sh
index a96cfbeb..ef409171 100644
--- a/test/test-lib-common.sh
+++ b/test/test-lib-common.sh
@@ -66,6 +66,11 @@ export LD_LIBRARY_PATH
 # configure output
 . $notmuch_path/sh.config || exit 1
 
+# load OS specifics
+if [ -e ./test-lib-$PLATFORM.sh ]; then
+   . ./test-lib-$PLATFORM.sh || exit 1
+fi
+
 if test -n "$valgrind"
 then
make_symlink () {
-- 
2.11.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [David Bremner] Re: [PATCH] cli/new: Avoid printing "\033[K" to non-terminal output

2017-03-09 Thread Tomi Ollila
On Thu, Mar 09 2017, David Bremner  wrote:

> From: David Bremner 
> Subject: Re: [PATCH] cli/new: Avoid printing "\033[K" to non-terminal output
> To: Łukasz Stelmach 
> Date: Thu, 09 Mar 2017 08:35:11 -0400
>
> Łukasz Stelmach  writes:
>
>> ---
>>  notmuch-new.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/notmuch-new.c b/notmuch-new.c
>> index 1321263..44174ad 100644
>> --- a/notmuch-new.c
>> +++ b/notmuch-new.c
>> @@ -905,10 +905,9 @@ print_results (const add_files_state_t *state)
>>  state->processed_files == 1 ? "file" : "total files");
>>  notmuch_time_print_formatted_seconds (elapsed);
>>  if (elapsed > 1)
>> -printf (" (%d files/sec.).\033[K\n",
>> +printf (" (%d files/sec.)",
>>  (int) (state->processed_files / elapsed));
>> -else
>> -printf (".\033[K\n");
>> +printf(".%s\n", (state->output_is_a_tty) ? "\033[K" : "");
>>  }
>
> Other than missing a space after printf (which I can hopefully remember
> to add when I commit it, this looks fine).

I looked this briefly a while ago -- there were quite a few \033[K:s
that were not taken care of... would those have needed to be...

For those who don't know, CSI K clears up to the end of line.

>
> d

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] tests: add compatibility layer

2017-03-09 Thread Tomi Ollila
On Thu, Mar 09 2017, David Bremner  wrote:

> From: Mikhail 
>
> Make test-lib-common.sh load test-lib-<$PLATFORM>.sh to create
> additional shim for platform specifics.
>
> Use test-lib-FREEBSD.sh to call GNU utilities instead of native ones.
>
> - amended by db following Tomi's suggestions
> ---
>
> I haven't tested this, except to verify it doesn't crash under GNU/Linux

I cannot test as I will not pollute my purish Frisbee KVM image with
coreutils package -- I could play with second image but I', too lazy
to do so.

Anyway, it looks ok to me.

Tomi


>
>  configure|  3 +++
>  test/README  | 11 +++
>  test/test-lib-FREEBSD.sh |  9 +
>  test/test-lib-common.sh  |  5 +
>  4 files changed, 28 insertions(+)
>  create mode 100644 test/test-lib-FREEBSD.sh
>
> diff --git a/configure b/configure
> index fa77eb8f..eb452a12 100755
> --- a/configure
> +++ b/configure
> @@ -1186,6 +1186,9 @@ NOTMUCH_PYTHON=${python}
>  # Are the ruby development files (and ruby) available? If not skip
>  # building/testing ruby bindings.
>  NOTMUCH_HAVE_RUBY_DEV=${have_ruby_dev}
> +
> +# Platform we are run on
> +PLATFORM=${platform}
>  EOF
>  
>  # Finally, after everything configured, inform the user how to continue.
> diff --git a/test/README b/test/README
> index 104a120e..ae22d6e0 100644
> --- a/test/README
> +++ b/test/README
> @@ -33,6 +33,17 @@ chosen directory to your PATH before running the tests.
>  
>  e.g. env PATH=/opt/gnu/bin:$PATH make test
>  
> +For FreeBSD you need to install latest gdb from ports or packages and
> +provide path to it in TEST_GDB environment variable before executing
> +the tests, native FreeBSD gdb does not not work.  If you install
> +coreutils, which provides GNU versions of basic utils like 'date' and
> +'base64' on FreeBSD, the test suite will use these instead of the
> +native ones. This provides robustness against portability issues with
> +these system tools. Most often the tests are written, reviewed and
> +tested on Linux system so such portability issues arise from time to
> +time.
> +
> +
>  Running Tests
>  -
>  The easiest way to run tests is to say "make test", (or simply run the
> diff --git a/test/test-lib-FREEBSD.sh b/test/test-lib-FREEBSD.sh
> new file mode 100644
> index ..d1840b56
> --- /dev/null
> +++ b/test/test-lib-FREEBSD.sh
> @@ -0,0 +1,9 @@
> +# If present, use GNU Coreutils instead of a native BSD utils
> +if command -v gdate >/dev/null
> +   then
> +   date () { gdate "$@"; }
> +   base64 () { gbase64 "$@"; }
> +   wc () { gwc "$@"; }
> +   sed () { gsed "$@"; }
> +   sha256sum () { gsha256sum "$@"; }
> +   fi
> diff --git a/test/test-lib-common.sh b/test/test-lib-common.sh
> index a96cfbeb..ef409171 100644
> --- a/test/test-lib-common.sh
> +++ b/test/test-lib-common.sh
> @@ -66,6 +66,11 @@ export LD_LIBRARY_PATH
>  # configure output
>  . $notmuch_path/sh.config || exit 1
>  
> +# load OS specifics
> +if [ -e ./test-lib-$PLATFORM.sh ]; then
> + . ./test-lib-$PLATFORM.sh || exit 1
> +fi
> +
>  if test -n "$valgrind"
>  then
>   make_symlink () {
> -- 
> 2.11.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: add support for stashing formatted timestamp

2017-03-09 Thread Tomi Ollila
On Thu, Mar 09 2017, David Bremner  wrote:

> Jani Nikula  writes:
>
>> notmuch-show-stash-date stashes the Date: header of the message
>> verbatim. While that is useful, sometimes more control of the output
>> is desirable.
>>
>> Add support for stashing the message timestamp (as parsed by gmime at
>> the lib level from the Date: header) according to a user customizable
>> format. The user can use this to stash the message date in the
>> preferred format, or perhaps as a date: range query, for example
>> "date:@%s.." to find all messages since the current message.
>> ---
>
> I'm not opposed to this, but I'd like at least one vote from someone
> other than Jani that would find it useful.

I've had plenty of thoughts for alternatives, but haven't got time
to write those out.

shortly: 1) initially no customization -> see 2
 2) if customization, have list instead of one item
-- would be incompatible change if this patch were applied
 3) make the customization to current date stashing, by default
being with one item so it could work like it is working now...
... that would save 'D' for docid (if we ever agree this
should be implemented (+2 (usability, convenience) from me.

>
> d

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [RFC PATCH 6] support make goals after initial {'', dist, data}clean goal(s)

2017-03-09 Thread Tomi Ollila
On Thu, Mar 09 2017, David Bremner  wrote:

> Tomi Ollila  writes:
>
>> Now make goal combinations starting with *clean goals,
>> ending with *clean coals, and having non-*clean goals in between
>> should work. What does not expected to work are
>> non-*clean - *clean - *non-clean goal combinations.
>>
>> Also, if first goals are *clean goals, re-creation of Makefile.config
>> is inhibited when Makefile.config exists and ./configure is newer.
>> ---
>>
>> Now there is more probability I don't figure out anything that
>> could be improved (but, if things go as usual, i know that
>> tomorrow morning ;)
>
> Hi Tomi;
>
> No more improvements for this? Maybe we should call it non-RFC now?

This is as good as I can make it. Yes, I think it matured beyond the
RFC status so IMO it can be released for wider reviewer audience ;)

Tomi

>
> d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Inconsistent query results

2017-03-09 Thread Olly Betts
On Wed, Mar 08, 2017 at 10:32:56PM -0400, David Bremner wrote:
> "Kirill A. Shutemov"  writes:
> > I found that on particular queries notmuch return different results if run
> > the query few times. Re-initialing the query or db doesn't help.
> 
> Thanks for the report. I don't yet understand where the bug is, but I
> think it's safe to say it's not in your code. I made a somewhat simpler
> test case that displays the same problem (at the end).

It's a bug in Xapian - I've committed a fix to master (commit
fa12a83957e97349aa6e2a6c0896faf210dfe4b4) which I'll backport for 1.4.4 and
1.2.25 (it also affects 1.2.x).

To trigger it you need an AND operator which is unweighted (e.g. being on the
right side of AND_NOT here) with a subquery which uses the passed max weight
value (the obvious case is another operator, OR in this case).

(David already confirmed on IRC that the fix applied solves this for him.)

Cheers,
Olly
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch