notmuch-next branch

2010-10-11 Thread Amit Kucheria
On Mon, Oct 11, 2010 at 10:01 PM, Jameson Rollins
 wrote:
> On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras  gmail.com> wrote:
>> I think many people agree notmuch mainline has been rather slow. So
>> I'm proposing to have notmuch-next branch, either on github or
>> gitorious (please vote).
>>
>> More than one person should have write access to this repo, but some
>> guidelines should be in place. I propose that patches should be
>> signed-off-by at least another person in the mailing list before
>> pushing. It would be nice if this is how the mainline branch works,
>> but we don't need to wait for that to happen. We need to vote on who
>> are the people to have write access.
>
> I think this generally sounds like a fine idea, but I don't see why we
> need a single central repo that multiple people need access to. ?The
> whole point of git is to allow for distributed development without need
> for a central repo.

While distributed development is good, it would be nice for users to
be able to clone one git repo instead of tracking 5 different trees.
And more users typically means more robust software.

It would also make it easier to merge patches back into notmuch-master
if it ever takes off again.

> In this case, folks can just merge the patches they're interested in
> into a "next" branch in their own personal repos, publish them where
> ever they want, and then every body can just keep their "next" branches
> synced with each other. ?As consensus is reached, the next release will
> emerge.

Everyone can still maintain their own trees. Patches can go into the
'-next' repo only after being ack'ed by 1-2 active developers on the
mailing list. Meanwhile they bake in personal trees.

/Amit


sluk, rss and notmuch - some use cases

2010-10-11 Thread Kristoffer Ström

I just wrote a simple script to turn rss feeds into notmuch-parsable 
directories.

Script and docs available at: http://github.com/krl/sluk/

I had run into problems with both of the two other solutions for this i know

feed2imap: problems with threading consuming 100% cpu somehow (seems like a 
local problem, only happended from cron), also it started messing up the 
maildir writing.
rss2emai: downside that you need to send mail when you just want to write it in 
a directory. also had encoding issues with this.

I use this to read all my rss, and tag the ones i find interesting with 
"recommended", thereafter i use

http://github.com/albins/notmuch-to-feed

...to generate a feed from this tag, to spam my friends and enemies.

Feel free to yell at me if anything breaks.

 - Kristoffer


notmuch-next branch

2010-10-11 Thread Jed Brown
On Mon, Oct 11, 2010 at 22:00, Jameson Rollins
 wrote:
> As long as all the repos are synced, then you only need to track one.
> But notmuch already has "official" repos [0], and making another
> pseudo-"official" repo will probably just makes things more confusing.

