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 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 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 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@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
Re: [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, > &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 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
[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 ___ 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 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 wrote: > LGTM, and fixes the issue. LGTM. Tomi > > On Mon, 21 Jan 2013, Amadeusz Żołnowski 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: extr
[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, > &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 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