Re: compile error of current git on F15
[notmuch-archives.git] / f3 / 5d367bc4db2309d38cd1cb7f6d4b2dd91d60a8
1 Return-Path: <Sebastian@sspaeth.de>\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 0AB40429E21\r
6         for <notmuch@notmuchmail.org>; Mon, 12 Sep 2011 05:30:23 -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.09\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
13         RCVD_IN_DNSWL_NONE=-0.0001, T_MIME_NO_TEXT=0.01] autolearn=disabled\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 TebOxhx236Bz for <notmuch@notmuchmail.org>;\r
17         Mon, 12 Sep 2011 05:30:22 -0700 (PDT)\r
18 Received: from homiemail-a22.g.dreamhost.com (caiajhbdcagg.dreamhost.com\r
19         [208.97.132.66])\r
20         by olra.theworths.org (Postfix) with ESMTP id 7A891431FB6\r
21         for <notmuch@notmuchmail.org>; Mon, 12 Sep 2011 05:30:22 -0700 (PDT)\r
22 Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])\r
23         by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id B58601A808D;\r
24         Mon, 12 Sep 2011 05:30:21 -0700 (PDT)\r
25 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sspaeth.de; h=from:to:cc:subject\r
26         :in-reply-to:references:date:message-id:mime-version:\r
27         content-type; q=dns; s=sspaeth.de; b=E7vx0s0zcZfrIVbEC/ZF1L0rWBG\r
28         sYyHeDTL8z5NgY8xcPqPaUE8hvE5OmbY+aGr/Kb23lY5sCPqK844qdf9TGMXSgZb\r
29         +GW/BQa5QUMkpg2YInS4Wr9/xNIBlsbe0kxIJ8a57PS+c1ZYAaNGdgC/wfbDhsCV\r
30         hrP2V0zgegLVoh04=\r
31 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sspaeth.de; h=from:to:cc\r
32         :subject:in-reply-to:references:date:message-id:mime-version:\r
33         content-type; s=sspaeth.de; bh=1KWAwEp3dMWrpAe7EprwMS3agUo=; b=b\r
34         3kyazrdS2Qb/iOCZrdgfRo5prcce1e8A7WkCW0IhcLo/gicAi8Wd22SbRcNVghRg\r
35         HjdPLlRn0NfllRJq3/cuoNMSpifcVeJmP2m5cnt5CwNxVuF8prGX/xeQDN54jJw7\r
36         yLxoZdaEkA9bqh1nPmXC43cNyhcn2OeNSm72zgLFmM=\r
37 Received: from spaetzbook.sspaeth.de (mtec-hg-docking-1-dhcp-21.ethz.ch\r
38         [129.132.133.21])\r
39         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
40         (No client certificate requested)\r
41         (Authenticated sender: fax@sspaeth.de)\r
42         by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPSA id A1F871A8083; \r
43         Mon, 12 Sep 2011 05:30:19 -0700 (PDT)\r
44 Received: by spaetzbook.sspaeth.de (sSMTP sendmail emulation);\r
45         Mon, 12 Sep 2011 14:30:18 +0200\r
46 From: Sebastian Spaeth <Sebastian@sspaeth.de>\r
47 To: Austin Clements <amdragon@MIT.EDU>\r
48 Subject: Re: Memory management practices\r
49 In-Reply-To: <20110909175328.GV5688@mit.edu>\r
50 References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
51         <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
52         <87liucyn7i.fsf@gmail.com> <87aaag3xaf.fsf@gmail.com>\r
53         <CAH-f9WsfHUm_D-+wB89Lt9Wt=hjwDyywvJTK-0NwmHRg0TUsxQ@mail.gmail.com>\r
54         <CAH-f9WveBfvmv2jOF+C81OeeQJt06g6U0q3J_idHrs60DLw7+g@mail.gmail.com>\r
55         <87zkiff8in.fsf@SSpaeth.de> <20110908151557.GM5688@mit.edu>\r
56         <8762l22hgk.fsf@SSpaeth.de> <20110909175328.GV5688@mit.edu>\r
57 User-Agent: Notmuch/0.7-19-gee4579a (http://notmuchmail.org) Emacs/23.2.1\r
58         (x86_64-pc-linux-gnu)\r
59 Date: Mon, 12 Sep 2011 14:30:17 +0200\r
60 Message-ID: <8739g2q6xy.fsf@SSpaeth.de>\r
61 MIME-Version: 1.0\r
62 Content-Type: multipart/signed; boundary="=-=-=";\r
63         micalg=pgp-sha1; protocol="application/pgp-signature"\r
64 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
65         Bart Massey <bart@cs.pdx.edu>, notmuch <notmuch@notmuchmail.org>\r
66 X-BeenThere: notmuch@notmuchmail.org\r
67 X-Mailman-Version: 2.1.13\r
68 Precedence: list\r
69 List-Id: "Use and development of the notmuch mail system."\r
70         <notmuch.notmuchmail.org>\r
71 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
72         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
73 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
74 List-Post: <mailto:notmuch@notmuchmail.org>\r
75 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
76 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
77         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
78 X-List-Received-Date: Mon, 12 Sep 2011 12:30:23 -0000\r
79 \r
80 --=-=-=\r
81 \r
82 On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
83 > Ah, the *Python* objects don't care, but the underlying C objects do.\r
84 [...]\r
85 \r
86 Thanks for the elaboration. I understand now and agree with the analysis..\r
87 \r
88 > Hence my suggestion that, rather than trying to emulate C-style memory\r
89 > management in bindings, bindings should create an additional talloc\r
90 > reference to the underlying objects and rather than calling\r
91 > notmuch_*_destroy during finalization, they should simply unlink this\r
92 > additional reference.\r
93 \r
94 Agreed, that sounds like a much better option, although it would keep a\r
95 (underlying C object) for Query and all derived Messages around, even\r
96 when I explicitely "del query" in python, as long as the python GC keeps\r
97 any of those Message() objects alive and around, wouldn't it? (which\r
98 would probably be an ok behavior).\r
99 \r
100 But the talloc ref/unref is not exposed through the lib currently, of course.\r
101 \r
102 > Then there's also no need to replicate the library's reference\r
103 > structure in the bindings (though there is a danger of needlessly\r
104 > delaying free's when the library creates convenience references like\r
105 > the one from notmuch_query_t to notmuch_messages_t; for these I'd\r
106 > recommend that the bindings undo such references, which requires a\r
107 > little knowledge of the library's reference structure, but nothing\r
108 > beyond what should be documented).\r
109 \r
110 Right, that would of course solve the above 'problem'.\r
111 \r
112 Sebastian\r
113 \r
114 --=-=-=\r
115 Content-Type: application/pgp-signature\r
116 \r
117 -----BEGIN PGP SIGNATURE-----\r
118 Version: GnuPG v1.4.11 (GNU/Linux)\r
119 \r
120 iEYEARECAAYFAk5t+1kACgkQVYX1jMgnoGLXlgCeNcuNFDuXEjaSzhW1df4FWtXf\r
121 0o4AnR0M3Hf9SbyHPW/4/6DZqjqsQqWD\r
122 =Ewc3\r
123 -----END PGP SIGNATURE-----\r
124 --=-=-=--\r