More ideas about logging.

[Austin Clements]

Quoth David Bremner on Dec 15 at 10:09 pm:
> Assume we have routines read_metadata and write_metadata that read and
> write to the xapian database metadata (in real life, I think we might
> need to decide in advance exactly what will be written there).
> 
> when we create a database
> 
> write_metadata('log_write',0)
> write_metadata('log_read',0) // more about this later
> 
> To carry out database operation X with logging, we do the following
> 
> begin_atomic
> 
> txn=read_metadata('last_written')
> 
> X
> 
> // begin dangerzone
> fprintf(logfile,"%d %s",num+1,stuff) // or whatever.
> 
> write_metadata('last_written', num+1)
> 
> end_atomic
> //end dangerzone

The trouble with this approach is that the OS doesn't have to flush
logfile to the disk platters in any particular order relative to the
updates to Xapian.  So, after someone trips over your plug, you could
come back with Xapian saying you have 500 log entries when your
logfile comes back with only 20.  The only way I know of to fix this
is to fsync after the logfile write, which would obviously have
performance issues.  But maybe there are cleverer ways?

[PATCH v3 2/4] emacs: Add a face for crypto parts headers

[David Bremner]

On Tue, 13 Dec 2011 18:32:10 +0100, Thomas Jost  
wrote:
> Commit cb841878 introduced new parts handlers for crypto parts, but also
> hardcoded values for their headers face. This replaces these hardcoded values
> with a customizable face.

pushed. and customized ;).

d

More ideas about logging.

[David Bremner]

Various discussions (mostly on IRC) from my jlog proposal, and a from
Thomas's mtime
(id:"1323796305-28789-1-git-send-email-schnouki at schnouki.net") proposal
got me thinking.  So let me know what you think about the following.

The goal here is to log tag adds and deletes (including those implicit
in message deletion) to facilitate tag synchonization.

If we use Xapian to store transaction numbers (much as the
last_thread_id is stored now), then we don't need an external logging
library. We can rely on the xapian to keep other clients from writing

Assume we have routines read_metadata and write_metadata that read and
write to the xapian database metadata (in real life, I think we might
need to decide in advance exactly what will be written there).

when we create a database

write_metadata('log_write',0)
write_metadata('log_read',0) // more about this later

To carry out database operation X with logging, we do the following

begin_atomic

txn=read_metadata('last_written')

X

// begin dangerzone
fprintf(logfile,"%d %s",num+1,stuff) // or whatever.

write_metadata('last_written', num+1)

end_atomic
//end dangerzone

If I understand correctly, then the only way the database and the log
can get out of sync is if this is interrupted in the "dangerzone"
between the start of the log write and the end of the xapian atomic
transaction. But then since we can consider the database authoritative
(since our goal is synchonization rather than recovery), we can discard
those portions of the log. We have to be a bit careful to discard
incomplete log items at the end of the log (maybe a checksum?).

So how do we discard? Two places. At the opening of the database for
writing, we truncate the log file (if we are very lazy, we can use seek
offsets as transaction indicies to facilitate this). 

