Re: notmuch version/Python bindings

[Sebastian Spaeth]

Hi there,
just tried to delete the notmuch packagr on pypi. While I am listed as the 
author, I do not own the package and it lists "Package Index Owner: Julian".

It might be that I have already transferred the ownership of the package, but I 
don't remember who Julian is. Has anyone else a clue?

Sebastian Spaeth
-- 
Sent from my mobile phone. Please excuse brevity.

Am 18. Februar 2017 16:14:49 MEZ schrieb David Bremner <da...@tethera.net>:
>Sebastian Spaeth <sebast...@sspaeth.de> writes:
>
>> Hi there, I did stop using notmuch, true. Let me know if I should
>hand
>> over administration or if I shouldnsimply delete the package on pypi.
>>
>
>Hi Sebastian;
>
>Thanks for the followup.  If no-one steps up to maintain by the end of
>next week, I'd say just delete them from pypi.
>
>I don't really think that "the notmuch project" needs to be involved in
>deciding who, if anyone, maintains a pypi package (anymore than we
>micromanage who maintains notmuch in various linux distros). I have a
>vague memory that Justus (nominally in charge of the python bindings)
>was not interested in pypi, but I could be wrong. In any case Justus
>not
>very active lately either.
>
>d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch version/Python bindings

[Sebastian Spaeth]

Hi there, I did stop using notmuch, true. Let me know if I should hand over 
administration or if I shouldnsimply delete the package on pypi.

Sebastian
-- 
Sent from my mobile phone. Please excuse brevity.

Am 16. Februar 2017 18:00:33 MEZ schrieb David Bremner :
>Aryeh Leib Taurog  writes:
>
>> Okay, makes sense.  Might I suggest a new release on pypi, then?
>
>I think Sebastian (listed as the pypi maintainer) somewhat lost
>interest
>in notmuch (since that version is 4 years old). I'm afraid I don't know
>anything about pypi, but I assume if someone else wanted to take over
>maintaining it, they should coordinate with Sebastian (in CC).
>
>d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

notmuch.readthedocs.org

[Sebastian Spaeth]

Am 16.11.2014 20:00, schrieb Ben Gamari:
> David Bremner  writes:
> 
>> It seems that this site has bitrotted.  I hit the build button and it
>> now builds the CLI docs instead of the python bindings.  I assume since
>> Sebastian has moved on from maintaining the bindings he's also not
>> intersted in maintaining this site. If someone would like to take over
>> and fix what needs to be fixed, then great, otherwise I'll ask the
>> readthedocs admins to purge the site. It seems like it should be
>> possible to have CLI and python docs in one sphinx tree, so maybe that's
>> something we can do upstream to help.

Let me know if I should be deleting the site. Or hand it over, or
something :-).

Sebastian


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: 

Re: notmuch.readthedocs.org

[Sebastian Spaeth]

Am 16.11.2014 20:00, schrieb Ben Gamari:
 David Bremner da...@tethera.net writes:
 
 It seems that this site has bitrotted.  I hit the build button and it
 now builds the CLI docs instead of the python bindings.  I assume since
 Sebastian has moved on from maintaining the bindings he's also not
 intersted in maintaining this site. If someone would like to take over
 and fix what needs to be fixed, then great, otherwise I'll ask the
 readthedocs admins to purge the site. It seems like it should be
 possible to have CLI and python docs in one sphinx tree, so maybe that's
 something we can do upstream to help.

Let me know if I should be deleting the site. Or hand it over, or
something :-).

Sebastian




signature.asc
Description: OpenPGP digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 7/7] python: wrap and use notmuch_database_destroy as destructor

[Sebastian Spaeth]

Austin Clements amdra...@mit.edu writes:
 (I think it also doesn't make sense to expose notmuch_database_destroy
 as a general, public method since it will free all of the other C
 objects out from under the bindings, resulting in exactly the double
 free-type crashes that you're trying to avoid.  It appears that none
 of the other Python classes have a destroy method.)

Agreed, that sounds right to me.

Sebastian


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

notmuch-poll and OfflineIMAP

[Sebastian Spaeth]

Adam Wolfe Gordon  wrote:
>
>I run offlineimap in autorefresh mode (with IDLE too, actually) and
>use a script based on inotify to update notmuch whenever new mail
>comes in: https://gist.github.com/1952483 . It sounds like some
>variant of this would probably work for you.

I actually plan to add new-message-hooks to offlineimap fairly soon.

Sebastian

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Message deletion wisdom

[Sebastian Spaeth]

Jameson Graef Rollins  wrote:
>So in summary, if you would like to "delete" messages, you can:
>
> * add a key binding to emacs (or your favorite ui) to add a "deleted"
>   tag to messages that you want to delete:
>
>(define-key notmuch-show-mode-map "d"
>  (lambda ()
>(interactive)
>(notmuch-show-tag-message "+deleted")))
>
> * add exclusion for messages with the "deleted" tag:
>
>notmuch config set search.exclude_tags deleted
>
> * and if you really want them purged from disk, delete them manually
>   with:
>
>notmuch search --output=files tag:deleted | xargs -l rm

Thanks Jamie, that ws a very helpful summary.

Sebastian

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

notmuch-poll and OfflineIMAP

[Sebastian Spaeth]

Jani Nikula  wrote:

>Jacek Generowicz  writes:
>
>> Hello,
>>
>> Would you have any advice on how to construct a notmuch-poll script
>> that would work well in concert with OfflineIMAP?  In particlular,
>how
>> can you avoid having to re-issue the IMAP account passwords?

>> Any words of wisdom?
>
>Offlineimap supports running hooks after syncing. Check if SIGUSR1 does
>that too. Then you could run notmuch new in the post sync hook.
>
>Also, notmuch new supports pre-new and post-new hooks. You could start
>or SIGUSR1 offlineimap in the pre-new hook. See man notmuch-hooks for

Offlineimap hooks work nicely for running notmuch scripts, i run it this way. 
Sending Sigusr1 will invoke that too, but I don't think that would be needed. 
It's mostly for peole running OfflineMap as a daemon

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Why not tags inside messages?

[Sebastian Spaeth]

>On Sat, Apr 7, 2012 at 10:46, David Belohrad  wrote:
>> I'd love to use notmuch with offline imap ?to work rather on local
>copy of
>> messages, than using remote notmuch, which is slightly slower due to
>> bandwidth limitation of my vdsl line. There is however fundamental
>problem
>> of syncing flags between two instances of notmuch. So my question is,
>> whether it would be possible, when tagging message, to store the tag
>as well
>> in the message itself. Might this help to sync across multiple
>instances?

My long-term dream is still to enable offlinemap to sync all imap flags and 
sync notmuch flags via offlineimap/imap server. But don` t hold your breath :-) 

Sebastian

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Why not tags inside messages?

[Sebastian Spaeth]

On Sat, Apr 7, 2012 at 10:46, David Belohrad da...@belohrad.ch wrote:
 I'd love to use notmuch with offline imap  to work rather on local
copy of
 messages, than using remote notmuch, which is slightly slower due to
 bandwidth limitation of my vdsl line. There is however fundamental
problem
 of syncing flags between two instances of notmuch. So my question is,
 whether it would be possible, when tagging message, to store the tag
as well
 in the message itself. Might this help to sync across multiple
instances?

My long-term dream is still to enable offlinemap to sync all imap flags and 
sync notmuch flags via offlineimap/imap server. But don` t hold your breath :-) 

Sebastian

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch-poll and OfflineIMAP

[Sebastian Spaeth]

Jani Nikula j...@nikula.org wrote:

Jacek Generowicz jacek.generow...@cern.ch writes:

 Hello,

 Would you have any advice on how to construct a notmuch-poll script
 that would work well in concert with OfflineIMAP?  In particlular,
how
 can you avoid having to re-issue the IMAP account passwords?

 Any words of wisdom?

Offlineimap supports running hooks after syncing. Check if SIGUSR1 does
that too. Then you could run notmuch new in the post sync hook.

Also, notmuch new supports pre-new and post-new hooks. You could start
or SIGUSR1 offlineimap in the pre-new hook. See man notmuch-hooks for

Offlineimap hooks work nicely for running notmuch scripts, i run it this way. 
Sending Sigusr1 will invoke that too, but I don't think that would be needed. 
It's mostly for peole running OfflineMap as a daemon

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Message deletion wisdom

[Sebastian Spaeth]

Jameson Graef Rollins jroll...@finestructure.net wrote:
So in summary, if you would like to delete messages, you can:

 * add a key binding to emacs (or your favorite ui) to add a deleted
   tag to messages that you want to delete:

(define-key notmuch-show-mode-map d
  (lambda ()
(interactive)
(notmuch-show-tag-message +deleted)))

 * add exclusion for messages with the deleted tag:

