[Review] Re: new "crypto" branch providing full PGP/MIME support

2011-02-27 Thread Darren McGuicken
On Sat, 26 Feb 2011 20:45:15 -0400, David Bremner  wrote:
> Further to our discussion on IRC the other day about providing
> feedback on patches, I have run these patches pretty much all of
> February with no glitches.  I am running them on 3 different machines,
> although they are all Debian AMD64 boxes.

If feedback is needed here then likewise, I've been running the crypto
branch since it was made available.  The only strangeness I've seen was
that which was reported in id:"87sjw2h6xy.fsf at bookbinder.fernseed.info"
for expired keys.

Even with that glitch, I really can't see me going back to vanilla
notmuch until these patches are pulled.  They're just ridiculously
useful.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110227/6909badb/attachment.pgp>


[PATCH] new: read db_files and db_subdirs if mtime changed

2011-02-27 Thread Austin Clements
Looks good (faster than, but provably equivalent to the original code!
 notmuch_directory_get_child_* are side-effect free,
db_files/db_subdirs aren't used between where they were set in the old
code and where they are set in the new code, and db_files/db_subdirs
are initialized to NULL when declared).

Another timing data point:
Old code: ./notmuch new  0.77s user 0.28s system 99% cpu 1.051 total
New code: ./notmuch new  0.09s user 0.27s system 98% cpu 0.368 total

I wonder if an even faster approach than the current recursive walk
would be to get *all* of the directory names and mtimes out of Xapian
in one pass and stat them all.  If the mtime didn't change, then
there's no need to scandir that directory at all.  This could even
beat the "time find >/dev/null" bound, but the gains may be too
marginal to make it worthwhile.

