Decryption fails

2011-05-30 Thread Felix Geller
Hi all,

I'm using a version of notmuch based on cb84187 from the master branch
on notmuchmail.org/git/notmuch and am accessing it mostly through the
Emacs UI. Signature verification seems to work nicely, only decryption
fails for any message/thread that I've tried it on. The respective
notmuch process 
notmuch show --format=json --decrypt 'id:x' 
starts eating all my CPU and doesn't return. Doing it on the command
line using gpg directly or going through Emacs' epa works fine. Most of
the test cases in crypto fail as well, but I'm not sure which ones are
actually supposed to work.

My OS is MacOS X, which seems to be non-existent among notmuch
developers and therefore might at some level be the cause. However, I
built gmime 2.4.24 (through a little modification to MacPorts'
respective Portfile) as was recommended on IRC at some point and am not
aware of any other incompatibilities.

I'm not sure how to identify the cause for this problem, do you have any
hints where to start searching?


Cheers,
Felix
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110530/3cb33256/attachment.pgp>


one-time-iterators

2011-05-30 Thread Austin Clements
Quoth Patrick Totzke on May 28 at  9:58 am:
> Excerpts from Austin Clements's message of Fri May 27 20:29:24 +0100 2011:
> > On Fri, May 27, 2011 at 2:04 PM, Patrick Totzke
> >  wrote:
> > > Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 2011:
> > >> >> > > Have you tried simply calling list() on your thread
> > >> >> > > iterator to see how expensive it is? ?My bet is that it's quite 
> > >> >> > > cheap,
> > >> >> > > both memory-wise and CPU-wise.
> > >> >> > Funny thing:
> > >> >> > ?q=Database().create_query('*')
> > >> >> > ?time tlist = list(q.search_threads())
> > >> >> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some 
> > >> >> > reason
> > >> >> > the list constructor must read mere than once from the iterator.
> > >> >> > So this is not an option, but even if it worked, it would show
> > >> >> > the same behaviour as my above test..
> > >> >>
> > >> >> Interesting. ?Looks like the Threads class implements __len__ and that
> > >> >> its implementation exhausts the iterator. ?Which isn't a great idea in
> > >> >> itself, but it turns out that Python's implementation of list() calls
> > >> >> __len__ if it's available (presumably to pre-size the list) before
> > >> >> iterating over the object, so it exhausts the iterator before even
> > >> >> using it.
> > >> >>
> > >> >> That said, if list(q.search_threads()) did work, it wouldn't give you
> > >> >> better performance than your experiment above.
> > > true. Nevertheless I think that list(q.search_threads())
> > > should be equivalent to [t for t in q.search_threads()], which is
> > > something to be fixed in the bindings. Should I file an issue somehow?
> > > Or is enough to state this as a TODO here on the list?
> > 
> > Yes, they should be equivalent.
> > 
> > Sebastian was thinking about fixing the larger issue of generator
> > exhaustion, which would address this, though the performance would
> > depend on the cost of iterating twice.  This is why generators
> > shouldn't support __len__.  Unfortunately, it's probably hard to get
> > rid of at this point and I doubt there's a way to tell list() to
> > overlook the presence of a __len__ method.
> Why not simply removing support for __len__ in the Threads and Messages 
> classes?

Presumably len is there because things use it.  On the other hand,
given the issues surrounding len, I suspect anything that's using it
is already a mess.