notmuch config set search.exclude_tags deleted

 * and if you really want them purged from disk, delete them manually
   with:

notmuch search --output=files tag:deleted | xargs -l rm

Thanks Jamie, that ws a very helpful summary.

Sebastian

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch-poll and OfflineIMAP

[Sebastian Spaeth]

Adam Wolfe Gordon awg+notm...@xvx.ca wrote:

I run offlineimap in autorefresh mode (with IDLE too, actually) and
use a script based on inotify to update notmuch whenever new mail
comes in: https://gist.github.com/1952483 . It sounds like some
variant of this would probably work for you.

I actually plan to add new-message-hooks to offlineimap fairly soon.

Sebastian

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

nomuch_addresses.py

[Sebastian Spaeth]

On Fri, 17 Feb 2012 20:58:50 +0200, Tomi Ollila  wrote:
> Thank you for promoting my stuff.
> 
> Latest version is 2.0 and name is now nottoomuch-addresses.sh
> It is available at:
> 
> http://www.iki.fi/too/nottoomuch/

It would be great to add these things to the notmuch wiki so that people
can actually find it without searching the email lists.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: nomuch_addresses.py

[Sebastian Spaeth]

On Fri, 17 Feb 2012 20:58:50 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
 Thank you for promoting my stuff.
 
 Latest version is 2.0 and name is now nottoomuch-addresses.sh
 It is available at:
 
 http://www.iki.fi/too/nottoomuch/

It would be great to add these things to the notmuch wiki so that people
can actually find it without searching the email lists.

Sebastian


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

Info about notmuch database

[Sebastian Spaeth]

On Thu, 05 Jan 2012 16:04:22 +0100, Thomas Jost  
wrote:
> There's a description of the DB "schema" in lib/database.cc in the
> notmuch source code. But you may also consider just using libnotmuch
> instead, if that's enough for what you want to do.
> 
> Also: why Xapian? I'm already using something similar I wrote with
> Python, storing everything in a dictionary, using Pickle to save that to
> disk: 162 lines of code and 45 kb of data are enough to store my
> addressbook and have completion in Emacs...

Ohh, that sounds nice. Is that public somewhere?

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

notmuch git's disk is full! ERROR pushing.

[Sebastian Spaeth]

Actually trying to push the above 2 patches, I get 

Writing objects: 100% (8/8), 1.25 KiB, done.
Total 8 (delta 5), reused 0 (delta 0)
error: unable to create temporary sha1 filename : No space left on device

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://spaetz at notmuchmail.org/git/notmuch
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://spaetz at notmuchmail.org/git/notmuch'

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 2/2] python test "compare message ids"

[Sebastian Spaeth]

On Mon,  2 Jan 2012 14:51:27 +, Patrick Totzke  wrote:
> Introduces a second (trivial) test for the python
> bindings that searches for message ids and compares
> the output with that of `notmuch search`.

Test passes, so it went in.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 1/2] clean up "compare thread ids" python test

[Sebastian Spaeth]

On Mon,  2 Jan 2012 14:51:26 +, Patrick Totzke  wrote:
> This makes the test script open the database in READ_ONLY mode
> and use the libraries own sorting methods instead of "sort".

+1 I don't want to fudge the tests (I don't know a thing about them), so
I can't judge the test outcome, but it is certainly good from the python side of
things. So I'll push this one.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH 1/2] clean up compare thread ids python test

[Sebastian Spaeth]

On Mon,  2 Jan 2012 14:51:26 +, Patrick Totzke 
patricktot...@googlemail.com wrote:
 This makes the test script open the database in READ_ONLY mode
 and use the libraries own sorting methods instead of sort.

+1 I don't want to fudge the tests (I don't know a thing about them), so
I can't judge the test outcome, but it is certainly good from the python side of
things. So I'll push this one.


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

Re: [PATCH 2/2] python test compare message ids

[Sebastian Spaeth]

On Mon,  2 Jan 2012 14:51:27 +, Patrick Totzke 
patricktot...@googlemail.com wrote:
 Introduces a second (trivial) test for the python
 bindings that searches for message ids and compares
 the output with that of `notmuch search`.

Test passes, so it went in.


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

notmuch git's disk is full! ERROR pushing.

[Sebastian Spaeth]

Actually trying to push the above 2 patches, I get 

Writing objects: 100% (8/8), 1.25 KiB, done.
Total 8 (delta 5), reused 0 (delta 0)
error: unable to create temporary sha1 filename : No space left on device

fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To ssh://spa...@notmuchmail.org/git/notmuch
 ! [remote rejected] master - master (n/a (unpacker error))
error: failed to push some refs to 'ssh://spa...@notmuchmail.org/git/notmuch'

Sebastian


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

Re: Info about notmuch database

[Sebastian Spaeth]

On Thu, 05 Jan 2012 16:04:22 +0100, Thomas Jost schno...@schnouki.net wrote:
 There's a description of the DB schema in lib/database.cc in the
 notmuch source code. But you may also consider just using libnotmuch
 instead, if that's enough for what you want to do.
 
 Also: why Xapian? I'm already using something similar I wrote with
 Python, storing everything in a dictionary, using Pickle to save that to
 disk: 162 lines of code and 45 kb of data are enough to store my
 addressbook and have completion in Emacs...

Ohh, that sounds nice. Is that public somewhere?

Sebastian


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

Re: [PATCH 5/5] python: add get_mtime() to the Message class

[Sebastian Spaeth]

On Tue, 13 Dec 2011 18:11:45 +0100, Thomas Jost schno...@schnouki.net wrote:
 ---
  bindings/python/notmuch/message.py |   20 
  1 files changed, 20 insertions(+), 0 deletions(-)

The patch looks good, so once this goes into libnotmuch, +1 for also
applying this one.

Sebastian


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

Re: [PATCH 5/7] py3k: the basestring and unicode types are removed in python 3

[Sebastian Spaeth]

Happy new year. Pushed patches 1-4 of this series so far. Looking fine,
but ugh, the below seems like a rather ugly hack in a function that is
probably called quite often.

Isn't there a more pretty variant avoiding these sys.version_info checks
all over the place?

 @@ -200,9 +201,9 @@ def _str(value):
  
  C++ code expects strings to be well formatted and
  unicode strings to have no null bytes.
 -if not isinstance(value, basestring):
 +if not isinstance(value, basestring if sys.version_info[0] == 2 else 
 str):
  raise TypeError(Expected str or unicode, got %s % str(type(value)))
 -if isinstance(value, unicode):
 +if sys.version_info[0] == 3 or isinstance(value, unicode):
  return value.encode('UTF-8')
  return value


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

Re: Segmentation fault at gmime-iconv with python binding

[Sebastian Spaeth]

On Fri, 30 Dec 2011 10:58:06 -0400, David Bremner da...@tethera.net wrote:
 On Thu, 29 Dec 2011 22:57:27 -0200, Kazuo Teramoto kaz@gmail.com wrote:
 
  notmuch CLI show the message correct. I know nothing about gmime or
  notmuch code, but can this be the case of the python bindings not
  calling g_mime_init() correctly?

The python binding are never calling g_mime_init, as that is not exposed
to the python bindings. So either libnotmuch needs to take care of that
or there needs to be a clear guideline as to when a binding needs to
call what gmime stuff itself.

Sebastian


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

Re: [PATCH 1/2] python: refactor print_messages into format_messages and print_messages

[Sebastian Spaeth]

On Wed, 21 Dec 2011 14:15:01 +0100, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 ---
  bindings/python/notmuch/message.py |   37 +--
  1 files changed, 26 insertions(+), 11 deletions(-)

Pushed


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

Re: [PATCH 2/2] python: make the result of Message.get_replies() more pythonic

[Sebastian Spaeth]

On Wed, 21 Dec 2011 14:15:02 +0100, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 Formerly Message.get_replies() returned an iterator or None forcing
 users to check the result before iterating over it leading to strange
 looking code at the call site.
 
 Fix this flaw by adding an EmptyMessagesResult class that behaves like
 the Messages class but immediatly raises StopIteration if used as an
 iterator and returning objects of this type from Message.get_replies()
 to indicate that there are no replies.


Makes sense, pushed. It shouldn't cause the breaking of existing
clients... (famous last words)

Sebastian


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

Python bindings for adoption

[Sebastian Spaeth]

Hi all, a happy new year!

After a few weeks of notmuch abstinence I am being overwhelmed with 750
new notmuch mails, and I really don't have the time or will (nor does my
family approve) to spend enormous amounts of time on notmuch. I am
already neglecting offlineimap, which also needs some attention.

As I have repeatedly stated that I want to hand over the maintainership
of the notmuch python bindings, and I would like to do it asap. I feel
that people like Patrick Totzke, or Justus Winter who generally have
been working on this far more intensely than I recently did are both
very well positioned to take on that role :-). Most importantly, they
actually work with the bindings while I don't use them myself anymore.

