Excerpts from David Bremner's message of January 17, 2015 13:29:
> Gaute Hope writes:
>
>>
>> Hi David,
>>
>> Would it be possible with an error code that I could compare against in
>> stead? It would then work a bit like a global instance of the gmime
>> error. It could even be a preparation
Gaute Hope writes:
>
> Hi David,
>
> Would it be possible with an error code that I could compare against in
> stead? It would then work a bit like a global instance of the gmime
> error. It could even be a preparation step against a gmime-error-style
> solution in the far future.
>
> I am sure
Excerpts from David Bremner's message of December 31, 2014 9:28:
> Gaute Hope writes:
>
>> I can work around this by checking for a NULL pointer returned from
>> notmuch_query_search_threads () and re-open the database
>> (notmuch_database_close () -> notmuch_database_open ()). But I have no
>>
Excerpts from David Bremner's message of December 31, 2014 9:28:
Gaute Hope e...@gaute.vetsj.com writes:
I can work around this by checking for a NULL pointer returned from
notmuch_query_search_threads () and re-open the database
(notmuch_database_close () - notmuch_database_open ()). But I
Gaute Hope e...@gaute.vetsj.com writes:
Hi David,
Would it be possible with an error code that I could compare against in
stead? It would then work a bit like a global instance of the gmime
error. It could even be a preparation step against a gmime-error-style
solution in the far future.
Excerpts from David Bremner's message of January 17, 2015 13:29:
Gaute Hope e...@gaute.vetsj.com writes:
Hi David,
Would it be possible with an error code that I could compare against in
stead? It would then work a bit like a global instance of the gmime
error. It could even be a preparation
Gaute Hope writes:
> I can work around this by checking for a NULL pointer returned from
> notmuch_query_search_threads () and re-open the database
> (notmuch_database_close () -> notmuch_database_open ()). But I have no
> way of knowing programatically if this really is the error that has
>
Gaute Hope e...@gaute.vetsj.com writes:
I can work around this by checking for a NULL pointer returned from
notmuch_query_search_threads () and re-open the database
(notmuch_database_close () - notmuch_database_open ()). But I have no
way of knowing programatically if this really is the error
On Thu, Aug 21, 2014 at 10:59 AM, Gaute Hope wrote:
> For portability I would suggest starting to move towards the GError
> scheme provided by glib (also used by gmime). This is a somewhat major
> effort though since ensuring that error propagation is done right [0] is
> somewhat tricky. It
Gaute Hope wrote on Mon, 11 Aug 2014 14:17:54 +0200:
> Hi,
>
> I've been working on an application that keeps a read-only handle on
> the notmuch database open for a long time. In some cases when a new
> message is added along with some renames of other messages using
> 'notmuch new' while the
Gaute Hope e...@gaute.vetsj.com wrote on Mon, 11 Aug 2014 14:17:54 +0200:
Hi,
I've been working on an application that keeps a read-only handle on
the notmuch database open for a long time. In some cases when a new
message is added along with some renames of other messages using
'notmuch new'
On Thu, Aug 21, 2014 at 10:59 AM, Gaute Hope e...@gaute.vetsj.com wrote:
For portability I would suggest starting to move towards the GError
scheme provided by glib (also used by gmime). This is a somewhat major
effort though since ensuring that error propagation is done right [0] is
somewhat
Hi,
I've been working on an application that keeps a read-only handle on
the notmuch database open for a long time. In some cases when a new
message is added along with some renames of other messages using
'notmuch new' while the application is running I get an Xapian
exception:
Hi,
I've been working on an application that keeps a read-only handle on
the notmuch database open for a long time. In some cases when a new
message is added along with some renames of other messages using
'notmuch new' while the application is running I get an Xapian
exception:
14 matches
Mail list logo