> > >> >> > would it be very hard to implement a Query.search_thread_ids() ?
> > >> >> > This name is a bit off because it had to be done on a lower level.
> > >> >>
> > >> >> Lazily fetching the thread metadata on the C side would probably
> > >> >> address your problem automatically. ?But what are you doing that
> > >> >> doesn't require any information about the threads you're manipulating?
> > >> > Agreed. Unfortunately, there seems to be no way to get a list of thread
> > >> > ids or a reliable iterator thereof by using the current python 
> > >> > bindings.
> > >> > It would be enough for me to have the ids because then I could
> > >> > search for the few threads I actually need individually on demand.
> > >>
> > >> There's no way to do that from the C API either, so don't feel left
> > >> out. ?]:--8) ?It seems to me that the right solution to your problem
> > >> is to make thread information lazy (effectively, everything gathered
> > >> in lib/thread.cc:_thread_add_message). ?Then you could probably
> > >> materialize that iterator cheaply.
> > > Alright. I'll put this on my mental notmuch wish list and
> > > hope that someone will have addressed this before I run out of
> > > ideas how to improve my UI and have time to look at this myself.
> > > For now, I go with the [t.get_thread_id for t in q.search_threads()]
> > > approach to cache the thread ids myself and live with the fact that
> > > this takes time for large result sets.
> > >
> > >> In fact, it's probably worth
> > >> trying a hack where you put dummy information in the thread object
> > >> from _thread_add_message and see how long it takes just to walk the
> > >> iterator (unfortunately I don't think profiling will help much here
> > >> because much of your time is probably spent waiting for I/O).
> > > I don't think I understand what you mean by dummy info in a thread
> > > object.
> > 
> > In _thread_add_message, rather than looking up the message's author,
> > subject, etc, just hard-code some dummy values.  Performance-wise,
> > this would simulate making the thread metadata lookup lazy, so you
> > could see if making this lazy would address your problem.
> Thanks for the clarification. I did that, and also commented out the
> lower parts of _notmuch_thread_create and this did indeed improve
> the performance, but not so much as I had hoped:
> 
> In [10]: q=Database().create_query('*')
> In [11]: time T=[t for t in q.search_threads()]
> CPU times: user 2.43 s, sys: 0.22 s, total: 2.65 s
> Wall time: 2.66 s
> 
> And I have only about 8000 mails in my 

Decryption fails

2011-05-30 Thread David Bremner
On Mon, 30 May 2011 21:30:03 +0200, Felix Geller  wrote:

> starts eating all my CPU and doesn't return. Doing it on the command
> line using gpg directly or going through Emacs' epa works fine. Most of
> the test cases in crypto fail as well, but I'm not sure which ones are
> actually supposed to work.

I can't help much with MacOS X, but all of the test cases should work
with gmime 2.4.24 (at least they do for people on Debian).

d


[PATCH] Change in increment_mtime for BSD compatibility of test suite

2011-05-30 Thread Felix Geller
 # additionally to the file test-results/$BASENAME.out, too.
 case "$GIT_TEST_TEE_STARTED, $* " in
@@ -214,14 +217,6 @@ remove_cr () {
 }

 # Notmuch helper functions
-increment_mtime_amount=0
-increment_mtime ()
-{
-dir="$1"
-
-increment_mtime_amount=$((increment_mtime_amount + 1))
-touch -d "+${increment_mtime_amount} seconds" "$dir"
-}

 # Generate a new message in the mail directory, with a unique message
 # ID and subject. The message is not added to the index.
@@ -514,7 +509,7 @@ NOTMUCH_NEW ()

 notmuch_search_sanitize ()
 {
-sed -r -e 's/("?thread"?: ?)("?)("?)/\1\2XXX\3/'
+$SED_EXTENDED 's/("?thread"?: ?)("?)("?)/\1\2XXX\3/'
 }

 NOTMUCH_SHOW_FILENAME_SQUELCH='s,filename:.*/mail,filename:/XXX/mail,'
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110530/f3fbf82c/attachment.pgp>


compile error of current git on F15

2011-05-30 Thread Jameson Graef Rollins
On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel  
wrote:
> CC -O2 notmuch-reply.o
> notmuch-reply.c: In function ?notmuch_reply_command?:
> notmuch-reply.c:658:3: error: unknown type name ?GMimeSession?
> notmuch-reply.c:659:3: warning: passing argument 1 of 
> ?g_mime_gpg_context_new? from incompatible pointer type [enabled by default]
> /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
> ?GMimePasswordRequestFunc? but argument is of type ?int *?
> make: *** [notmuch-reply.o] Error 1
> 
> This seems to have been introduced in Jameson's crypto patch series...
> 
> ./configure shows:
> 
> Checking for Xapian development files... Yes (1.2.4).
> Checking for GMime development files... Yes (gmime-2.6).
> Checking for Glib development files (>= 2.14)... Yes.

Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
never looked at, and it looks like there are API changes.  This of
course doesn't help you, Dirk, but this probably means we should require
libgmime-2.4, at least until we can figure out how to support both
versions, which I'm not sure how to handle.