I will only merge bug fixes as of now, and not invest time to refactor
the code or add lots of bells and whistles. Let me know if anyone would
volunteer to take them on.

Looking forward to see more cool notmuch, alot, afew, and muchother
development progress.

Sebastian


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

Re: [PATCH 1/3] pep8 fixes

[Sebastian Spaeth]

On Mon,  5 Dec 2011 21:12:33 +, Patrick Totzke 
patricktot...@googlemail.com wrote:
 no changes to the code, only fixed stuff denounced by `pep8 *py`

Hi, just tried to apply but it doesn't apply cleanly anymore, can you
update the patch to latest master? 

Sorry for letting this languish for so long.

Sebastian


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

[PATCH 1/3] pep8 fixes

[Sebastian Spaeth]

On Mon,  5 Dec 2011 21:12:33 +, Patrick Totzke  wrote:
> no changes to the code, only fixed stuff denounced by `pep8 *py`

Hi, just tried to apply but it doesn't apply cleanly anymore, can you
update the patch to latest master? 

Sorry for letting this languish for so long.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Python bindings for adoption

[Sebastian Spaeth]

Hi all, a happy new year!

After a few weeks of notmuch abstinence I am being overwhelmed with 750
new notmuch mails, and I really don't have the time or will (nor does my
family approve) to spend enormous amounts of time on notmuch. I am
already neglecting offlineimap, which also needs some attention.

As I have repeatedly stated that I want to hand over the maintainership
of the notmuch python bindings, and I would like to do it asap. I feel
that people like Patrick Totzke, or Justus Winter who generally have
been working on this far more intensely than I recently did are both
very well positioned to take on that role :-). Most importantly, they
actually work with the bindings while I don't use them myself anymore.

I will only merge bug fixes as of now, and not invest time to refactor
the code or add lots of bells and whistles. Let me know if anyone would
volunteer to take them on.

Looking forward to see more cool notmuch, alot, afew, and muchother
development progress.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 2/2] python: make the result of Message.get_replies() more pythonic

[Sebastian Spaeth]

On Wed, 21 Dec 2011 14:15:02 +0100, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
> Formerly Message.get_replies() returned an iterator or None forcing
> users to check the result before iterating over it leading to strange
> looking code at the call site.
> 
> Fix this flaw by adding an EmptyMessagesResult class that behaves like
> the Messages class but immediatly raises StopIteration if used as an
> iterator and returning objects of this type from Message.get_replies()
> to indicate that there are no replies.


Makes sense, pushed. It shouldn't cause the breaking of existing
clients... (famous last words)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 1/2] python: refactor print_messages into format_messages and print_messages

[Sebastian Spaeth]

On Wed, 21 Dec 2011 14:15:01 +0100, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
> ---
>  bindings/python/notmuch/message.py |   37 +--
>  1 files changed, 26 insertions(+), 11 deletions(-)

Pushed
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Segmentation fault at gmime-iconv with python binding

[Sebastian Spaeth]

On Fri, 30 Dec 2011 10:58:06 -0400, David Bremner  wrote:
> On Thu, 29 Dec 2011 22:57:27 -0200, Kazuo Teramoto  
> wrote:
> 
> > notmuch CLI show the message correct. I know nothing about gmime or
> > notmuch code, but can this be the case of the python bindings not
> > calling g_mime_init() correctly?

The python binding are never calling g_mime_init, as that is not exposed
to the python bindings. So either libnotmuch needs to take care of that
or there needs to be a clear guideline as to when a binding needs to
call what gmime stuff itself.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 5/7] py3k: the basestring and unicode types are removed in python 3

[Sebastian Spaeth]

Happy new year. Pushed patches 1-4 of this series so far. Looking fine,
but ugh, the below seems like a rather ugly hack in a function that is
probably called quite often.

Isn't there a more pretty variant avoiding these sys.version_info checks
all over the place?

