It was assumed the destructor of notmuch_rb_database_type did return a
notmuch_status_t because that's what notmuch_database_close returns, and
that value was checked by notmuch_rb_database_close in order to decide
if to raise an exception.
It turns out notmuch_database_destroy was called instead, so nothing was
returned (void).
All the destroy functions are void, and that's what we want.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Mirrors the C API: 7864350c (Split notmuch_database_close into two
functions, 2012-04-25).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
We basically steal all the objects from their notmuch parents, therefore
they are completely under Ruby's gc control.
The order at which these objects are freed does not matter any more,
because destroying the database does not destroy all the children
objects, since they belong to Ruby now.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Currently Ruby data points directly to a notmuch object (e.g.
notmuch_database_t), since we don't need any extra data that is fine.
However, in the next commit we will need extra data, therefore we create
a new struct notmuch_rb_object_t wrapper which contains nothing but a
pointer to the current pointer (e.g. notmuch_database_t).
This struct is tied to the Ruby object, and is freed when the Ruby
object is freed by the garbage collector.
We do nothing with this wrapper, so no functionality should be changed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
The ruby MakeMakefile generates a makefile that is suboptimal, which has
CFLAGS like this:
CFLAGS = $(CCDLFLAGS) -march=x86-64 -mtune=generic \
-O2 -pipe -fno-plt -fPIC $(ARCH_FLAG)
This works as long as the user doesn't modify the Makefile.
Certain flags (namely -fPIC) need to be present regardless of what
CFLAGS are specified.
The Makefile should have done this instead:
CFLAGS = -march=x86-64 -mtune=generic -O2
override CFLAGS += $(CCDLFLAGS) -pipe -fno-plt -fPIC $(ARCH_FLAG)
Unfortunately they didn't, so we need to workaround their lack of
foresight.
We can simply add the necessary flags in the parent Makefile so everyone
is happy.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
The struct used to store the types (rb_data_type_t) contains a "data"
field where we can store whatever we want. I use that field to store a
pointer to the corresponding destroy function. For example
notmuch_rb_database_type contains a pointer to notmuch_database_destroy.
I cast that pointer as a notmuch_status_t (func*)(void *) and call
that function passing the internal object (e.g. notmuch_database_t).
Using the rb_data_type_t data we can call the correct notmuch destroy
function.
Therefore this:
ret = ((notmuch_status_t (*)(void *)) type->data) (nm_object);
Is effectively the same as this:
ret = notmuch_database_destroy (database);
The advantage of doing it this way is that much less code is necesary
since each rb_data_type_t has the corresponding destroy function stored
in it.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Virtually the whole ruby core moved from RData to RTypeData, let's do so
ourselves too.
Basically the information typically passed through Data_Wrap_Struct is
now stored in a struct rb_data_type_t (mark and free functions). This
has the advantage that more information can be easily added, like the
name of the type, a custom data ponter, and more.
Data_Wrap_Struct is replaced with TypedData_Wrap_Struct, and the
information is stored in a struct rb_data_type_t, rather than passed
as arguments.
Check_Type is replaced with Check_TypedStruct, which is a wrapper for
rb_check_typeddata (with casts).
#define Check_TypedStruct(v, t) \
rb_check_typeddata(RBIMPL_CAST((VALUE)(v)), (t))
We can use rb_check_typeddata directly, just like we use rb_data_object_get
directly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
This makes the code more maintainable and will help in further patches.
No functional changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
There is not much point in complicating the code for error messages that
can be easily constructed.
Before:
database closed (RuntimeError)
After:
Notmuch::Database object destroyed (RuntimeError)
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Data_Get_Struct is nothing but a macro that calls
rb_data_object_get with a cast (unnecessary in C).
#define Data_Get_Struct(obj, type, sval) \
((sval) = RBIMPL_CAST((type*)rb_data_object_get(obj)))
We can use rb_data_object_get directly, and this way we don't need to
pass the type, which is unnecessary information.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
There's no need to do Check_Type, Data_Get_Struct calls
rb_data_object_get(), which already does that.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Apparently commit 5c9e3855 (ruby: Don't barf if an object is destroyed
more than once, 2010-05-26) missed these two.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
init.c:214:5: warning: ‘rb_cData’ is deprecated: by: rb_cObject. Will be removed in 3.1. [-Wdeprecated-declarations]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
This is the last bit of "python" left in the notmuch codebase.
https://www.python.org/dev/peps/pep-0394/#recommendation encourages
"third-party distributors" to use more-specific shebang lines. I'm
not certain that the notmuch project itself is a "third-party
contributor" but I think this is a safe way to encourage people to use
python3 when they're developing notmuch.
We already have python3 explicitly elsewhere in the codebase for
developers (in nmbug).
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This will allow client code to provide more meaningful diagnostics. In
particular it will enable "notmuch new" to continue suggsting the user
run "notmuch setup" to create a config after "notmuch new" is
transitioned to the new configuration framework.
A typo in Database._create_query lost the exclude_tag names during the
string to utf-8 conversion.
Amended by DB: fixed patch format and updated commit message.
Building Notmuch on macOS is known to cause problems because the Notmuch
distribution archive contains two files named "version". These names
clash with the <version> header as defined in C++20. Therefore, the
existing naming will likely become a problem on other platforms as well,
once compilers adopt the new standard.
Signed-off-by: Ralph Seichter <github@seichter.de>
Amended-by: db s/keyword/header/ in commit message.
Use `makefile-gmake-mode' instead of `makefile-mode' because the
former also highlights ifdef et al. while the latter does not.
"./Makefile.global" and one "Makefile.local" failed to specify any
major mode at all but doing so is necessary because Emacs does not
automatically figure out that these are Makefiles (of any flavor).
Since it is possible to use an atomic context to abort a number of
changes support this usage. Because the only way to actually abort
the transaction is to close the database this must also do so.
Amended by db: Note the limitation requiring close is a limitation of
the underlying notmuch API, which should be fixed in a future notmuch
release.
This reverses the logic of StandaloneMessage to instead create a
OwnedMessage. Only the Thread class allows retrieving messages more
then once so it can explicitly create such messages.
The added test fails with SIGABRT without the fix for the message
re-use in threads being present.
Any messages retrieved from a query - either directly via
search_messages() or indirectly via thread objects - are owned by that
query. Retrieving the same message (i.e. corresponding to the same
message ID / database object) several times will always yield the same
C object.
The caller is allowed to destroy message objects owned by a query before
the query itself - which can save memory for long-lived queries.
However, that message must then never be retrieved again from that
query.
The python-notmuch2 bindings will currently destroy every message object
in Message._destroy(), which will lead to an invalid free if the same
message is then retrieved again. E.g. the following python program leads
to libtalloc abort()ing:
import notmuch2
db = notmuch2.Database(mode = notmuch2.Database.MODE.READ_ONLY)
t = next(db.threads('*'))
msgs = list(zip(t.toplevel(), t.toplevel()))
msgs = list(zip(t.toplevel(), t.toplevel()))
Fix this issue by creating a subclass of Message, which is used for
"standalone" message which have to be freed by the caller. Message class
is then used only for messages descended from a query, which do not need
to be freed by the caller.
Even though we use collections.abc.Set which implements all these
methods under their operator names, the actual named variations of
these methods are shockingly missing. So let's add them manually.
crypto.gpg_path was only used when we built against gmime versions
before 3.0. Since we now depend on gmime 3.0.3 or later, it is
meaningless.
The removal of the field from the _notmuch_config struct would be an
ABI change if that struct were externally exposed, but it is not, so
it's safe to unilaterally remove it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Another fix to the docstrings, this time for the English part of the
docstrings, not the Python class name. No functional changes here.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
I was supposed to amend the original patch that added this function,
but somehow I botched that. The original version runs, so make an
extra commit for the tidying.
This moves away from the deprecated notmuch_database_add_message API
and instead uses the notmuch_database_index_file API. This means
instroducing a class to manage the index options and bumping the
library version requirement to 5.1.
This add the notmuch version and absolute path of the binary used
in the pytest header. This is nice when running the tests
interactively as you get confirmation you're testing the version you
thought you were testing.
This introduces CFFI-based Python3-only bindings.
The bindings aim at:
- Better performance on pypy
- Easier to use Python-C interface
- More "pythonic"
- The API should not allow invalid operations
- Use native object protocol where possible
- Memory safety; whatever you do from python, it should not coredump.
From notmuch 0.28, notmuch support relative database path in
notmuch-config(1), but python binding haven't taught this yet.
afew denied to work with a perfectly fine notmuch-config due to this.
In Python bindings, Message.get_property fails with an AttributeError when trying to fetch a property that doesn't exist.
From d712832ba982085975c27b23bb502af82e638b39 Mon Sep 17 00:00:00 2001
From: hydrargyrum <dev@indigo.re>
Date: Sun, 6 Jan 2019 16:08:55 +0100
Subject: [PATCH] python: fix get_property error when property doesn't exist
Indent the directive properly to attach it to Threads autoclass
documentation.
Fixes:
WARNING: don't know which module to import for autodocumenting
'__str__' (try placing a "module" or "currentmodule" directive in the
document, or giving an explicit module name)
