Re: [PATCH 0/4] Allow specifying alternate names for addresses in other_email
[notmuch-archives.git] / 62 / 8d4ff0916871dbacb65c1048e50327426b3a76
1 Return-Path: <bgamari.foss@gmail.com>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id C607F431FD0\r
6         for <notmuch@notmuchmail.org>; Wed,  7 Sep 2011 13:36:14 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.799\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id kBU0wLyPsP7U for <notmuch@notmuchmail.org>;\r
17         Wed,  7 Sep 2011 13:36:14 -0700 (PDT)\r
18 Received: from mail-qw0-f41.google.com (mail-qw0-f41.google.com\r
19         [209.85.216.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id 917A0431FB6\r
22         for <notmuch@notmuchmail.org>; Wed,  7 Sep 2011 13:36:14 -0700 (PDT)\r
23 Received: by qwa26 with SMTP id 26so54073qwa.28\r
24         for <notmuch@notmuchmail.org>; Wed, 07 Sep 2011 13:36:12 -0700 (PDT)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
26         h=from:to:cc:subject:in-reply-to:references:user-agent:date\r
27         :message-id:mime-version:content-type;\r
28         bh=8O53PxPrLOLTeQAvEF0cEkXAzLmFBwOJXXwpQHGIzLw=;\r
29         b=KHlQVwQ1pmceDfIQXw9u6V8INmmm0yR+kq1RLrVGrKQVxCqlPMh6ezCg9yh+pfK0b0\r
30         zCer2SNCvhvG+0PSYF7QP7yiLKHu2makG9wt6bFOjf9Hyx128z0Zv7cfBLmi2KihAcmN\r
31         lovEf/w4YS250EL9owaYVP66bMFgdf9HT6QDc=\r
32 Received: by 10.224.184.12 with SMTP id ci12mr5207760qab.270.1315427772596;\r
33         Wed, 07 Sep 2011 13:36:12 -0700 (PDT)\r
34 Received: from localhost (pool-96-233-180-23.spfdma.east.verizon.net.\r
35         [96.233.180.23])\r
36         by mx.google.com with ESMTPS id dh6sm1205141qab.0.2011.09.07.13.36.09\r
37         (version=TLSv1/SSLv3 cipher=OTHER);\r
38         Wed, 07 Sep 2011 13:36:10 -0700 (PDT)\r
39 From: Ben Gamari <bgamari.foss@gmail.com>\r
40 To: notmuch <notmuch@notmuchmail.org>, Carl Worth <cworth@cworth.org>\r
41 Subject: Re: Memory management practices\r
42 In-Reply-To: <87liucyn7i.fsf@gmail.com>\r
43 References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
44         <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
45         <87liucyn7i.fsf@gmail.com>\r
46 User-Agent: Notmuch/0.7-37-g5c3c7f6 (http://notmuchmail.org) Emacs/23.2.1\r
47         (x86_64-pc-linux-gnu)\r
48 Date: Wed, 07 Sep 2011 16:36:08 -0400\r
49 Message-ID: <87aaag3xaf.fsf@gmail.com>\r
50 MIME-Version: 1.0\r
51 Content-Type: text/plain; charset=us-ascii\r
52 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
53         Bart Massey <bart@cs.pdx.edu>\r
54 X-BeenThere: notmuch@notmuchmail.org\r
55 X-Mailman-Version: 2.1.13\r
56 Precedence: list\r
57 List-Id: "Use and development of the notmuch mail system."\r
58         <notmuch.notmuchmail.org>\r
59 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
60         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
61 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
62 List-Post: <mailto:notmuch@notmuchmail.org>\r
63 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
64 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
65         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
66 X-List-Received-Date: Wed, 07 Sep 2011 20:36:14 -0000\r
67 \r
68 On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari <bgamari.foss@gmail.com> wrote:\r
69 > [SNIP]\r
70\r
71 > In general, it seems to me that memory management in notmuch bindings is\r
72 > a little bit harder than it needs to me due to the decision not to\r
73 > talloc_ref parent objects when a new child object is created. This means\r
74 > that a bindings author needs to recreate the ownership tree in their\r
75 > binding, a task which is fairly easily done (except in the case of\r
76 > Haskell due to the weak GC finalization guarantees) but seems quite\r
77 > unnecessary. Is there a reason this decision was made? Would a patch be\r
78 > accepted adding talloc_ref'ing parents in those functions creating\r
79 > children and talloc_frees in *_destroys?\r
80\r
81 Any opinions concerning whether this is an acceptable idea? I wouldn't\r
82 mind putting together a patch-set, but I'd rather not waste my time if\r
83 the set would ultimately be rejected due to some technical objection I\r
84 have yet to think of.\r
85 \r
86 Cheers,\r
87 \r
88 - Ben\r