[PATCH] ruby: make sure the database is closed
2012/4/23 Felipe Contreras : > On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: > >> I'd rather not do this. >> Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 > > OK, I've read this.. So? You are one step close to what I thought you had thought. > The order in which Ruby's garbage-collector frees the database and > other objects is irrelevant, because with this patch we are not > manually freeing other objects, only the database. What I wanted was to make all objects "depending" on the database to be unusable once the database object is freed. Seeing that's not practically easy I decided to leave it to the user. > Sure, it's _better_ if the user calls close(), even better if it's > inside an 'ensure', and even better if blocks are used (which I am > using in most cases), but that's not *required*. If you have such a use case, I'm fine with that patch. I might push it in the next few days or get someone else to push it. > The user might just do: > > def foo > ?db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) > end > > That's perfectly fine in Ruby (although not ideal), since 'db' will > get garbage-collected. But nobody will be able to use the database > again until that process is killed. > > You think that's correct? Yes that is correct. I have not thought about this. I'd say it's a partial misunderstanding on my part due to lack of (and/or too much) vodka. > -- > Felipe Contreras -alip
[PATCH v3 1/2] cli: make --entire-thread=false work for format=json.
Quoth Mark Walters on Apr 21 at 10:15 am:
> The --entire-thread option in notmuch-show.c defaults to true when
> format=json. Previously there was no way to turn this off. This patch
> makes it respect --entire-thread=false.
>
> The one subtlety is that we initialise a notmuch_bool_t to -1 to
> indicate that the option parsing has not set it. This allows the code
> to distinguish between the option being omitted from the command line,
> and the option being set to false on the command line.
>
> Finally, all formats except Json can output empty messages for non
> entire-thread, but in Json format we need to output {} to keep the
> other elements (e.g. the replies to this message) in the correct
> place.
> ---
> notmuch-show.c | 34 +-
> 1 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/notmuch-show.c b/notmuch-show.c
> index da4a797..327c263 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -800,6 +800,16 @@ format_part_raw (unused (const void *ctx), mime_node_t
> *node,
> }
>
> static notmuch_status_t
> +show_null_message (const notmuch_show_format_t *format)
> +{
> +/* For all formats except json an empty message output is valid;
> + * for json we need the braces.*/
> +if (format == &format_json)
This should probably be specified as a field in the format, rather
than using a hard-coded dispatch. It could even be a plain string
field that you could fputs in show_messages.
> + printf ("{}");
This is a definite improvement over the current strangeness, but I
think 'null' would be better than an empty object. null is a clearly
distinguished value, rather than something that initially has a
message-like type, but then isn't a message.
You should also update devel/schemata to reflect this change.
> +return NOTMUCH_STATUS_SUCCESS;
> +}
> +
> +static notmuch_status_t
> show_message (void *ctx,
> const notmuch_show_format_t *format,
> notmuch_message_t *message,
> @@ -862,11 +872,13 @@ show_messages (void *ctx,
> if (status && !res)
> res = status;
> next_indent = indent + 1;
> -
> - if (!status && format->message_set_sep)
> - fputs (format->message_set_sep, stdout);
> + } else {
> + status = show_null_message (format);
> }
>
> + if (!status && format->message_set_sep)
> + fputs (format->message_set_sep, stdout);
> +
> status = show_messages (ctx,
> format,
> notmuch_message_get_replies (message),
I believe the stuff above could be a separate patch from the stuff
below.
> @@ -984,7 +996,13 @@ notmuch_show_command (void *ctx, unused (int argc),
> unused (char *argv[]))
> char *query_string;
> int opt_index, ret;
> const notmuch_show_format_t *format = &format_text;
> -notmuch_show_params_t params = { .part = -1, .omit_excluded = TRUE };
> +
> +/* We abuse the notmuch_bool_t variable params.entire-thread by
> + * setting it to -1 to denote that the command line parsing has
> + * not set it. We ensure it is set to TRUE or FALSE before passing
> + * it to any other function.*/
> +notmuch_show_params_t params = { .part = -1, .entire_thread = -1 };
> +
> int format_sel = NOTMUCH_FORMAT_NOT_SPECIFIED;
> notmuch_bool_t verify = FALSE;
> int exclude = EXCLUDE_TRUE;
> @@ -1024,7 +1042,9 @@ notmuch_show_command (void *ctx, unused (int argc),
> unused (char *argv[]))
> switch (format_sel) {
> case NOTMUCH_FORMAT_JSON:
> format = &format_json;
> - params.entire_thread = TRUE;
> + /* JSON defaults to entire-thread TRUE */
> + if (params.entire_thread == -1)
> + params.entire_thread = TRUE;
> break;
> case NOTMUCH_FORMAT_TEXT:
> format = &format_text;
> @@ -1046,6 +1066,10 @@ notmuch_show_command (void *ctx, unused (int argc),
> unused (char *argv[]))
> params.raw = TRUE;
> break;
> }
> +/* Default is entire-thread = FALSE except for format=json which
> + * is dealt with above. */
> +if (params.entire_thread == -1)
> + params.entire_thread = FALSE;
>
> if (params.decrypt || verify) {
> #ifdef GMIME_ATLEAST_26
[PATCH] ruby: make sure the database is closed
Quoth Felipe Contreras on Apr 24 at 3:45 am: > On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: > > 2012/4/24 Felipe Contreras : > > >> Personally I don't see why an object, like say a query would remain > >> working correctly after the database is gone, either by calling > >> .close() directly, or just loosing the pointer to the original object. > >> I don't think users would expect that, or, even if they somehow found > >> it useful, that most likely would be very seldom, and hardly worth > >> worrying about it. > > > > Working correctly is not expected but wouldn't it be more appropriate > > to throw an exception rather than dumping core or printing on standard > > error? > > Sure, if that was possible. > > > I wonder whether we can make both work somehow. > > Maybe by using talloc explicitly and keeping reference pointers? > > I don't know whether it's worth bothering. > > Maybe, I don't see how, that's just not how C works. Maybe talloc does > have some way to figure out if a pointer has been freed, but I doubt > that, and I can't find it by grepping through the API. > > Another option would be hook into talloc's destructor so we know when > an object is freed and taint it, but then we would be overriding > notmuch's destructor, and there's no way around that (unless we tap > into talloc's internal structures). A way to workaround that would be > to modify notmuch's API so that we can specify a destructor for > notmuch objects, but that would be tedious, and I doubt a lof people > beside us would benefit from that. I believe (though I might be wrong) that bindings could simply maintain their own talloc references to C objects returned by libnotmuch to prevent them from being freed until the wrapper object is garbage collected. This would require modifying all of the library's _destroy functions to use talloc_find_parent_bytype and talloc_unlink instead of simply calling talloc_free, but I don't think this change would be particularly invasive and it certainly wouldn't affect the library interface.
Re: [PATCH v3 1/2] cli: make --entire-thread=false work for format=json.
Quoth Mark Walters on Apr 21 at 10:15 am:
> The --entire-thread option in notmuch-show.c defaults to true when
> format=json. Previously there was no way to turn this off. This patch
> makes it respect --entire-thread=false.
>
> The one subtlety is that we initialise a notmuch_bool_t to -1 to
> indicate that the option parsing has not set it. This allows the code
> to distinguish between the option being omitted from the command line,
> and the option being set to false on the command line.
>
> Finally, all formats except Json can output empty messages for non
> entire-thread, but in Json format we need to output {} to keep the
> other elements (e.g. the replies to this message) in the correct
> place.
> ---
> notmuch-show.c | 34 +-
> 1 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/notmuch-show.c b/notmuch-show.c
> index da4a797..327c263 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -800,6 +800,16 @@ format_part_raw (unused (const void *ctx), mime_node_t
> *node,
> }
>
> static notmuch_status_t
> +show_null_message (const notmuch_show_format_t *format)
> +{
> +/* For all formats except json an empty message output is valid;
> + * for json we need the braces.*/
> +if (format == &format_json)
This should probably be specified as a field in the format, rather
than using a hard-coded dispatch. It could even be a plain string
field that you could fputs in show_messages.
> + printf ("{}");
This is a definite improvement over the current strangeness, but I
think 'null' would be better than an empty object. null is a clearly
distinguished value, rather than something that initially has a
message-like type, but then isn't a message.
You should also update devel/schemata to reflect this change.
> +return NOTMUCH_STATUS_SUCCESS;
> +}
> +
> +static notmuch_status_t
> show_message (void *ctx,
> const notmuch_show_format_t *format,
> notmuch_message_t *message,
> @@ -862,11 +872,13 @@ show_messages (void *ctx,
> if (status && !res)
> res = status;
> next_indent = indent + 1;
> -
> - if (!status && format->message_set_sep)
> - fputs (format->message_set_sep, stdout);
> + } else {
> + status = show_null_message (format);
> }
>
> + if (!status && format->message_set_sep)
> + fputs (format->message_set_sep, stdout);
> +
> status = show_messages (ctx,
> format,
> notmuch_message_get_replies (message),
I believe the stuff above could be a separate patch from the stuff
below.
> @@ -984,7 +996,13 @@ notmuch_show_command (void *ctx, unused (int argc),
> unused (char *argv[]))
> char *query_string;
> int opt_index, ret;
> const notmuch_show_format_t *format = &format_text;
> -notmuch_show_params_t params = { .part = -1, .omit_excluded = TRUE };
> +
> +/* We abuse the notmuch_bool_t variable params.entire-thread by
> + * setting it to -1 to denote that the command line parsing has
> + * not set it. We ensure it is set to TRUE or FALSE before passing
> + * it to any other function.*/
> +notmuch_show_params_t params = { .part = -1, .entire_thread = -1 };
> +
> int format_sel = NOTMUCH_FORMAT_NOT_SPECIFIED;
> notmuch_bool_t verify = FALSE;
> int exclude = EXCLUDE_TRUE;
> @@ -1024,7 +1042,9 @@ notmuch_show_command (void *ctx, unused (int argc),
> unused (char *argv[]))
> switch (format_sel) {
> case NOTMUCH_FORMAT_JSON:
> format = &format_json;
> - params.entire_thread = TRUE;
> + /* JSON defaults to entire-thread TRUE */
> + if (params.entire_thread == -1)
> + params.entire_thread = TRUE;
> break;
> case NOTMUCH_FORMAT_TEXT:
> format = &format_text;
> @@ -1046,6 +1066,10 @@ notmuch_show_command (void *ctx, unused (int argc),
> unused (char *argv[]))
> params.raw = TRUE;
> break;
> }
> +/* Default is entire-thread = FALSE except for format=json which
> + * is dealt with above. */
> +if (params.entire_thread == -1)
> + params.entire_thread = FALSE;
>
> if (params.decrypt || verify) {
> #ifdef GMIME_ATLEAST_26
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] ruby: make sure the database is closed
Quoth Felipe Contreras on Apr 24 at 3:45 am: > On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: > > 2012/4/24 Felipe Contreras : > > >> Personally I don't see why an object, like say a query would remain > >> working correctly after the database is gone, either by calling > >> .close() directly, or just loosing the pointer to the original object. > >> I don't think users would expect that, or, even if they somehow found > >> it useful, that most likely would be very seldom, and hardly worth > >> worrying about it. > > > > Working correctly is not expected but wouldn't it be more appropriate > > to throw an exception rather than dumping core or printing on standard > > error? > > Sure, if that was possible. > > > I wonder whether we can make both work somehow. > > Maybe by using talloc explicitly and keeping reference pointers? > > I don't know whether it's worth bothering. > > Maybe, I don't see how, that's just not how C works. Maybe talloc does > have some way to figure out if a pointer has been freed, but I doubt > that, and I can't find it by grepping through the API. > > Another option would be hook into talloc's destructor so we know when > an object is freed and taint it, but then we would be overriding > notmuch's destructor, and there's no way around that (unless we tap > into talloc's internal structures). A way to workaround that would be > to modify notmuch's API so that we can specify a destructor for > notmuch objects, but that would be tedious, and I doubt a lof people > beside us would benefit from that. I believe (though I might be wrong) that bindings could simply maintain their own talloc references to C objects returned by libnotmuch to prevent them from being freed until the wrapper object is garbage collected. This would require modifying all of the library's _destroy functions to use talloc_find_parent_bytype and talloc_unlink instead of simply calling talloc_free, but I don't think this change would be particularly invasive and it certainly wouldn't affect the library interface. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: > I'd rather not do this. > Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 OK, I've read this.. So? The order in which Ruby's garbage-collector frees the database and other objects is irrelevant, because with this patch we are not manually freeing other objects, only the database. Sure, it's _better_ if the user calls close(), even better if it's inside an 'ensure', and even better if blocks are used (which I am using in most cases), but that's not *required*. The user might just do: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end That's perfectly fine in Ruby (although not ideal), since 'db' will get garbage-collected. But nobody will be able to use the database again until that process is killed. You think that's correct? -- Felipe Contreras
Re: [PATCH] ruby: make sure the database is closed
On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel wrote: > 2012/4/24 Felipe Contreras : >> Personally I don't see why an object, like say a query would remain >> working correctly after the database is gone, either by calling >> .close() directly, or just loosing the pointer to the original object. >> I don't think users would expect that, or, even if they somehow found >> it useful, that most likely would be very seldom, and hardly worth >> worrying about it. > > Working correctly is not expected but wouldn't it be more appropriate > to throw an exception rather than dumping core or printing on standard error? Sure, if that was possible. > I wonder whether we can make both work somehow. > Maybe by using talloc explicitly and keeping reference pointers? > I don't know whether it's worth bothering. Maybe, I don't see how, that's just not how C works. Maybe talloc does have some way to figure out if a pointer has been freed, but I doubt that, and I can't find it by grepping through the API. Another option would be hook into talloc's destructor so we know when an object is freed and taint it, but then we would be overriding notmuch's destructor, and there's no way around that (unless we tap into talloc's internal structures). A way to workaround that would be to modify notmuch's API so that we can specify a destructor for notmuch objects, but that would be tedious, and I doubt a lof people beside us would benefit from that. In the meantime, it doesn't hurt to apply this patch. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
2012/4/23 Felipe Contreras :
> If the Ruby code does not manually close the database, we need to make
> sure it's closed when garbage collected.
>
> In Ruby, users are not _required_ to close, the garbage collector should
> take care of that.
>
> Signed-off-by: Felipe Contreras
> ---
> ?bindings/ruby/database.c | ? ?8 +++-
> ?1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
> index 982fd59..7b2ed47 100644
> --- a/bindings/ruby/database.c
> +++ b/bindings/ruby/database.c
> @@ -20,10 +20,16 @@
>
> ?#include "defs.h"
>
> +static void
> +database_free (void *p)
> +{
> + ? ?notmuch_database_close (p);
> +}
> +
> ?VALUE
> ?notmuch_rb_database_alloc (VALUE klass)
> ?{
> - ? ?return Data_Wrap_Struct (klass, NULL, NULL, NULL);
> + ? ?return Data_Wrap_Struct (klass, NULL, database_free, NULL);
> ?}
>
> ?/*
> --
> 1.7.10
>
I'd rather not do this.
Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324
-alip
Re: [PATCH] ruby: make sure the database is closed
2012/4/24 Felipe Contreras : > On Mon, Apr 23, 2012 at 11:43 PM, Ali Polatel wrote: >> 2012/4/23 Felipe Contreras : >>> On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: >>> I'd rather not do this. Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 >>> >>> OK, I've read this.. So? >> >> You are one step close to what I thought you had thought. > > I don't parse that. I meant that _now_ I've read it. Sorry, my subconscious likes to barf on emails every now and then. >>> The order in which Ruby's garbage-collector frees the database and >>> other objects is irrelevant, because with this patch we are not >>> manually freeing other objects, only the database. >> >> What I wanted was to make all objects "depending" on the database to be >> unusable >> once the database object is freed. Seeing that's not practically easy >> I decided to leave >> it to the user. > > Well, sure, but if the user has problems, the user can keep the > database object around. > > Personally I don't see why an object, like say a query would remain > working correctly after the database is gone, either by calling > .close() directly, or just loosing the pointer to the original object. > I don't think users would expect that, or, even if they somehow found > it useful, that most likely would be very seldom, and hardly worth > worrying about it. Working correctly is not expected but wouldn't it be more appropriate to throw an exception rather than dumping core or printing on standard error? >>> Sure, it's _better_ if the user calls close(), even better if it's >>> inside an 'ensure', and even better if blocks are used (which I am >>> using in most cases), but that's not *required*. >> >> If you have such a use case, I'm fine with that patch. >> I might push it in the next few days or get someone else to push it. > > I did at some point, not sure if I do now. But that's beside the > point, the point is that it really does happen. > >>> The user might just do: >>> >>> def foo >>> db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) >>> end >>> >>> That's perfectly fine in Ruby (although not ideal), since 'db' will >>> get garbage-collected. But nobody will be able to use the database >>> again until that process is killed. >>> >>> You think that's correct? >> >> Yes that is correct. I have not thought about this. >> I'd say it's a partial misunderstanding on my part due to lack of >> (and/or too much) vodka. > > Well, there's only two options. > > a) This works: > > def foo > db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) > end > > (as in; the database gets closed eventually) > > b) This works: > > def start_query(search) > db = Notmuch::Database.new($db_name) > return db.query(search) > end > > (as in; the query returned would keep working properly) > > I personally don't see why anybody would want b), and if they have > problems with code like that, I think it's obvious to see why. > > I think we should go for a) and thus apply the patch. I wonder whether we can make both work somehow. Maybe by using talloc explicitly and keeping reference pointers? I don't know whether it's worth bothering. > Cheers. Cheers > -- > Felipe Contreras -alip ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
On Mon, Apr 23, 2012 at 12:39 PM, Charlie Allom wrote: > /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 > -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE > ?-I/opt/local/include -fno-common -pipe -O2 -arch x86_64 ?-fno-common -pipe > -fno-common ?-arch x86_64 -c database.c Where is the output file defined? There should be a -o database.o there. Weird. This is what I have in my machine: gcc -I. -I/usr/include/ruby-1.9.1/x86_64-linux -I/usr/include/ruby-1.9.1/ruby/backward -I/usr/include/ruby-1.9.1 -I. -I../../lib -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -o messages.o -c messages.c -- Felipe Contreras
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
Re: [PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 11:43 PM, Ali Polatel wrote: > 2012/4/23 Felipe Contreras : >> On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: >> >>> I'd rather not do this. >>> Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 >> >> OK, I've read this.. So? > > You are one step close to what I thought you had thought. I don't parse that. I meant that _now_ I've read it. >> The order in which Ruby's garbage-collector frees the database and >> other objects is irrelevant, because with this patch we are not >> manually freeing other objects, only the database. > > What I wanted was to make all objects "depending" on the database to be > unusable > once the database object is freed. Seeing that's not practically easy > I decided to leave > it to the user. Well, sure, but if the user has problems, the user can keep the database object around. Personally I don't see why an object, like say a query would remain working correctly after the database is gone, either by calling .close() directly, or just loosing the pointer to the original object. I don't think users would expect that, or, even if they somehow found it useful, that most likely would be very seldom, and hardly worth worrying about it. >> Sure, it's _better_ if the user calls close(), even better if it's >> inside an 'ensure', and even better if blocks are used (which I am >> using in most cases), but that's not *required*. > > If you have such a use case, I'm fine with that patch. > I might push it in the next few days or get someone else to push it. I did at some point, not sure if I do now. But that's beside the point, the point is that it really does happen. >> The user might just do: >> >> def foo >> db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) >> end >> >> That's perfectly fine in Ruby (although not ideal), since 'db' will >> get garbage-collected. But nobody will be able to use the database >> again until that process is killed. >> >> You think that's correct? > > Yes that is correct. I have not thought about this. > I'd say it's a partial misunderstanding on my part due to lack of > (and/or too much) vodka. Well, there's only two options. a) This works: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end (as in; the database gets closed eventually) b) This works: def start_query(search) db = Notmuch::Database.new($db_name) return db.query(search) end (as in; the query returned would keep working properly) I personally don't see why anybody would want b), and if they have problems with code like that, I think it's obvious to see why. I think we should go for a) and thus apply the patch. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
[PATCH 6/7] ruby: Use notmuch_database_destroy instead of notmuch_database_close
Hi,
On Sun, Apr 22, 2012 at 3:07 PM, Justus Winter
<4winter at informatik.uni-hamburg.de> wrote:
> Adapt the ruby bindings to the notmuch_database_close split.
>
> Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de>
> ---
> ?bindings/ruby/database.c | ? ?2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
> index 982fd59..ba9a139 100644
> --- a/bindings/ruby/database.c
> +++ b/bindings/ruby/database.c
> @@ -110,7 +110,7 @@ notmuch_rb_database_close (VALUE self)
> ? ? notmuch_database_t *db;
>
> ? ? Data_Get_Notmuch_Database (self, db);
> - ? ?notmuch_database_close (db);
> + ? ?notmuch_database_destroy (db);
> ? ? DATA_PTR (self) = NULL;
>
> ? ? return Qnil;
> --
I don't think this is the right approach. If database_destroy truly
destroys the object, then we would want to do it only at garbage
collection, when it's not accessible any more. What if I want to
re-use the database from the Ruby code?
This would probably be better:
-- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_destroy (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
Felipe Contreras
[ANN] New awesome vim plug-in using Ruby bindings
Hi, If you reply to all, remove Ryan Harper, as the address doesn't work. Or just reply here. Cheers. 2012/4/23 Felipe Contreras : > I've never been particularly happy with the code of the vim plug-in, > but it sort of did the job, after some fixes, and has been working > great so far for most of my needs even though it's clearly very rough > on the edges. > > However, I'm recently in need of been able to read HTML mails, and > just trying to add that code was a nightmare, so I decided to look for > alternatives, including Anton's Python vim plug-in (which is nice, but > doesn't have support for that), and even learning emacs, to use what > most people here use (but it turns out the HTML messages don't work > correctly there either). I also tried the various mutt+notmuch > options, and none fit the bill. > > So, since I'm a big fan of Ruby, I decided to try my luck writing a > plug-in from scratch. It took me one weekend, but I'm pretty happy > with the result. This plug-in has already essentially all the > functionality of the current one, but it's much, *much* simpler (only > 600) lines of code. > > And in addition has many more features: > > ?* Gradual searches; you don't have to wait for the whole search to finish, > ? sort of like the 'less' command > ?* Proper multi-part handling; finds out if there's text/plain, or if > ? text/html, converts it using elinks > ?* Extract all attachments > ?* Open message with mutt (or any external application that can open an mbox) > ?* More proper UTF-8 handling > ?* Configurable key mappings > ?* Much simpler, cleaner, beautiful, and extensible code (only 600 lines!) > > I just added support to reply mails today, and after trying a bit I > got complaints from the vger.kernel.org server, but people using mutt > have had the same complaint, so I don't know, I wouldn't reply totally > on that. *But* you can open the mail with mutt, or any other client > that you want, as a fall-back option (the command to run is > configurable). > > Sure, it depends on the Ruby bindings from notmuch (but those are easy > to compile), and on the 'mail' library from Ruby (easy to install), > but it makes things much, *much* easier. There might be ways to make > certain dependencies optional, and make this, and the current plug-in > converge somehow (maybe even the python one too), but for now I don't > see any reason to look back. > > I can't wait to start using it for real :) > > Enjoy ;) > > https://github.com/felipec/notmuch-vim-ruby > > P.S. I CC'ed a bunch of people that have showed interest in the vim > interface, I hope you don't mind -- Felipe Contreras
[ANN] New awesome vim plug-in using Ruby bindings
On Mon, Apr 23, 2012 at 6:41 AM, Adam Wolfe Gordon wrote: > Hi Felipe, > > This work sounds nice - it's good to have lots of interface choices. > One question below: > > On Sun, Apr 22, 2012 at 19:12, Felipe Contreras > wrote: >> doesn't have support for that), and even learning emacs, to use what >> most people here use (but it turns out the HTML messages don't work >> correctly there either). I also tried the various mutt+notmuch > > HTML emails should work properly in emacs, and work even better if you > have w3.el installed. Replying to HTML emails isn't in git yet, but > there are patches for it in progress [1]. If there's a bug in the HTML > support, we should probably fix it, so could you explain what doesn't > work for you? I do have w3.el installed. I can read the HTML, but when scrolling and selecting there are glitches, and when replying nothing gets quoted. Cheers. -- Felipe Contreras
[PATCH 6/7] ruby: Use notmuch_database_destroy instead of notmuch_database_close
Quoting Felipe Contreras (2012-04-23 14:36:33) > I don't think this is the right approach. If database_destroy truly > destroys the object, then we would want to do it only at garbage > collection, when it's not accessible any more. What if I want to > re-use the database from the Ruby code? > > This would probably be better: > >[...] You're probably right, I don't know the ruby bindings at all, I just wanted to preserve the old behavior. You are welcome to refine the ruby bindings later (or maintain them, I *believe* they are unmaintained, the last change was back in october 2011), but let's get this patch series in first. Cheers, Justus
ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
On Mon, Apr 23, 2012 at 03:48:40PM +0300, Felipe Contreras wrote: > On Mon, Apr 23, 2012 at 12:39 PM, Charlie Allom > wrote: > > > /opt/local/bin/gcc-apple-4.2 -I. -I. > > -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include > > -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE ?-I/opt/local/include -fno-common -pipe > > -O2 -arch x86_64 ?-fno-common -pipe -fno-common ?-arch x86_64 -c database.c > > Where is the output file defined? There should be a -o database.o there. > Weird. it seems to be implicit: 14:03 capslock:notmuch/bindings/ruby% file database.o database.o: Mach-O 64-bit object x86_64 the -o is only needed when linking notmuch.bundle C. -- +442077294797 http://mediasp.com/
Re: [PATCH] ruby: make sure the database is closed
2012/4/23 Felipe Contreras : > On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: > >> I'd rather not do this. >> Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 > > OK, I've read this.. So? You are one step close to what I thought you had thought. > The order in which Ruby's garbage-collector frees the database and > other objects is irrelevant, because with this patch we are not > manually freeing other objects, only the database. What I wanted was to make all objects "depending" on the database to be unusable once the database object is freed. Seeing that's not practically easy I decided to leave it to the user. > Sure, it's _better_ if the user calls close(), even better if it's > inside an 'ensure', and even better if blocks are used (which I am > using in most cases), but that's not *required*. If you have such a use case, I'm fine with that patch. I might push it in the next few days or get someone else to push it. > The user might just do: > > def foo > db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) > end > > That's perfectly fine in Ruby (although not ideal), since 'db' will > get garbage-collected. But nobody will be able to use the database > again until that process is killed. > > You think that's correct? Yes that is correct. I have not thought about this. I'd say it's a partial misunderstanding on my part due to lack of (and/or too much) vodka. > -- > Felipe Contreras -alip ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
Hello, Has anyone seen this on OS X? I can't see what the linker must be doing. 10:36 capslock:notmuch/bindings/ruby% ruby extconf.rb checking for notmuch.h in ../../lib... yes checking for notmuch_database_create() in -lnotmuch... yes creating Makefile 10:36 capslock:notmuch/bindings/ruby% make /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c database.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c directory.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c filenames.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c init.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c message.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c messages.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c query.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c status.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c tags.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c thread.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c threads.c /opt/local/bin/gcc-apple-4.2 -dynamic -bundle -undefined suppress -flat_namespace -o notmuch.bundle database.o directory.o filenames.o init.o message.o messages.o query.o status.o tags.o thread.o threads.o -L. -L/opt/local/lib -L/opt/local/lib -L. -L/opt/local/lib -arch x86_64 -arch x86_64 -lruby -lnotmuch -lpthread -ldl -lobjc ld: duplicate symbol _notmuch_rb_cDatabase in directory.o and database.o for architecture x86_64 collect2: ld returned 1 exit status make: *** [notmuch.bundle] Error 1 10:37 capslock:notmuch/bindings/ruby% -- +442077294797 http://mediasp.com/
Re: [PATCH] ruby: make sure the database is closed
On Mon, Apr 23, 2012 at 5:04 PM, Ali Polatel wrote: > I'd rather not do this. > Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324 OK, I've read this.. So? The order in which Ruby's garbage-collector frees the database and other objects is irrelevant, because with this patch we are not manually freeing other objects, only the database. Sure, it's _better_ if the user calls close(), even better if it's inside an 'ensure', and even better if blocks are used (which I am using in most cases), but that's not *required*. The user might just do: def foo db = Notmuch::Database.new($db_name, :mode => Notmuch::MODE_READ_WRITE) end That's perfectly fine in Ruby (although not ideal), since 'db' will get garbage-collected. But nobody will be able to use the database again until that process is killed. You think that's correct? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
On Mon, Apr 23, 2012 at 05:53, Felipe Contreras wrote: > I do have w3.el installed. I can read the HTML, but when scrolling and > selecting there are glitches, and when replying nothing gets quoted. Ah, I see. As I said before, reply will work soon. The other issues sound like emacs/w3 problems, out of our control. Thanks for explaining. -- Adam
Re: [PATCH] ruby: make sure the database is closed
2012/4/23 Felipe Contreras :
> If the Ruby code does not manually close the database, we need to make
> sure it's closed when garbage collected.
>
> In Ruby, users are not _required_ to close, the garbage collector should
> take care of that.
>
> Signed-off-by: Felipe Contreras
> ---
> bindings/ruby/database.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
> index 982fd59..7b2ed47 100644
> --- a/bindings/ruby/database.c
> +++ b/bindings/ruby/database.c
> @@ -20,10 +20,16 @@
>
> #include "defs.h"
>
> +static void
> +database_free (void *p)
> +{
> + notmuch_database_close (p);
> +}
> +
> VALUE
> notmuch_rb_database_alloc (VALUE klass)
> {
> - return Data_Wrap_Struct (klass, NULL, NULL, NULL);
> + return Data_Wrap_Struct (klass, NULL, database_free, NULL);
> }
>
> /*
> --
> 1.7.10
>
I'd rather not do this.
Please read: http://comments.gmane.org/gmane.comp.lang.ruby.general/320324
-alip
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Mon, Apr 23, 2012 at 05:53, Felipe Contreras wrote: > I do have w3.el installed. I can read the HTML, but when scrolling and > selecting there are glitches, and when replying nothing gets quoted. Ah, I see. As I said before, reply will work soon. The other issues sound like emacs/w3 problems, out of our control. Thanks for explaining. -- Adam ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
On Mon, Apr 23, 2012 at 03:48:40PM +0300, Felipe Contreras wrote: > On Mon, Apr 23, 2012 at 12:39 PM, Charlie Allom wrote: > > > /opt/local/bin/gcc-apple-4.2 -I. -I. > > -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include > > -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe > > -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c database.c > > Where is the output file defined? There should be a -o database.o there. > Weird. it seems to be implicit: 14:03 capslock:notmuch/bindings/ruby% file database.o database.o: Mach-O 64-bit object x86_64 the -o is only needed when linking notmuch.bundle C. -- +442077294797 http://mediasp.com/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/7] ruby: Use notmuch_database_destroy instead of notmuch_database_close
Quoting Felipe Contreras (2012-04-23 14:36:33) > I don't think this is the right approach. If database_destroy truly > destroys the object, then we would want to do it only at garbage > collection, when it's not accessible any more. What if I want to > re-use the database from the Ruby code? > > This would probably be better: > >[...] You're probably right, I don't know the ruby bindings at all, I just wanted to preserve the old behavior. You are welcome to refine the ruby bindings later (or maintain them, I *believe* they are unmaintained, the last change was back in october 2011), but let's get this patch series in first. Cheers, Justus ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
On Mon, Apr 23, 2012 at 12:39 PM, Charlie Allom wrote: > /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 > -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE > -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe > -fno-common -arch x86_64 -c database.c Where is the output file defined? There should be a -o database.o there. Weird. This is what I have in my machine: gcc -I. -I/usr/include/ruby-1.9.1/x86_64-linux -I/usr/include/ruby-1.9.1/ruby/backward -I/usr/include/ruby-1.9.1 -I. -I../../lib -fPIC -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fPIC -o messages.o -c messages.c -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] ruby: make sure the database is closed
If the Ruby code does not manually close the database, we need to make
sure it's closed when garbage collected.
In Ruby, users are not _required_ to close, the garbage collector should
take care of that.
Signed-off-by: Felipe Contreras
---
bindings/ruby/database.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
index 982fd59..7b2ed47 100644
--- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_close (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
1.7.10
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/7] ruby: Use notmuch_database_destroy instead of notmuch_database_close
Hi,
On Sun, Apr 22, 2012 at 3:07 PM, Justus Winter
<4win...@informatik.uni-hamburg.de> wrote:
> Adapt the ruby bindings to the notmuch_database_close split.
>
> Signed-off-by: Justus Winter <4win...@informatik.uni-hamburg.de>
> ---
> bindings/ruby/database.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c
> index 982fd59..ba9a139 100644
> --- a/bindings/ruby/database.c
> +++ b/bindings/ruby/database.c
> @@ -110,7 +110,7 @@ notmuch_rb_database_close (VALUE self)
> notmuch_database_t *db;
>
> Data_Get_Notmuch_Database (self, db);
> - notmuch_database_close (db);
> + notmuch_database_destroy (db);
> DATA_PTR (self) = NULL;
>
> return Qnil;
> --
I don't think this is the right approach. If database_destroy truly
destroys the object, then we would want to do it only at garbage
collection, when it's not accessible any more. What if I want to
re-use the database from the Ruby code?
This would probably be better:
-- a/bindings/ruby/database.c
+++ b/bindings/ruby/database.c
@@ -20,10 +20,16 @@
#include "defs.h"
+static void
+database_free (void *p)
+{
+notmuch_database_destroy (p);
+}
+
VALUE
notmuch_rb_database_alloc (VALUE klass)
{
-return Data_Wrap_Struct (klass, NULL, NULL, NULL);
+return Data_Wrap_Struct (klass, NULL, database_free, NULL);
}
/*
--
Felipe Contreras
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANN] New awesome vim plug-in using Ruby bindings
Hi, If you reply to all, remove Ryan Harper, as the address doesn't work. Or just reply here. Cheers. 2012/4/23 Felipe Contreras : > I've never been particularly happy with the code of the vim plug-in, > but it sort of did the job, after some fixes, and has been working > great so far for most of my needs even though it's clearly very rough > on the edges. > > However, I'm recently in need of been able to read HTML mails, and > just trying to add that code was a nightmare, so I decided to look for > alternatives, including Anton's Python vim plug-in (which is nice, but > doesn't have support for that), and even learning emacs, to use what > most people here use (but it turns out the HTML messages don't work > correctly there either). I also tried the various mutt+notmuch > options, and none fit the bill. > > So, since I'm a big fan of Ruby, I decided to try my luck writing a > plug-in from scratch. It took me one weekend, but I'm pretty happy > with the result. This plug-in has already essentially all the > functionality of the current one, but it's much, *much* simpler (only > 600) lines of code. > > And in addition has many more features: > > * Gradual searches; you don't have to wait for the whole search to finish, > sort of like the 'less' command > * Proper multi-part handling; finds out if there's text/plain, or if > text/html, converts it using elinks > * Extract all attachments > * Open message with mutt (or any external application that can open an mbox) > * More proper UTF-8 handling > * Configurable key mappings > * Much simpler, cleaner, beautiful, and extensible code (only 600 lines!) > > I just added support to reply mails today, and after trying a bit I > got complaints from the vger.kernel.org server, but people using mutt > have had the same complaint, so I don't know, I wouldn't reply totally > on that. *But* you can open the mail with mutt, or any other client > that you want, as a fall-back option (the command to run is > configurable). > > Sure, it depends on the Ruby bindings from notmuch (but those are easy > to compile), and on the 'mail' library from Ruby (easy to install), > but it makes things much, *much* easier. There might be ways to make > certain dependencies optional, and make this, and the current plug-in > converge somehow (maybe even the python one too), but for now I don't > see any reason to look back. > > I can't wait to start using it for real :) > > Enjoy ;) > > https://github.com/felipec/notmuch-vim-ruby > > P.S. I CC'ed a bunch of people that have showed interest in the vim > interface, I hope you don't mind -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANN] New awesome vim plug-in using Ruby bindings
On Mon, Apr 23, 2012 at 6:41 AM, Adam Wolfe Gordon wrote: > Hi Felipe, > > This work sounds nice - it's good to have lots of interface choices. > One question below: > > On Sun, Apr 22, 2012 at 19:12, Felipe Contreras > wrote: >> doesn't have support for that), and even learning emacs, to use what >> most people here use (but it turns out the HTML messages don't work >> correctly there either). I also tried the various mutt+notmuch > > HTML emails should work properly in emacs, and work even better if you > have w3.el installed. Replying to HTML emails isn't in git yet, but > there are patches for it in progress [1]. If there's a bug in the HTML > support, we should probably fix it, so could you explain what doesn't > work for you? I do have w3.el installed. I can read the HTML, but when scrolling and selecting there are glitches, and when replying nothing gets quoted. Cheers. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[ANN] New awesome vim plug-in using Ruby bindings
Hi, I've never been particularly happy with the code of the vim plug-in, but it sort of did the job, after some fixes, and has been working great so far for most of my needs even though it's clearly very rough on the edges. However, I'm recently in need of been able to read HTML mails, and just trying to add that code was a nightmare, so I decided to look for alternatives, including Anton's Python vim plug-in (which is nice, but doesn't have support for that), and even learning emacs, to use what most people here use (but it turns out the HTML messages don't work correctly there either). I also tried the various mutt+notmuch options, and none fit the bill. So, since I'm a big fan of Ruby, I decided to try my luck writing a plug-in from scratch. It took me one weekend, but I'm pretty happy with the result. This plug-in has already essentially all the functionality of the current one, but it's much, *much* simpler (only 600) lines of code. And in addition has many more features: * Gradual searches; you don't have to wait for the whole search to finish, sort of like the 'less' command * Proper multi-part handling; finds out if there's text/plain, or if text/html, converts it using elinks * Extract all attachments * Open message with mutt (or any external application that can open an mbox) * More proper UTF-8 handling * Configurable key mappings * Much simpler, cleaner, beautiful, and extensible code (only 600 lines!) I just added support to reply mails today, and after trying a bit I got complaints from the vger.kernel.org server, but people using mutt have had the same complaint, so I don't know, I wouldn't reply totally on that. *But* you can open the mail with mutt, or any other client that you want, as a fall-back option (the command to run is configurable). Sure, it depends on the Ruby bindings from notmuch (but those are easy to compile), and on the 'mail' library from Ruby (easy to install), but it makes things much, *much* easier. There might be ways to make certain dependencies optional, and make this, and the current plug-in converge somehow (maybe even the python one too), but for now I don't see any reason to look back. I can't wait to start using it for real :) Enjoy ;) https://github.com/felipec/notmuch-vim-ruby P.S. I CC'ed a bunch of people that have showed interest in the vim interface, I hope you don't mind -- Felipe Contreras
ruby bindings on OS X are broken? (was Re: [ANN] New awesome vim plug-in using Ruby bindings)
Hello, Has anyone seen this on OS X? I can't see what the linker must be doing. 10:36 capslock:notmuch/bindings/ruby% ruby extconf.rb checking for notmuch.h in ../../lib... yes checking for notmuch_database_create() in -lnotmuch... yes creating Makefile 10:36 capslock:notmuch/bindings/ruby% make /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c database.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c directory.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c filenames.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c init.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c message.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c messages.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c query.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c status.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c tags.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c thread.c /opt/local/bin/gcc-apple-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin11 -I. -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -pipe -O2 -arch x86_64 -fno-common -pipe -fno-common -arch x86_64 -c threads.c /opt/local/bin/gcc-apple-4.2 -dynamic -bundle -undefined suppress -flat_namespace -o notmuch.bundle database.o directory.o filenames.o init.o message.o messages.o query.o status.o tags.o thread.o threads.o -L. -L/opt/local/lib -L/opt/local/lib -L. -L/opt/local/lib -arch x86_64 -arch x86_64 -lruby -lnotmuch -lpthread -ldl -lobjc ld: duplicate symbol _notmuch_rb_cDatabase in directory.o and database.o for architecture x86_64 collect2: ld returned 1 exit status make: *** [notmuch.bundle] Error 1 10:37 capslock:notmuch/bindings/ruby% -- +442077294797 http://mediasp.com/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3 1/4] emacs: Let the user choose where to compose new mails
Le 15 avril 2012 ? 16:52 CEST, David Bremner a ?crit : > Jameson Graef Rollins writes: > >> I think the issues that David was experiencing have to do with flakiness >> in emacs's dedicated windows, not in this patch itself. > > Thomas, > > Did you have a change to investigate this as proposed in > id:"87zke0aifa.fsf at thor.loria.fr"? David, Sorry for the delay. I did investigate a little bit, but I did not try to write a patch to fix the wrong behaviour in Emacs 23. AFAICT, Emacs 23 is just buggy in this case. By reading the code of message-send-and-exit and message-bury [1], here is what happens when you call message-send-buffer-and-exit with message-kill-buffer-on-exit set to nil: - message is sent - buffer is buried with burry-buffer - message-bury: if the window is dedicated and its frame not the only visible frame, then this frame is deleted which explains what happens in Emacs 23 both in daemon and non-daemon mode. In Emacs 24 [2], here is what happens: - message is sent - message-bury: buffer is buried with bury-buffer which is (obviously?) correct. Really, this looks like a bug in Emacs 23 to me. Emacs 24 has been fixed by Gnus commits [3] and [4] (maybe [3] is enough, I didn't try). Users of Emacs 23 can probably just use an up-to-date version of Gnus to have this issue fixed. So I'm not sure it would make sense to try to come up with a workaround in my patch, nor if it would be worth it. Maybe just adding a message suggesting Emacs 23 users to enable message-kill-buffer-on-exit if they use the Gnus version shipped with Emacs? Other than that, Jameson's commit [5] is exactly the same as the one in my tree with a better commit message, so I'm in favor of pulling it. [1] http://bzr.savannah.gnu.org/lh/emacs/emacs-23/annotate/head:/lisp/gnus/message.el [2] http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/lisp/gnus/message.el [3] http://git.gnus.org/cgit/gnus.git/commit/?id=30eb6d24d30bc028fce91a0c62044c5dc1fdd90e [4] http://git.gnus.org/cgit/gnus.git/commit/?id=e3fc7cb33eb07dd3b48cfc72f0cada1f1edbcb85 [5] id:"1334436137-6099-1-git-send-email-jrollins at finestructure.net" Regards, -- Thomas/Schnouki -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120423/270ce479/attachment.pgp>