On Fri, Feb 4, 2011 at 4:44 PM, Karel Zak  wrote:
> The db_files and db_subdirs are unnecessary for unchanged directories.
>
> maildir with 1 e-mails:
>
> old version:
> ? ? ? ?$ time ./notmuch new
> ? ? ? ?No new mail.
>
> ? ? ? ?real ? ?0m0.053s
> ? ? ? ?user ? ?0m0.028s
> ? ? ? ?sys ? ? 0m0.026s
>
> new version:
> ? ? ? ?$ time ./notmuch new
> ? ? ? ?No new mail.
>
> ? ? ? ?real ? ?0m0.032s
> ? ? ? ?user ? ?0m0.009s
> ? ? ? ?sys ? ? 0m0.023s
>
> Signed-off-by: Karel Zak 
> ---
> ?notmuch-new.c | ? 15 ++-
> ?1 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/notmuch-new.c b/notmuch-new.c
> index 941f9d6..31d4553 100644
> --- a/notmuch-new.c
> +++ b/notmuch-new.c
> @@ -247,15 +247,7 @@ add_files_recursive (notmuch_database_t *notmuch,
> ? ? directory = notmuch_database_get_directory (notmuch, path);
> ? ? db_mtime = notmuch_directory_get_mtime (directory);
>
> - ? ?if (db_mtime == 0) {
> - ? ? ? new_directory = TRUE;
> - ? ? ? db_files = NULL;
> - ? ? ? db_subdirs = NULL;
> - ? ?} else {
> - ? ? ? new_directory = FALSE;
> - ? ? ? db_files = notmuch_directory_get_child_files (directory);
> - ? ? ? db_subdirs = notmuch_directory_get_child_directories (directory);
> - ? ?}
> + ? ?new_directory = db_mtime ? FALSE : TRUE;
>
> ? ? /* If the database knows about this directory, then we sort based
> ? ? ?* on strcmp to match the database sorting. Otherwise, we can do
> @@ -328,6 +320,11 @@ add_files_recursive (notmuch_database_t *notmuch,
> ? ? if (fs_mtime == db_mtime)
> ? ? ? ?goto DONE;
>
> + ? ?if (!new_directory) {
> + ? ? ? db_files = notmuch_directory_get_child_files (directory);
> + ? ? ? db_subdirs = notmuch_directory_get_child_directories (directory);
> + ? ?}
> +
> ? ? /* Pass 2: Scan for new files, removed files, and removed directories. */
> ? ? for (i = 0; i < num_fs_entries; i++)
> ? ? {
> --
> 1.7.3.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>


[PATCH] Return error status from notmuch_message_tags_to_maildir_flags().

2011-02-27 Thread Austin Clements
Looks good to me, but it appears that both callers of
notmuch_message_tags_to_maildir_flags ignore the return value.  Both
callers synchronize maildir flags immediately after thawing the tag
changes on a message.  Perhaps they should instead synchronize
*before* thawing and abort if the sync fails?

On Tue, Feb 15, 2011 at 1:07 AM, Rob Browning  wrote:
> Signed-off-by: Rob Browning 
> ---
> ?lib/message.cc | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib/message.cc b/lib/message.cc
> index 0590f76..979fad5 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -1252,7 +1252,7 @@ notmuch_message_tags_to_maildir_flags 
> (notmuch_message_t *message)
> ? ? talloc_free (to_set);
> ? ? talloc_free (to_clear);
>
> - ? ?return NOTMUCH_STATUS_SUCCESS;
> + ? ?return status;
> ?}
>
> ?notmuch_status_t
> --
> 1.7.2.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>


Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation

2011-02-27 Thread Xavier Maillard
Hi,

On Wed, 23 Feb 2011 11:01:27 -0800, Jameson Rollins  wrote:
> On Wed, 23 Feb 2011 15:10:22 +0100, Albin Stjerna  wrote:
> > On Tue, 22 Feb 2011 14:59:03 -0500, Daniel Kahn Gillmor  > fifthhorseman.net> wrote:
> > 
> > > I'm running the crypto branch (from jrollins, available at
> > > git://finestructure.net/notmuch ), which incorporates dme's multipart
> > > MIME overhaul.
> > 
> > Ah. I've now built and installed that one, and it works as you described
> > it. Thanks!
> > 
> > Is there a plan for the inclusion of this branch in mainline notmuch?
> 
> Carl has expressed interest in the crypto work, but he hasn't commented
> on the work in that branch directly yet.  I will certainly continue to
> push for it's inclusion.

What is the easy way to switch to your codebase from notmuch mainline ?
I mean, what exact commands do we need to type in order to use your
branch code ? Knowing that would certainly help people in switching and
testing your code.

Thank you

/Xavier


Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation

2011-02-27 Thread Xavier Maillard
Hi Rob,

On Tue, 22 Feb 2011 19:13:26 -0600, Rob Browning  
wrote:

> The "Display Customization" section in the emacs/mime info pages might
> also be interesting.  i.e. at the moment I use
> mm-discouraged-alternatives like this (via Gnus):
> 
>   (setq mm-discouraged-alternatives
> '("text/html" "text/richtext")
> mm-automatic-display
> (remove "text/html" mm-automatic-display))

Doest it have any action on notmuch.el buffers or is it just some
GNUS/Mime specific setup ?

Thank you

/Xavier


RFC: Dovecot locking

2011-02-27 Thread Xavier Maillard
Hi Rob,

On Wed, 16 Feb 2011 20:59:09 -0600, Rob Browning  
wrote:

> For now, I'm interested in general comments, i.e. is this desirable, is
> it a reasonable approach, etc.  As you can see, there's no config
> handling yet, so -llockfile is added unconditionally.

I need this since I can't currently use notmuch-remote due to these
stale files making 'notmuch new' failing.

I won't comment about your approach since I am no expert both with
notmuch codebase and C :D

I hope I will be able to play with notmuch-remote soon.

/Xavier


Re: [PATCH] new: read db_files and db_subdirs if mtime changed

2011-02-27 Thread Austin Clements
Looks good (faster than, but provably equivalent to the original code!
 notmuch_directory_get_child_* are side-effect free,
db_files/db_subdirs aren't used between where they were set in the old
code and where they are set in the new code, and db_files/db_subdirs
are initialized to NULL when declared).

Another timing data point:
Old code: ./notmuch new  0.77s user 0.28s system 99% cpu 1.051 total
New code: ./notmuch new  0.09s user 0.27s system 98% cpu 0.368 total

I wonder if an even faster approach than the current recursive walk
would be to get *all* of the directory names and mtimes out of Xapian
in one pass and stat them all.  If the mtime didn't change, then
there's no need to scandir that directory at all.  This could even
beat the time find /dev/null bound, but the gains may be too
marginal to make it worthwhile.

On Fri, Feb 4, 2011 at 4:44 PM, Karel Zak k...@redhat.com wrote:
 The db_files and db_subdirs are unnecessary for unchanged directories.

 maildir with 1 e-mails:

 old version:
        $ time ./notmuch new
        No new mail.

        real    0m0.053s
        user    0m0.028s
        sys     0m0.026s

 new version:
        $ time ./notmuch new
        No new mail.

        real    0m0.032s
        user    0m0.009s
        sys     0m0.023s

 Signed-off-by: Karel Zak k...@redhat.com
 ---
  notmuch-new.c |   15 ++-
  1 files changed, 6 insertions(+), 9 deletions(-)

 diff --git a/notmuch-new.c b/notmuch-new.c
 index 941f9d6..31d4553 100644
 --- a/notmuch-new.c
 +++ b/notmuch-new.c
 @@ -247,15 +247,7 @@ add_files_recursive (notmuch_database_t *notmuch,
     directory = notmuch_database_get_directory (notmuch, path);
     db_mtime = notmuch_directory_get_mtime (directory);

 -    if (db_mtime == 0) {
 -       new_directory = TRUE;
 -       db_files = NULL;
 -       db_subdirs = NULL;
 -    } else {
 -       new_directory = FALSE;
 -       db_files = notmuch_directory_get_child_files (directory);
 -       db_subdirs = notmuch_directory_get_child_directories (directory);
 -    }
 +    new_directory = db_mtime ? FALSE : TRUE;

     /* If the database knows about this directory, then we sort based
      * on strcmp to match the database sorting. Otherwise, we can do
 @@ -328,6 +320,11 @@ add_files_recursive (notmuch_database_t *notmuch,
     if (fs_mtime == db_mtime)
        goto DONE;

 +    if (!new_directory) {
 +       db_files = notmuch_directory_get_child_files (directory);
 +       db_subdirs = notmuch_directory_get_child_directories (directory);
 +    }
 +
     /* Pass 2: Scan for new files, removed files, and removed directories. */
     for (i = 0; i  num_fs_entries; i++)
     {
 --
 1.7.3.4

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

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