In order to guarantee that log item is output exactly once, it seems
like we need another counter (or maybe I'm overthinking this)

 read_ptr = read_metadata('last_read')

 write_ptr = read_metadata('last_write')

 while (read_ptr < write_ptr) {
 begin_atomic
s = read(read_ptr)
do_stuff(s)
read_ptr++
write_metadata('log_read', read_ptr);
 end_atomic
 }

 write_metadata('log_write',0) // The log file will be truncated on
   // on db open
 write_metadata('log_read',0) 

I think we can double check if write_ptr <= read_ptr on next db open,
and truncate then if needed.

I think we need to assume that do_stuff is atomic here; I'm not sure how
reasonable or unreasonable that is in practice.

I also don't know about the performance implications of reading and
writing like maniac from the xapian metadata. Of course if this whole
scheme is fatally flawed, no need to worry about performance.

I don't think the actual amount of code involved would be too bad. Of
course, I thought was going to be a short message too.

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/20111215/8c031179/attachment.pgp>

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Thu, 15 Dec 2011 09:18:00 -0800, Jameson Graef Rollins  wrote:
> 
> Hey, David.  I think that notmuch-mua-mail is not the correct function.
> It works fine if you just use 'm' to invoke a new mail compose, which
> actually calls notmuch-mua-new-mail.
> 

I think the problem is related to emacsclient.

With 'm' I have the following behaviour:

emacs -q --daemon
M-x notmuch (to load variable definitions)
M-x customize-variable notmuch-mua-compose-in
(select compose in new window, save for current session)
M-x notmuch
m   ;; new window is opened as it should be
C-c C-c ;; frame is closed.

Error Running "notmuch new"

[Austin Clements]

Quoth Nathan Edson on Dec 15 at  2:08 pm:
> Hello,
> 
> I am running Ubuntu.  Here is what I get:
> 
> yabai at newb:~$ gdb --args notmuch new
> GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/bin/notmuch...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /usr/bin/notmuch new
> [Thread debugging using libthread_db enabled]
> 
> GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
> allocate 2147483648 bytes
> aborting...
> 
> Program received signal SIGABRT, Aborted.
> 0xb7fe1424 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7fe1424 in __kernel_vsyscall ()
> #1  0xb7ce7e71 in raise () from /lib/i386-linux-gnu/libc.so.6
> #2  0xb7ceb34e in abort () from /lib/i386-linux-gnu/libc.so.6
> #3  0xb7e8bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #4  0xb7e8bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #5  0xb7e89c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #6  0xb7e54965 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
> #7  0xb7e54d5d in g_array_append_vals () from 
> /lib/i386-linux-gnu/libglib-2.0.so.0
> #8  0xb7e560c0 in g_byte_array_append () from 
> /lib/i386-linux-gnu/libglib-2.0.so.0
> #9  0xb7f83c94 in ?? () from /usr/lib/libgmime-2.4.so.2
> #10 0xb7f84fbf in ?? () from /usr/lib/libgmime-2.4.so.2
> #11 0xb7f85761 in ?? () from /usr/lib/libgmime-2.4.so.2
> #12 0xb7f869ea in g_mime_parser_construct_message () from 
> /usr/lib/libgmime-2.4.so.2
> #13 0xb7fc40fd in ?? () from /usr/lib/libnotmuch.so.1
> #14 0xb7fc1a45 in notmuch_database_add_message () from 
> /usr/lib/libnotmuch.so.1
> #15 0x0804f521 in ?? ()
> #16 0x080501fe in ?? ()
> #17 0x0804c9c0 in ?? ()
> #18 0xb7cd3e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
> #19 0x0804ba91 in ?? ()
> (gdb) quit

Interesting.  So this is probably a gmime bug, but try running
$ strace -eopen notmuch new

Just before it aborts, you should see a line saying that it's opening
some message in your maildir.  If you can share that message, send the
message file as an attachment.  If you can share just the headers, but
not the body, that's probably enough.

Error Running "notmuch new"

[Nathan Edson]

On Thu, Dec 15, 2011 at 05:22:30PM -0500, Austin Clements wrote:
> Quoth Nathan Edson on Dec 15 at  2:08 pm:
> > Hello,
> > 
> > I am running Ubuntu.  Here is what I get:
> > 
> > yabai at newb:~$ gdb --args notmuch new
> > GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
> > Copyright (C) 2010 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > 
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "i686-linux-gnu".
> > For bug reporting instructions, please see:
> > ...
> > Reading symbols from /usr/bin/notmuch...(no debugging symbols found)...done.
> > (gdb) run
> > Starting program: /usr/bin/notmuch new
> > [Thread debugging using libthread_db enabled]
> > 
> > GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
> > allocate 2147483648 bytes
> > aborting...
> > 
> > Program received signal SIGABRT, Aborted.
> > 0xb7fe1424 in __kernel_vsyscall ()
> > (gdb) bt
> > #0  0xb7fe1424 in __kernel_vsyscall ()
> > #1  0xb7ce7e71 in raise () from /lib/i386-linux-gnu/libc.so.6
> > #2  0xb7ceb34e in abort () from /lib/i386-linux-gnu/libc.so.6
> > #3  0xb7e8bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
> > #4  0xb7e8bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
> > #5  0xb7e89c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0
> > #6  0xb7e54965 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
> > #7  0xb7e54d5d in g_array_append_vals () from 
> > /lib/i386-linux-gnu/libglib-2.0.so.0
> > #8  0xb7e560c0 in g_byte_array_append () from 
> > /lib/i386-linux-gnu/libglib-2.0.so.0
> > #9  0xb7f83c94 in ?? () from /usr/lib/libgmime-2.4.so.2
> > #10 0xb7f84fbf in ?? () from /usr/lib/libgmime-2.4.so.2
> > #11 0xb7f85761 in ?? () from /usr/lib/libgmime-2.4.so.2
> > #12 0xb7f869ea in g_mime_parser_construct_message () from 
> > /usr/lib/libgmime-2.4.so.2
> > #13 0xb7fc40fd in ?? () from /usr/lib/libnotmuch.so.1
> > #14 0xb7fc1a45 in notmuch_database_add_message () from 
> > /usr/lib/libnotmuch.so.1
> > #15 0x0804f521 in ?? ()
> > #16 0x080501fe in ?? ()
> > #17 0x0804c9c0 in ?? ()
> > #18 0xb7cd3e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
> > #19 0x0804ba91 in ?? ()
> > (gdb) quit
> 
> Interesting.  So this is probably a gmime bug, but try running
> $ strace -eopen notmuch new
> 
> Just before it aborts, you should see a line saying that it's opening
> some message in your maildir.  If you can share that message, send the
> message file as an attachment.  If you can share just the headers, but
> not the body, that's probably enough.

Hello, 
I didn't see it open a message.  Here it is:

yabai at newb:~$ strace -eopen notmuch new
open("/etc/ld.so.cache", O_RDONLY)  = 3
open("/usr/lib/libnotmuch.so.1", O_RDONLY) = 3
open("/usr/lib/libgmime-2.4.so.2", O_RDONLY) = 3
open("/usr/lib/i386-linux-gnu/libgobject-2.0.so.0", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libglib-2.0.so.0", O_RDONLY) = 3
open("/usr/lib/libtalloc.so.2", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libpthread.so.0", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libc.so.6", O_RDONLY) = 3
open("/usr/lib/sse2/libxapian.so.22", O_RDONLY) = 3
open("/usr/lib/i386-linux-gnu/libstdc++.so.6", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libgcc_s.so.1", O_RDONLY) = 3
open("/usr/lib/i386-linux-gnu/libgmodule-2.0.so.0", O_RDONLY) = 3
open("/usr/lib/i386-linux-gnu/libgthread-2.0.so.0", O_RDONLY) = 3
open("/lib/i386-linux-gnu/librt.so.1", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libz.so.1", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libnsl.so.1", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libpcre.so.3", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libuuid.so.1", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libm.so.6", O_RDONLY) = 3
open("/lib/i386-linux-gnu/libdl.so.2", O_RDONLY) = 3
open("/usr/lib/i386-linux-gnu/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY|O_LARGEFILE) = 3
open("/home/yabai/.notmuch-config", O_RDONLY|O_LARGEFILE) = 3
open("/home/yabai/Mail/.notmuch/xapian/flintlock", 
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
open("/home/yabai/Mail/.notmuch/xapian/iamchert", O_RDONLY|O_LARGEFILE) = 3
open("/home/yabai/Mail/.notmuch/xapian/record.DB", O_RDWR|O_LARGEFILE) = 3
open("/home/yabai/Mail/.notmuch/xapian/record.baseA", O_RDONLY|O_LARGEFILE) = 5
open("/home/yabai/Mail/.notmuch/xapian/record.baseB", O_RDONLY|O_LARGEFILE) = 5
open("/home/yabai/Mail/.notmuch/xapian/spelling.DB", O_RDWR|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
open("/home/yabai/Mail/.notmuch/xapian/synonym.DB", O_RDWR|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
open("/home/yabai/Mail/.notmuch/xapian/termlist.DB", O_RDWR|O_LARGEFILE) = 5
open("/home/yabai/Mail/.notmuch/xapian/termlist.baseA", 

Error Running "notmuch new"

[Nathan Edson]

On Thu, Dec 15, 2011 at 04:56:23PM -0500, Austin Clements wrote:
> Quoth David Bremner on Dec 15 at  5:46 pm:
> > On Thu, 15 Dec 2011 10:18:26 -0800, Nathan Edson  
> > wrote:
> > > When I run "notmuch new" I'm getting the following error:
> > > 
> > > Processed 1 files (0 files/sec.)
> > > GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
> > > allocate 2147483648 bytes
> > > aborting...
> > > Aborted
> > Hi Nathan;
> > 
> > That looks like debian/ubuntu. Can you tell us more about your
> > environment? The version of gmime is usually pretty important.
> 
> A backtrace would also be useful.  Something like
> 
> $ gdb --args notmuch new
> (gdb) run
> ... wait until it aborts
> (gdb) bt

Hello,

I am running Ubuntu.  Here is what I get:

yabai at newb:~$ gdb --args notmuch new
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/notmuch...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/notmuch new
[Thread debugging using libthread_db enabled]

GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
allocate 2147483648 bytes
aborting...

Program received signal SIGABRT, Aborted.
0xb7fe1424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7ce7e71 in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb7ceb34e in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xb7e8bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb7e8bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5  0xb7e89c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6  0xb7e54965 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7  0xb7e54d5d in g_array_append_vals () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
#8  0xb7e560c0 in g_byte_array_append () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
#9  0xb7f83c94 in ?? () from /usr/lib/libgmime-2.4.so.2
#10 0xb7f84fbf in ?? () from /usr/lib/libgmime-2.4.so.2
#11 0xb7f85761 in ?? () from /usr/lib/libgmime-2.4.so.2
#12 0xb7f869ea in g_mime_parser_construct_message () from 
/usr/lib/libgmime-2.4.so.2
#13 0xb7fc40fd in ?? () from /usr/lib/libnotmuch.so.1
#14 0xb7fc1a45 in notmuch_database_add_message () from /usr/lib/libnotmuch.so.1
#15 0x0804f521 in ?? ()
#16 0x080501fe in ?? ()
#17 0x0804c9c0 in ?? ()
#18 0xb7cd3e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#19 0x0804ba91 in ?? ()
(gdb) quit

[PATCH 3/3] test: add emacs test for hiding a message following an HTML part

[Tom Prince]

On Thu, 15 Dec 2011 08:14:08 -0400, David Bremner  wrote:
> On Mon,  4 Jul 2011 05:59:03 +0400, Dmitry Kurochkin  gmail.com> wrote:
> > Result: nothing happens except for "No URL at point" message
> > 
> > Expected result: the second message is shown/hidden
> 
> Unfortunately this patch is unreliable, reporting BROKEN for some
> environments and FIXED for others; I think you mentioned it depends
> on whether w3m-el is installed? I have reverted it for now to reduce the
> noise in the test logs.

Would a proper fix for this be to explicitly select which html renderer
is used, and then test it with each renderer in turn? If it is the
renderer that is causing the BROKEN/FIXED distinction, this would
trigger all possbile behaviors.

  Tom

the present and future of patch tracking for notmuch.

[David Bremner]

On Sun, 13 Nov 2011 10:53:40 -0400, David Bremner  wrote:
> - It would be nice if people without notmuch installed had access to the
>   information.  Some way to make html dumps of threads with tags would
>   do the trick, I believe. So far I am resisting the temptation to write
>   such a thing.

In the end I failed to resist this temptation. See 

   http://notmuchmail.org/nmbug/status/

Of course there could be more queries, nicer formatting, etc, etc...
Hint: the report generator source is on the wiki.

d

[PATCH] notmuch: unref charset_filter (once more) to fix one memory leak

[David Bremner]

On Tue, 13 Dec 2011 20:18:48 +0200, tomi.ollila at iki.fi wrote:
> From: Tomi Ollila 
> 
> In my test case added g_object_unref(charset_filter) reduces memory
> consumption over 90% when 'notmuch show --format=text "*"' is
> executed (~11000 messages, RES ~330M -> ~25M).

pushed

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Tue, 13 Dec 2011 18:32:09 +0100, Thomas Jost  
wrote:
> Reusing the current window to compose a new mail may be troublesome for the
> user. This patch introduces a new customizable variable, 
> notmuch-mua-compose-in,
> which lets the user choose where to create the mail buffer: in the current
> window (current and default behaviour), in a new window, or in a new frame.

There is something odd about the compose-in-new-frame support. If I run
M-x notmuch-mua-mail from within an initial frame, it doesn't create a
new frame but splits the current one. If I then run M-x notmuch, _that_
creates the new frame.

d

[PATCH v3 0/4] First step of 'show' rewrite

[David Bremner]

On Sun, 11 Dec 2011 14:41:50 +0400, Dmitry Kurochkin  wrote:

> I vote for pushing this series as soon as Austin finds it appropriate.
> If Austin makes a new version of this patch series with some of my
> comments fixed, it gets my auto-approve without another round of review :)

As discussed on IRC, we will basically follow this plan. Austin will
need to rebase anyway because of the hook patches.

d

[Alpha Patch 2/2] test: update dump-restore tests for 8 bit characters.

[Dmitry Kurochkin]

On Wed, 14 Dec 2011 16:14:01 -0400, David Bremner  wrote:
> From: David Bremner 
> 
> hex-escape: fix for handling of 8 bit chars
> 
> The low level problem was passing negative numbers to sprintf(s,"%x");
> we fix this and clarify the api for hex_(decode|encode) by making
> encode go from (unsigned char *) (i.e. 8bit) to (char *) and decode
> vise-versa.

I did not do a proper review.  But I think the encoder and decoder
should accept and return the same type, either char* or unsigned char*.
The decision should be based on what type strings (that would be fed to
the encoder and decoder) have in notmuch code.  I guess it is char*, so
the encoder and decoder should take and return char*.  Internally we
would cast char* to unsigned char*.

Also, I do not like the _octet typedef in hex-escape.c.  Having
different function parameters in header and .c is confusing.  IMO we
should either move the typedef to some header, or just use unsigned
char.

Regards,
  Dmitry

> ---
>  test/dump-restore |2 --
>  test/hex-escaping |1 -
>  util/hex-escape.c |   26 +++---
>  util/hex-escape.h |6 --
>  4 files changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/test/dump-restore b/test/dump-restore
> index eee1773..c5b2e86 100755
> --- a/test/dump-restore
> +++ b/test/dump-restore
> @@ -114,7 +114,6 @@ notmuch dump --format=notmuch > BACKUP
>  notmuch tag +"$tag1" +"$tag2" +"$tag3" -inbox -unread "*"
>  
>  test_begin_subtest 'format=notmuch, round trip with strange tags'
> -   test_subtest_known_broken
> notmuch dump --format=notmuch > EXPECTED.$test_count
> notmuch dump --format=notmuch | notmuch restore --format=notmuch
> notmuch dump --format=notmuch > OUTPUT.$test_count
> @@ -122,7 +121,6 @@ test_expect_equal_file EXPECTED.$test_count 
> OUTPUT.$test_count
>  
>  
>  test_begin_subtest 'format=notmuch, checking encoded output'
> -test_subtest_known_broken
>  cp /dev/null EXPECTED.$test_count
>  notmuch dump --format=notmuch -- from:cworth |\
>awk "{ print \$1 \" $enc1 $enc2 $enc3\" }" > EXPECTED.$test_count
> diff --git a/test/hex-escaping b/test/hex-escaping
> index 2053fb0..daa6446 100755
> --- a/test/hex-escaping
> +++ b/test/hex-escaping
> @@ -19,7 +19,6 @@ $TEST_DIRECTORY/hex-xcode e  < EXPECTED.$test_count |\
>  test_expect_equal_file EXPECTED.$test_count OUTPUT.$test_count
>  
>  test_begin_subtest "round trip 8bit chars"
> -test_subtest_known_broken
>  echo '%c3%91%c3%a5%c3%b0%c3%a3%c3%a5%c3%a9-%c3%8f%c3%8a' > 
> EXPECTED.$test_count
>  $TEST_DIRECTORY/hex-xcode d  < EXPECTED.$test_count |\
>   $TEST_DIRECTORY/hex-xcode e > OUTPUT.$test_count
> diff --git a/util/hex-escape.c b/util/hex-escape.c
> index dcf87cf..565ae99 100644
> --- a/util/hex-escape.c
> +++ b/util/hex-escape.c
> @@ -28,23 +28,24 @@ static const size_t default_buf_size=1024;
>  static const char* output_charset=
>  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+-_@=.:,";
>  
> -static const char escape_char='%';
> +static const int escape_char = '%';
>  
>  static int
>  is_output (char c) {
>  return (strchr (output_charset, c) != NULL);
>  }
>  
> +typedef unsigned char _octet;
>  
>  static int
> -maybe_realloc(void *ctx, size_t needed, char **out, size_t *out_size)
> +maybe_realloc(void *ctx, size_t needed, _octet **out, size_t *out_size)
>  {
>  if (*out_size < needed) {
>  
>   if (*out == NULL)
>   *out = talloc_size(ctx,needed);
>   else
> - *out = talloc_realloc(ctx,*out,char,needed);
> + *out = talloc_realloc(ctx, *out, _octet, needed);
>  
>   if (*out == NULL)
>   return 0;
> @@ -56,24 +57,27 @@ maybe_realloc(void *ctx, size_t needed, char **out, 
> size_t *out_size)
>  
>  
>  hex_status_t
> -hex_encode (void *ctx, const char *in, char **out, size_t *out_size)
> +hex_encode (void *ctx, const _octet *in, char **out, size_t *out_size)
>  {
>  
> -const char *p;
> +const _octet *p;
>  char *q;
>  
> -int escape_count=0;
> +size_t escape_count = 0;
> +size_t len = 0;
>  size_t needed;
>  
> -for  (p = in; *p; p++)
> +for  (p = in; *p; p++) {
>   escape_count += (! is_output (*p));
> + len++;
> +}
>  
> -needed = strlen (in) + 2*escape_count + 1;
> +needed = len + 2*escape_count + 1;
>  
>  if (*out == NULL)
>   *out_size=0;
>  
> -if (!maybe_realloc (ctx, needed, out, out_size))
> +if (!maybe_realloc (ctx, needed, (_octet**)out, out_size))
>   return HEX_OUT_OF_MEMORY;
>  
>  q = *out;
> @@ -94,12 +98,12 @@ hex_encode (void *ctx, const char *in, char **out, size_t 
> *out_size)
>  
>  
>  hex_status_t
> -hex_decode (void *ctx, const char *in, char **out, size_t *out_size) {
> +hex_decode (void *ctx, const char *in, _octet **out, size_t *out_size) {
>  
>  char buf[3];
>  
>  const char *p;
> -char *q;
> +_octet *q;
>  
>  size_t escape_count = 0;
>  size_t needed = 0;
> diff --git 

[PATCH v3] emacs: support "notmuch new" as a notmuch-poll-script

[David Bremner]

On Mon, 12 Dec 2011 22:50:04 +0200, Jani Nikula  wrote:
> Support nil value for notmuch-poll-script to run "notmuch new" instead of
> an external script, and make this the new default. "notmuch new" is run
> using the configured notmuch-command.

pushed.

d

[PATCH] debian: add upstream-tag and fix debian-tag configs for git-buildpackage

[David Bremner]

On Sun, 11 Dec 2011 17:21:09 -0800, Jameson Graef Rollins  wrote:
> Debian tags have been using '/', instead of '-' as a separator.

pushed

d

[Alpha PATCH 6/6] test: second set of dump/restore --format=notmuch tests

[Dmitry Kurochkin]

On Tue, 13 Dec 2011 16:27:55 -0400, David Bremner  wrote:
> From: David Bremner 
> 
> These one need the completed functionality in notmuch-restore. Fairly
> exotic tags are tested, but no weird message id's.
> ---
>  test/dump-restore |   33 +
>  1 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/test/dump-restore b/test/dump-restore
> index 48caf4e..122de5c 100755
> --- a/test/dump-restore
> +++ b/test/dump-restore
> @@ -94,4 +94,37 @@ notmuch dump --format=sup -- from:cworth | tr -d \(\) > 
> EXPECTED.$test_count
>  notmuch dump --format=notmuch -- from:cworth > OUTPUT.$test_count
>  test_expect_equal_file OUTPUT.$test_count EXPECTED.$test_count
>  
> +test_begin_subtest "format=notmuch, # round-trip"
> +notmuch dump --format=sup | sort > EXPECTED.$test_count
> +notmuch dump --format=notmuch | notmuch restore --format=notmuch
> +notmuch dump --format=sup | sort > OUTPUT.$test_count
> +test_expect_equal_file EXPECTED.$test_count OUTPUT.$test_count
> +
> +tag1='comic_swear=$&^%$^%\\//-+$^%$'
> +enc1=$($TEST_DIRECTORY/hex-xcode e "$tag1")
> +
> +tag2=$(printf 'this\n tag\t has\n spaces')
> +enc2=$($TEST_DIRECTORY/hex-xcode e "$tag2")
> +
> +notmuch dump --format=notmuch > BACKUP
> +
> +notmuch tag +"$tag1" +"$tag2" -inbox -unread "*"
> +
> +test_begin_subtest 'format=notmuch, round trip with strange tags'
> +   notmuch dump --format=notmuch > EXPECTED.$test_count
> +   notmuch dump --format=notmuch | notmuch restore --format=notmuch
> +   notmuch dump --format=notmuch > OUTPUT.$test_count

Noticed this while looking at the 8bit patch.  The indent offset should
be 4.

Regards,
  Dmitry

> +test_expect_equal_file EXPECTED.$test_count OUTPUT.$test_count
> +
> +
> +test_begin_subtest 'format=notmuch, checking encoded output'
> +cp /dev/null EXPECTED.$test_count
> +notmuch dump --format=notmuch -- from:cworth |\
> +  awk "{ print \$1 \" $enc1 $enc2\" }" > EXPECTED.$test_count
> +
> +notmuch dump --format=notmuch -- from:cworth  > OUTPUT.$test_count
> +test_expect_equal_file EXPECTED.$test_count OUTPUT.$test_count
> +
> +notmuch restore --format=notmuch < BACKUP
> +
>  test_done
> -- 
> 1.7.5.4
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 0/4] First step of 'show' rewrite

[David Bremner]

On Sun, 11 Dec 2011 14:41:50 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:

 I vote for pushing this series as soon as Austin finds it appropriate.
 If Austin makes a new version of this patch series with some of my
 comments fixed, it gets my auto-approve without another round of review :)

As discussed on IRC, we will basically follow this plan. Austin will
need to rebase anyway because of the hook patches.

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

Re: [PATCH] notmuch: unref charset_filter (once more) to fix one memory leak

[David Bremner]

On Tue, 13 Dec 2011 20:18:48 +0200, tomi.oll...@iki.fi wrote:
 From: Tomi Ollila tomi.oll...@iki.fi
 
 In my test case added g_object_unref(charset_filter) reduces memory
 consumption over 90% when 'notmuch show --format=text *' is
 executed (~11000 messages, RES ~330M - ~25M).

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

Re: the present and future of patch tracking for notmuch.

[David Bremner]

On Sun, 13 Nov 2011 10:53:40 -0400, David Bremner da...@tethera.net wrote:
 - It would be nice if people without notmuch installed had access to the
   information.  Some way to make html dumps of threads with tags would
   do the trick, I believe. So far I am resisting the temptation to write
   such a thing.

In the end I failed to resist this temptation. See 

   http://notmuchmail.org/nmbug/status/

Of course there could be more queries, nicer formatting, etc, etc...
Hint: the report generator source is on the wiki.

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

Re: [PATCH 3/3] test: add emacs test for hiding a message following an HTML part

[David Bremner]

On Mon,  4 Jul 2011 05:59:03 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 Result: nothing happens except for No URL at point message
 
 Expected result: the second message is shown/hidden

Unfortunately this patch is unreliable, reporting BROKEN for some
environments and FIXED for others; I think you mentioned it depends
on whether w3m-el is installed? I have reverted it for now to reduce the
noise in the test logs.

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

Notmuch for Christmas

[David Bremner]

As some of you might remember, I plan to freeze around December 25 for
the release of 0.11

If you have something you think should be there, feel free to ping me
about it, or tag the patch as notmuch::0.11 in nmbug [1]. Ideally something
proposed for 0.11 should already have a few reviews.

d

[1]: http://notmuchmail.org/nmbug



pgpOzocjim3Ro.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[Jameson Graef Rollins]

On Thu, 15 Dec 2011 07:27:24 -0400, David Bremner da...@tethera.net wrote:
 There is something odd about the compose-in-new-frame support. If I run
 M-x notmuch-mua-mail from within an initial frame, it doesn't create a
 new frame but splits the current one. If I then run M-x notmuch, _that_
 creates the new frame.

Hey, David.  I think that notmuch-mua-mail is not the correct function.
It works fine if you just use 'm' to invoke a new mail compose, which
actually calls notmuch-mua-new-mail.

I've been using this patch and it works quite well, particularly if you
set message-kill-buffer-on-exit.

jamie.


pgpcqw4tzqP4B.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Fix build with binutils-2.22

[Thomas Jost]

binutils-2.22 changes the behaviour of ld by defaulting to
--no-copy-dt-needed-entries, which means that required objects/libs are not
indirectly linked through intermediate objects/libs anymore. As a consequence,
when using binutils-2.22, building symbol-test fails with the following error:

/usr/bin/ld: test/symbol-test.o: undefined reference to symbol
'std::basic_stringchar, std::char_traitschar, std::allocatorchar
::~basic_string()@@GLIBCXX_3.4'

/usr/bin/ld: note: 'std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::~basic_string()@@GLIBCXX_3.4' is defined in DSO
/usr/lib/libstdc++.so.6 so try adding it to the linker command line

/usr/lib/libstdc++.so.6: could not read symbols: Invalid operation

An easy fix is to link using CXX instead of CC.
---
Hi there,

This build issue happens on Arch Linux. For more details, the relevant binutils
changelog is here: http://ur1.ca/6px8j, and more explanations are available on
the Fedora wiki: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
(People who read the arch-general ML may want to read the thread starting at
id:1323458274-sup-9064@eris.)

Best regards,
Thomas

 test/Makefile.local |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/test/Makefile.local b/test/Makefile.local
index 6cb6c82..fa2df73 100644
--- a/test/Makefile.local
+++ b/test/Makefile.local
@@ -17,7 +17,7 @@ $(dir)/smtp-dummy: $(smtp_dummy_modules)
$(call quiet,CC) $^ -o $@
 
 $(dir)/symbol-test: $(dir)/symbol-test.o
-   $(call quiet,CC) $^ -o $@ -Llib -lnotmuch -lxapian
+   $(call quiet,CXX) $^ -o $@ -Llib -lnotmuch -lxapian
 
 .PHONY: test check
 
-- 
1.7.8

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

Error Running notmuch new

[Nathan Edson]

I'm having a problem using notmuch.

When I run notmuch new I'm getting the following error:

Processed 1 files (0 files/sec.)
GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
allocate 2147483648 bytes
aborting...
Aborted

Any ideas or tips?  

Thanks!
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Error Running notmuch new

[Austin Clements]

Quoth Nathan Edson on Dec 15 at  2:08 pm:
 Hello,
 
 I am running Ubuntu.  Here is what I get:
 
 yabai@newb:~$ gdb --args notmuch new
 GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
 Copyright (C) 2010 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as i686-linux-gnu.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /usr/bin/notmuch...(no debugging symbols found)...done.
 (gdb) run
 Starting program: /usr/bin/notmuch new
 [Thread debugging using libthread_db enabled]
 
 GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
 allocate 2147483648 bytes
 aborting...
 
 Program received signal SIGABRT, Aborted.
 0xb7fe1424 in __kernel_vsyscall ()
 (gdb) bt
 #0  0xb7fe1424 in __kernel_vsyscall ()
 #1  0xb7ce7e71 in raise () from /lib/i386-linux-gnu/libc.so.6
 #2  0xb7ceb34e in abort () from /lib/i386-linux-gnu/libc.so.6
 #3  0xb7e8bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
 #4  0xb7e8bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
 #5  0xb7e89c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0
 #6  0xb7e54965 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
 #7  0xb7e54d5d in g_array_append_vals () from 
 /lib/i386-linux-gnu/libglib-2.0.so.0
 #8  0xb7e560c0 in g_byte_array_append () from 
 /lib/i386-linux-gnu/libglib-2.0.so.0
 #9  0xb7f83c94 in ?? () from /usr/lib/libgmime-2.4.so.2
 #10 0xb7f84fbf in ?? () from /usr/lib/libgmime-2.4.so.2
 #11 0xb7f85761 in ?? () from /usr/lib/libgmime-2.4.so.2
 #12 0xb7f869ea in g_mime_parser_construct_message () from 
 /usr/lib/libgmime-2.4.so.2
 #13 0xb7fc40fd in ?? () from /usr/lib/libnotmuch.so.1
 #14 0xb7fc1a45 in notmuch_database_add_message () from 
 /usr/lib/libnotmuch.so.1
 #15 0x0804f521 in ?? ()
 #16 0x080501fe in ?? ()
 #17 0x0804c9c0 in ?? ()
 #18 0xb7cd3e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
 #19 0x0804ba91 in ?? ()
 (gdb) quit

Interesting.  So this is probably a gmime bug, but try running
$ strace -eopen notmuch new

Just before it aborts, you should see a line saying that it's opening
some message in your maildir.  If you can share that message, send the
message file as an attachment.  If you can share just the headers, but
not the body, that's probably enough.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Error Running notmuch new

[Nathan Edson]

On Thu, Dec 15, 2011 at 04:56:23PM -0500, Austin Clements wrote:
 Quoth David Bremner on Dec 15 at  5:46 pm:
  On Thu, 15 Dec 2011 10:18:26 -0800, Nathan Edson ned...@nedson.net wrote:
   When I run notmuch new I'm getting the following error:
   
   Processed 1 files (0 files/sec.)
   GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
   allocate 2147483648 bytes
   aborting...
   Aborted
  Hi Nathan;
  
  That looks like debian/ubuntu. Can you tell us more about your
  environment? The version of gmime is usually pretty important.
 
 A backtrace would also be useful.  Something like
 
 $ gdb --args notmuch new
 (gdb) run
 ... wait until it aborts
 (gdb) bt

Hello,

I am running Ubuntu.  Here is what I get:

yabai@newb:~$ gdb --args notmuch new
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i686-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/notmuch...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/notmuch new
[Thread debugging using libthread_db enabled]

GLib-ERROR **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to 
allocate 2147483648 bytes
aborting...

Program received signal SIGABRT, Aborted.
0xb7fe1424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe1424 in __kernel_vsyscall ()
#1  0xb7ce7e71 in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xb7ceb34e in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xb7e8bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb7e8bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
#5  0xb7e89c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0
#6  0xb7e54965 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#7  0xb7e54d5d in g_array_append_vals () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
#8  0xb7e560c0 in g_byte_array_append () from 
/lib/i386-linux-gnu/libglib-2.0.so.0
#9  0xb7f83c94 in ?? () from /usr/lib/libgmime-2.4.so.2
#10 0xb7f84fbf in ?? () from /usr/lib/libgmime-2.4.so.2
#11 0xb7f85761 in ?? () from /usr/lib/libgmime-2.4.so.2
#12 0xb7f869ea in g_mime_parser_construct_message () from 
/usr/lib/libgmime-2.4.so.2
#13 0xb7fc40fd in ?? () from /usr/lib/libnotmuch.so.1
#14 0xb7fc1a45 in notmuch_database_add_message () from /usr/lib/libnotmuch.so.1
#15 0x0804f521 in ?? ()
#16 0x080501fe in ?? ()
#17 0x0804c9c0 in ?? ()
#18 0xb7cd3e37 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#19 0x0804ba91 in ?? ()
(gdb) quit

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

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

On Thu, 15 Dec 2011 09:18:00 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 
 Hey, David.  I think that notmuch-mua-mail is not the correct function.
 It works fine if you just use 'm' to invoke a new mail compose, which
 actually calls notmuch-mua-new-mail.
 

I think the problem is related to emacsclient.

With 'm' I have the following behaviour:

emacs -q --daemon
M-x notmuch (to load variable definitions)
M-x customize-variable notmuch-mua-compose-in
(select compose in new window, save for current session)
M-x notmuch
m   ;; new window is opened as it should be
C-c C-c ;; frame is closed.



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

Re: [PATCH v3 2/4] emacs: Add a face for crypto parts headers

[Dmitry Kurochkin]

On Tue, 13 Dec 2011 18:32:10 +0100, Thomas Jost schno...@schnouki.net wrote:
 Commit cb841878 introduced new parts handlers for crypto parts, but also
 hardcoded values for their headers face. This replaces these hardcoded values
 with a customizable face.
 ---

Looks good to me.

Regards,
  Dmitry

  emacs/notmuch-crypto.el |5 +
  emacs/notmuch-show.el   |4 ++--
  2 files changed, 7 insertions(+), 2 deletions(-)
 
 diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
 index 44fccae..67c26af 100644
 --- a/emacs/notmuch-crypto.el
 +++ b/emacs/notmuch-crypto.el
 @@ -37,6 +37,11 @@ mode.
:group 'notmuch
:type 'boolean)
  
 +(defface notmuch-crypto-part-header
 +  '((t (:foreground blue)))
 +  Face used for crypto parts headers.
 +  :group 'notmuch)
 +
  (defface notmuch-crypto-signature-good
'((t (:background green :foreground black)))
Face used for good signatures.
 diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
 index 33ee3d8..ec9c52c 100644
 --- a/emacs/notmuch-show.el
 +++ b/emacs/notmuch-show.el
 @@ -457,7 +457,7 @@ current buffer, if possible.
  
  (defun notmuch-show-insert-part-multipart/signed (msg part content-type nth 
 depth declared-type)
(let ((button (notmuch-show-insert-part-header nth declared-type 
 content-type nil)))
 -(button-put button 'face '(:foreground blue))
 +(button-put button 'face 'notmuch-crypto-part-header)
  ;; add signature status button if sigstatus provided
  (if (plist-member part :sigstatus)
   (let* ((from (notmuch-show-get-header :From msg))
 @@ -479,7 +479,7 @@ current buffer, if possible.
  
  (defun notmuch-show-insert-part-multipart/encrypted (msg part content-type 
 nth depth declared-type)
(let ((button (notmuch-show-insert-part-header nth declared-type 
 content-type nil)))
 -(button-put button 'face '(:foreground blue))
 +(button-put button 'face 'notmuch-crypto-part-header)
  ;; add encryption status button if encstatus specified
  (if (plist-member part :encstatus)
   (let ((encstatus (car (plist-get part :encstatus
 -- 
 1.7.8
 
 ___
 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 3/4] emacs: rename notmuch-decimal-separator to notmuch-thousands-separator

[Dmitry Kurochkin]

On Tue, 13 Dec 2011 18:32:11 +0100, Thomas Jost schno...@schnouki.net wrote:
 In 123,456.78, . is the decimal separator, but , is the thousands 
 separator.
 
 This commit also mentions the space being used as thousands separator in 
 several
 European countries.
 ---

What do perople think about making the thousands separator a space by
default?

  emacs/notmuch-hello.el |8 
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 0582cae..0fe9c1d 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -131,10 +131,10 @@ So:
 (integer :tag Number of characters)
 (float :tag Fraction of window)))
  
 -(defcustom notmuch-decimal-separator ,
 -  The string used as a decimal separator.
 +(defcustom notmuch-thousands-separator ,
 +  The string used as a thousands separator.

I suggest renaming this to notmuch-hello-thousands-separator.

Looks good otherwise.

Regards,
  Dmitry

  
 -Typically \,\ in the US and UK and \.\ in Europe.
 +Typically \,\ in the US and UK and \.\ or \ \ in Europe.
:group 'notmuch
:type 'string)
  
 @@ -159,7 +159,7 @@ Typically \,\ in the US and UK and \.\ in Europe.
  (apply #'concat
   (number-to-string (car result))
   (mapcar (lambda (elem)
 -   (format %s%03d notmuch-decimal-separator elem))
 +   (format %s%03d notmuch-thousands-separator elem))
(cdr result)
  
  (defun notmuch-hello-trim (search)
 -- 
 1.7.8
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

More ideas about logging.

[David Bremner]

Various discussions (mostly on IRC) from my jlog proposal, and a from
Thomas's mtime
(id:1323796305-28789-1-git-send-email-schno...@schnouki.net) proposal
got me thinking.  So let me know what you think about the following.

The goal here is to log tag adds and deletes (including those implicit
in message deletion) to facilitate tag synchonization.

If we use Xapian to store transaction numbers (much as the
last_thread_id is stored now), then we don't need an external logging
library. We can rely on the xapian to keep other clients from writing

Assume we have routines read_metadata and write_metadata that read and
write to the xapian database metadata (in real life, I think we might
need to decide in advance exactly what will be written there).

when we create a database

write_metadata('log_write',0)
write_metadata('log_read',0) // more about this later

To carry out database operation X with logging, we do the following

begin_atomic

txn=read_metadata('last_written')

X

// begin dangerzone
fprintf(logfile,%d %s,num+1,stuff) // or whatever.

write_metadata('last_written', num+1)

end_atomic
//end dangerzone

If I understand correctly, then the only way the database and the log
can get out of sync is if this is interrupted in the dangerzone
between the start of the log write and the end of the xapian atomic
transaction. But then since we can consider the database authoritative
(since our goal is synchonization rather than recovery), we can discard
those portions of the log. We have to be a bit careful to discard
incomplete log items at the end of the log (maybe a checksum?).

So how do we discard? Two places. At the opening of the database for
writing, we truncate the log file (if we are very lazy, we can use seek
offsets as transaction indicies to facilitate this). 

In order to guarantee that log item is output exactly once, it seems
like we need another counter (or maybe I'm overthinking this)

 read_ptr = read_metadata('last_read')

 write_ptr = read_metadata('last_write')
 
 while (read_ptr  write_ptr) {
 begin_atomic
s = read(read_ptr)
do_stuff(s)
read_ptr++
write_metadata('log_read', read_ptr);
 end_atomic
 }

 write_metadata('log_write',0) // The log file will be truncated on
   // on db open
 write_metadata('log_read',0) 

I think we can double check if write_ptr = read_ptr on next db open,
and truncate then if needed.

I think we need to assume that do_stuff is atomic here; I'm not sure how
reasonable or unreasonable that is in practice.

I also don't know about the performance implications of reading and
writing like maniac from the xapian metadata. Of course if this whole
scheme is fatally flawed, no need to worry about performance.

I don't think the actual amount of code involved would be too bad. Of
course, I thought was going to be a short message too.

d



pgpm6UusVzIeY.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 2/4] emacs: Add a face for crypto parts headers

[David Bremner]

On Tue, 13 Dec 2011 18:32:10 +0100, Thomas Jost schno...@schnouki.net wrote:
 Commit cb841878 introduced new parts handlers for crypto parts, but also
 hardcoded values for their headers face. This replaces these hardcoded values
 with a customizable face.

pushed. and customized ;).

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

Re: More ideas about logging.

[Austin Clements]

Quoth David Bremner on Dec 15 at 10:09 pm:
 Assume we have routines read_metadata and write_metadata that read and
 write to the xapian database metadata (in real life, I think we might
 need to decide in advance exactly what will be written there).
 
 when we create a database
 
 write_metadata('log_write',0)
 write_metadata('log_read',0) // more about this later
 
 To carry out database operation X with logging, we do the following
 
 begin_atomic
 
 txn=read_metadata('last_written')
 
 X
 
 // begin dangerzone
 fprintf(logfile,%d %s,num+1,stuff) // or whatever.
 
 write_metadata('last_written', num+1)
 
 end_atomic
 //end dangerzone

The trouble with this approach is that the OS doesn't have to flush
logfile to the disk platters in any particular order relative to the
updates to Xapian.  So, after someone trips over your plug, you could
come back with Xapian saying you have 500 log entries when your
logfile comes back with only 20.  The only way I know of to fix this
is to fsync after the logfile write, which would obviously have
performance issues.  But maybe there are cleverer ways?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Fix build with binutils-2.22

[Tomi Ollila]

On Thu, 15 Dec 2011 20:41:58 +0100, Thomas Jost schno...@schnouki.net wrote:
 binutils-2.22 changes the behaviour of ld by defaulting to
 --no-copy-dt-needed-entries, which means that required objects/libs are not
 indirectly linked through intermediate objects/libs anymore. As a 
 consequence,
 when using binutils-2.22, building symbol-test fails with the following error:
 
 /usr/bin/ld: test/symbol-test.o: undefined reference to symbol
 'std::basic_stringchar, std::char_traitschar, std::allocatorchar
 ::~basic_string()@@GLIBCXX_3.4'
 
 /usr/bin/ld: note: 'std::basic_stringchar, std::char_traitschar,
 std::allocatorchar ::~basic_string()@@GLIBCXX_3.4' is defined in DSO
 /usr/lib/libstdc++.so.6 so try adding it to the linker command line
 
 /usr/lib/libstdc++.so.6: could not read symbols: Invalid operation
 
 An easy fix is to link using CXX instead of CC.
 ---

+1 -- LGTM, Works for me (hits also on Fedora 15). Interesting that gcc
does not fully default to g++ behaviour when source file is symbol-test.cc

Tomi

 Hi there,
 
 This build issue happens on Arch Linux. For more details, the relevant 
 binutils
 changelog is here: http://ur1.ca/6px8j, and more explanations are available on
 the Fedora wiki: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
 (People who read the arch-general ML may want to read the thread starting at
 id:1323458274-sup-9064@eris.)
 
 Best regards,
 Thomas
 
  test/Makefile.local |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/test/Makefile.local b/test/Makefile.local
 index 6cb6c82..fa2df73 100644
 --- a/test/Makefile.local
 +++ b/test/Makefile.local
 @@ -17,7 +17,7 @@ $(dir)/smtp-dummy: $(smtp_dummy_modules)
   $(call quiet,CC) $^ -o $@
  
  $(dir)/symbol-test: $(dir)/symbol-test.o
 - $(call quiet,CC) $^ -o $@ -Llib -lnotmuch -lxapian
 + $(call quiet,CXX) $^ -o $@ -Llib -lnotmuch -lxapian
  
  .PHONY: test check
  
 -- 
 1.7.8
 
 ___
 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: More ideas about logging.

[Michael Hudson-Doyle]

On Thu, 15 Dec 2011 22:09:08 -0400, David Bremner brem...@debian.org wrote:
 Various discussions (mostly on IRC) from my jlog proposal, and a from
 Thomas's mtime
 (id:1323796305-28789-1-git-send-email-schno...@schnouki.net) proposal
 got me thinking.  So let me know what you think about the following.

 The goal here is to log tag adds and deletes (including those implicit
 in message deletion) to facilitate tag synchonization.

It's a tangent, but would this sort of thing allow a undo last tagging
operation command in emacs?

Cheers,
mwh
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch