On Tue 04 Oct 2011 14:18, David Bremner writes:
>
> So I've pushed the ABI changes, making it more urgent to do something
> about this. At this point I'm inclined to bump the soname in order to
> unbreak things, unless someone wants to come up with a convincing set of
> patches to do the symbol
On Thu, 29 Sep 2011 16:15:36 -0400, Austin Clements wrote:
> With symbol versioning we'd still provide the old function (presumably
> re-implemented in terms of the new function). Both would wind up in
> the .so and old binaries would still link against the old symbol. It
> doesn't help that
On Thu, 29 Sep 2011 16:15:36 -0400, Austin Clements amdra...@mit.edu wrote:
With symbol versioning we'd still provide the old function (presumably
re-implemented in terms of the new function). Both would wind up in
the .so and old binaries would still link against the old symbol. It
doesn't
On Tue 04 Oct 2011 14:18, David Bremner da...@tethera.net writes:
So I've pushed the ABI changes, making it more urgent to do something
about this. At this point I'm inclined to bump the soname in order to
unbreak things, unless someone wants to come up with a convincing set of
patches to
Austin Clements yazm??:
>Quoth Ali Polatel on Sep 28 at 10:53 am:
>> On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements
>> wrote:
>> > Quoth David Bremner on Sep 27 at 1:59 pm:
>> > > On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel
>> > > wrote:
>> > >
>> > > > The problem with their design
Austin Clements yazmış:
Quoth Ali Polatel on Sep 28 at 10:53 am:
On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements amdra...@mit.edu wrote:
Quoth David Bremner on Sep 27 at 1:59 pm:
On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel pola...@gmail.com wrote:
The problem with their design
On Thu, 29 Sep 2011 10:51:29 -0400, Austin Clements wrote:
> Yes. We could just deal with that (there aren't *that* many API
> consumers). For binary compatibility, I suppose we could even use
> symbol versioning.
I noticed a similar remark in lib/Makefile.local. But I'm not sure how
this
Quoth David Bremner on Sep 29 at 4:59 pm:
> On Thu, 29 Sep 2011 10:51:29 -0400, Austin Clements
> wrote:
>
> > Yes. We could just deal with that (there aren't *that* many API
> > consumers). For binary compatibility, I suppose we could even use
> > symbol versioning.
>
> I noticed a similar
Quoth Ali Polatel on Sep 28 at 10:53 am:
On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements amdra...@mit.edu wrote:
Quoth David Bremner on Sep 27 at 1:59 pm:
On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel pola...@gmail.com wrote:
The problem with their design is NULL return may
On Thu, 29 Sep 2011 10:51:29 -0400, Austin Clements amdra...@mit.edu wrote:
Yes. We could just deal with that (there aren't *that* many API
consumers). For binary compatibility, I suppose we could even use
symbol versioning.
I noticed a similar remark in lib/Makefile.local. But I'm not sure
Quoth David Bremner on Sep 29 at 4:59 pm:
On Thu, 29 Sep 2011 10:51:29 -0400, Austin Clements amdra...@mit.edu wrote:
Yes. We could just deal with that (there aren't *that* many API
consumers). For binary compatibility, I suppose we could even use
symbol versioning.
I noticed a
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".
On Tue, 27 Sep 2011 18:46:22 -0400, Austin Clements wrote:
> Quoth David Bremner on Sep 27 at 1:59 pm:
> > On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel
> > wrote:
> >
> > > The problem with their design is NULL return may both mean an error
> > > condition and "message not found". However,
Quoth David Bremner on Sep 27 at 1:59 pm:
> On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel wrote:
>
> > 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,
On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel wrote:
> 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().
So, I take
Hello,
Being the maintainer of Ruby bindings, I've been watching the
development of API changes closely. Ruby bindings are nearly complete
with the exception of two functions which I think are poorly implemented
in terms of error handling.
The two functions I've mentioned above are
Quoth David Bremner on Sep 27 at 1:59 pm:
On Tue, 27 Sep 2011 16:25:58 +0300, Ali Polatel pola...@gmail.com wrote:
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
17 matches
Mail list logo
