Re: Usage after database close
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 http://debug.mirrors.debian.org/debian-debug testing-debug/main > amd64 Packages > 500 http://debug.mirrors.debian.org/debian-debug unstable-debug/main > amd64 Packages > 100 /var/lib/dpkg/status My goodness, I completely missed the dbgsym memo. Thanks! ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] bindings/python-cffi: update version from global version.
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', 'version.py') >> +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 setup.py 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 setup.py then (as > much as that sounds like a design mistake), we can apply similar sed > hackery directly to setup.py. 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 setup.py 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 notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Usage after database close
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
>return NOTMUCH_STATUS_XAPIAN_EXCEPTION
>
> 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
either.
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.
d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
