Re: bug: "no top level messages" crash on Zen email loops
On Mon, Mar 19, 2018 at 05:03:21PM -0300, David Bremner wrote: > I can confirm this reproduces both the xapian-check and the notmuch-show > error. Olly agrees that whatever notmuch is doing wrong, it shouldn't > lead to a corrupted database There was a Xapian bug here, which I fixed on master last week and will be fixed in 1.4.6. If changes to a new database which didn't modify the termlist table were committed, then a disk block which had been allocated to be the root block in the termlist table was leaked (not used but not on the freelist of blocks the table can recycle). This was largely harmless, except that it was detected by Database::check() and caused an error. Cheers, Olly ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
Brian May writes: > David Bremner writes: > >> We tried this before, and it didn't work out very well. Bindings tend to >> depend on a strict matching of versions with the underlying library, so >> distributing them seperately doesn't really make sense to me. You need >> the underlying libraries, so why not get the matching bindings from the >> same place? We found that the situation was exacerbated by the fact >> that no-one cared about updating the bindings on pypi. > [...] > Unfortunately, I think many people will not even consider using a python > library unless it has up-to-date bindings available on pypi. That's not an itch I personally have, but as I said in the next paragraph, if someone want's to take on the project of maintaining a wheel, we'll render the same kind of assistance we give *BSD/Linux/MacOS package maintainers. We're happy to look at (reasonable) things we can do to make downstream projects life easier. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
David Bremner writes: > We tried this before, and it didn't work out very well. Bindings tend to > depend on a strict matching of versions with the underlying library, so > distributing them seperately doesn't really make sense to me. You need > the underlying libraries, so why not get the matching bindings from the > same place? We found that the situation was exacerbated by the fact > that no-one cared about updating the bindings on pypi. I believe that is the purpose of Python Wheels. https://pythonwheels.com/ pypi is the defecto standard for distributing Python code for use in Python applications. It means packages that use notmuch just need to list it as a dependancy in 'requirements.txt' and a 'pip install -r requirements.txt' will install everything required (if inside a virtualenv no root access required even). There are also various solutions to get automatic deploys to pypi, for example through travis: https://docs.travis-ci.com/user/deployment/pypi/ Unfortunately, I think many people will not even consider using a python library unless it has up-to-date bindings available on pypi. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
On Wed, Mar 28 2018, David Bremner wrote: > Brian May writes: > >> I can into this thread late. However, my priorities for python bindings >> would be: > > [...] >> * Packages should be available from pypi.python.org >> > > We tried this before, and it didn't work out very well. Bindings tend to > depend on a strict matching of versions with the underlying library, so > distributing them seperately doesn't really make sense to me. You need > the underlying libraries, so why not get the matching bindings from the > same place? We found that the situation was exacerbated by the fact > that no-one cared about updating the bindings on pypi. I did build a #if LIBNOTMUCH_MAJOR_VERSION < 5 #error libnotmuch version not supported by notdb #endif into my current bindings which kind of allows you to do this to some, hopefully reasonable, level. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
On Wed, Mar 28 2018, Brian May wrote: > Justus Winter writes: > >>> This is exactly what I have fixed in my alternative bindings which I >>> created around the end of last year [0]. So we do have an idea of how >>> to fix this, at the time I said I do believe that it's possible to also >>> do this for the existing bindings even though it is a lot of work. >>> After some talking between dkg and me we got to a way forward which >>> proposed this, but I must admit that after messing a little with getting >>> a pytest run integrated into the notmuch test-suite instead of using tox >>> I lost momentum on the project and didn't advance any further. >> >> I'm sorry that I didn't speak up when you announced your work. I'm >> actually excited about a new set of bindings for Python. I agree with >> using cffi. I briefly looked at the code, and I believe it is much >> nicer than what we currently have. > > I can into this thread late. However, my priorities for python bindings > would be: > > * I don't care about anything less then Python 3.5. > * Reliable Python 3.6 support important. > * Packages should be available from pypi.python.org Well, the 1st two should already be covered on my https://github.com/flub/notmuch/tree/cffi branch. There's obviously still room for improvement. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings
On Wed, Mar 28 2018, Justus Winter wrote: > Floris Bruynooghe writes: > >> On Wed, Mar 21 2018, Justus Winter wrote: >>> >>> Floris Bruynooghe writes: >>> This is exactly what I have fixed in my alternative bindings which I created around the end of last year [0]. So we do have an idea of how to fix this, at the time I said I do believe that it's possible to also do this for the existing bindings even though it is a lot of work. After some talking between dkg and me we got to a way forward which proposed this, but I must admit that after messing a little with getting a pytest run integrated into the notmuch test-suite instead of using tox I lost momentum on the project and didn't advance any further. >>> >>> I'm sorry that I didn't speak up when you announced your work. I'm >>> actually excited about a new set of bindings for Python. I agree with >>> using cffi. I briefly looked at the code, and I believe it is much >>> nicer than what we currently have. >> >> Nice to hear, thanks! > > Thanks for all the work :) > >>> I trust that it works fine with Python 3, does it? >> >> The version I made so far *only* works on Python 3. Mostly because it >> was easier, but it also allows some API niceties. > > Reasonable choice. Which versions of Python 3 are supported? I am also > writing bindings and I am wondering which versions to target. Personally I consider python3.5, pypy3.5 and python3.6 the ones to target if I have no other constraints, which was the case here. For upstreaming into notmuch proper there are naturally other constraints ;-) But unless you need something specific I think 3.4 is when py3k became the better version than 2.7, everything below that is probably not worth it. All IMHO obviously. Cheers, Floris ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: bump LIBRARY_MINOR_VERSION
On Tue, Mar 27 2018, David Bremner wrote: > We added several new functions, at least > >notmuch_database_get_default_indexopts >notmuch_database_index_file >notmuch_indexopts_destroy >notmuch_indexopts_get_decrypt_policy >notmuch_indexopts_set_decrypt_policy >notmuch_message_count_files >notmuch_message_has_maildir_flag >notmuch_message_reindex >notmuch_message_remove_all_properties_with_prefix >notmuch_thread_get_total_files > --- > NEWS | 10 ++ > lib/notmuch.h | 2 +- > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/NEWS b/NEWS > index 01ac3942..734ac03b 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,3 +1,13 @@ > +Notmuch 0.26.1 (UNRELEASED) > +=== > + > +Library Changes > +--- > + > +Bump the library minor version. This should have happened in 0.26, but > +better late than never, I guess. +1, imo you could drop that ', I guess' Tomi > + > + > Notmuch 0.26 (2018-01-09) > = > > diff --git a/lib/notmuch.h b/lib/notmuch.h > index 39759b7a..ab5854d7 100644 > --- a/lib/notmuch.h > +++ b/lib/notmuch.h > @@ -58,7 +58,7 @@ NOTMUCH_BEGIN_DECLS > * version in Makefile.local. > */ > #define LIBNOTMUCH_MAJOR_VERSION 5 > -#define LIBNOTMUCH_MINOR_VERSION 0 > +#define LIBNOTMUCH_MINOR_VERSION 1 > #define LIBNOTMUCH_MICRO_VERSION 0 > > > -- > 2.16.1 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
Brian May writes: > I can into this thread late. However, my priorities for python bindings > would be: [...] > * Packages should be available from pypi.python.org > We tried this before, and it didn't work out very well. Bindings tend to depend on a strict matching of versions with the underlying library, so distributing them seperately doesn't really make sense to me. You need the underlying libraries, so why not get the matching bindings from the same place? We found that the situation was exacerbated by the fact that no-one cared about updating the bindings on pypi. Projects like numpy seem to get around this by distributing compiled shared libraries on pypi. That's fine if someone wants to do it, but it looks like "just another distro" to me, and not really an upstream problem. I guess we'd entertain minor tweaks to the build system to support that, but probably not a wholesale conversion. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
Justus Winter writes: >> This is exactly what I have fixed in my alternative bindings which I >> created around the end of last year [0]. So we do have an idea of how >> to fix this, at the time I said I do believe that it's possible to also >> do this for the existing bindings even though it is a lot of work. >> After some talking between dkg and me we got to a way forward which >> proposed this, but I must admit that after messing a little with getting >> a pytest run integrated into the notmuch test-suite instead of using tox >> I lost momentum on the project and didn't advance any further. > > I'm sorry that I didn't speak up when you announced your work. I'm > actually excited about a new set of bindings for Python. I agree with > using cffi. I briefly looked at the code, and I believe it is much > nicer than what we currently have. I can into this thread late. However, my priorities for python bindings would be: * I don't care about anything less then Python 3.5. * Reliable Python 3.6 support important. * Packages should be available from pypi.python.org I have found the current official bindings unreliable with Python 3.x, and tend to cause aborts on exiting and/or fail to save updates. As such, for now I have downgraded to Python 2.7 for now. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch