Re: [PATCH] ruby: improve compilation with CFLAGS
On Mon, May 17, 2021 at 12:48 AM Felipe Contreras wrote: > > The ruby MakeMakefile generates a makefile that is suboptimal, which has > CFLAGS like this: > > CFLAGS = $(CCDLFLAGS) -march=x86-64 -mtune=generic \ > -O2 -pipe -fno-plt -fPIC $(ARCH_FLAG) > > This works as long as the user doesn't modify the Makefile. Great... doesn't modify the CFLAGS. -- Felipe Contreras ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH] ruby: improve compilation with CFLAGS
The ruby MakeMakefile generates a makefile that is suboptimal, which has CFLAGS like this: CFLAGS = $(CCDLFLAGS) -march=x86-64 -mtune=generic \ -O2 -pipe -fno-plt -fPIC $(ARCH_FLAG) This works as long as the user doesn't modify the Makefile. Certain flags (namely -fPIC) need to be present regardless of what CFLAGS are specified. The Makefile should have done this instead: CFLAGS = -march=x86-64 -mtune=generic -O2 override CFLAGS += $(CCDLFLAGS) -pipe -fno-plt -fPIC $(ARCH_FLAG) Unfortunately they didn't, so we need to workaround their lack of foresight. We can simply add the necessary flags in the parent Makefile so everyone is happy. Signed-off-by: Felipe Contreras --- bindings/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bindings/Makefile.local b/bindings/Makefile.local index bc960bbc..3672e69f 100644 --- a/bindings/Makefile.local +++ b/bindings/Makefile.local @@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1) LIBNOTMUCH="../../lib/$(LINKER_NAME)" \ NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \ $(RUBY) extconf.rb --vendor - $(MAKE) -C $(dir)/ruby + $(MAKE) -C $(dir)/ruby CFLAGS="$(CFLAGS) -pipe -fno-plt -fPIC" endif python-cffi-bindings: lib/$(LINKER_NAME) -- 2.31.1 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Breakage after updating to 0.32 (database and path issues)
Hi David, David Bremner writes: > Jack Kamm writes: > >> Update: I was able to fix my problems by explicitly setting "database.path" >> to "$HOME/mail" in my .notmuch-config. Then, notmuch was able to find my >> emails in my "$HOME/mail" as well as my database at "$HOME/mail/.notmuch". >> >> Confusingly, if "database.path" wasn't explicitly set in >> .notmuch-config, then "notmuch config get database.path" still >> returned "$HOME/mail", but notmuch cant' find the database, instead >> looking in ".local/share/notmuch/default". Is this a bug? > > It's a bit surprising that you can't reproduce this anymore, because I > think there really was a bug here. I have sent a patch as a followup, Is it possible that at this point the config variable had been set in the database, so it remained set even though I commented it from my dotfile, hence the inability to reproduce? Just a wild guess, as I'm not sure how the database and config file interact with each other. I don't want to mess further with my email at the moment, so not going to do more testing on this right now. But I'll keep an eye on it and update if I notice anything wrong. Thanks again, and sorry for the delayed response. Best, Jack ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
2021-05-16 12:19:45, Anton Khirnov wrote: > Thought I'd share with the people here the fork of alot I've been > hacking on for the past ~1.5 years, see if there is any interest in it. > The code can be found at git://git.khirnov.net/alot. This looks very promising, and at least for me personally it is very interesting. I tried it, and for my workflow at least it seems to work as a drop-in for the mainline alot version. The only thing I have noticed that broke was the now unnecessary ANSI-coloring I used in mailcap scripts as a workaround to get rudimentary quote coloring. I have been using sup/notmuch/alot (and forks thereof) for the last decade or so, and I am very grateful for the work people have put into this notmuch ecosystem of MUAs. None of the UIs have ever been perfect, but that is okay, because for me at least most of them are still much better than the alternatives (e.g. mutt, GMail, Thunderbird, Zimbra). > - quoted blocks [...] > - [...] thread mode is split-window This new view is very nice, and for large threads (especially ones with deep reply indentation) splitting it up like this gives a much better overview of the threads than alots indented tree view. > - all the parts are rendered for multipart/mixed messages, as per the > RFCs > - encrypted/signed parts are now wrapped in a frame that indicates which > bits of the message are actually encrypted or signed But I actually think this new way of dealing with multipart messages is the most novel feature. It should be mentioned that mainline merged in a similar togglemimepart/tree feature about a year ago (i.e. later than where you forked), but this seems to be a more thoughtful design. This is actually the first UI I have seen that intuitively presents the different parts of complicated mails. > - various architectural restructurings which were needed for the above > or to allow for future changes (I have a large TODO list left) I for one at least would be very interested in hearing what sort of feature you plan in the road map ahead. > At this point my tree has over 200 new commits and some ~4k changed > lines, so it's looking increasingly unlikely that I'll ever find the > free time and motivation to upstream it -- especially given alot's > glacial pace of development recently. If people are interested in using > this, I'll probably fork it "properly" under a new name. I really get this. I too have custom forks of e.g. alot tweaking small annoyances in ways often considered more hacky than production ready. For me at least these are tools I am using all day, so if I end of supporting whatever fork I settled on for my own use long after the that fork / the mainline dies away, that is fine by me. Regardless of what happens to this with regards the mainline alot, I just want to point out how nice it is that we have notmuch as a shared backend for all these UIs. This makes it so much easier to port between them as newer alternatives pops up. It also means that none of the UIs needs to be feature complete to be useful, because for e.g. features people needs once in a blue moon, there is no problem having a tailored UIs/CLIs around for dealing with those particular things. Best wishes, -- johs (Johannes Larsen), (+47) 41435451 signature.asc Description: signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: ruby: building with CFLAGS="something"
On Sun, May 16 2021, Felipe Contreras wrote: > On Sun, May 16, 2021 at 7:28 AM David Bremner wrote: >> >> >> The rest of the (C and C++) codebase supports >> >> make CFLAGS="-g -O0" >> >> or >> >> CFLAGS="-g -O0" ./configure >> >> but the ruby bindings don't build: > > That's because -fPIC is needed. > > The way Ruby's mkmf generates the Makefile is wrong, because it should do: > > override CFLAGS+=-fPIC > > So that the user can specify other CFLAGS. > > However, we can fix that by doing that ourselves: > > --- a/bindings/Makefile.local > +++ b/bindings/Makefile.local > @@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1) > LIBNOTMUCH="../../lib/$(LINKER_NAME)" \ > NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \ > $(RUBY) extconf.rb --vendor > - $(MAKE) -C $(dir)/ruby > + $(MAKE) -C $(dir)/ruby CFLAGS="$(CFLAGS) -pipe -fno-plt -fPIC" forget my suggestion -- also in general, usually, make variables have more "power" than defining such a thing in environment (would not be in those cases there is intermediate wrapper which does not get the make variable...) Tomi > endif > > We lose -march=x86-64 -mtune=generic (at least on my machine), but I > guess that's not a big deal since libnotmuch itself isn't getting > compiled with those. > > I'll send a patch soonish. > > -- > Felipe Contreras > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 1/4] bindings/ruby: unexport CFLAGS when building
On Sun, May 16 2021, David Bremner wrote: > This prevents breaking the ruby build when passing CFLAGS to other > parts of the build. > --- > bindings/Makefile.local | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/bindings/Makefile.local b/bindings/Makefile.local > index bc960bbc..8e3cd051 100644 > --- a/bindings/Makefile.local > +++ b/bindings/Makefile.local > @@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1) > LIBNOTMUCH="../../lib/$(LINKER_NAME)" \ > NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \ > $(RUBY) extconf.rb --vendor > - $(MAKE) -C $(dir)/ruby > + env -u CFLAGS $(MAKE) -C $(dir)/ruby As you mentioned posix env does not have -u (that's shame), perhaps CFLAGS= $(MAKE) -C $(dir)/ruby works -- that is slightly different as now CFLAGS is defined in env, just empty. Tomi > endif > > python-cffi-bindings: lib/$(LINKER_NAME) > -- > 2.30.2 > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: announce: my fork of alot
Quoting Patrick Totzke (2021-05-16 17:41:49) > Hi everyone, > > All this sounds very exciting and I'd be very happy to see these features in > (mainline) alot! > > I agree that some of alot's underlying code is ready for refactoring > and urwid in particular has been a big drag on quickly implementing things. > Also, I'd be interested in hearing your thoughts on deprecating some > "unworthy" > features in order to reduce the maintenance effort! That is largely a matter of perspective and personal preference. E.g. among the things gone in my tree are: - removing messages - I dropped that because I considered that code potentially dangerous, had no use for it myself, and just didn't want to tiptoe around it; someone actually using RemoveCommand in their workflow would have a different opinion - switching to split-window layout for thread view made it simpler to implement quote folding, but also made sense to me since I never want to see more than one message at once; again, someone who prefers collapsing messages would see this as loss of functionality https://xkcd.com/1172/ is very much in effect > > > Why did I not submit all this as PRs to upstream alot? The main reasons > > > were my lack of time and disagreement with the upstream about project > > > status. From what I can tell, alot maintainers consider the project to > > > be mature, so they prioritize stability and small incremental changes. > > > From my perspective, alot is lacking some critical features -- some > > > implemented in my fork already, some planned -- which makes it > > > borderline-unusable for me. As implementing those features required > > > large-scale architectural changes and my free time was quite limited, I > > > prioritized quickly implementing the things I cared about over > > > progressing in small incremental stable easily-reviewable steps. > > > > I have a similar impression about the project status. I'm curious: What > > are the architectural changes that you made? > > > Yes, the speed at which alot progresses is borderline problematic. This is of > course down to the small number of core contributors and the fact that for all > of us life goes on an priorities change. > > One problem is that the project attracts many users interested in pushing what > I'd call "hotfixes" to address missing features: Often people would present > a (nicely working) proof-of concept that is not well documented, tested, and > doesn't adhere to common code conventions, only not to follow up on their > promises to "clean things up", for all too understandable reasons. > Still, I believe that just merging everything will quickly kill the project as > a) this leads to code that is very difficult and time-consuming to maintain > and > b) broken features are very damaging to user's perception of the software, > much > more so than missing ones. > > I am not accusing you of anything here, Anton. I just wish to point out > potential long term difficulties and clarify that I tried to err on the side > of > cautiousness to keep alot afloat in a usable state for most (potential) users. You would be very correct to accuse me of taking various shortcuts. I would not call my changes "hotfixes", as I tried to keep continuous future improvements in mind (and in fact see many of my changes as cleanup and simplification). But I did make an explicit decision to prioritise rapidly adding new functionality, at the cost of potential regressions and loss of some features I did not need. And again, this is a matter of perspective. If alot does what you want it to do then of course you will value stability and consistency. But if the lack of certain features makes it barely usable, then it makes sense to be more radical. > > > At this point my tree has over 200 new commits and some ~4k changed > > > lines, so it's looking increasingly unlikely that I'll ever find the > > > free time and motivation to upstream it -- especially given alot's > > > glacial pace of development recently. If people are interested in using > > > this, I'll probably fork it "properly" under a new name. > > > > > > Any comments or questions are very much welcome. I can also be reached > > > on IRC as elenril. > > > > Have you tried raising these concerns with upstream before your fork? > > Have you tried gathering a team around an idea and starting something > > new together? > > > > Frankly, upstream is borderline small already, and the way you started > > your fork probably will not attract a team of people who want to make > > that new fork their (common) own or are looking for a stronger team. > > I share Michael's concerns about further splintering the small group of > developers and believe that this would be to the detriment of both projects. > > It's no secret that I am ready to give the helm to others. I have been > maintaining this project for a while now, mainly for personal usage and as > a fun distraction. I have tried to squeeze in time to re
Re: announce: my fork of alot
Hi everyone, Of course I feel obliged to chime in and clarify, so here it goes. Quoting Michael J Gruber (2021-05-16 12:15:28) > Anton Khirnov venit, vidit, dixit 2021-05-16 12:19:45: > > Hi, > > > > Thought I'd share with the people here the fork of alot I've been > > hacking on for the past ~1.5 years, see if there is any interest in it. > > Thanks for sharing! First of all many thanks to Anton for his enthusiasm in pushing the alot project further! > > The code can be found at git://git.khirnov.net/alot. > > Any particular reason why this is not a fork where upstream is (GitHub)? > > > There are many changes in various places, the most user-visible ones in > > the thread view mode. Specifically > > - quoted blocks in the email body can now be colored and folded (this > > was probably my main motivation for starting all this) > > - in upstream the thread mode shows a tree of messages, each node in the > > tree is a rendered message, that can be collapsed into a single-line > > summary; > > in my fork the thread mode is split-window - upper window for the tree > > with the thread structure, lower window for the currently selected > > message; no collapsing of messages > > - attachments can be rendered inline, possibly colored with pygments > > - git patches are colored with pygments > > - all the parts are rendered for multipart/mixed messages, as per the > > RFCs > > - encrypted/signed parts are now wrapped in a frame that indicates which > > bits of the message are actually encrypted or signed > > - various architectural restructurings which were needed for the above > > or to allow for future changes (I have a large TODO list left) > > This all sounds like getting closer to mutt's view, which is not a bad > thing at all! > > > The code is currently alpha quality - I am using it as my main MUA and > > it works for my workflow, but any features I don't use regularly may be > > broken. There is a general lack of "UX" polish (appearance and > > documentation). I didn't bother updating the test suite to keep up with > > all the architectural changes (plan to get to that once I consider the > > code more stable). > > I have to question this strategy. alot (upstream) suffers from a lack of > tests already. There is really no point writing tests after the fact or > once you discover bugs by chance. Especially if you go for "disruptive" > changes it's important to get the new architecture correct right from > the beginning. > > > I removed some features which I considered an > > impediment to progress and not worth the maintenance effort - YMMV. All this sounds very exciting and I'd be very happy to see these features in (mainline) alot! I agree that some of alot's underlying code is ready for refactoring and urwid in particular has been a big drag on quickly implementing things. Also, I'd be interested in hearing your thoughts on deprecating some "unworthy" features in order to reduce the maintenance effort! > > Why did I not submit all this as PRs to upstream alot? The main reasons > > were my lack of time and disagreement with the upstream about project > > status. From what I can tell, alot maintainers consider the project to > > be mature, so they prioritize stability and small incremental changes. > > From my perspective, alot is lacking some critical features -- some > > implemented in my fork already, some planned -- which makes it > > borderline-unusable for me. As implementing those features required > > large-scale architectural changes and my free time was quite limited, I > > prioritized quickly implementing the things I cared about over > > progressing in small incremental stable easily-reviewable steps. > > I have a similar impression about the project status. I'm curious: What > are the architectural changes that you made? Yes, the speed at which alot progresses is borderline problematic. This is of course down to the small number of core contributors and the fact that for all of us life goes on an priorities change. One problem is that the project attracts many users interested in pushing what I'd call "hotfixes" to address missing features: Often people would present a (nicely working) proof-of concept that is not well documented, tested, and doesn't adhere to common code conventions, only not to follow up on their promises to "clean things up", for all too understandable reasons. Still, I believe that just merging everything will quickly kill the project as a) this leads to code that is very difficult and time-consuming to maintain and b) broken features are very damaging to user's perception of the software, much more so than missing ones. I am not accusing you of anything here, Anton. I just wish to point out potential long term difficulties and clarify that I tried to err on the side of cautiousness to keep alot afloat in a usable state for most (potential) users. > > At this point my tree has over 200 new commits and some ~4k changed > > lines,
Re: Fixes for building with -DDEBUG
David Bremner writes: > The first patch is an attempt at fixing the build failure in the ruby > bindings. I'm not sure if this is an acceptable use of "env" or not. I > noticed that all of our shebangs use env, but I guess that is optional > in some sense. I belatedly checked, and POSIX env does not have -u ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 3/4] test: ignore debugging messages
Previously building with "-DDEBUG" broke the test suite in several places.
---
test/T300-encoding.sh | 12 ++--
test/T310-emacs.sh | 1 -
test/T450-emacs-show.sh | 1 -
test/test-lib.sh| 23 +++
4 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/test/T300-encoding.sh b/test/T300-encoding.sh
index 1e9d2a3d..6fcd10c5 100755
--- a/test/T300-encoding.sh
+++ b/test/T300-encoding.sh
@@ -31,18 +31,18 @@ test_expect_equal "$output" "thread:0002
2001-01-05 [1/1] Notmuch
test_begin_subtest "RFC 2047 encoded word with spaces"
add_message '[subject]="=?utf-8?q?encoded word with spaces?="'
-output=$(notmuch search id:${gen_msg_id} 2>&1 | notmuch_show_sanitize)
-test_expect_equal "$output" "thread:0003 2001-01-05 [1/1]
Notmuch Test Suite; encoded word with spaces (inbox unread)"
+output=$(notmuch search id:${gen_msg_id} 2>&1 | notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX 2001-01-05 [1/1] Notmuch Test Suite;
encoded word with spaces (inbox unread)"
test_begin_subtest "RFC 2047 encoded words back to back"
add_message '[subject]="=?utf-8?q?encoded-words-back?==?utf-8?q?to-back?="'
-output=$(notmuch search id:${gen_msg_id} 2>&1 | notmuch_show_sanitize)
-test_expect_equal "$output" "thread:0004 2001-01-05 [1/1]
Notmuch Test Suite; encoded-words-backto-back (inbox unread)"
+output=$(notmuch search id:${gen_msg_id} 2>&1 | notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX 2001-01-05 [1/1] Notmuch Test Suite;
encoded-words-backto-back (inbox unread)"
test_begin_subtest "RFC 2047 encoded words without space before or after"
add_message '[subject]="=?utf-8?q?encoded?=word without=?utf-8?q?space?=" '
-output=$(notmuch search id:${gen_msg_id} 2>&1 | notmuch_show_sanitize)
-test_expect_equal "$output" "thread:0005 2001-01-05 [1/1]
Notmuch Test Suite; encodedword withoutspace (inbox unread)"
+output=$(notmuch search id:${gen_msg_id} 2>&1 | notmuch_search_sanitize)
+test_expect_equal "$output" "thread:XXX 2001-01-05 [1/1] Notmuch Test Suite;
encodedword withoutspace (inbox unread)"
test_begin_subtest "Mislabeled Windows-1252 encoding"
add_message '[content-type]="text/plain; charset=iso-8859-1"'
\
diff --git a/test/T310-emacs.sh b/test/T310-emacs.sh
index 851ef64e..dad09b11 100755
--- a/test/T310-emacs.sh
+++ b/test/T310-emacs.sh
@@ -1058,7 +1058,6 @@ End of search results.
=== MESSAGES ===
YYY/notmuch_fail exited with status 1 (see *Notmuch errors* for more details)
=== ERROR ===
-[XXX]
YYY/notmuch_fail exited with status 1
command: YYY/notmuch_fail search --format\=sexp --format-version\=4
--sort\=newest-first tag\:inbox
exit status: 1"
diff --git a/test/T450-emacs-show.sh b/test/T450-emacs-show.sh
index bd76d378..52353bf4 100755
--- a/test/T450-emacs-show.sh
+++ b/test/T450-emacs-show.sh
@@ -190,7 +190,6 @@ test_expect_equal "$(notmuch_emacs_error_sanitize
notmuch_fail OUTPUT MESSAGES E
=== MESSAGES ===
This is an error (see *Notmuch errors* for more details)
=== ERROR ===
-[XXX]
This is an error
command: YYY/notmuch_fail show --format\\=sexp --format-version\\=4
--decrypt\\=true --exclude\\=false \\' \\* \\'
exit status: 1
diff --git a/test/test-lib.sh b/test/test-lib.sh
index d46bb4c3..69d9583c 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -637,6 +637,11 @@ print(msg.as_string(False))
' "$@"
}
+notmuch_debug_sanitize ()
+{
+grep -v '^D.:'
+}
+
notmuch_exception_sanitize ()
{
perl -pe 's/(A Xapian exception occurred at .*[.]cc?):([0-9]*)/\1:XXX/'
@@ -644,7 +649,7 @@ notmuch_exception_sanitize ()
notmuch_search_sanitize ()
{
-perl -pe 's/("?thread"?: ?)("?)("?)/\1\2XXX\3/'
+notmuch_debug_sanitize | perl -pe 's/("?thread"?:
?)("?)("?)/\1\2XXX\3/'
}
notmuch_search_files_sanitize ()
@@ -664,10 +669,11 @@ notmuch_show_sanitize ()
}
notmuch_show_sanitize_all ()
{
-sed \
- -e 's| filename:.*| filename:X|' \
- -e 's| id:[^ ]* | id:X |' | \
- notmuch_date_sanitize
+notmuch_debug_sanitize |
+ sed \
+ -e 's| filename:.*| filename:X|' \
+ -e 's| id:[^ ]* | id:X |' | \
+notmuch_date_sanitize
}
notmuch_json_show_sanitize ()
@@ -688,9 +694,10 @@ notmuch_emacs_error_sanitize ()
shift
for file in "$@"; do
echo "=== $file ==="
- cat "$file"
+ notmuch_debug_sanitize < "$file"
done | sed \
- -e 's/^\[.*\]$/[XXX]/' \
+ -e '/^$/d' \
+ -e '/^\[.*\]$/d' \
-e "s|^\(command: \)\{0,1\}/.*/$command|\1YYY/$command|"
}
@@ -1133,7 +1140,7 @@ test_C () {
echo "== stdout ==" > OUTPUT.stdout
echo "== stderr ==" > OUTPUT.stderr
./${exec_file} "$@" 1>>OUTPUT.stdout 2>>OUTPUT.stderr
-notmuch_dir_sanitize OUTPUT.stdout OUTPUT.stderr |
notmuch_exception_sanitize > OUTPUT
+notmuch_dir_sanitize OUTPUT.stdout
[PATCH 4/4] test: quiet some extra debugging output
This output does not cause test failures, but may make it harder to
interpret the output.
---
test/T140-excludes.sh| 2 +-
test/T380-atomicity.sh | 2 +-
test/T700-reindex.sh | 4 ++--
test/T750-user-header.sh | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/test/T140-excludes.sh b/test/T140-excludes.sh
index acab5381..7b5bea2e 100755
--- a/test/T140-excludes.sh
+++ b/test/T140-excludes.sh
@@ -22,7 +22,7 @@ generate_thread ()
done
notmuch new > /dev/null
# We cannot retrieve the thread_id until after we have run notmuch new.
-gen_thread_id=`notmuch search --output=threads id:${gen_thread_msg_id[0]}`
+gen_thread_id=$(notmuch search --output=threads id:${gen_thread_msg_id[0]}
2>/dev/null)
}
#
diff --git a/test/T380-atomicity.sh b/test/T380-atomicity.sh
index 45de2228..afe49d93 100755
--- a/test/T380-atomicity.sh
+++ b/test/T380-atomicity.sh
@@ -67,7 +67,7 @@ if test_require_external_prereq gdb; then
${TEST_GDB} -tty /dev/null -batch -x $NOTMUCH_SRCDIR/test/atomicity.py
notmuch 1>gdb.out 2>&1
# Get the final, golden output
-notmuch search '*' > expected
+notmuch search '*' 2>/dev/null > expected
# Check output against golden output
outcount=$(cat outcount)
diff --git a/test/T700-reindex.sh b/test/T700-reindex.sh
index f51130e8..52bba4d3 100755
--- a/test/T700-reindex.sh
+++ b/test/T700-reindex.sh
@@ -6,8 +6,8 @@ add_email_corpus
notmuch tag +usertag1 '*'
-notmuch search '*' | notmuch_search_sanitize > initial-threads
-notmuch search --output=messages '*' > initial-message-ids
+notmuch search '*' 2>1 | notmuch_search_sanitize > initial-threads
+notmuch search --output=messages '*' 2>/dev/null > initial-message-ids
notmuch dump > initial-dump
test_begin_subtest 'reindex preserves threads'
diff --git a/test/T750-user-header.sh b/test/T750-user-header.sh
index 05f80885..03c43656 100755
--- a/test/T750-user-header.sh
+++ b/test/T750-user-header.sh
@@ -4,8 +4,8 @@ test_description='indexing user specified headers'
add_email_corpus
-notmuch search '*' | notmuch_search_sanitize > initial-threads
-notmuch search --output=messages '*' > initial-message-ids
+notmuch search '*' 2>1 | notmuch_search_sanitize > initial-threads
+notmuch search --output=messages '*' 2>/dev/null > initial-message-ids
notmuch dump > initial-dump
test_begin_subtest "adding illegal prefix name, bad utf8"
--
2.30.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 1/4] bindings/ruby: unexport CFLAGS when building
This prevents breaking the ruby build when passing CFLAGS to other parts of the build. --- bindings/Makefile.local | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bindings/Makefile.local b/bindings/Makefile.local index bc960bbc..8e3cd051 100644 --- a/bindings/Makefile.local +++ b/bindings/Makefile.local @@ -10,7 +10,7 @@ ifeq ($(HAVE_RUBY_DEV),1) LIBNOTMUCH="../../lib/$(LINKER_NAME)" \ NOTMUCH_SRCDIR='$(NOTMUCH_SRCDIR)' \ $(RUBY) extconf.rb --vendor - $(MAKE) -C $(dir)/ruby + env -u CFLAGS $(MAKE) -C $(dir)/ruby endif python-cffi-bindings: lib/$(LINKER_NAME) -- 2.30.2 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[PATCH 2/4] lib/thread: add common prefix to debug messages, join lines
This will simplify filtering these message, e.g. in the test suite.
---
lib/thread.cc | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/lib/thread.cc b/lib/thread.cc
index 46a50e80..5ac0db6f 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -25,7 +25,7 @@
#include/* GHashTable */
#ifdef DEBUG_THREADING
-#define THREAD_DEBUG(format, ...) fprintf (stderr, format " (%s).\n",
##__VA_ARGS__, __location__)
+#define THREAD_DEBUG(format, ...) fprintf (stderr, "DT: " format " (%s).\n",
##__VA_ARGS__, __location__)
#else
#define THREAD_DEBUG(format, ...) do {} while (0) /* ignored */
#endif
@@ -400,7 +400,7 @@ _parent_via_in_reply_to (notmuch_thread_t *thread,
notmuch_message_t *message)
const char *in_reply_to;
in_reply_to = _notmuch_message_get_in_reply_to (message);
-THREAD_DEBUG ("checking message = %s in_reply_to=%s\n",
+THREAD_DEBUG ("checking message = %s in_reply_to=%s",
notmuch_message_get_message_id (message), in_reply_to);
if (in_reply_to && (! EMPTY_STRING (in_reply_to)) &&
@@ -423,31 +423,31 @@ _parent_or_toplevel (notmuch_thread_t *thread,
notmuch_message_t *message)
const notmuch_string_list_t *references =
_notmuch_message_get_references (message);
-THREAD_DEBUG ("trying to reparent via references: %s\n",
+THREAD_DEBUG ("trying to reparent via references: %s",
notmuch_message_get_message_id (message));
for (notmuch_string_node_t *ref_node = references->head;
ref_node; ref_node = ref_node->next) {
- THREAD_DEBUG ("checking reference=%s\n", ref_node->string);
+ THREAD_DEBUG ("checking reference=%s", ref_node->string);
if ((g_hash_table_lookup_extended (thread->message_hash,
ref_node->string, NULL,
(void **) &new_parent))) {
size_t new_depth = _notmuch_message_get_thread_depth (new_parent);
- THREAD_DEBUG ("got depth %lu\n", new_depth);
+ THREAD_DEBUG ("got depth %lu", new_depth);
if (new_depth > max_depth || ! parent) {
- THREAD_DEBUG ("adding at depth %lu parent=%s\n", new_depth,
ref_node->string);
+ THREAD_DEBUG ("adding at depth %lu parent=%s", new_depth,
ref_node->string);
max_depth = new_depth;
parent = new_parent;
}
}
}
if (parent) {
- THREAD_DEBUG ("adding reply %s to parent=%s\n",
+ THREAD_DEBUG ("adding reply %s to parent=%s",
notmuch_message_get_message_id (message),
notmuch_message_get_message_id (parent));
_notmuch_message_add_reply (parent, message);
} else {
- THREAD_DEBUG ("adding as toplevel %s\n",
+ THREAD_DEBUG ("adding as toplevel %s",
notmuch_message_get_message_id (message));
_notmuch_message_list_add_message (thread->toplevel_list, message);
}
@@ -482,13 +482,13 @@ _resolve_thread_relationships (notmuch_thread_t *thread)
*/
if (first_node) {
message = first_node->message;
- THREAD_DEBUG ("checking first message %s\n",
+ THREAD_DEBUG ("checking first message %s",
notmuch_message_get_message_id (message));
if (_notmuch_message_list_empty (maybe_toplevel_list) ||
! _parent_via_in_reply_to (thread, message)) {
- THREAD_DEBUG ("adding first message as toplevel = %s\n",
+ THREAD_DEBUG ("adding first message as toplevel = %s",
notmuch_message_get_message_id (message));
_notmuch_message_list_add_message (maybe_toplevel_list, message);
}
--
2.30.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Fixes for building with -DDEBUG
The first patch is an attempt at fixing the build failure in the ruby bindings. I'm not sure if this is an acceptable use of "env" or not. I noticed that all of our shebangs use env, but I guess that is optional in some sense. The remaining patches keep debugging output from disrupting the test suite. Apparently only thread debugging output is problematic currently. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH v2 2/6] test: more style fixes
Felipe Contreras writes: > In order to fit the git coding style. > > Signed-off-by: Felipe Contreras I personally prefer this style, but I have to point out that the C and C++ code in the code base (including the Ruby bindings) use the "brace-on-the-next-line" style. Should we strive for consistency with the C code, or is there some overriding concern here? Tomi mentioned compactness; is that more important for shell scripts? Whatever we decide, I guess it should be documented in test/README. For the record, I don't think restyling the rest of the codebase to match is a good option. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
announce: my fork of alot
Hi, Thought I'd share with the people here the fork of alot I've been hacking on for the past ~1.5 years, see if there is any interest in it. The code can be found at git://git.khirnov.net/alot. There are many changes in various places, the most user-visible ones in the thread view mode. Specifically - quoted blocks in the email body can now be colored and folded (this was probably my main motivation for starting all this) - in upstream the thread mode shows a tree of messages, each node in the tree is a rendered message, that can be collapsed into a single-line summary; in my fork the thread mode is split-window - upper window for the tree with the thread structure, lower window for the currently selected message; no collapsing of messages - attachments can be rendered inline, possibly colored with pygments - git patches are colored with pygments - all the parts are rendered for multipart/mixed messages, as per the RFCs - encrypted/signed parts are now wrapped in a frame that indicates which bits of the message are actually encrypted or signed - various architectural restructurings which were needed for the above or to allow for future changes (I have a large TODO list left) The code is currently alpha quality - I am using it as my main MUA and it works for my workflow, but any features I don't use regularly may be broken. There is a general lack of "UX" polish (appearance and documentation). I didn't bother updating the test suite to keep up with all the architectural changes (plan to get to that once I consider the code more stable). I removed some features which I considered an impediment to progress and not worth the maintenance effort - YMMV. Why did I not submit all this as PRs to upstream alot? The main reasons were my lack of time and disagreement with the upstream about project status. From what I can tell, alot maintainers consider the project to be mature, so they prioritize stability and small incremental changes. >From my perspective, alot is lacking some critical features -- some implemented in my fork already, some planned -- which makes it borderline-unusable for me. As implementing those features required large-scale architectural changes and my free time was quite limited, I prioritized quickly implementing the things I cared about over progressing in small incremental stable easily-reviewable steps. At this point my tree has over 200 new commits and some ~4k changed lines, so it's looking increasingly unlikely that I'll ever find the free time and motivation to upstream it -- especially given alot's glacial pace of development recently. If people are interested in using this, I'll probably fork it "properly" under a new name. Any comments or questions are very much welcome. I can also be reached on IRC as elenril. -- Anton Khirnov ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
