Re: Usage after database close

2020-06-29 Thread Floris Bruynooghe
On Sun 28 Jun 2020 at 19:11 -0300, David Bremner wrote:
> You need to add a seperate repo for the new style debug symbols in
> Debian:
> $ (git)-[master]-% apt policy libxapian30-dbgsym
> libxapian30-dbgsym:
>   Installed: 1.4.15-1
>   Candidate: 1.4.15-1
>   Version table:
>  *** 1.4.15-1 500
> 500 testing-debug/main 
> amd64 Packages
> 500 unstable-debug/main 
> amd64 Packages
> 100 /var/lib/dpkg/status

My goodness, I completely missed the dbgsym memo.  Thanks!
notmuch mailing list

Re: [PATCH 2/2] bindings/python-cffi: update version from global version.

2020-06-29 Thread Floris Bruynooghe
On Thu 25 Jun 2020 at 10:34 -0300, David Bremner wrote:

> David Bremner  writes:
>> Copy machinery from the older python bindings
>> +# get the notmuch version number without importing the notmuch module
>> +version_file = os.path.join(os.path.dirname(__file__),
>> +'notmuch2', '')
>> +exec(compile(open(version_file).read(), version_file, 'exec'))
>> +assert '__VERSION__' in globals(), \
>> +'Failed to read the notmuch binding version number'
> I wrote a cover letter for this, but that seems to have gotten lost. My
> main point was I'm not sure why this is better than Floris's version,
> since they both read a file when is run. I don't understand (or
> use) pip, so someone else will have to figure this out. If the
> constraint is that the version has to be hardcoded in then (as
> much as that sounds like a design mistake), we can apply similar sed
> hackery directly to Perhaps someone can remember why we didn't
> do that for the old python bindings.

For some reason this is the only mail in this thread I have, so I don't
actually know the patch.

I think it can be simpler though, is it possible to copy the toplevel
version file into bindings/python-cffi/version in the part of the build
that would otherwise do the sed magic?  Then only needs to look
for the version file in the same directory as itself instead of finding
the toplevel of the repo.
notmuch mailing list

Re: Usage after database close

2020-06-29 Thread David Bremner
David Bremner  writes:

> David Bremner  writes:
>>> But part of my question is, *should* this be improved?  Am I
>>> interpreting notmuch's intended API correctly?
>> Well, I agree you should get NOTMUCH_STATUS_XAPIAN_EXCEPTION back, or we
>> should change the docs to say "just don't do that".
> Arguments in favour of the latter:
> 1) several API calls don't return notmuch_status_t, so can't literally
> 2) notmuch_message_get_{message,thread}_id promise never to return NULL,
>has no way to report errors.
> I think it would probably make sense to say (if notmuch_database_reopen)
> existed, that if you call notmuch_database_close, don't call anything
> else except notmuch_database_reopen or notmuch_database_destroy.

I belatedly realized the exception is being caught, but then because of
a lack of an error path (and presumably thinking this error was unlikely
/ impossible), INTERNAL_ERROR is called. This is not great for bindings

Regardless of how the API docs are updated, the current calling of
INTERNAL_ERROR should be avoided. I think I know what to do, it's just a
matter doing so with a sensible amount of boilerplate and changes.

notmuch mailing list