Patches show up in a different order in each person's "personal, but
'synced'" repository.  Then you need a mess of merges to actually get
them synced (if they are published, you can't rebase).

Jed


notmuch-next branch

2010-10-11 Thread Felipe Contreras
Hi,

I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
gitorious (please vote).

More than one person should have write access to this repo, but some
guidelines should be in place. I propose that patches should be
signed-off-by at least another person in the mailing list before
pushing. It would be nice if this is how the mainline branch works,
but we don't need to wait for that to happen. We need to vote on who
are the people to have write access.

Also, we need to agree which patches to start with and how. One
proposal would be to propose and vote here, another would be to resend
them and wait for signed-off-by's.

What do you think?

-- 
Felipe Contreras


notmuch-next branch

2010-10-11 Thread Kristoffer Ström
> What do you think?

Good idea. github+


notmuch-next branch

2010-10-11 Thread Jesse Rosenthal

On Mon, 11 Oct 2010 22:10:24 +0200, Jed Brown  wrote:
> Patches show up in a different order in each person's "personal, but
> 'synced'" repository.  Then you need a mess of merges to actually get
> them synced (if they are published, you can't rebase).

I'd add, by way of voting for something a bit more central, that it
would be very hard to offer support to new users over IRC or the list,
if there wasn't some brancha franca. Any problems they might have could
be traced to some patch in whatever repo they pulled from, and everyone
on the channel would, in order to help, be clamoring to have them pull
from this or that repo.

I don't know how official this has to be -- just an agreed upon branch
that people keep around next to their own personal one. Sebastian used
to have one that served this purpose a while back, I think.

None of this means that people couldn't publish their own -- but that
there was one, run probably by a team, to serve as a point of a
reference.

--Jesse


notmuch-next branch

2010-10-11 Thread Jameson Rollins
On Mon, 11 Oct 2010 22:40:52 +0300, Amit Kucheria  wrote:
> While distributed development is good, it would be nice for users to
> be able to clone one git repo instead of tracking 5 different trees.
> And more users typically means more robust software.

As long as all the repos are synced, then you only need to track one.
But notmuch already has "official" repos [0], and making another
pseudo-"official" repo will probably just makes things more confusing.

jamie.

[0] git://notmuchmail.org/git/notmuch
-- 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/20101011/59d54bab/attachment.pgp>


notmuch-next branch

2010-10-11 Thread Jameson Rollins
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras  wrote:
> I think many people agree notmuch mainline has been rather slow. So
> I'm proposing to have notmuch-next branch, either on github or
> gitorious (please vote).
> 
> More than one person should have write access to this repo, but some
> guidelines should be in place. I propose that patches should be
> signed-off-by at least another person in the mailing list before
> pushing. It would be nice if this is how the mainline branch works,
> but we don't need to wait for that to happen. We need to vote on who
> are the people to have write access.

I think this generally sounds like a fine idea, but I don't see why we
need a single central repo that multiple people need access to.  The
whole point of git is to allow for distributed development without need
for a central repo.

In this case, folks can just merge the patches they're interested in
into a "next" branch in their own personal repos, publish them where
ever they want, and then every body can just keep their "next" branches
synced with each other.  As consensus is reached, the next release will
emerge.

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/20101011/b1e06538/attachment.pgp>


notmuch-next branch

2010-10-11 Thread Servilio Afre Puentes
On 11 October 2010 14:45, Felipe Contreras  
wrote:
> Hi,
>
> I think many people agree notmuch mainline has been rather slow. So
> I'm proposing to have notmuch-next branch, either on github or
> gitorious (please vote).

+1 for gitorious, you can use OpenID and their code is available (for
me a sign of more faith in free software than the Github people).

An alternative would be to have a list of git branches in the wiki,
with description, clone URL, etc.

Servilio


[PATCH 3/3] notmuch-tag.c: Add tag logging.

2010-10-11 Thread da...@tethera.net
From: David Bremner 

logging of tags is enabled by adding a stanza like

[log]
tags = /some/path/you/can/write/to

to your notmuch config.

Note that we intentionally do the logging after the database
transaction is finished.
---
 notmuch-tag.c |   31 +++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/notmuch-tag.c b/notmuch-tag.c
index fd54bc7..f24d1e4 100644
--- a/notmuch-tag.c
+++ b/notmuch-tag.c
@@ -46,6 +46,9 @@ notmuch_tag_command (void *ctx, unused (int argc), unused 
(char *argv[]))
 notmuch_message_t *message;
 struct sigaction action;
 int i;
+int log_fd = -1;
+notmuch_bool_t enable_log = FALSE;
+const char *log_path;

 /* Setup our handler for SIGINT */
 memset (, 0, sizeof (struct sigaction));
@@ -96,6 +99,17 @@ notmuch_tag_command (void *ctx, unused (int argc), unused 
(char *argv[]))
 if (config == NULL)
return 1;

+log_path = notmuch_config_get_log_path (config, "tags");
+
+if (log_path != NULL) {
+  enable_log = TRUE;
+
+  log_fd = notmuch_log_open(log_path);
+
+  if (log_fd < 0)
+   return 1;
+}
+
 notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
 NOTMUCH_DATABASE_MODE_READ_WRITE);
 if (notmuch == NULL)
@@ -114,10 +128,15 @@ notmuch_tag_command (void *ctx, unused (int argc), unused 
(char *argv[]))
 notmuch_messages_valid (messages) && !interrupted;
 notmuch_messages_move_to_next (messages))
 {
+   const char *message_id = NULL;
message = notmuch_messages_get (messages);

notmuch_message_freeze (message);

+   if (enable_log)
+   message_id = talloc_strdup (ctx,
+   notmuch_message_get_message_id 
(message));
+
for (i = 0; i < remove_tags_count; i++)
notmuch_message_remove_tag (message,
argv[remove_tags[i]] + 1);
@@ -128,6 +147,18 @@ notmuch_tag_command (void *ctx, unused (int argc), unused 
(char *argv[]))
notmuch_message_thaw (message);

notmuch_message_destroy (message);
+
+   if (enable_log) {
+   for (i = 0; i < remove_tags_count; i++)
+   notmuch_log_string_pair (ctx, log_fd,
+message_id,
+argv[remove_tags[i]]);
+
+   for (i = 0; i < add_tags_count; i++)
+   notmuch_log_string_pair (ctx, log_fd,
+message_id,
+argv[add_tags[i]]);
+   }
 }

 notmuch_query_destroy (query);
