test suite crash with TERM=dumb
In 0.15 (or current master) try running % TERM=dump make test At least for me and the Debian build daemons, this causes the run to end with PASS Show message: json, utf-8 FATAL: Unexpected exit with code 1 make: *** [test] Error 124 This is much worse than a test failure since it causes the build to exit with non-zero status. I have temporarily disabled running the test suite in the debian packaging, but this is obviously not a good permanent solution. Apparently the problem is on the line TERM=$ORIGINAL_TERM dtach -n $TEST_TMPDIR/emacs-dtach-socket.$$ It would be easy to hardcode the TERM for dtach, but I'm not sure if there is some advantage to testing with the user's actual term? Also, I guess we'd have to be careful the chosen terminal type is portable. d pgpsLYMDug1j_.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: test suite crash with TERM=dumb
On Mon, Jan 21 2013, David Bremner da...@tethera.net wrote: In 0.15 (or current master) try running % TERM=dump make test At least for me and the Debian build daemons, this causes the run to end with PASS Show message: json, utf-8 FATAL: Unexpected exit with code 1 make: *** [test] Error 124 This is much worse than a test failure since it causes the build to exit with non-zero status. I have temporarily disabled running the test suite in the debian packaging, but this is obviously not a good permanent solution. Apparently the problem is on the line TERM=$ORIGINAL_TERM dtach -n $TEST_TMPDIR/emacs-dtach-socket.$$ It would be easy to hardcode the TERM for dtach, but I'm not sure if there is some advantage to testing with the user's actual term? Also, I guess we'd have to be careful the chosen terminal type is portable. For user it only matters when/if one wants to attach to the dtach'd terminal (i.e. rarely). Then if the terminal chosen is knows subset of the control sequences any of the terminals users might use then it is not much of a problem -- the terminal just doesn't work optimally, display colors or something. In your tests you could just run `TERM=xterm make test` (and forget the issue ;) d Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: test suite crash with TERM=dumb
On Mon, Jan 21 2013, Tomi Ollila tomi.oll...@iki.fi wrote: In your tests you could just run `TERM=xterm make test` (and forget the issue ;) or better, vt100: localhost$ TERM=vt100 tput setaf 1 zsh: exit 1 TERM=vt100 tput setaf 1 So that say_color () will not print colors. $ TERM=vt100 emacs -nw works (or, at least, starts). Tomi Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: update top level argument handling
On Sat, 19 Jan 2013, da...@tethera.net wrote: The only new feature here is an option --leak-report to notmuch new, as requested in id:m2hangivfu@guru.guru-group.fi There is also a bunch of cleanup of the argument handling. One casualty of this is that the use of aliases (in particular notmuch part and notmuch search-tags is no longer supported). Patches 1-4 look good, and IMO should be used regardless of the bikeshedding result on patches 5-7. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/5] notmuch batch count
On Wed, 16 Jan 2013, Tomi Ollila tomi.oll...@iki.fi wrote:
On Wed, Jan 16 2013, Mark Walters markwalters1...@gmail.com wrote:
On Tue, 15 Jan 2013, Jani Nikula j...@nikula.org wrote:
Hi all -
Notmuch remote usage [1] is a pretty handy way of accessing a notmuch
database on a remote server. However, the more you have saved searches
and tags, the slower notmuch-hello becomes, and it ends up being by and
far the biggest usability issue with remote notmuch. This is because
notmuch-hello issues a separate 'notmuch count' for each saved search
and tag.
One could argue that notmuch-hello should be fixed somehow, but I chose
to try another route: batch support for notmuch count. This enables
notmuch-hello to get the counts for all the saved searches or tags in a
single call. The performance improvement is huge in remote usage, but
it's not limited to that. Regular local usage benefits from it too, but
it's not as obviously noticeable.
This series looks good to me (that is the code looks fine).
Two questions are:
Do we want this functionality? I think it is useful even on local setups
particularly if people have lots of tags (the section that shows all
tags can be quite noticeably sped up). It is a substantial improvement
on remote setups but I am not sure if that is sufficiently common to
warrant the change. At least the code path is the same so it will get
enough testing.
I do want the functionality. Especialy where I am now it takes about
0.4 sec for 'ssh remote echo foo' to get executed (using connection sharing).
pipelining the count requests could make all the count requests emacs
does (in my current set) to complete in less than 1 sec.
Secondly, if we do the functionality should it be more general so that
it can do searches etc too. I think this is less clear. Count is likely
to be the most useful one since running several (simultaneous) counts is
probably more common than running several simultaneous searches.
One could argue that we'd should send json documents to notmuch in
stdin and notmuch would output json(/sexp) documents. That is just
SMOP. I bet Austin would like this solution, especially the part
that involves writing or integrating json parser ;).
I'd be happy with this 'batch' approach.
I'll be testing this soon, but refrain from reviewing the code
until 0.15 is out.
id:87a9s5cp38.fsf@zancas.localnet ;)
J.
Best wishes
Mark
Tomi
Here's a script that demonstrates one-by-one count vs. batch count,
locally and over ssh (assuming ssh key authentication is set up), over
10 iterations:
#!/bin/bash
echo tag count:
notmuch search --output=tags * | wc -l
for remote in ssh example.com; do
export remote
echo one-by-one count:
time sh -c 'for i in `seq 10`; do notmuch search --format=text0
--output=tags * | xargs -0 -n 1 -I {} $remote notmuch count tag:{}
/dev/null; done'
echo batch count:
time sh -c 'for i in `seq 10`; do notmuch search --format=text
--output=tags * | sed s/.*/tag:\\0\/ | $remote notmuch count --batch
/dev/null; done'
done
And here's the output of it in my setup:
tag count:
36
one-by-one count:
real0m2.349s
user0m0.552s
sys 0m0.868s
batch count:
real0m0.179s
user0m0.120s
sys 0m0.064s
one-by-one count:
real0m56.527s
user0m1.424s
sys 0m1.164s
batch count:
real0m2.407s
user0m0.068s
sys 0m0.040s
As can be seen, in local usage (the first pair of results) the speedup
is more than 10x, although one-by-one notmuch count is usually
sufficiently fast. The difference is more noticeable in remote use (the
second pair of results), where the speedup is 20x here, and any
additional, occasional network latency is multiplied by tag count. (That
result is actually faster than usual for me, but it's still 5+ seconds
to display or refresh notmuch-hello.)
Mark has written a patch that I've been using to switch notmuch-hello to
use batch count. That has made me switch from running notmuch in ssh to
using remote notmuch. The great thing is that we could switch to using
that in Emacs with no special casing for remote usage, and it would
speed things up also in local use. I'm expecting Mark to post his patch
in reply to this series.
Mark actually wrote the elisp part based on the rough idea prior to any
of this cli plumbing, so I felt obliged to follow up. So thanks Mark!
BR,
Jani.
[1] http://notmuchmail.org/remoteusage/ (the page could use some
cleanup; it's really not nearly as complicated as the page suggests)
Jani Nikula (5):
cli: remove useless strdup
cli: extract count printing to a separate function in notmuch count
cli: add --batch option to notmuch count
man: document notmuch count --batch and --input options
test: notmuch count --batch and --input options
man/man1/notmuch-count.1 | 20 +
notmuch-count.c | 111
Re: [PATCH v3 08/20] tag-util: move out 'tag' command-line checks
On Sun, 20 Jan 2013, Peter Wang noval...@gmail.com wrote:
parse_tag_command_line checked for two error conditions which are
specific to the 'tag' command. It can be reused for the notmuch
'insert' command if we move the checks out, into notmuch-tag.c.
*three* error conditions, two of which are specific to notmuch tag. See
below.
---
notmuch-tag.c | 10 ++
tag-util.c| 10 --
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/notmuch-tag.c b/notmuch-tag.c
index d9daf8f..a901dad 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -234,6 +234,16 @@ notmuch_tag_command (void *ctx, int argc, char *argv[])
if (parse_tag_command_line (ctx, argc - opt_index, argv + opt_index,
query_string, tag_ops))
return 1;
+
+ if (tag_op_list_size (tag_ops) == 0) {
+ fprintf (stderr, Error: 'notmuch tag' requires at least one tag to
add or remove.\n);
+ return 1;
+ }
+
+ if (*query_string == '\0') {
+ fprintf (stderr, Error: notmuch tag requires at least one search
term.\n);
+ return 1;
+ }
}
config = notmuch_config_open (ctx, NULL, NULL);
diff --git a/tag-util.c b/tag-util.c
index 3f9da05..41f2c09 100644
--- a/tag-util.c
+++ b/tag-util.c
@@ -186,18 +186,8 @@ parse_tag_command_line (void *ctx, int argc, char **argv,
tag_op_list_append (tag_ops, argv[i] + 1, is_remove);
}
-if (tag_op_list_size (tag_ops) == 0) {
- fprintf (stderr, Error: 'notmuch tag' requires at least one tag to add
or remove.\n);
- return TAG_PARSE_INVALID;
-}
-
*query_str = query_string_from_args (ctx, argc - i, argv[i]);
-if (*query_str == NULL || **query_str == '\0') {
You must leave *query_str == NULL check intact here. Fix the error
message to be about allocation failure and drop the reference to notmuch
tag while at it.
Otherwise LGTM.
- fprintf (stderr, Error: notmuch tag requires at least one search
term.\n);
- return TAG_PARSE_INVALID;
-}
-
return TAG_PARSE_SUCCESS;
}
--
1.7.12.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 07/20] tag-util: do not reset list in parse_tag_command_line
On Sun, 20 Jan 2013, Peter Wang noval...@gmail.com wrote:
No current callers of parse_tag_command_line require that it clear its
tag list argument. The notmuch 'insert' command will be better served
if the function modifies a pre-populated list (of new.tags) instead of
clobbering it outright.
I think I'd like parse_tag_command_line() and parse_tag_line() to behave
similarly, both either resetting or not resetting tag list. I think you
could just parse command line first, and add new.tags afterwards, and
you'd be fine without changing parse_tag_command_line().
---
tag-util.c | 2 --
tag-util.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tag-util.c b/tag-util.c
index 701d329..3f9da05 100644
--- a/tag-util.c
+++ b/tag-util.c
@@ -165,8 +165,6 @@ parse_tag_command_line (void *ctx, int argc, char **argv,
int i;
-tag_op_list_reset (tag_ops);
-
for (i = 0; i argc; i++) {
if (strcmp (argv[i], --) == 0) {
i++;
diff --git a/tag-util.h b/tag-util.h
index 246de85..4628f16 100644
--- a/tag-util.h
+++ b/tag-util.h
@@ -81,6 +81,8 @@ parse_tag_line (void *ctx, char *line,
* Output Parameters:
* ops contains a list of tag operations
* query_str the search terms.
+ *
+ * The ops argument is not cleared.
*/
tag_parse_status_t
--
1.7.12.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/Makefile.local: depend on libs we are linking with
LGTM, and fixes the issue. On Mon, 21 Jan 2013, Amadeusz Żołnowski aide...@aidecoe.name wrote: --- lib/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 7785944..155ac02 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -73,7 +73,7 @@ libnotmuch_modules := $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o) $(dir)/libnotmuch.a: $(libnotmuch_modules) $(call quiet,AR) rcs $@ $^ -$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym +$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym util/libutil.a parse-time-string/libparse-time-string.a $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ util/libutil.a parse-time-string/libparse-time-string.a notmuch.sym: $(srcdir)/$(dir)/notmuch.h $(libnotmuch_modules) -- 1.8.1.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib/Makefile.local: depend on libs we are linking with
On Tue, Jan 22 2013, Jani Nikula j...@nikula.org wrote: LGTM, and fixes the issue. LGTM. Tomi On Mon, 21 Jan 2013, Amadeusz Żołnowski aide...@aidecoe.name wrote: --- lib/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 7785944..155ac02 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -73,7 +73,7 @@ libnotmuch_modules := $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o) $(dir)/libnotmuch.a: $(libnotmuch_modules) $(call quiet,AR) rcs $@ $^ -$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym +$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym util/libutil.a parse-time-string/libparse-time-string.a $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ util/libutil.a parse-time-string/libparse-time-string.a notmuch.sym: $(srcdir)/$(dir)/notmuch.h $(libnotmuch_modules) -- 1.8.1.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 5/7] CLI: add --leak-report top level option
On Sun, Jan 20 2013, Jameson Graef Rollins wrote: > On Sat, Jan 19 2013, david at tethera.net wrote: >> This roughly mimics the samba4 argument. The presence of the command >> line argument overrides any value of NOTMUCH_TALLOC_REPORT in the >> environment. >> --- >> man/man1/notmuch.1 |8 >> notmuch.c | 18 +++--- >> 2 files changed, 15 insertions(+), 11 deletions(-) >> >> diff --git a/man/man1/notmuch.1 b/man/man1/notmuch.1 >> index 6bf9b2e..5c58c41 100644 >> --- a/man/man1/notmuch.1 >> +++ b/man/man1/notmuch.1 >> @@ -70,6 +70,14 @@ Print a synopsis of available commands and exit. >> Print the installed version of notmuch, and exit. >> .RE >> >> +.RS 4 >> +.TP 4 >> +.BI \-\-leak-report= path >> + >> +Write a detailed report of all memory allocated via talloc to >> +.I path >> +.RE > > Do we really need a command line option for this? Why isn't the env var > sufficient? This just seems to me like it clutters the interface, for > an option that is purely for debugging and should rarely if ever be used > by most users. Jameson does have a point. Now that we already have that environment variable and it can be used in shipped notmuch 0.15 it is perhaps simplest just to stick with that. My thoughts after brief first visit to the patche series has so far being either make the command line usage 1:1 compatible with samba or use option like --leak-report-output=..., --leak-report-file=... or --leak-report-to=... (and attempt to deprecate the env var...) That said, I withdraw my previous suggestion of the command line option... The other changes in this patch series looks initially good -- and changes that drop deprecated features should be get in as early after last release as possible. > jamie. Tomi
[PATCH 2/2] test/test-lib.sh: separate signaled exit
When execution of tests is interrupted by signal coming outside of the
test system itself, output just one line "interrupted by signal "
message to standard output. This distinguishes the case from internal
exit and reduces noise.
---
test/test-lib.sh | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 0098bfd..e717c52 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -190,9 +190,15 @@ test_fixed=0
test_broken=0
test_success=0
-die () {
+_die_common () {
code=$?
+ trap - EXIT
+ set +ex
rm -rf "$TEST_TMPDIR"
+}
+
+die () {
+ _die_common
if test -n "$GIT_EXIT_OK"
then
exit $code
@@ -206,10 +212,17 @@ die () {
fi
}
+die_signal () {
+ _die_common
+ echo >&5 "FATAL: $0: interrupted by signal" $((code - 128))
+ exit $code
+}
+
GIT_EXIT_OK=
# Note: TEST_TMPDIR *NOT* exported!
TEST_TMPDIR=$(mktemp -d "${TMPDIR:-/tmp}/notmuch-test-$$.XX")
trap 'die' EXIT
+trap 'die_signal' HUP INT TERM
test_decode_color () {
sed -e 's/.\[1m//g' \
--
1.8.0
[PATCH 1/2] test/test-lib.sh: use $test_subtest_name in all tests
Set the variable '$test_subtest_name' in all functions which starts
a new test and use that variable in all functions that output
test results.
Additionally output the latest '$test_subtest_name' in case of
abnormal exit, to avoid confusion.
---
This obsoletes id:1358717806-11376-1-git-send-email-tomi.ollila at iki.fi
which had fd:s in function 'die' wrong order in 'exec [1]>&5' line.
I did plenty of (ad hoc) hand-testing for this but failed to notice that
messages weren't always as verbose as those should have been. The wip
patch set mentioned below has it right but this was hand-rewritten as
this is somewhat different here...
The main reason to do this change is to get latest '$test_subtest_name'
printed in case of abnormal exit. I cherry-picked this change from a
larger work-in-progress patch set that adds 'set -e -o pipefail' support...
I am pretty sure I got all the cases covered. If not, we'll notice
it later when some test fail in a way I could not anticipate.
Anyway, tests success & fail as they used to be.
test/test-lib.sh | 52 +---
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 6ce3b31..0098bfd 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -197,7 +197,11 @@ die () {
then
exit $code
else
- echo >&5 "FATAL: Unexpected exit with code $code"
+ exec >&5
+ say_color error '%-6s' FATAL
+ echo " $test_subtest_name"
+ echo
+ echo "Unexpected exit while executing $0. Exit code $code."
exit 1
fi
}
@@ -494,12 +498,12 @@ test_expect_equal ()
if ! test_skip "$test_subtest_name"
then
if [ "$output" = "$expected" ]; then
- test_ok_ "$test_subtest_name"
+ test_ok_
else
testname=$this_test.$test_count
echo "$expected" > $testname.expected
echo "$output" > $testname.output
- test_failure_ "$test_subtest_name" "$(diff -u
$testname.expected $testname.output)"
+ test_failure_ "$(diff -u $testname.expected
$testname.output)"
fi
fi
}
@@ -520,12 +524,12 @@ test_expect_equal_file ()
if ! test_skip "$test_subtest_name"
then
if diff -q "$file1" "$file2" >/dev/null ; then
- test_ok_ "$test_subtest_name"
+ test_ok_
else
testname=$this_test.$test_count
cp "$file1" "$testname.$basename1"
cp "$file2" "$testname.$basename2"
- test_failure_ "$test_subtest_name" "$(diff -u
"$testname.$basename1" "$testname.$basename2")"
+ test_failure_ "$(diff -u "$testname.$basename1"
"$testname.$basename2")"
fi
fi
}
@@ -563,9 +567,9 @@ test_emacs_expect_t () {
result=$(cat OUTPUT)
if [ "$result" = t ]
then
- test_ok_ "$test_subtest_name"
+ test_ok_
else
- test_failure_ "$test_subtest_name" "${result}"
+ test_failure_ "${result}"
fi
else
# Restore state after the (non) test.
@@ -666,12 +670,12 @@ test_require_external_prereq () {
test_ok_ () {
if test "$test_subtest_known_broken_" = "t"; then
- test_known_broken_ok_ "$@"
+ test_known_broken_ok_
return
fi
test_success=$(($test_success + 1))
say_color pass "%-6s" "PASS"
- echo " $@"
+ echo " $test_subtest_name"
}
test_failure_ () {
@@ -680,7 +684,7 @@ test_failure_ () {
return
fi
test_failure=$(($test_failure + 1))
- test_failure_message_ "FAIL" "$@"
+ test_failure_message_ "FAIL" "$test_subtest_name" "$@"
test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
return 1
}
@@ -697,13 +701,13 @@ test_known_broken_ok_ () {
test_reset_state_
test_fixed=$(($test_fixed+1))
say_color pass "%-6s" "FIXED"
- echo " $@"
+ echo " $test_subtest_name"
}
test_known_broken_failure_ () {
test_reset_state_
test_broken=$(($test_broken+1))
- test_failure_message_ "BROKEN" "$@"
+ test_failure_message_ "BROKEN" "$test_subtest_name" "$@"
return 1
}
@@ -771,6 +775,7 @@ test_expect_success () {
test "$#" = 3 && { prereq=$1; shift; } || prereq=
test "$#" = 2 ||
error "bug in the test script: not 2 or 3 parameters to
test-expect-success"
+ test_subtest_name="$1"
test_reset_state_
if ! test_skip "$@"
then
@@ -780,9 +785,9 @@ test_expect_success
[PATCH 1/2] test/test-lib.sh: use $test_subtest_name in all tests
On Mon, Jan 21 2013, Tomi Ollila wrote: > Set the variable '$test_subtest_name' in all functions which starts > a new test and use that variable in all functions that output > test results. > > Additionally output the latest '$test_subtest_name' in case of > abnormal exit, to avoid confusion. > --- > > This obsoletes id:1358717806-11376-1-git-send-email-tomi.ollila at iki.fi How can this be so hard again, the patch that obsoleted is id:1358717493-11231-1-git-send-email-tomi.ollila at iki.fi Additionally, I tried to add that mail as reply-to to that particular email but git-send-email is not smart enough to strip the 'id:' part from beginning of the Reply-To: field ;/. Enter 'V' in notmuch show window to see what was written into Reply-To: header ;/. Tomi
test suite crash with TERM=dumb
In 0.15 (or current master) try running % TERM=dump make test At least for me and the Debian build daemons, this causes the run to end with PASS Show message: json, utf-8 FATAL: Unexpected exit with code 1 make: *** [test] Error 124 This is much worse than a test failure since it causes the build to exit with non-zero status. I have temporarily disabled running the test suite in the debian packaging, but this is obviously not a good permanent solution. Apparently the problem is on the line TERM=$ORIGINAL_TERM dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" It would be easy to hardcode the TERM for dtach, but I'm not sure if there is some advantage to testing with the user's actual term? Also, I guess we'd have to be careful the chosen terminal type is portable. d -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130121/8f1336e6/attachment.pgp>
test suite crash with TERM=dumb
On Mon, Jan 21 2013, David Bremner wrote: > In 0.15 (or current master) try running > > % TERM=dump make test > > At least for me and the Debian build daemons, this causes the run to end > with > > PASS Show message: json, utf-8 > FATAL: Unexpected exit with code 1 > make: *** [test] Error 124 > > This is much worse than a test failure since it causes the build to exit > with non-zero status. > > I have temporarily disabled running the test suite in the debian > packaging, but this is obviously not a good permanent solution. > > Apparently the problem is on the line > > TERM=$ORIGINAL_TERM dtach -n "$TEST_TMPDIR/emacs-dtach-socket.$$" > > It would be easy to hardcode the TERM for dtach, but I'm not sure if > there is some advantage to testing with the user's actual term? Also, I > guess we'd have to be careful the chosen terminal type is portable. For user it only matters when/if one wants to attach to the dtach'd terminal (i.e. rarely). Then if the terminal chosen is knows subset of the control sequences any of the terminals users might use then it is not much of a problem -- the terminal just doesn't work optimally, display colors or something. In your tests you could just run `TERM=xterm make test` (and forget the issue >;) > d Tomi
test suite crash with TERM=dumb
On Mon, Jan 21 2013, Tomi Ollila wrote: > > In your tests you could just run `TERM=xterm make test` (and forget the > issue >;) or better, vt100: localhost$ TERM=vt100 tput setaf 1 zsh: exit 1 TERM=vt100 tput setaf 1 So that say_color () will not print colors. $ TERM=vt100 emacs -nw works (or, at least, starts). > Tomi Tomi
update top level argument handling
On Sat, 19 Jan 2013, david at tethera.net wrote: > The only new feature here is an option --leak-report > to notmuch new, as requested in id:m2hangivfu.fsf at guru.guru-group.fi > > There is also a bunch of cleanup of the argument handling. One > casualty of this is that the use of aliases (in particular "notmuch > part" and "notmuch search-tags" is no longer supported). Patches 1-4 look good, and IMO should be used regardless of the bikeshedding result on patches 5-7. BR, Jani. > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/5] notmuch batch count
On Wed, 16 Jan 2013, Tomi Ollila wrote:
> On Wed, Jan 16 2013, Mark Walters wrote:
>
>> On Tue, 15 Jan 2013, Jani Nikula wrote:
>>> Hi all -
>>>
>>> Notmuch remote usage [1] is a pretty handy way of accessing a notmuch
>>> database on a remote server. However, the more you have saved searches
>>> and tags, the slower notmuch-hello becomes, and it ends up being by and
>>> far the biggest usability issue with remote notmuch. This is because
>>> notmuch-hello issues a separate 'notmuch count' for each saved search
>>> and tag.
>>>
>>> One could argue that notmuch-hello should be fixed somehow, but I chose
>>> to try another route: batch support for notmuch count. This enables
>>> notmuch-hello to get the counts for all the saved searches or tags in a
>>> single call. The performance improvement is huge in remote usage, but
>>> it's not limited to that. Regular local usage benefits from it too, but
>>> it's not as obviously noticeable.
>>
>> This series looks good to me (that is the code looks fine).
>>
>> Two questions are:
>>
>> Do we want this functionality? I think it is useful even on local setups
>> particularly if people have lots of tags (the section that shows all
>> tags can be quite noticeably sped up). It is a substantial improvement
>> on remote setups but I am not sure if that is sufficiently common to
>> warrant the change. At least the code path is the same so it will get
>> enough testing.
>
> I do want the functionality. Especialy where I am now it takes about
> 0.4 sec for 'ssh remote echo foo' to get executed (using connection sharing).
> pipelining the count requests could make all the count requests emacs
> does (in my current set) to complete in less than 1 sec.
>
>> Secondly, if we do the functionality should it be more general so that
>> it can do searches etc too. I think this is less clear. Count is likely
>> to be the most useful one since running several (simultaneous) counts is
>> probably more common than running several simultaneous searches.
>
> One could argue that we'd should send json "documents" to notmuch in
> stdin and notmuch would output json(/sexp) "documents". That is just
> SMOP. I bet Austin would like this solution, especially the part
> that involves writing or integrating json parser >;).
> I'd be happy with this 'batch' approach.
>
> I'll be testing this soon, but refrain from reviewing the code
> until 0.15 is out.
id:87a9s5cp38.fsf at zancas.localnet ;)
J.
>
>>
>> Best wishes
>>
>> Mark
>
>
> Tomi
>
>
>>
>>
>>>
>>> Here's a script that demonstrates one-by-one count vs. batch count,
>>> locally and over ssh (assuming ssh key authentication is set up), over
>>> 10 iterations:
>>>
>>> #!/bin/bash
>>>
>>> echo "tag count:"
>>> notmuch search --output=tags "*" | wc -l
>>>
>>> for remote in "" "ssh example.com"; do
>>> export remote
>>> echo "one-by-one count:"
>>> time sh -c 'for i in `seq 10`; do notmuch search --format=text0
>>> --output=tags "*" | xargs -0 -n 1 -I "{}" $remote notmuch count tag:"{}" >
>>> /dev/null; done'
>>>
>>> echo "batch count:"
>>> time sh -c 'for i in `seq 10`; do notmuch search --format=text
>>> --output=tags "*" | sed "s/.*/tag:\"\0\"/" | $remote notmuch count --batch
>>> > /dev/null; done'
>>> done
>>>
>>> And here's the output of it in my setup:
>>>
>>> tag count:
>>> 36
>>> one-by-one count:
>>>
>>> real0m2.349s
>>> user0m0.552s
>>> sys 0m0.868s
>>> batch count:
>>>
>>> real0m0.179s
>>> user0m0.120s
>>> sys 0m0.064s
>>> one-by-one count:
>>>
>>> real0m56.527s
>>> user0m1.424s
>>> sys 0m1.164s
>>> batch count:
>>>
>>> real0m2.407s
>>> user0m0.068s
>>> sys 0m0.040s
>>>
>>> As can be seen, in local usage (the first pair of results) the speedup
>>> is more than 10x, although one-by-one notmuch count is usually
>>> sufficiently fast. The difference is more noticeable in remote use (the
>>> second pair of results), where the speedup is 20x here, and any
>>> additional, occasional network latency is multiplied by tag count. (That
>>> result is actually faster than usual for me, but it's still 5+ seconds
>>> to display or refresh notmuch-hello.)
>>>
>>> Mark has written a patch that I've been using to switch notmuch-hello to
>>> use batch count. That has made me switch from running notmuch in ssh to
>>> using remote notmuch. The great thing is that we could switch to using
>>> that in Emacs with no special casing for remote usage, and it would
>>> speed things up also in local use. I'm expecting Mark to post his patch
>>> in reply to this series.
>>>
>>> Mark actually wrote the elisp part based on the rough idea prior to any
>>> of this cli plumbing, so I felt obliged to follow up. So thanks Mark!
>>>
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>> [1] http://notmuchmail.org/remoteusage/ (the page could use some
>>> cleanup; it's really not nearly as complicated as the page suggests)
>>>
>>>
>>> Jani Nikula (5):
>>> cli: remove useless strdup
>>> cli:
[PATCH v3 08/20] tag-util: move out 'tag' command-line checks
On Sun, 20 Jan 2013, Peter Wang wrote:
> parse_tag_command_line checked for two error conditions which are
> specific to the 'tag' command. It can be reused for the notmuch
> 'insert' command if we move the checks out, into notmuch-tag.c.
*three* error conditions, two of which are specific to notmuch tag. See
below.
> ---
> notmuch-tag.c | 10 ++
> tag-util.c| 10 --
> 2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/notmuch-tag.c b/notmuch-tag.c
> index d9daf8f..a901dad 100644
> --- a/notmuch-tag.c
> +++ b/notmuch-tag.c
> @@ -234,6 +234,16 @@ notmuch_tag_command (void *ctx, int argc, char *argv[])
> if (parse_tag_command_line (ctx, argc - opt_index, argv + opt_index,
> _string, tag_ops))
> return 1;
> +
> + if (tag_op_list_size (tag_ops) == 0) {
> + fprintf (stderr, "Error: 'notmuch tag' requires at least one tag to
> add or remove.\n");
> + return 1;
> + }
> +
> + if (*query_string == '\0') {
> + fprintf (stderr, "Error: notmuch tag requires at least one search
> term.\n");
> + return 1;
> + }
> }
>
> config = notmuch_config_open (ctx, NULL, NULL);
> diff --git a/tag-util.c b/tag-util.c
> index 3f9da05..41f2c09 100644
> --- a/tag-util.c
> +++ b/tag-util.c
> @@ -186,18 +186,8 @@ parse_tag_command_line (void *ctx, int argc, char **argv,
> tag_op_list_append (tag_ops, argv[i] + 1, is_remove);
> }
>
> -if (tag_op_list_size (tag_ops) == 0) {
> - fprintf (stderr, "Error: 'notmuch tag' requires at least one tag to add
> or remove.\n");
> - return TAG_PARSE_INVALID;
> -}
> -
> *query_str = query_string_from_args (ctx, argc - i, [i]);
>
> -if (*query_str == NULL || **query_str == '\0') {
You must leave *query_str == NULL check intact here. Fix the error
message to be about allocation failure and drop the reference to notmuch
tag while at it.
Otherwise LGTM.
> - fprintf (stderr, "Error: notmuch tag requires at least one search
> term.\n");
> - return TAG_PARSE_INVALID;
> -}
> -
> return TAG_PARSE_SUCCESS;
> }
>
> --
> 1.7.12.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3 07/20] tag-util: do not reset list in parse_tag_command_line
On Sun, 20 Jan 2013, Peter Wang wrote:
> No current callers of parse_tag_command_line require that it clear its
> tag list argument. The notmuch 'insert' command will be better served
> if the function modifies a pre-populated list (of new.tags) instead of
> clobbering it outright.
I think I'd like parse_tag_command_line() and parse_tag_line() to behave
similarly, both either resetting or not resetting tag list. I think you
could just parse command line first, and add new.tags afterwards, and
you'd be fine without changing parse_tag_command_line().
> ---
> tag-util.c | 2 --
> tag-util.h | 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tag-util.c b/tag-util.c
> index 701d329..3f9da05 100644
> --- a/tag-util.c
> +++ b/tag-util.c
> @@ -165,8 +165,6 @@ parse_tag_command_line (void *ctx, int argc, char **argv,
>
> int i;
>
> -tag_op_list_reset (tag_ops);
> -
> for (i = 0; i < argc; i++) {
> if (strcmp (argv[i], "--") == 0) {
> i++;
> diff --git a/tag-util.h b/tag-util.h
> index 246de85..4628f16 100644
> --- a/tag-util.h
> +++ b/tag-util.h
> @@ -81,6 +81,8 @@ parse_tag_line (void *ctx, char *line,
> * Output Parameters:
> * ops contains a list of tag operations
> * query_str the search terms.
> + *
> + * The ops argument is not cleared.
> */
>
> tag_parse_status_t
> --
> 1.7.12.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] lib/Makefile.local: depend on libs we are linking with
--- lib/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 7785944..155ac02 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -73,7 +73,7 @@ libnotmuch_modules := $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o) $(dir)/libnotmuch.a: $(libnotmuch_modules) $(call quiet,AR) rcs $@ $^ -$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym +$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym util/libutil.a parse-time-string/libparse-time-string.a $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ util/libutil.a parse-time-string/libparse-time-string.a notmuch.sym: $(srcdir)/$(dir)/notmuch.h $(libnotmuch_modules) -- 1.8.1.1