> @@ -200,9 +201,9 @@ def _str(value):
>  
>  C++ code expects strings to be well formatted and
>  unicode strings to have no null bytes."""
> -if not isinstance(value, basestring):
> +if not isinstance(value, basestring if sys.version_info[0] == 2 else 
> str):
>  raise TypeError("Expected str or unicode, got %s" % str(type(value)))
> -if isinstance(value, unicode):
> +if sys.version_info[0] == 3 or isinstance(value, unicode):
>  return value.encode('UTF-8')
>  return value
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 5/5] python: add get_mtime() to the Message class

[Sebastian Spaeth]

On Tue, 13 Dec 2011 18:11:45 +0100, Thomas Jost  
wrote:
> ---
>  bindings/python/notmuch/message.py |   20 
>  1 files changed, 20 insertions(+), 0 deletions(-)

The patch looks good, so once this goes into libnotmuch, +1 for also
applying this one.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 3/3] errors='ignore' when decode to unicode

[Sebastian Spaeth]

Just for reference, all three patches went in.
Perhaps this warrants a NEWS entry such as:

 * python: using more unicode throughout and robustify against unicode
   errors (credits to Patrick Totzke)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[python] documentation & TODO list

[Sebastian Spaeth]

On Mon, 05 Dec 2011 22:36:06 +, Patrick Totzke wrote:
> These are the things I noticed when going through the code today:
> 1) in filenames.py,  __str__ of Filenames: should the return value be
>'\n'.join(self._files)? alternatively, define __iter__ to make this object
>behave as iterator.

To be honest, I don't remember why the code looks the way it looks, but
it certainly is not right like this. Defining __iter__ sounds like a
correct thing to me, but it could be that there was some reason why I
don't have it...
Feel free to implement a working __iter__ and provide a patch :-).

> 2) in message.py:  tags_to_maildir_flags and maildir_flags_to_tags never 
> return a
>:class:`STATUS` as advertised.

But it has been doing that for, , 1 minute :-)
[master ecf8da3] python: Return a STATUS value in tags_to_flags and 
flags_to_tags

(thanks)

> I would like to see up-to-date API docs online, even if only the
> version string changed.
> Sebastian suggested using readthedocs.org for building and hosting APIdocs.

I currently manually upload a generated API doc to the
packages.python.org website. I kind of like that address because it
sounds official ;-), but it is manual work. I am currently not looking
into expending the efforts I have to do on python notmuch. So setting

> I tested this recently for alot and it looks quite promising.
> A simple http get and their build-host checks out the new sources from git 
> and builds
> them. This could be easily integrated into notmuch the release process.
> Comments on this?

I think that it would be cool to have that automatically been done on
notmuchmail.org. But given that it takes some work to set that up and
readthedocs.org is already there, I am all for using that for now.

> Lastly, does anyone have an opinion on how to share a TODO list/issue tracker
> for the bindings? I'm OK with github, we could move all this to the list
> and use David's nmbug..

Ohh, there is already notmuch::python in nmbug :-)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 2/2] python: annotate all calls into libnotmuch with types

[Sebastian Spaeth]

On Tue, 06 Dec 2011 10:46:31 +, Patrick Totzke  wrote:
> This commit breaks raising XapianErrors for me.
> 
> If I lock the index with some `notmuch tag +test '*'`
> and try to write to it in alot, i get a segfault and
> the following on stderr:
> 
> Xapian exception occurred opening database: Unable to get write lock on
> /home/pazz/mail/.notmuch/xapian: already locked

Hi Justus,
I can confirm that this patch breaks as Totzke has described it:

http://git.notmuchmail.org/git/notmuch/commitdiff/3434d194026ff65217d9342ffe511f67fd71e79f

This change makes python segfault with a Xapianerror on stdout rather
than the python exception that we were seeing before this patch.

- _open.restype = c_void_p
+ _open.restype = NotmuchDatabaseP


As the patch obviously fixed other crashers I would like to not revert
it. Can you have a look and see if you find a cause of that?

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH] lib: call g_type_init from notmuch_database_open

[Sebastian Spaeth]

On Sun,  4 Dec 2011 15:35:14 -0400, David Bremner  wrote:
> From: David Bremner 
> This seems to fix the segfault for me. Any other comments/experiences?

> +/* Initialize the GLib type system and threads */
> +g_type_init ();
> +


Thanks the patch looks sane, and relieves me from doing ugly things with
gmime from the python side of things.

+1

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 2/2] python: annotate all calls into libnotmuch with types

[Sebastian Spaeth]

On Tue, 06 Dec 2011 10:46:31 +, Patrick Totzke  wrote:
> This commit breaks raising XapianErrors for me.
> 
> If I lock the index with some `notmuch tag +test '*'`
> and try to write to it in alot, i get a segfault and
> the following on stderr:
> 
> Xapian exception occurred opening database: Unable to get write lock on
> /home/pazz/mail/.notmuch/xapian: already locked

Can you confirm that this only occurs with this patch and not without?
To be honest, I don't see how the patch would change things in a way
that make it throw XapianErrors that would not also occur before this
patch.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH 2/2] python: annotate all calls into libnotmuch with types

[Sebastian Spaeth]

On Tue, 06 Dec 2011 10:46:31 +, Patrick Totzke 
patricktot...@googlemail.com wrote:
 This commit breaks raising XapianErrors for me.
 
 If I lock the index with some `notmuch tag +test '*'`
 and try to write to it in alot, i get a segfault and
 the following on stderr:
 
 Xapian exception occurred opening database: Unable to get write lock on
 /home/pazz/mail/.notmuch/xapian: already locked

Can you confirm that this only occurs with this patch and not without?
To be honest, I don't see how the patch would change things in a way
that make it throw XapianErrors that would not also occur before this
patch.

Sebastian


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

Re: [PATCH] lib: call g_type_init from notmuch_database_open

[Sebastian Spaeth]

On Sun,  4 Dec 2011 15:35:14 -0400, David Bremner da...@tethera.net wrote:
 From: David Bremner brem...@debian.org
 This seems to fix the segfault for me. Any other comments/experiences?

 +/* Initialize the GLib type system and threads */
 +g_type_init ();
 +


Thanks the patch looks sane, and relieves me from doing ugly things with
gmime from the python side of things.

+1

Sebastian


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

Re: [PATCH 2/2] python: annotate all calls into libnotmuch with types

[Sebastian Spaeth]

On Tue, 06 Dec 2011 10:46:31 +, Patrick Totzke 
patricktot...@googlemail.com wrote:
 This commit breaks raising XapianErrors for me.
 
 If I lock the index with some `notmuch tag +test '*'`
 and try to write to it in alot, i get a segfault and
 the following on stderr:
 
 Xapian exception occurred opening database: Unable to get write lock on
 /home/pazz/mail/.notmuch/xapian: already locked

Hi Justus,
I can confirm that this patch breaks as Totzke has described it:

http://git.notmuchmail.org/git/notmuch/commitdiff/3434d194026ff65217d9342ffe511f67fd71e79f

This change makes python segfault with a Xapianerror on stdout rather
than the python exception that we were seeing before this patch.

- _open.restype = c_void_p
+ _open.restype = NotmuchDatabaseP


As the patch obviously fixed other crashers I would like to not revert
it. Can you have a look and see if you find a cause of that?

Sebastian


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

Re: [python] documentation TODO list

[Sebastian Spaeth]

On Mon, 05 Dec 2011 22:36:06 +, Patrick Totzke wrote:
 These are the things I noticed when going through the code today:
 1) in filenames.py,  __str__ of Filenames: should the return value be
'\n'.join(self._files)? alternatively, define __iter__ to make this object
behave as iterator.

To be honest, I don't remember why the code looks the way it looks, but
it certainly is not right like this. Defining __iter__ sounds like a
correct thing to me, but it could be that there was some reason why I
don't have it...
Feel free to implement a working __iter__ and provide a patch :-).

 2) in message.py:  tags_to_maildir_flags and maildir_flags_to_tags never 
 return a
:class:`STATUS` as advertised.

But it has been doing that for, , 1 minute :-)
[master ecf8da3] python: Return a STATUS value in tags_to_flags and 
flags_to_tags

(thanks)

 I would like to see up-to-date API docs online, even if only the
 version string changed.
 Sebastian suggested using readthedocs.org for building and hosting APIdocs.

I currently manually upload a generated API doc to the
packages.python.org website. I kind of like that address because it
sounds official ;-), but it is manual work. I am currently not looking
into expending the efforts I have to do on python notmuch. So setting

 I tested this recently for alot and it looks quite promising.
 A simple http get and their build-host checks out the new sources from git 
 and builds
 them. This could be easily integrated into notmuch the release process.
 Comments on this?

I think that it would be cool to have that automatically been done on
notmuchmail.org. But given that it takes some work to set that up and
readthedocs.org is already there, I am all for using that for now.
 
 Lastly, does anyone have an opinion on how to share a TODO list/issue tracker
 for the bindings? I'm OK with github, we could move all this to the list
 and use David's nmbug..

Ohh, there is already notmuch::python in nmbug :-)

Sebastian


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

Re: [PATCH 3/3] errors='ignore' when decode to unicode

[Sebastian Spaeth]

Just for reference, all three patches went in.
Perhaps this warrants a NEWS entry such as:

 * python: using more unicode throughout and robustify against unicode
   errors (credits to Patrick Totzke)


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

Re: [PATCH] python: use wrapped notmuch_*_t types instead of raw pointers

[Sebastian Spaeth]

On Tue,  6 Dec 2011 11:03:22 +0100, Thomas Jost schno...@schnouki.net wrote:
 Now that types are checked correctly, we also need to make sure that all the
 arguments actually are instances of these types. Otherwise the function calls
 will fail and raise an exception similar to this one:
ctypes.ArgumentError: argument 3: type 'exceptions.TypeError': expected
LP_LP_NotmuchMessageS instance instead of pointer to c_void_p

Thanks, Pushed.


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

python-notmuch decoding error on a message

[Sebastian Spaeth]

On Thu, 24 Nov 2011 12:13:22 -0400, David Bremner  wrote:
> I get a set of critical errors about forgetting to call g_type_init.
> We actually call g_type_init in the CLI now, thanks to 

Oooh, ahh, I just saw these message on doing 'notmuch.py search "moo"'
myself. I would prefer if I (the binding) would not have to deal with
g_type_init stuff myself, it would mean loading more C libraries and
doing stuff that no libnotmuch documentation has told me about :-).

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 1/2] python: add classes to wrap all notmuch_*_t types

[Sebastian Spaeth]

On Mon, 28 Nov 2011 13:36:44 +0100, Justus Winter wrote:
> Well, quoting my commit message:
> 
> > Add type information to the ctypes._FuncPtr wrappers and
> > use the wrapper classes instead of c_void_p for pointers
> > to notmuch_*_t.
> >
> > This enables the ctypes library to type check parameters
> > being handed to functions from the notmuch library.


This strikes me as a rather good thing, so the patches went in.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH 1/2] python: add classes to wrap all notmuch_*_t types

[Sebastian Spaeth]

On Mon, 28 Nov 2011 13:36:44 +0100, Justus Winter wrote:
 Well, quoting my commit message:
 
  Add type information to the ctypes._FuncPtr wrappers and
  use the wrapper classes instead of c_void_p for pointers
  to notmuch_*_t.
 
  This enables the ctypes library to type check parameters
  being handed to functions from the notmuch library.


This strikes me as a rather good thing, so the patches went in.

Sebastian


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

Re: python-notmuch decoding error on a message

[Sebastian Spaeth]

On Thu, 24 Nov 2011 12:13:22 -0400, David Bremner da...@tethera.net wrote:
 I get a set of critical errors about forgetting to call g_type_init.
 We actually call g_type_init in the CLI now, thanks to 

Oooh, ahh, I just saw these message on doing 'notmuch.py search moo'
myself. I would prefer if I (the binding) would not have to deal with
g_type_init stuff myself, it would mean loading more C libraries and
doing stuff that no libnotmuch documentation has told me about :-).

Sebastian


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

[PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search cost.

[Sebastian Spaeth]

On Tue,  8 Nov 2011 21:55:28 -0500, Austin Clements  wrote:
>  emacs/notmuch.el |   11 +++
>  1 files changed, 3 insertions(+), 8 deletions(-)


Tested and works great here! +1 for quick inclusion.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH] tag: Automatically limit to messages whose tags will actually change.

[Sebastian Spaeth]

On Wed, 09 Nov 2011 08:46:02 +, Jani Nikula  wrote:
> It's unrelated, but looking at the above also made me check something
> I've suspected before: notmuch allows you to have empty or zero length
> tags "", which is probably not intentional.

I had reported already that it is possible to add either an empty or a
"\n" tag (not sure what gets added) via '+' in the emacs UI. See
the newline in the tag list. Remove it again with '-' in emacs.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search cost.

[Sebastian Spaeth]

On Tue,  8 Nov 2011 21:55:28 -0500, Austin Clements amdra...@mit.edu wrote:
  emacs/notmuch.el |   11 +++
  1 files changed, 3 insertions(+), 8 deletions(-)


Tested and works great here! +1 for quick inclusion.

Sebastian


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

[PATCH] tag: Automatically limit to messages whose tags will actually change.

[Sebastian Spaeth]

On Mon,  7 Nov 2011 22:55:23 -0500, Austin Clements  wrote:
> This optimizes the user's tagging query to exclude messages that won't
> be affected by the tagging operation, saving computation and IO for
> redundant tagging operations.

+1 for this!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH] tag: Automatically limit to messages whose tags will actually change.

[Sebastian Spaeth]

On Mon,  7 Nov 2011 22:55:23 -0500, Austin Clements amdra...@mit.edu wrote:
 This optimizes the user's tagging query to exclude messages that won't
 be affected by the tagging operation, saving computation and IO for
 redundant tagging operations.

+1 for this!


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

python: unpythonic result of Message.get_replies()

[Sebastian Spaeth]

On Wed, 05 Oct 2011 03:42:38 +0200, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
Non-text part: multipart/mixed
> I noticed that Message.get_replies() returns a Messages object *or*
> None. Quoting the documentation:
> 
> > Returns: Messages or None if there are no replies to this message
> 
> Messages is a class implementing the iterator protocol, so a python
> programmer would expect to get an iterator that raises a StopIteration
> on the first invocation of next() if there aren't any replies.
> 

Yes, that change would make perfect sense, and I would be happy to
accept a patch for it :-)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 1/2] python: add classes to wrap all notmuch_*_t types

[Sebastian Spaeth]

On Mon, 10 Oct 2011 00:12:53 +0200, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
> Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de>
> ---
>  bindings/python/notmuch/globals.py |   38 
> +++-

Hi there, catching up on email, sorry for the delay.
I am not opposed to the change, but I fail to see any justification for
a whole lot more complexity either. What was wrong with the previous
approach?

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH 1/2] python: add classes to wrap all notmuch_*_t types

[Sebastian Spaeth]

On Mon, 10 Oct 2011 00:12:53 +0200, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 Signed-off-by: Justus Winter 4win...@informatik.uni-hamburg.de
 ---
  bindings/python/notmuch/globals.py |   38 
 +++-

Hi there, catching up on email, sorry for the delay.
I am not opposed to the change, but I fail to see any justification for
a whole lot more complexity either. What was wrong with the previous
approach?

Sebastian


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

Re: python: unpythonic result of Message.get_replies()

[Sebastian Spaeth]

On Wed, 05 Oct 2011 03:42:38 +0200, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
Non-text part: multipart/mixed
 I noticed that Message.get_replies() returns a Messages object *or*
 None. Quoting the documentation:
 
  Returns: Messages or None if there are no replies to this message
 
 Messages is a class implementing the iterator protocol, so a python
 programmer would expect to get an iterator that raises a StopIteration
 on the first invocation of next() if there aren't any replies.
 

Yes, that change would make perfect sense, and I would be happy to
accept a patch for it :-)

Sebastian


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

Re: [PATCH] lib: make find_message{,by_filename) report errors

[Sebastian Spaeth]

The new API looks sane and much better to me.

+1, just give me plenty of time to catch up before releasing once this
goes in :-)

Sebastian


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

Re: [python] can't find shared lib

[Sebastian Spaeth]

On Wed, 05 Oct 2011 13:58:14 +0100, Patrick Totzke wrote:
 I fumbled around with resetting come commits, and it turns out that the
 problem is in 9e976fc60c40e07cb62a7d656e86ee3101c1b2f5. Once resetted before 
 that,
 everything works nicely.

Thanks for the pointer :)

[master 7047975] python: also use libnotmuch.so.2

Sebastian


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

[python] can't find shared lib

[Sebastian Spaeth]

On Wed, 05 Oct 2011 13:58:14 +0100, Patrick Totzke wrote:
> I fumbled around with resetting come commits, and it turns out that the
> problem is in 9e976fc60c40e07cb62a7d656e86ee3101c1b2f5. Once resetted before 
> that,
> everything works nicely.

Thanks for the pointer :)

[master 7047975] python: also use libnotmuch.so.2

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH] lib: make find_message{,by_filename) report errors

[Sebastian Spaeth]

The new API looks sane and much better to me.

+1, just give me plenty of time to catch up before releasing once this
goes in :-)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH] python: fix Message.get_filenames()

[Sebastian Spaeth]

On Fri, 30 Sep 2011 12:16:47 +0200, Thomas Jost  
wrote:
> Previously, the Filenames generator only yielded *one* filename before
> returning, making Message.get_filenames() behave as Message.get_filename(). 
> This
> commit fixes this incorrect behavior: now the generator yields all the
> filenames, as expected.

APPLIED to master, thanks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 7/9] python: provide more exception classes

[Sebastian Spaeth]

On Mon, 26 Sep 2011 03:05:35 +0200, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
> To make the exception handling more effective in code using the
> python bindings it is necessary to differentiate between the
> different kind of failures.

[master b6a0173] python: provide more exception classes

Hi, I have taken your patch and used it as a template, modifying things
slightly. I also converted database.py to make use of the new
subclasses. Documentation will have to follow, but as users can use the
code, just as they had done before, there is no urgency.

Justus is that what you had in mind?

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH v6 00/17] Fix 'notmuch new' atomicity issues

[Sebastian Spaeth]

On Thu, 29 Sep 2011 11:01:47 -0400, Austin Clements  wrote:
> Quoth Sebastian Spaeth on Sep 28 at  6:36 pm:
> > db.find_message_by_filename("moo")
> > Internal error: Failure to ensure database is writable
> > (lib/directory.cc:100).

> It appears that looking up a directory requires a writable database
> because notmuch will try to *create* a database document for the
> directory if one doesn't already exist.  This is clearly wrong
> behavior for a "find" function.

First of all, I consider libnotmuch exiting, taking python down, an
outright bug. So we should modify this case to return:
NOTMUCH_STATUS_READ_ONLY_DATABASE

so I can at least give some sensible error than having an angry mob run
with pitchforks towards me.

Ideally, we don't need READ-WRITE dbs for the find :-)

As it is, the same issue happens with the
notmuch_database_get_directory call, which should be protected in the
same manner (and probably has the same root cause). It is debatable
whether get_directory should be creating a directory on demand, I guess,
but it should never crash.

I have documented this in the python bindings, so it's not super urgent.
But it's dangerous and wrong nonetheless.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110930/6d8d957a/attachment.pgp>

[PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

On Fri, 30 Sep 2011 02:41:02 +0200, Justus Winter <4winter at 
informatik.uni-hamburg.de> wrote:
Non-text part: multipart/mixed
> Quoting Sebastian Spaeth (2011-09-29 09:45:38)
> >Also, not all "status" are an error, e.g. DuplicateMessageId denotes
> >success rather than failure, it just communicates a status.
> 
> I just stumbled upon the following comment in notmuch.h:
> 
> /* Status codes used for the return values of most functions.
>  *
>  * A zero value (NOTMUCH_STATUS_SUCCESS) indicates that the function
>  * completed without error. Any other value indicates an error as
>  * follows:
> [...]

That sounds like notmuch.h doesn't know what it wants :-). The "error"
can occur on add_message or remove_message and notmuch.h has to say:

on add_message:
 * If 'message' is not NULL, then, on successful return
 * (NOTMUCH_STATUS_SUCCESS or NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) '*message'
 * will be initialized to a message object that can be used for things
 * such as adding tags to the just-added message. The user should call
 * notmuch_message_destroy when done with the message. ... On any failure
 * '*message' will be set to NULL.

So DUPLICATE_MESSAGE_ID is definitely a successful return here, filling in the
Message object.

on remove_message:
 * NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID: This filename was removed but
 *  the message persists in the database with at least one other
 *  filename.

Similarly, the operation succeeded, it's just that there are other
messages with that ID still around. One could argue whether this is an
error or not.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110930/0b50e98e/attachment.pgp>

[PATCH] python: fix docstring of Message.get_header()

[Sebastian Spaeth]

On Fri, 30 Sep 2011 03:05:04 +0200, Justus Winter wrote:
> Update the docstring from notmuch.h.

APPLIED; thanks.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH] python: fix docstring of Message.get_header()

[Sebastian Spaeth]

On Fri, 30 Sep 2011 03:05:04 +0200, Justus Winter wrote:
 Update the docstring from notmuch.h.

APPLIED; thanks.


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

Re: [PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

On Fri, 30 Sep 2011 02:41:02 +0200, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
Non-text part: multipart/mixed
 Quoting Sebastian Spaeth (2011-09-29 09:45:38)
 Also, not all status are an error, e.g. DuplicateMessageId denotes
 success rather than failure, it just communicates a status.
 
 I just stumbled upon the following comment in notmuch.h:
 
 /* Status codes used for the return values of most functions.
  *
  * A zero value (NOTMUCH_STATUS_SUCCESS) indicates that the function
  * completed without error. Any other value indicates an error as
  * follows:
 [...]

That sounds like notmuch.h doesn't know what it wants :-). The error
can occur on add_message or remove_message and notmuch.h has to say:

on add_message:
 * If 'message' is not NULL, then, on successful return
 * (NOTMUCH_STATUS_SUCCESS or NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID) '*message'
 * will be initialized to a message object that can be used for things
 * such as adding tags to the just-added message. The user should call
 * notmuch_message_destroy when done with the message. ... On any failure
 * '*message' will be set to NULL.

So DUPLICATE_MESSAGE_ID is definitely a successful return here, filling in the
Message object.

on remove_message:
 * NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID: This filename was removed but
 *  the message persists in the database with at least one other
 *  filename.

Similarly, the operation succeeded, it's just that there are other
messages with that ID still around. One could argue whether this is an
error or not.


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

Re: [PATCH v6 00/17] Fix 'notmuch new' atomicity issues

[Sebastian Spaeth]

On Thu, 29 Sep 2011 11:01:47 -0400, Austin Clements amdra...@mit.edu wrote:
 Quoth Sebastian Spaeth on Sep 28 at  6:36 pm:
  db.find_message_by_filename(moo)
  Internal error: Failure to ensure database is writable
  (lib/directory.cc:100).

 It appears that looking up a directory requires a writable database
 because notmuch will try to *create* a database document for the
 directory if one doesn't already exist.  This is clearly wrong
 behavior for a find function.

First of all, I consider libnotmuch exiting, taking python down, an
outright bug. So we should modify this case to return:
NOTMUCH_STATUS_READ_ONLY_DATABASE

so I can at least give some sensible error than having an angry mob run
with pitchforks towards me.

Ideally, we don't need READ-WRITE dbs for the find :-)

As it is, the same issue happens with the
notmuch_database_get_directory call, which should be protected in the
same manner (and probably has the same root cause). It is debatable
whether get_directory should be creating a directory on demand, I guess,
but it should never crash.

I have documented this in the python bindings, so it's not super urgent.
But it's dangerous and wrong nonetheless.

Sebastian


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

Re: [PATCH 7/9] python: provide more exception classes

[Sebastian Spaeth]

On Mon, 26 Sep 2011 03:05:35 +0200, Justus Winter 
4win...@informatik.uni-hamburg.de wrote:
 To make the exception handling more effective in code using the
 python bindings it is necessary to differentiate between the
 different kind of failures.

[master b6a0173] python: provide more exception classes

Hi, I have taken your patch and used it as a template, modifying things
slightly. I also converted database.py to make use of the new
subclasses. Documentation will have to follow, but as users can use the
code, just as they had done before, there is no urgency.

Justus is that what you had in mind?

Sebastian


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

[Justus Winter] Re: [PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

Here goes Justus's reply which he accidentally sent to me only.

-- next part --
An embedded message was scrubbed...
From: Justus Winter <4win...@informatik.uni-hamburg.de>
Subject: Re: [PATCH 1/9] python: add a .gitignore file and refine the toplevel 
one
Date: Thu, 29 Sep 2011 12:37:53 +0200
Size: 5902
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Python bindings doc update

[Sebastian Spaeth]

Online docs for current master are updated and as usual online at:

http://packages.python.org/notmuch/

Besides some prettifications, the three new functions have been
documented.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

On Mon, 26 Sep 2011 03:05:29 +0200, Justus Winter wrote:

P.S. I don't use the bindings myself, and I don't see me using them in
the near future. If you are volunteering to take over the binding
maintainership, I'd be happy to hand the reign over :-).

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

On Mon, 26 Sep 2011 03:05:29 +0200, Justus Winter wrote:

#1) APPLIED
#2) APPLIED
#3) reorder the arguments of NotmuchError.__init__(): NOT APPLIED

The python tutorial gives an example of custom TransitionError with
three arguments, a custom message as the third. In addition, a STATUS
value is always expected to be given, while the additional explanatory
msg is optional, so STATUS makes for a more logical 1st parameter IMHO.
Even if it were the case, it makes for lots of code churn, longer code
(status=foo) to all Exceptions, and existing third party code would be
broken. Overall, I think there is more potential for trouble than
cleanup.

#4) APPLIED
status is always expected to be existing, but bullet proofing never hurts,
so this patch makes sense.

#5) APPLIED
Modified the patches to apply again, as some changes had been made.

#7) NOT APPLIED, INPUT SOUGHT :)
I do see the value of more fine grained exceptions, but I am not sure,
we need this level of fine-grainedness. It would also make things more
tricky (the API is still actively evolving, and e.g. 4 days ago, a new
error status was added), so users of the bindings would now have
 +NotmuchError,
 +OutOfMemoryError,
 +ReadOnlyDatabaseError,
 +XapianError,
 +FileError,
 +FileNotEmailError,
 +DuplicateMessageIdError,
 +NullPointerError,
 +TagTooLongError,
 +UnbalancedFreezeThawError,
 +UnbalancedAtomicError,
 +NotInitializedError

to check where e.g. Xapian could also hide an Out of Memory. Do people
really want to catch, say UnbalancedAtomic errors specifically, rather
than testing whether an operation succeeded, and check the status code
if not? I could see the case for NotInitializedError, as that is a bit
specific to the python bindings and users might want to catch it separately.

Also, not all "status" are an error, e.g. DuplicateMessageId denotes
success rather than failure, it just communicates a status.

What do people ( of the bindings) think would make sense here?
I am not opposed, but want more discussion and input before such a
change is made.

#8) Not merged, as it depends on #7

#9) APPLIED

Thanks for the patches, most of them are quite nice. For 7&8, I'd like
to hear more opinions.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: [PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

On Mon, 26 Sep 2011 03:05:29 +0200, Justus Winter wrote:

#1) APPLIED
#2) APPLIED
#3) reorder the arguments of NotmuchError.__init__(): NOT APPLIED

The python tutorial gives an example of custom TransitionError with
three arguments, a custom message as the third. In addition, a STATUS
value is always expected to be given, while the additional explanatory
msg is optional, so STATUS makes for a more logical 1st parameter IMHO.
Even if it were the case, it makes for lots of code churn, longer code
(status=foo) to all Exceptions, and existing third party code would be
broken. Overall, I think there is more potential for trouble than
cleanup.

#4) APPLIED
status is always expected to be existing, but bullet proofing never hurts,
so this patch makes sense.

#5#6) APPLIED
Modified the patches to apply again, as some changes had been made.

#7) NOT APPLIED, INPUT SOUGHT :)
I do see the value of more fine grained exceptions, but I am not sure,
we need this level of fine-grainedness. It would also make things more
tricky (the API is still actively evolving, and e.g. 4 days ago, a new
error status was added), so users of the bindings would now have
 +NotmuchError,
 +OutOfMemoryError,
 +ReadOnlyDatabaseError,
 +XapianError,
 +FileError,
 +FileNotEmailError,
 +DuplicateMessageIdError,
 +NullPointerError,
 +TagTooLongError,
 +UnbalancedFreezeThawError,
 +UnbalancedAtomicError,
 +NotInitializedError

to check where e.g. Xapian could also hide an Out of Memory. Do people
really want to catch, say UnbalancedAtomic errors specifically, rather
than testing whether an operation succeeded, and check the status code
if not? I could see the case for NotInitializedError, as that is a bit
specific to the python bindings and users might want to catch it separately.

Also, not all status are an error, e.g. DuplicateMessageId denotes
success rather than failure, it just communicates a status.

What do people (user of the bindings) think would make sense here?
I am not opposed, but want more discussion and input before such a
change is made.

#8) Not merged, as it depends on #7

#9) APPLIED

Thanks for the patches, most of them are quite nice. For 78, I'd like
to hear more opinions.

Sebastian


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

Python bindings doc update

[Sebastian Spaeth]

Online docs for current master are updated and as usual online at:

http://packages.python.org/notmuch/

Besides some prettifications, the three new functions have been
documented.

Sebastian


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

[Justus Winter] Re: [PATCH 1/9] python: add a .gitignore file and refine the toplevel one

[Sebastian Spaeth]

Here goes Justus's reply which he accidentally sent to me only.

---BeginMessage---

Hey Sebastian,

Quoting Sebastian Spaeth (2011-09-29 09:45:38)
On Mon, 26 Sep 2011 03:05:29 +0200, Justus Winter wrote:

#1) APPLIED
#2) APPLIED
#4) APPLIED
#5#6) APPLIED
#9) APPLIED
Thanks for the patches, most of them are quite nice. For 78, I'd like
to hear more opinions.

Thanks :)

#3) reorder the arguments of NotmuchError.__init__(): NOT APPLIED

The python tutorial gives an example of custom TransitionError with
three arguments, a custom message as the third. In addition, a STATUS
value is always expected to be given, while the additional explanatory
msg is optional, so STATUS makes for a more logical 1st parameter IMHO.
Even if it were the case, it makes for lots of code churn, longer code
(status=foo) to all Exceptions, and existing third party code would be
broken. Overall, I think there is more potential for trouble than
cleanup.

Well, #3 wasn't meant to be used standalone, I just wanted an intermediate
step in the refactoring process.

To address your concern wrt status being optional: I do consider code
doing 'raise NotmuchError(status=...)' to be wrong, one should raise
a more specific error in the first case.

#7) NOT APPLIED, INPUT SOUGHT :)
I do see the value of more fine grained exceptions, but I am not sure,
we need this level of fine-grainedness. It would also make things more
tricky (the API is still actively evolving, and e.g. 4 days ago, a new
error status was added), so users of the bindings would now have
 +NotmuchError,
 +OutOfMemoryError,
 +ReadOnlyDatabaseError,
 +XapianError,
 +FileError,
 +FileNotEmailError,
 +DuplicateMessageIdError,
 +NullPointerError,
 +TagTooLongError,
 +UnbalancedFreezeThawError,
 +UnbalancedAtomicError,
 +NotInitializedError

 [...]

to check where e.g. Xapian could also hide an Out of Memory.
Well, if the underlying API changes, the bindings will have to be
updated as well. What's wrong with that?

 Do people
really want to catch, say UnbalancedAtomic errors specifically, rather
than testing whether an operation succeeded, and check the status code
if not? I could see the case for NotInitializedError, as that is a bit
specific to the python bindings and users might want to catch it separately.

Well, those not interested in the exact nature of the failure can
still except NotmuchError as before. I also added the status code to
each class so that legacy style exception handling won't break.

(On second thought, we could also provide a .args property that issues
a deprecation warning when used to make the transition  even smoother.)

Also, not all status are an error, e.g. DuplicateMessageId denotes
success rather than failure, it just communicates a status.
Hm, I didn't knew that. This feels somewhat strange though.

If I were to design an API that uses an integer to indicate both
success and error, I'd reserve one bit indicating error so testing
for errors can be easily done by anding with a bitmask.

Cheers,
Justus

.signature
Description: Binary data
---End Message---


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

[PATCH v6 00/17] Fix 'notmuch new' atomicity issues

[Sebastian Spaeth]

On Sat, 11 Jun 2011 16:04:26 -0400, Austin Clements  wrote:
> Here's the reworked patch series that uses atomic sections more
> heavily rather than changing the removal API.  This is atomic-new-v6
> on http://awakening.csail.mit.edu/git/notmuch.git .

I just caught up implementing find_message_by_filename and
begin|end_atomic

One oddity, since databases are opened in read-only by default, I was
surprise to see find_message_by_filename on such a database have my
python instance crash...

> lib: Add an API to find a message by filename.
>   Culled from "lib: Add API's to find by filename and ..." in the old
>   series.  What I kept is identical.

db.find_message_by_filename("moo")
Internal error: Failure to ensure database is writable
(lib/directory.cc:100).

Outch?
Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Concerns regarding some library functions

[Sebastian Spaeth]

On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel wrote:
> The two functions I've mentioned above are
> notmuch_database_find_message() and
> notmuch_database_find_message_by_filename().
> 
> The problem with their design is NULL return may both mean an error
> condition and "message not found". However, we already have a similar
> function which does not have such a flaw, namely 
> notmuch_database_add_message().

Yes, this is because NULL used to mean message not found and NULL means
error was tacked on later (because cworth did not expect that xapian
would actually throw errors that often (such as database modified and
whatnot). So the meaning of NULL is, ahhem, suboptimal...

ERROR or really not there? There are mails from me, commenting on
that. I would welcome receiving back a notmuch_status_t value and have a
separate notmuch_message_t parameter which receives the actual message.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Rethinking *_destroy()

[Sebastian Spaeth]

On Mon, 19 Sep 2011 18:08:22 -0400, Ben Gamari  
wrote:
[...]

Just sayin' that from a python perspective, this happen to seem to work
fine with the current cpython implementation, but it might well break
when switching to pypy or what not.

So, given some spare time, I would be happy to move towards using a
talloc_refunref scheme which would work just fine as well. Even better,
I would take patches doing that for me :-)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: Rethinking *_destroy()

[Sebastian Spaeth]

On Mon, 19 Sep 2011 18:08:22 -0400, Ben Gamari bgamari.f...@gmail.com wrote:
[...]

Just sayin' that from a python perspective, this happen to seem to work
fine with the current cpython implementation, but it might well break
when switching to pypy or what not.

So, given some spare time, I would be happy to move towards using a
talloc_refunref scheme which would work just fine as well. Even better,
I would take patches doing that for me :-)

Sebastian


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

Python Unicode Was: Not much database creation error

[Sebastian Spaeth]

P.S. perhaps we should be using:

locale.getpreferredencoding()

to determine the default path and tag encoding? Opinions, Experiences,...?

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Python Unicode Was: Not much database creation error

[Sebastian Spaeth]

On Thu, 15 Sep 2011 13:41:11 -0400, Martin Owens wrote:
> I've attached a diff for some proposed changes to help make dealing with
> unicode and strings in the bindings more regular. I noticed some of the
> methods were protected and others were not.

I've now pushed a slightly modified version of the patch (BTW, you have
find_message_by_filename() when I don't, care to send that patch too?
:-))

As discussed on IRC with Bremner and ojwb: Rather than hardcoding UTF-8
we should probably detect the systems locale variable and use that as
encoding for file paths (falling back to utf8).

But your patch is better than what we have before, so it's going in for
now.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Unicode Paths

[Sebastian Spaeth]

On Thu, 15 Sep 2011 13:52:12 -0400, Austin Clements  wrote:
> On Tue, Sep 13, 2011 at 11:55 PM, Martin Owens  wrote:
> > Hello Again,
> >
> > I notice in the lib code notmuch_database_open(),
> > notmuch_database_create() these functions use const char *path for the
> > directory path input. Is this unicode safe?
> >
> > The python bindings (and ctype docs) seem to suggest using something
> > called 'wchar_t *' for accepting unicode but that's for C not C++.
> >
> > Is this something that should be patched?
> 
> char* is the correct type for paths on POSIX systems.  The *meaning*
> of those bytes is a more complicated matter and depends on your locale
> settings.  On old systems it was generally ASCII, on modern systems
> it's generally UTF-8, and it can be many other things.  However, as a
> consequence of UNIX's C heritage, it is *always* terminated with a
> NULL byte and cannot contain embedded NULL's.

Right, that's what we are doing, passing in utf-8 encoded unicode
strings to char*, which should be just fine if that is what the
underlying OS uses.

> wchar_t is another matter entirely.  wchar_t is the type used by C to
> represent wide strings internally, which generally (but not
> necessarily!) means it stores a Unicode code point.  However, this
> isn't an encoding, and different compilers can give wchar_t different
> meanings, so wchar_t strings aren't generally appropriate for storing
> or sharing between processes or with the kernel.

Mmh, I remember I attempted to user wchar_t to pass in unicode objects
directly and it had failed miserably.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: Unicode Paths

[Sebastian Spaeth]

On Thu, 15 Sep 2011 13:52:12 -0400, Austin Clements amdra...@mit.edu wrote:
 On Tue, Sep 13, 2011 at 11:55 PM, Martin Owens docto...@gmail.com wrote:
  Hello Again,
 
  I notice in the lib code notmuch_database_open(),
  notmuch_database_create() these functions use const char *path for the
  directory path input. Is this unicode safe?
 
  The python bindings (and ctype docs) seem to suggest using something
  called 'wchar_t *' for accepting unicode but that's for C not C++.
 
  Is this something that should be patched?
 
 char* is the correct type for paths on POSIX systems.  The *meaning*
 of those bytes is a more complicated matter and depends on your locale
 settings.  On old systems it was generally ASCII, on modern systems
 it's generally UTF-8, and it can be many other things.  However, as a
 consequence of UNIX's C heritage, it is *always* terminated with a
 NULL byte and cannot contain embedded NULL's.

Right, that's what we are doing, passing in utf-8 encoded unicode
strings to char*, which should be just fine if that is what the
underlying OS uses.

 wchar_t is another matter entirely.  wchar_t is the type used by C to
 represent wide strings internally, which generally (but not
 necessarily!) means it stores a Unicode code point.  However, this
 isn't an encoding, and different compilers can give wchar_t different
 meanings, so wchar_t strings aren't generally appropriate for storing
 or sharing between processes or with the kernel.

Mmh, I remember I attempted to user wchar_t to pass in unicode objects
directly and it had failed miserably.

Sebastian


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

Re: Python Unicode Was: Not much database creation error

[Sebastian Spaeth]

On Thu, 15 Sep 2011 13:41:11 -0400, Martin Owens wrote:
 I've attached a diff for some proposed changes to help make dealing with
 unicode and strings in the bindings more regular. I noticed some of the
 methods were protected and others were not.

I've now pushed a slightly modified version of the patch (BTW, you have
find_message_by_filename() when I don't, care to send that patch too?
:-))

As discussed on IRC with Bremner and ojwb: Rather than hardcoding UTF-8
we should probably detect the systems locale variable and use that as
encoding for file paths (falling back to utf8).

But your patch is better than what we have before, so it's going in for
now.

Sebastian


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

Memory management practices

[Sebastian Spaeth]

On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements  wrote:
> Ah, the *Python* objects don't care, but the underlying C objects do.
[...]

Thanks for the elaboration. I understand now and agree with the analysis..

> Hence my suggestion that, rather than trying to emulate C-style memory
> management in bindings, bindings should create an additional talloc
> reference to the underlying objects and rather than calling
> notmuch_*_destroy during finalization, they should simply unlink this
> additional reference.

Agreed, that sounds like a much better option, although it would keep a
(underlying C object) for Query and all derived Messages around, even
when I explicitely "del query" in python, as long as the python GC keeps
any of those Message() objects alive and around, wouldn't it? (which
would probably be an ok behavior).

But the talloc ref/unref is not exposed through the lib currently, of course.

> Then there's also no need to replicate the library's reference
> structure in the bindings (though there is a danger of needlessly
> delaying free's when the library creates convenience references like
> the one from notmuch_query_t to notmuch_messages_t; for these I'd
> recommend that the bindings undo such references, which requires a
> little knowledge of the library's reference structure, but nothing
> beyond what should be documented).

Right, that would of course solve the above 'problem'.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Patch: Flush and Reopen

[Sebastian Spaeth]

On Sun, 11 Sep 2011 21:04:39 -0400, Martin Owens  wrote:

> Subject: [PATCH] Add flush and reopen to notmuch database + python bindings.

The python parts look fine to me, they certainly have my blessing to go
in if the rest is being checked in.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: Memory management practices

[Sebastian Spaeth]

On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements amdra...@mit.edu wrote:
 Ah, the *Python* objects don't care, but the underlying C objects do.
[...]

Thanks for the elaboration. I understand now and agree with the analysis..

 Hence my suggestion that, rather than trying to emulate C-style memory
 management in bindings, bindings should create an additional talloc
 reference to the underlying objects and rather than calling
 notmuch_*_destroy during finalization, they should simply unlink this
 additional reference.

Agreed, that sounds like a much better option, although it would keep a
(underlying C object) for Query and all derived Messages around, even
when I explicitely del query in python, as long as the python GC keeps
any of those Message() objects alive and around, wouldn't it? (which
would probably be an ok behavior).

But the talloc ref/unref is not exposed through the lib currently, of course.

 Then there's also no need to replicate the library's reference
 structure in the bindings (though there is a danger of needlessly
 delaying free's when the library creates convenience references like
 the one from notmuch_query_t to notmuch_messages_t; for these I'd
 recommend that the bindings undo such references, which requires a
 little knowledge of the library's reference structure, but nothing
 beyond what should be documented).

Right, that would of course solve the above 'problem'.

Sebastian


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

Memory management practices

[Sebastian Spaeth]

On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements  wrote:
> In general, a garbage collector can't make any guarantees about
> finalization order.  When a collection of objects all become
> unreachable simultaneously (for example, the last reference to any
> Messages object is dropped, causing the Query object and the Message
> object to both become unreachable), the garbage collector *could*
> finalize the Query first (causing talloc to free the
> notmuch_messages_t) and then the Messages object (causing it to
> crash).  There's no guarantee in general because, in the presence of
> cycles, there is no meaningful finalization order.

Right, but that should not pose a problem for python. If e.g. both a
Query and derived Message objects become unreachable, the python objects
would not care which object is ditched and deleted first. Currently, it
seems that we finalize the Messages first, and the Query second. But we
would not fail if the Query were finalized first. Granted, the
underlying libnotmuch Message objects were torn away while the python
Message objects were still around. But they would ultimately also be
sweeped away, and that would not cause any problems.

But I am sure that I am missing out something. I'll leave this
discussion to the pros :-).

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: Memory management practices

[Sebastian Spaeth]

On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements amdra...@mit.edu wrote:
 In general, a garbage collector can't make any guarantees about
 finalization order.  When a collection of objects all become
 unreachable simultaneously (for example, the last reference to any
 Messages object is dropped, causing the Query object and the Message
 object to both become unreachable), the garbage collector *could*
 finalize the Query first (causing talloc to free the
 notmuch_messages_t) and then the Messages object (causing it to
 crash).  There's no guarantee in general because, in the presence of
 cycles, there is no meaningful finalization order.

Right, but that should not pose a problem for python. If e.g. both a
Query and derived Message objects become unreachable, the python objects
would not care which object is ditched and deleted first. Currently, it
seems that we finalize the Messages first, and the Query second. But we
would not fail if the Query were finalized first. Granted, the
underlying libnotmuch Message objects were torn away while the python
Message objects were still around. But they would ultimately also be
sweeped away, and that would not cause any problems.

But I am sure that I am missing out something. I'll leave this
discussion to the pros :-).

Sebastian


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

Memory management practices

[Sebastian Spaeth]

On Wed, 7 Sep 2011 23:05:19 -0400, Austin Clements  wrote:
> Sorry, I went back and re-read your earlier messages and now I see why
> your references were the way they were.  I stand by the rest of my
> previous message though.  I think the technique used in the Python
> bindings only works because Python's GC happens to finalize in a
> particular order (though I doubt that's guaranteed, and could easily
> not be the case if you stray into the realm of its cycle collector).
> In general, it seems like approach is trying to recreate C-like memory
> management and is fragile as a result, whereas talloc should, I think,
> allow bindings to express their runtime's memory management rather
> naturally.

Mmmh? Why would the method in python be fragile? Each message object
holds a reference to its parent query object to keep it alive. Are you
saying cycle collectors could kill off the query object nonetheless?
(Assume that I know nothing of GCs which comes close to reality)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Not much database creation error

[Sebastian Spaeth]

On Wed, 07 Sep 2011 01:26:59 -0400, Martin Owens  wrote:
> As a further question, I have a program opening the database for
> READ_WRITE access (this process provides a simple write only dbus
> interface) and I want clients to connect to notmuch over a read only
> connection.
> 
> A problem I'm having is that when I add messages to the database,
> searching using the read only interface fails to show anything.

> Is this api topology not expected/recommended/working? Please advise.

hi Martin,

I have to admit, I am not deep into the libnotmuch/xapian internals, so
I might be the wrong person to ask (I just do some python bindings to
whatever libnotmuch provides).

However, when a read-write connection changes content, I believe that
all other existing connections will return an error stating
DATABASE_MODIFIED. I think we throw (or at least are supposed to throw)
an exception in this case.

Are you seeing any exceptions or errors been thrown?  Does it not show
ANYTHING or only not the new messages?

An open database connection provides you only with a snapshot, and you
need to reopen it after content has been modified.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH] Do not import notmuch in setup.py (again).

[Sebastian Spaeth]

On Mon, 05 Sep 2011 09:04:54 -0300, David Bremner  wrote:
>  On Wed, 24 Aug 2011 09:20:51 +0200, Sebastian Spaeth wrote
>  > Ahh, sorry, I must have missed that patch (or forgotten about it). I
>  > solved this now by having the version number in version.py (which
>  > contains nothing else, so David Bremner can easily overwrite it with
>  > makefile magic :-)).
> 
> I pushed a test to be run during the release process, to see that the
> versions of the lib and the python bindings match. I decided against
> automagically overwriting the file (for now), since I'd prefer the
> committed version.py match the tarball, and I'm not super happy with
> auto-commiting things.

Sounds fair enough. You've got hereby got a blanket permission to fudge
the version number as needed for the release process ;-)

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110906/f31ddf28/attachment.pgp>

Not much database creation error

[Sebastian Spaeth]

On Sun, 04 Sep 2011 00:34:58 -0400, Martin Owens  wrote:
> I am creating a program using notmuch and the python notmuch API and
> have found a problem. when creating or loading a database using a
> unicode path, notmuch returns an error:
> 
> Error: Cannot create directory //.notmuch: Permission denied

Hi Martin,

the underlying notmuch library is agnostic to whatever encoding it is
handed and I indeed had simply assumed strings. I have now added
encoding/decoding in a couple of places where it seemed necessary and
pushed the result to the master branch.

Let me know if this fixes things.

Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

Re: Not much database creation error

[Sebastian Spaeth]

On Sun, 04 Sep 2011 00:34:58 -0400, Martin Owens docto...@gmail.com wrote:
 I am creating a program using notmuch and the python notmuch API and
 have found a problem. when creating or loading a database using a
 unicode path, notmuch returns an error:
 
 Error: Cannot create directory //.notmuch: Permission denied

Hi Martin,

the underlying notmuch library is agnostic to whatever encoding it is
handed and I indeed had simply assumed strings. I have now added
encoding/decoding in a couple of places where it seemed necessary and
pushed the result to the master branch.

Let me know if this fixes things.

Sebastian


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