-- 
1.7.1



[PATCH 2/3] notmuch-log.c: Add a function to log a pair of strings with a timestamp.

2010-10-11 Thread da...@tethera.net
From: David Bremner 

Since the function is supposed to work for any pair of strings, this
means some form of quoting seems necessary. I decided to re-use the
json quoting routines for convenience.
---
 notmuch-client.h |4 
 notmuch-log.c|   18 ++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 0422b1c..a849e21 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -201,6 +201,10 @@ notmuch_log_open (const char *path);
 notmuch_status_t
 notmuch_log_append (int file_desc, const char *buffer, size_t len);

+notmuch_status_t
+notmuch_log_string_pair (void *ctx, int file_desc,
+const char *str1, const char *str2);
+
 notmuch_bool_t
 debugger_is_active (void);

diff --git a/notmuch-log.c b/notmuch-log.c
index c4ddcd3..b0aca95 100644
--- a/notmuch-log.c
+++ b/notmuch-log.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include "notmuch-client.h"
 /*
@@ -100,3 +102,19 @@ notmuch_log_append (int file_desc, const char *buffer, 
size_t len){

 return NOTMUCH_STATUS_SUCCESS;
 }
+
+notmuch_status_t
+notmuch_log_string_pair(void *ctx, int log_fd,
+   const char *string1, const char *string2){
+
+char *quoted1, *quoted2, *buffer;
+
+quoted1 = json_quote_str (ctx, string1);
+quoted2 = json_quote_str (ctx, string2);
+
+buffer = talloc_asprintf (ctx, "%ld %s %s\n",
+ (long)time(NULL),
+ quoted1, quoted2);
+
+return notmuch_log_append (log_fd, buffer, strlen(buffer));
+}
-- 
1.7.1



[PATCH 1/3] Initial implementation of low level logging routines.

2010-10-11 Thread da...@tethera.net
From: David Bremner 

notmuch_log_open: open a log file; just a wrapper around open(2)
notmuch_log_append: atomically append a buffer (character array) to a log file

Based on per-write file locking, performance will have to be tested.
---
 Makefile.local   |1 +
 notmuch-client.h |   10 +
 notmuch-config.c |   15 
 notmuch-log.c|  102 ++
 4 files changed, 128 insertions(+), 0 deletions(-)
 create mode 100644 notmuch-log.c

diff --git a/Makefile.local b/Makefile.local
index ade8412..8dbda15 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -240,6 +240,7 @@ notmuch_client_srcs =   \
notmuch-config.c\
notmuch-count.c \
notmuch-dump.c  \
+   notmuch-log.c   \
notmuch-new.c   \
notmuch-reply.c \
notmuch-restore.c   \
diff --git a/notmuch-client.h b/notmuch-client.h
index 20be43b..0422b1c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -191,6 +191,16 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 const char *new_tags[],
 size_t length);

+const char *
+notmuch_config_get_log_path (notmuch_config_t *config,
+const char *name);
+
+int
+notmuch_log_open (const char *path);
+
+notmuch_status_t
+notmuch_log_append (int file_desc, const char *buffer, size_t len);
+
 notmuch_bool_t
 debugger_is_active (void);

diff --git a/notmuch-config.c b/notmuch-config.c
index cf30603..c01e8f4 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -562,3 +562,18 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 config->new_tags = NULL;
 }

+const char *
+notmuch_config_get_log_path (notmuch_config_t *config, const char *name)
+{
+char *path, *rpath;
+
+path= g_key_file_get_string (config->key_file,
+"log", name, NULL);
+if (path != NULL) {
+   rpath = talloc_strdup (config, path);
+   free (path);
+   return rpath;
+} else {
+   return NULL;
+}
+}
diff --git a/notmuch-log.c b/notmuch-log.c
new file mode 100644
index 000..c4ddcd3
--- /dev/null
+++ b/notmuch-log.c
@@ -0,0 +1,102 @@
+
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright ?? 2010 David Bremner
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/ .
+ *
+ * Author: David Bremner 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "notmuch-client.h"
+/*
+   Look a key up in the config file; open the corresponding file as a
+   log.
+
+   Return a file descriptor to the open log file, or -1 if an error
+   occurs.
+  */
+
+int
+notmuch_log_open (const char *path)
+{
+int fd;
+
+fd = open (path, O_CREAT|O_WRONLY|O_APPEND);
+if (fd < 0) {
+   fprintf (stderr, "Failed to open %s: %s\n",
+path, strerror (errno));
+}
+
+return fd;
+}
+
+notmuch_status_t
+notmuch_log_append (int file_desc, const char *buffer, size_t len){
+
+struct flock lock;
+
+lock.l_type = F_WRLCK;
+lock.l_whence = SEEK_SET;
+lock.l_start = 0;
+lock.l_len = 0;
+
+if (fcntl (file_desc, F_SETLKW, ) != 0) {
+   fprintf (stderr, "Failed to lock  %s\n",
+strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+}
+
+while (len > 0)
+{
+   int written;
+
+   written = write(file_desc, buffer, len);
+   if (written < 0 || (written == 0 && errno !=0))
+   {
+   fprintf (stderr, "Failed to write %zd characters: %s\n",
+len, strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+   }
+
+   len -= written;
+   buffer += written;
+
+}
+
+if (fdatasync (file_desc) != 0) {
+   fprintf (stderr, "Failed to sync:  %s\n",
+strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+}
+
+lock.l_type=F_UNLCK;
+
+if (fcntl (file_desc, F_SETLK, ) != 0) {
+   fprintf (stderr, "Failed to unlock:  %s\n",
+strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+}
+
+return NOTMUCH_STATUS_SUCCESS;
+}
-- 
1.7.1



First draft of logging functionality.

2010-10-11 Thread da...@tethera.net
The patches following this message are my first attempt at
implementing atomic logging for notmuch.  The idea is that such logs
could be useful in synchronizing notmuch instances.

Feedback of any kind is welcome. I'm particularly interested in
comments about the log format and performance.

In my tests, logging adds about a 10% speed penalty (tagging ~3700
messages) if enabled. I'd be curious if people for whom tagging is
slow could tell me if they take a bigger hit. If you want to test, add
a stanza like

[log]
tags = /path/to/logfile

to your notmuch config.

About the format, I am currently using

seconds-since-epoch json-quoted-message-id json-quoted-plus-minus-tag

I know some of you will not be thrilled with the quoting format; I'm
open to other ideas, but this is what was already existing in notmuch
code.  At the moment I wanted to push the quoting fairly far down the
stack and use the same for all potential logging, but perhaps this is
too much "design by convenient implementation".

Canadian-Thanksgiving-Greetings,

David


First draft of logging functionality.

2010-10-11 Thread david
The patches following this message are my first attempt at
implementing atomic logging for notmuch.  The idea is that such logs
could be useful in synchronizing notmuch instances.

Feedback of any kind is welcome. I'm particularly interested in
comments about the log format and performance.

In my tests, logging adds about a 10% speed penalty (tagging ~3700
messages) if enabled. I'd be curious if people for whom tagging is
slow could tell me if they take a bigger hit. If you want to test, add
a stanza like

[log]
tags = /path/to/logfile

to your notmuch config.

About the format, I am currently using

seconds-since-epoch json-quoted-message-id json-quoted-plus-minus-tag

I know some of you will not be thrilled with the quoting format; I'm
open to other ideas, but this is what was already existing in notmuch
code.  At the moment I wanted to push the quoting fairly far down the
stack and use the same for all potential logging, but perhaps this is
too much design by convenient implementation.

Canadian-Thanksgiving-Greetings,

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


[PATCH 1/3] Initial implementation of low level logging routines.

2010-10-11 Thread david
From: David Bremner brem...@unb.ca

notmuch_log_open: open a log file; just a wrapper around open(2)
notmuch_log_append: atomically append a buffer (character array) to a log file

Based on per-write file locking, performance will have to be tested.
---
 Makefile.local   |1 +
 notmuch-client.h |   10 +
 notmuch-config.c |   15 
 notmuch-log.c|  102 ++
 4 files changed, 128 insertions(+), 0 deletions(-)
 create mode 100644 notmuch-log.c

diff --git a/Makefile.local b/Makefile.local
index ade8412..8dbda15 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -240,6 +240,7 @@ notmuch_client_srcs =   \
notmuch-config.c\
notmuch-count.c \
notmuch-dump.c  \
+   notmuch-log.c   \
notmuch-new.c   \
notmuch-reply.c \
notmuch-restore.c   \
diff --git a/notmuch-client.h b/notmuch-client.h
index 20be43b..0422b1c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -191,6 +191,16 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 const char *new_tags[],
 size_t length);
 
+const char *
+notmuch_config_get_log_path (notmuch_config_t *config,
+const char *name);
+
+int
+notmuch_log_open (const char *path);
+
+notmuch_status_t
+notmuch_log_append (int file_desc, const char *buffer, size_t len);
+
 notmuch_bool_t
 debugger_is_active (void);
 
diff --git a/notmuch-config.c b/notmuch-config.c
index cf30603..c01e8f4 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -562,3 +562,18 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 config-new_tags = NULL;
 }
 
+const char *
+notmuch_config_get_log_path (notmuch_config_t *config, const char *name)
+{
+char *path, *rpath;
+
+path= g_key_file_get_string (config-key_file,
+log, name, NULL);
+if (path != NULL) {
+   rpath = talloc_strdup (config, path);
+   free (path);
+   return rpath;
+} else {
+   return NULL;
+}
+}
diff --git a/notmuch-log.c b/notmuch-log.c
new file mode 100644
index 000..c4ddcd3
--- /dev/null
+++ b/notmuch-log.c
@@ -0,0 +1,102 @@
+
+/* notmuch - Not much of an email program, (just index and search)
+ *
+ * Copyright © 2010 David Bremner
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/ .
+ *
+ * Author: David Bremner da...@tethera.net
+ */
+
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include unistd.h
+
+#include notmuch-client.h
+/*
+   Look a key up in the config file; open the corresponding file as a
+   log.
+
+   Return a file descriptor to the open log file, or -1 if an error
+   occurs.
+  */
+
+int
+notmuch_log_open (const char *path)
+{
+int fd;
+
+fd = open (path, O_CREAT|O_WRONLY|O_APPEND);
+if (fd  0) {
+   fprintf (stderr, Failed to open %s: %s\n,
+path, strerror (errno));
+}
+
+return fd;
+}
+
+notmuch_status_t
+notmuch_log_append (int file_desc, const char *buffer, size_t len){
+
+struct flock lock;
+
+lock.l_type = F_WRLCK;
+lock.l_whence = SEEK_SET;
+lock.l_start = 0;
+lock.l_len = 0;
+
+if (fcntl (file_desc, F_SETLKW, lock) != 0) {
+   fprintf (stderr, Failed to lock  %s\n,
+strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+}
+
+while (len  0)
+{
+   int written;
+
+   written = write(file_desc, buffer, len);
+   if (written  0 || (written == 0  errno !=0))
+   {
+   fprintf (stderr, Failed to write %zd characters: %s\n,
+len, strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+   }
+
+   len -= written;
+   buffer += written;
+
+}
+
+if (fdatasync (file_desc) != 0) {
+   fprintf (stderr, Failed to sync:  %s\n,
+strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+}
+
+lock.l_type=F_UNLCK;
+
+if (fcntl (file_desc, F_SETLK, lock) != 0) {
+   fprintf (stderr, Failed to unlock:  %s\n,
+strerror (errno));
+
+   return NOTMUCH_STATUS_FILE_ERROR;
+}
+
+return NOTMUCH_STATUS_SUCCESS;
+}
-- 
1.7.1

___
notmuch mailing list
notmuch@notmuchmail.org

[PATCH 2/3] notmuch-log.c: Add a function to log a pair of strings with a timestamp.

2010-10-11 Thread david
From: David Bremner brem...@unb.ca

Since the function is supposed to work for any pair of strings, this
means some form of quoting seems necessary. I decided to re-use the
json quoting routines for convenience.
---
 notmuch-client.h |4 
 notmuch-log.c|   18 ++
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/notmuch-client.h b/notmuch-client.h
index 0422b1c..a849e21 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -201,6 +201,10 @@ notmuch_log_open (const char *path);
 notmuch_status_t
 notmuch_log_append (int file_desc, const char *buffer, size_t len);
 
+notmuch_status_t
+notmuch_log_string_pair (void *ctx, int file_desc,
+const char *str1, const char *str2);
+
 notmuch_bool_t
 debugger_is_active (void);
 
diff --git a/notmuch-log.c b/notmuch-log.c
index c4ddcd3..b0aca95 100644
--- a/notmuch-log.c
+++ b/notmuch-log.c
@@ -23,6 +23,8 @@
 #include sys/stat.h
 #include fcntl.h
 #include unistd.h
+#include time.h
+#include talloc.h
 
 #include notmuch-client.h
 /*
@@ -100,3 +102,19 @@ notmuch_log_append (int file_desc, const char *buffer, 
size_t len){
 
 return NOTMUCH_STATUS_SUCCESS;
 }
+
+notmuch_status_t
+notmuch_log_string_pair(void *ctx, int log_fd,
+   const char *string1, const char *string2){
+
+char *quoted1, *quoted2, *buffer;
+
+quoted1 = json_quote_str (ctx, string1);
+quoted2 = json_quote_str (ctx, string2);
+
+buffer = talloc_asprintf (ctx, %ld %s %s\n,
+ (long)time(NULL),
+ quoted1, quoted2);
+
+return notmuch_log_append (log_fd, buffer, strlen(buffer));
+}
-- 
1.7.1

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


notmuch-next branch

2010-10-11 Thread Felipe Contreras
Hi,

I think many people agree notmuch mainline has been rather slow. So
I'm proposing to have notmuch-next branch, either on github or
gitorious (please vote).

More than one person should have write access to this repo, but some
guidelines should be in place. I propose that patches should be
signed-off-by at least another person in the mailing list before
pushing. It would be nice if this is how the mainline branch works,
but we don't need to wait for that to happen. We need to vote on who
are the people to have write access.

Also, we need to agree which patches to start with and how. One
proposal would be to propose and vote here, another would be to resend
them and wait for signed-off-by's.

What do you think?

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


Re: notmuch-next branch

2010-10-11 Thread Servilio Afre Puentes
On 11 October 2010 14:45, Felipe Contreras felipe.contre...@gmail.com wrote:
 Hi,

 I think many people agree notmuch mainline has been rather slow. So
 I'm proposing to have notmuch-next branch, either on github or
 gitorious (please vote).

+1 for gitorious, you can use OpenID and their code is available (for
me a sign of more faith in free software than the Github people).

An alternative would be to have a list of git branches in the wiki,
with description, clone URL, etc.

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


Re: notmuch-next branch

2010-10-11 Thread Jameson Rollins
On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras 
felipe.contre...@gmail.com wrote:
 I think many people agree notmuch mainline has been rather slow. So
 I'm proposing to have notmuch-next branch, either on github or
 gitorious (please vote).
 
 More than one person should have write access to this repo, but some
 guidelines should be in place. I propose that patches should be
 signed-off-by at least another person in the mailing list before
 pushing. It would be nice if this is how the mainline branch works,
 but we don't need to wait for that to happen. We need to vote on who
 are the people to have write access.

I think this generally sounds like a fine idea, but I don't see why we
need a single central repo that multiple people need access to.  The
whole point of git is to allow for distributed development without need
for a central repo.

In this case, folks can just merge the patches they're interested in
into a next branch in their own personal repos, publish them where
ever they want, and then every body can just keep their next branches
synced with each other.  As consensus is reached, the next release will
emerge.

jamie.


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


Re: notmuch-next branch

2010-10-11 Thread Servilio Afre Puentes
On 11 October 2010 15:01, Jameson Rollins jroll...@finestructure.net wrote:
 On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras 
 felipe.contre...@gmail.com wrote:
 I think many people agree notmuch mainline has been rather slow. So
 I'm proposing to have notmuch-next branch, either on github or
 gitorious (please vote).

 More than one person should have write access to this repo, but some
 guidelines should be in place. I propose that patches should be
 signed-off-by at least another person in the mailing list before
 pushing. It would be nice if this is how the mainline branch works,
 but we don't need to wait for that to happen. We need to vote on who
 are the people to have write access.

 I think this generally sounds like a fine idea, but I don't see why we
 need a single central repo that multiple people need access to.  The
 whole point of git is to allow for distributed development without need
 for a central repo.

 In this case, folks can just merge the patches they're interested in
 into a next branch in their own personal repos, publish them where
 ever they want, and then every body can just keep their next branches
 synced with each other.  As consensus is reached, the next release will
 emerge.

+1 and maintaining a list of these repos in the wiki ;)

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


Re: notmuch-next branch

2010-10-11 Thread Jed Brown
On Mon, Oct 11, 2010 at 22:00, Jameson Rollins
jroll...@finestructure.net wrote:
 As long as all the repos are synced, then you only need to track one.
 But notmuch already has official repos [0], and making another
 pseudo-official repo will probably just makes things more confusing.

Patches show up in a different order in each person's personal, but
'synced' repository.  Then you need a mess of merges to actually get
them synced (if they are published, you can't rebase).

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


sluk, rss and notmuch - some use cases

2010-10-11 Thread Kristoffer Ström

I just wrote a simple script to turn rss feeds into notmuch-parsable 
directories.

Script and docs available at: http://github.com/krl/sluk/

I had run into problems with both of the two other solutions for this i know

feed2imap: problems with threading consuming 100% cpu somehow (seems like a 
local problem, only happended from cron), also it started messing up the 
maildir writing.
rss2emai: downside that you need to send mail when you just want to write it in 
a directory. also had encoding issues with this.

I use this to read all my rss, and tag the ones i find interesting with 
recommended, thereafter i use

http://github.com/albins/notmuch-to-feed

...to generate a feed from this tag, to spam my friends and enemies.

Feel free to yell at me if anything breaks.

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


Re: notmuch-next branch

2010-10-11 Thread Felipe Contreras
On Mon, Oct 11, 2010 at 10:01 PM, Jameson Rollins
jroll...@finestructure.net wrote:
 On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras 
 felipe.contre...@gmail.com wrote:
 I think many people agree notmuch mainline has been rather slow. So
 I'm proposing to have notmuch-next branch, either on github or
 gitorious (please vote).

 More than one person should have write access to this repo, but some
 guidelines should be in place. I propose that patches should be
 signed-off-by at least another person in the mailing list before
 pushing. It would be nice if this is how the mainline branch works,
 but we don't need to wait for that to happen. We need to vote on who
 are the people to have write access.

 I think this generally sounds like a fine idea, but I don't see why we
 need a single central repo that multiple people need access to.  The
 whole point of git is to allow for distributed development without need
 for a central repo.

And yet, git is hosted in a central repo. Different projects have
different needs, and this one seems to need a place to cook up
patches, having multiple committers there seems like it would work.
Note that this wouldn't be the main repo, it would be preparing stage.

 In this case, folks can just merge the patches they're interested in
 into a next branch in their own personal repos, publish them where
 ever they want, and then every body can just keep their next branches
 synced with each other.  As consensus is reached, the next release will
 emerge.

That might also work, it would be the first project I see doing that
though. But what I worry is the ordering of the patches; we might have
applied the same patches, but they would appear as totally different
branches to a 3rd party, and of course merging other people's 'next'
branches would create a total mess. There should be one repo that has
the latest and greatest 'next' branch that everybody can rebase into,
like the current 'master'.

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