Dirk, just out of curiosity, what system are you running that is
provides gmime 2.6?

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110530/877c31f0/attachment-0001.pgp>


Re: [PATCH] Added C-up and C-down to cycle through previous searches

2011-05-30 Thread Dmitry Kurochkin
Hi Dima.

On Sun, 29 May 2011 01:56:28 -0700, notm...@dima.secretsauce.net wrote:
 From: Dima Kogan d...@secretsauce.net
 
 ---
 
  Hi.
 
  I made a few improvements to the emacs UI. This patch allows the user to 
 scroll
  through the most recent searches with C-up and C-down while in the search 
 box.
 

This sounds like a very nice improvement to me!  I just have one
concern: Why C-up and C-down?  I believe M-p and M-n would be more
natural for Emacs users (at least for me :)).

Also, I did not read the code and can not comment on it.  But notmuch
coding style is to use tabs for indentation.  I guess .dir-locals.el
should be improved to set coding style variables for all modes, not just
C.

Regards,
  Dmitry

  dima
 
  emacs/notmuch-hello.el |   49 +--
  1 files changed, 42 insertions(+), 7 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 916cda1..56f853f 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -123,6 +123,12 @@ Typically \,\ in the US and UK and \.\ in Europe.
  
  (defvar notmuch-hello-recent-searches nil)
  
 +(defvar notmuch-hello-cyclerecent-index 0
 +  The current index of the most-recent searches )
 +
 +(defvar notmuch-hello-search-widget nil
 +  The search widget)
 +
  (defun notmuch-hello-remember-search (search)
(if (not (member search notmuch-hello-recent-searches))
(push search notmuch-hello-recent-searches))
 @@ -148,6 +154,28 @@ Typically \,\ in the US and UK and \.\ in Europe.
(match-string 1 search)
  search))
  
 +(defun notmuch-hello-cyclerecent-next ()
 +  Cycle through the most recently-searched queries, going forwards
 +  (interactive)
 +  (notmuch-hello-cyclerecent 1))
 +
 +(defun notmuch-hello-cyclerecent-prev ()
 +  Cycle through the most recently-searched queries, going backwards
 +  (interactive)
 +  (notmuch-hello-cyclerecent -1))
 +
 +(defun notmuch-hello-cyclerecent (d) ()
 +
 +  (when notmuch-hello-recent-searches ; if no recent searches, do nothing
 +(let ((N (length notmuch-hello-recent-searches)))
 +  (setq notmuch-hello-cyclerecent-index
 +(% (+ notmuch-hello-cyclerecent-index d N) N))) ; update the 
 index
 +
 +(widget-value-set notmuch-hello-search-widget
 +  (nth notmuch-hello-cyclerecent-index 
 notmuch-hello-recent-searches))
 +(widget-setup))
 +)
 +
  (defun notmuch-hello-search (search)
(let ((search (notmuch-hello-trim search)))
  (notmuch-hello-remember-search search)
 @@ -455,13 +483,19 @@ Complete list of currently available key bindings:
  
   (widget-insert \nSearch: )
   (setq notmuch-hello-search-bar-marker (point-marker))
 - (widget-create 'editable-field
 -;; Leave some space at the start and end of the
 -;; search boxes.
 -:size (max 8 (- (window-width) notmuch-hello-indent
 -(length Search: )))
 -:action (lambda (widget rest ignore)
 -  (notmuch-hello-search (widget-value widget
 + (setq notmuch-hello-search-widget
 +  (widget-create 'editable-field
 + ;; Leave some space at the start and end of the
 + ;; search boxes.
 + :size (max 8 (- (window-width) 
 notmuch-hello-indent
 + (length Search: )))
 + :action (lambda (widget rest ignore)
 +   (notmuch-hello-search (widget-value 
 widget)))
 + :keymap (let ((map (make-sparse-keymap)))
 +   (set-keymap-parent map 
 widget-field-keymap)
 +   (define-key map (kbd C-up)   
 'notmuch-hello-cyclerecent-prev)
 +   (define-key map (kbd C-down) 
 'notmuch-hello-cyclerecent-next)
 +   map)))
   (widget-insert \n)
  
   (when notmuch-hello-recent-searches
 @@ -535,6 +569,7 @@ Complete list of currently available key bindings:
   (widget-insert Type a search query and hit RET to view matching 
 threads.\n)
   (when notmuch-hello-recent-searches
 (widget-insert Hit RET to re-submit a previous search. Edit it first 
 if you like.\n)
 +   (widget-insert In the search box, C-up/C-down cycles through the 
 recent searches.\n)
 (widget-insert Save recent searches with the `save' button.\n))
   (when notmuch-saved-searches
 (widget-insert Edit saved searches with the `edit' button.\n))
 -- 
 1.7.4.4
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org

compile error of current git on F15

2011-05-30 Thread Dirk Hohndel

CC -O2 notmuch-reply.o
notmuch-reply.c: In function ‘notmuch_reply_command’:
notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ 
from incompatible pointer type [enabled by default]
/usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
make: *** [notmuch-reply.o] Error 1

This seems to have been introduced in Jameson's crypto patch series...

./configure shows:

Checking for Xapian development files... Yes (1.2.4).
Checking for GMime development files... Yes (gmime-2.6).
Checking for Glib development files (= 2.14)... Yes.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 2/2] emacs: add notmuch-show-worker function for specifying crypto processing directly

2011-05-30 Thread Jameson Graef Rollins
The main reason to introduce this new unexposed function is to allow
the buffer redisplay crypto switch to behaving in a more expected way.
The prefix to notmuch-show-redisplay buffer now switches the crypto
processing of the current show buffer, as opposed to switching the
logic of the notmuch-crypto-process-mime customization variable.  This
behavior is more intuitive.
---
 emacs/notmuch-show.el |   20 
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 6e0d454..3a075a4 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -811,13 +811,16 @@ The optional CRYPTO-SWITCH toggles the value of the
 notmuch-crypto-process-mime customization variable for this show
 buffer.
   (interactive sNotmuch show: )
+  (let* ((process-crypto (if crypto-switch
+(not notmuch-crypto-process-mime)
+  notmuch-crypto-process-mime)))
+(notmuch-show-worker thread-id parent-buffer query-context buffer-name 
process-crypto)))
+
+(defun notmuch-show-worker (thread-id parent-buffer query-context buffer-name 
process-crypto)
   (let* ((buffer-name (generate-new-buffer-name
   (or buffer-name
   (concat *notmuch- thread-id *
 (buffer (get-buffer-create buffer-name))
-(process-crypto (if crypto-switch
-(not notmuch-crypto-process-mime)
-  notmuch-crypto-process-mime))
 (inhibit-read-only t))
 (switch-to-buffer buffer)
 (notmuch-show-mode)
@@ -864,16 +867,17 @@ buffer.
   Refresh the current view (with crypto switch if prefix given).
 
 Kills the current buffer and reruns notmuch show with the same
-thread id.  If a prefix is given, the current thread is
-redisplayed with the crypto switch activated, which switch the
-logic of the notmuch-crypto-process-mime customization variable.
+thread id.  If a prefix is given, crypto processing is toggled.
   (interactive P)
   (let ((thread-id notmuch-show-thread-id)
(parent-buffer notmuch-show-parent-buffer)
(query-context notmuch-show-query-context)
-   (buffer-name notmuch-show-buffer-name))
+   (buffer-name notmuch-show-buffer-name)
+   (process-crypto (if crypto-switch
+   (not notmuch-show-process-crypto)
+ notmuch-show-process-crypto)))
 (notmuch-kill-this-buffer)
-(notmuch-show thread-id parent-buffer query-context buffer-name 
crypto-switch)))
+(notmuch-show-worker thread-id parent-buffer query-context buffer-name 
process-crypto)))
 
 (defvar notmuch-show-stash-map
   (let ((map (make-sparse-keymap)))
-- 
1.7.4.4

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


Re: [PATCH] Change in increment_mtime for BSD compatibility of test suite

2011-05-30 Thread Felix Geller
Another try :)

[...]

Support for platform-specific test configuration
 - Platform-specific functionality is stored in test-config-PLATFORM.sh 
files
 - configure script creates a test/test-config.sh depending on the platform
 - test-lib.sh loads test-config.sh file
 - Some platform-specific functionality included for gnu/bsd:
   - Work-around for touch -d on BSD
   - Variable to store sed command for extended expressions

diff --git a/configure b/configure
index bbf30cd..053a4a1 100755
--- a/configure
+++ b/configure
@@ -16,6 +16,13 @@ if [ $srcdir != . ]; then
 # whole thing into the build directory.
 cp -a $srcdir/test/* test
 
+# Platform specific test configuration
+if [ $platform = MACOSX ] ; then
+   cp test/test-config-bsd.sh test/test-config.sh
+else
+   cp test/test-config-gnu.sh test/test-config.sh
+fi
+
 # Emacs only likes to generate compiled files next to the .el files
 # by default so copy these as well (which is not ideal0.
 cp -a $srcdir/emacs/*.el emacs
diff --git a/test/basic b/test/basic
index 808c968..5fbedfe 100755
--- a/test/basic
+++ b/test/basic
@@ -54,13 +54,14 @@ test_begin_subtest 'Ensure that all available tests will be 
run by notmuch-test'
 eval $(sed -n -e '/^TESTS=$/,/^$/p' notmuch-test ../notmuch-test)
 tests_in_suite=$(for i in $TESTS; do echo $i; done | sort)
 available=$(ls -1 ../ | \
-sed -r -e 
/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d \
-  -e 
/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d \
-  -e 
/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose)/d \
-  -e /^(test.expected-output|.*~)/d \
-  -e /^(gnupg-secret-key.asc)/d \
-  -e /^(gnupg-secret-key.NOTE)/d \
-  | sort)
+$SED_EXTENDED -e 
/^(aggregate-results.sh|Makefile|Makefile.local|notmuch-test)/d \
+ -e 
/^(README|test-lib.sh|test-lib.el|test-results|tmp.*|valgrind|corpus*)/d \
+ -e 
/^(emacs.expected-output|smtp-dummy|smtp-dummy.c|test-verbose)/d \
+ -e /^(test.expected-output|.*~)/d \
+ -e /^(gnupg-secret-key.asc)/d \
+ -e /^(gnupg-secret-key.NOTE)/d \
+ -e /^(test-config*)/d \
+ | sort)
 test_expect_equal $tests_in_suite $available
 
 EXPECTED=../test.expected-output
diff --git a/test/test-config-bsd.sh b/test/test-config-bsd.sh
new file mode 100644
index 000..e35d2fa
--- /dev/null
+++ b/test/test-config-bsd.sh
@@ -0,0 +1,23 @@
+# This file contains helper functions and other values that are
+# require platform-specific functionality (e.g., differing between GNU
+# and BSD). The configure script is used to identify the appropriate
+# file for a given platform, and copies the file test-config-FOO.sh to
+# test-config.sh, where FOO is the respective platform (bsd or gnu).
+#
+# This file is BSD-specific.
+
+# Syntax for extended expressions
+SED_EXTENDED=sed -E
+
+# There is no touch -d on BSD, therefore we have to use a more tedious
+# version that uses date/stat to increment a date by a single second.
+increment_mtime_amount=0
+increment_mtime ()
+{
+dir=$1
+
+last_mod_date=`date -j -f %Y%m%d%H%M%S \`stat -f %Sm -t %Y%m%d%H%M%S 
${dir}\` +%s`
+increment_mtime_amount=$((increment_mtime_amount + 1))
+new_date=`date -j -r ${last_mod_date} -v+${increment_mtime_amount}S 
+%Y%m%d%H%M.%S`
+touch -t ${new_date} ${dir}
+}
diff --git a/test/test-config-gnu.sh b/test/test-config-gnu.sh
new file mode 100644
index 000..596505a
--- /dev/null
+++ b/test/test-config-gnu.sh
@@ -0,0 +1,20 @@
+# This file contains helper functions and other values that are
+# require platform-specific functionality (e.g., differing between GNU
+# and BSD). The configure script is used to identify the appropriate
+# file for a given platform, and copies the file test-config-FOO.sh to
+# test-config.sh, where FOO is the respective platform (bsd or gnu).
+#
+# This file is GNU-specific.
+
+# Syntax for extended expressions
+SED_EXTENDED=sed -r
+
+# Use touch to increment the modification date by a single second.
+increment_mtime_amount=0
+increment_mtime ()
+{
+dir=$1
+
+increment_mtime_amount=$((increment_mtime_amount + 1))
+touch -d +${increment_mtime_amount} seconds $dir
+}
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 922b1ef..1aa3a1c 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -23,6 +23,9 @@ if [ ${BASH_VERSINFO[0]} -lt 4 ]; then
 exit 1
 fi
 
+# Load platform-specific values
+. ./test-config.sh
+
 # if --tee was passed, write the output not only to the terminal, but
 # additionally to the file test-results/$BASENAME.out, too.
 case $GIT_TEST_TEE_STARTED, $*  in
@@ -214,14 +217,6 @@ remove_cr () {
 }
 
 # Notmuch helper functions
-increment_mtime_amount=0
-increment_mtime ()
-{
-dir=$1
-
-increment_mtime_amount=$((increment_mtime_amount + 1))
-touch -d 

Re: compile error of current git on F15

2011-05-30 Thread Jameson Graef Rollins
On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 CC -O2 notmuch-reply.o
 notmuch-reply.c: In function ‘notmuch_reply_command’:
 notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’
 notmuch-reply.c:659:3: warning: passing argument 1 of 
 ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default]
 /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected 
 ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’
 make: *** [notmuch-reply.o] Error 1
 
 This seems to have been introduced in Jameson's crypto patch series...
 
 ./configure shows:
 
 Checking for Xapian development files... Yes (1.2.4).
 Checking for GMime development files... Yes (gmime-2.6).
 Checking for Glib development files (= 2.14)... Yes.

Hey, Dirk.  Looks like you're using gmime-2.6, which is something I've
never looked at, and it looks like there are API changes.  This of
course doesn't help you, Dirk, but this probably means we should require
libgmime-2.4, at least until we can figure out how to support both
versions, which I'm not sure how to handle.

Dirk, just out of curiosity, what system are you running that is
provides gmime 2.6?

jamie.


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


Decryption fails

2011-05-30 Thread Felix Geller
Hi all,

I'm using a version of notmuch based on cb84187 from the master branch
on notmuchmail.org/git/notmuch and am accessing it mostly through the
Emacs UI. Signature verification seems to work nicely, only decryption
fails for any message/thread that I've tried it on. The respective
notmuch process 
notmuch show --format=json --decrypt 'id:x' 
starts eating all my CPU and doesn't return. Doing it on the command
line using gpg directly or going through Emacs' epa works fine. Most of
the test cases in crypto fail as well, but I'm not sure which ones are
actually supposed to work.

My OS is MacOS X, which seems to be non-existent among notmuch
developers and therefore might at some level be the cause. However, I
built gmime 2.4.24 (through a little modification to MacPorts'
respective Portfile) as was recommended on IRC at some point and am not
aware of any other incompatibilities.

I'm not sure how to identify the cause for this problem, do you have any
hints where to start searching?


Cheers,
Felix


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


Re: Decryption fails

2011-05-30 Thread David Bremner
On Mon, 30 May 2011 21:30:03 +0200, Felix Geller fgel...@gmail.com wrote:

 starts eating all my CPU and doesn't return. Doing it on the command
 line using gpg directly or going through Emacs' epa works fine. Most of
 the test cases in crypto fail as well, but I'm not sure which ones are
 actually supposed to work.

I can't help much with MacOS X, but all of the test cases should work
with gmime 2.4.24 (at least they do for people on Debian).

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


Re: one-time-iterators

2011-05-30 Thread Austin Clements
Quoth Patrick Totzke on May 28 at  9:58 am:
 Excerpts from Austin Clements's message of Fri May 27 20:29:24 +0100 2011:
  On Fri, May 27, 2011 at 2:04 PM, Patrick Totzke
  patricktot...@googlemail.com wrote:
   Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 2011:
  Have you tried simply calling list() on your thread
  iterator to see how expensive it is?  My bet is that it's quite 
  cheap,
  both memory-wise and CPU-wise.
 Funny thing:
  q=Database().create_query('*')
  time tlist = list(q.search_threads())
 raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some 
 reason
 the list constructor must read mere than once from the iterator.
 So this is not an option, but even if it worked, it would show
 the same behaviour as my above test..
   
Interesting.  Looks like the Threads class implements __len__ and that
its implementation exhausts the iterator.  Which isn't a great idea in
itself, but it turns out that Python's implementation of list() calls
__len__ if it's available (presumably to pre-size the list) before
iterating over the object, so it exhausts the iterator before even
using it.
   
That said, if list(q.search_threads()) did work, it wouldn't give you
better performance than your experiment above.
   true. Nevertheless I think that list(q.search_threads())
   should be equivalent to [t for t in q.search_threads()], which is
   something to be fixed in the bindings. Should I file an issue somehow?
   Or is enough to state this as a TODO here on the list?
  
  Yes, they should be equivalent.
  
  Sebastian was thinking about fixing the larger issue of generator
  exhaustion, which would address this, though the performance would
  depend on the cost of iterating twice.  This is why generators
  shouldn't support __len__.  Unfortunately, it's probably hard to get
  rid of at this point and I doubt there's a way to tell list() to
  overlook the presence of a __len__ method.
 Why not simply removing support for __len__ in the Threads and Messages 
 classes?

Presumably len is there because things use it.  On the other hand,
given the issues surrounding len, I suspect anything that's using it
is already a mess.

 would it be very hard to implement a Query.search_thread_ids() ?
 This name is a bit off because it had to be done on a lower level.
   
Lazily fetching the thread metadata on the C side would probably
address your problem automatically.  But what are you doing that
doesn't require any information about the threads you're manipulating?
Agreed. Unfortunately, there seems to be no way to get a list of thread
ids or a reliable iterator thereof by using the current python 
bindings.
It would be enough for me to have the ids because then I could
search for the few threads I actually need individually on demand.
  
   There's no way to do that from the C API either, so don't feel left
   out.  ]:--8)  It seems to me that the right solution to your problem
   is to make thread information lazy (effectively, everything gathered
   in lib/thread.cc:_thread_add_message).  Then you could probably
   materialize that iterator cheaply.
   Alright. I'll put this on my mental notmuch wish list and
   hope that someone will have addressed this before I run out of
   ideas how to improve my UI and have time to look at this myself.
   For now, I go with the [t.get_thread_id for t in q.search_threads()]
   approach to cache the thread ids myself and live with the fact that
   this takes time for large result sets.
  
   In fact, it's probably worth
   trying a hack where you put dummy information in the thread object
   from _thread_add_message and see how long it takes just to walk the
   iterator (unfortunately I don't think profiling will help much here
   because much of your time is probably spent waiting for I/O).
   I don't think I understand what you mean by dummy info in a thread
   object.
  
  In _thread_add_message, rather than looking up the message's author,
  subject, etc, just hard-code some dummy values.  Performance-wise,
  this would simulate making the thread metadata lookup lazy, so you
  could see if making this lazy would address your problem.
 Thanks for the clarification. I did that, and also commented out the
 lower parts of _notmuch_thread_create and this did indeed improve
 the performance, but not so much as I had hoped:
 
 In [10]: q=Database().create_query('*')
 In [11]: time T=[t for t in q.search_threads()]
 CPU times: user 2.43 s, sys: 0.22 s, total: 2.65 s
 Wall time: 2.66 s
 
 And I have only about 8000 mails in my index.
 Making thread lookups lazy would help, but here one would still
 create a lot of unused (empty) thread objects.
 The easiest solution to my problem would in my opinion be
 a function that queries only for thread ids without instanciating them.
 But I can't think of any other use case than mine for this
 

Re: Multiple sender identities (composing)

2011-05-30 Thread Stewart Smith
On Tue, 24 May 2011 14:54:37 -0700, Carl Worth cwo...@cworth.org wrote:
 I've wanted something like this, but I'm extremely reluctant to put
 fancy things like this in my .emacs file. The problem I have is that I
 don't want to restrict nice features to the people who manage to
 configure their emacs just so.

I completely agree - and am rather glad that there's a proper solution now.

 I'll reply with a patch I just wrote attempting to implement that. By
 default, it generates the list of addresses by looking in your notmuch
 configuration file. It also provides a customizable list of addresses
 that the user can provide (notmuch-identities).

I'll try trunk with the patches as soon as I get home from travel and am
somewhat remotely close to not being a zombie.

 I don't know what trouble you had with ido on Ubuntu, but hopefully you
 can work that out.

I hope so too... it could just be how I was trying to use it or user
ignorance or something like that.

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