On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements wrote:
> Ah, the *Python* objects don't care, but the underlying C objects do.
[...]
Thanks for the elaboration. I understand now and agree with the analysis..
> Hence my suggestion that, rather than trying to emulate C-style memory
>
On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements amdra...@mit.edu wrote:
Ah, the *Python* objects don't care, but the underlying C objects do.
[...]
Thanks for the elaboration. I understand now and agree with the analysis..
Hence my suggestion that, rather than trying to emulate C-style
Quoth Ben Gamari on Sep 11 at 5:47 pm:
> Sorry I've been so quiet on this recently. I've been a little under the
> weather.
No worries.
> On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements
> wrote:
> > Hence my suggestion that, rather than trying to emulate C-style memory
> > management in
Sorry I've been so quiet on this recently. I've been a little under the
weather.
On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements wrote:
> Ah, the *Python* objects don't care, but the underlying C objects do.
> Suppose the Query were finalized first. Python calls Query.__del__,
> which calls
Sorry I've been so quiet on this recently. I've been a little under the
weather.
On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements amdra...@mit.edu wrote:
Ah, the *Python* objects don't care, but the underlying C objects do.
Suppose the Query were finalized first. Python calls Query.__del__,
Quoth Sebastian Spaeth on Sep 09 at 11:27 am:
> On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements
> wrote:
> > In general, a garbage collector can't make any guarantees about
> > finalization order. When a collection of objects all become
> > unreachable simultaneously (for example, the last
On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements wrote:
> In general, a garbage collector can't make any guarantees about
> finalization order. When a collection of objects all become
> unreachable simultaneously (for example, the last reference to any
> Messages object is dropped, causing the
On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements amdra...@mit.edu wrote:
In general, a garbage collector can't make any guarantees about
finalization order. When a collection of objects all become
unreachable simultaneously (for example, the last reference to any
Messages object is dropped,
Quoth Sebastian Spaeth on Sep 09 at 11:27 am:
On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements amdra...@mit.edu wrote:
In general, a garbage collector can't make any guarantees about
finalization order. When a collection of objects all become
unreachable simultaneously (for example, the
On Wed, 7 Sep 2011 23:05:19 -0400, Austin Clements wrote:
> Sorry, I went back and re-read your earlier messages and now I see why
> your references were the way they were. I stand by the rest of my
> previous message though. I think the technique used in the Python
> bindings only works
Quoth Sebastian Spaeth on Sep 08 at 3:50 pm:
> On Wed, 7 Sep 2011 23:05:19 -0400, Austin Clements
> wrote:
> > Sorry, I went back and re-read your earlier messages and now I see why
> > your references were the way they were. I stand by the rest of my
> > previous message though. I think the
On Wed, Sep 7, 2011 at 10:48 PM, Austin Clements wrote:
> *snip*
>
> I'm a bit confused by the reference tree you drew. ?The references in
> the underlying libnotmuch objects are the other way around.
> notmuch_query_t holds a talloc reference to every notmuch_messages_t
> it produces, not the
Quoth Sebastian Spaeth on Sep 08 at 3:50 pm:
On Wed, 7 Sep 2011 23:05:19 -0400, Austin Clements amdra...@mit.edu wrote:
Sorry, I went back and re-read your earlier messages and now I see why
your references were the way they were. I stand by the rest of my
previous message though. I
On Wed, Sep 7, 2011 at 4:36 PM, Ben Gamari wrote:
> On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari
> wrote:
>> [SNIP]
>>
>> In general, it seems to me that memory management in notmuch bindings is
>> a little bit harder than it needs to me due to the decision not to
>> talloc_ref parent objects
On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari
wrote:
> [SNIP]
>
> In general, it seems to me that memory management in notmuch bindings is
> a little bit harder than it needs to me due to the decision not to
> talloc_ref parent objects when a new child object is created. This means
> that a
Hey all,
Over the last few weeks I've been trying to fix some brokeness in the
notmuch-haskell bindings with respect to memory management.
In discussion included below, I describe the issue as I approached it.
In short, it appears that GHC's garbage collector is quite liberal with
the order in
Hey all,
Over the last few weeks I've been trying to fix some brokeness in the
notmuch-haskell bindings with respect to memory management.
In discussion included below, I describe the issue as I approached it.
In short, it appears that GHC's garbage collector is quite liberal with
the order in
17 matches
Mail list logo
