43/1bb3c0808b51e49be3c1872ebfb433b30fc57e

   1 Return-Path: <jrollins@finestructure.net>\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 1312A429E58\r
   6         for <notmuch@notmuchmail.org>; Sun,  2 Jun 2013 08:51:33 -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: -2.3\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id 7sPSOnPf2kLs for <notmuch@notmuchmail.org>;\r
  16         Sun,  2 Jun 2013 08:51:24 -0700 (PDT)\r
  17 Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
  18         [131.215.239.19])\r
  19         by olra.theworths.org (Postfix) with ESMTP id D7E88429E55\r
  20         for <notmuch@notmuchmail.org>; Sun,  2 Jun 2013 08:51:24 -0700 (PDT)\r
  21 Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
  22         by fire-doxen-postvirus (Postfix) with ESMTP id 5F71E2E50E39;\r
  23         Sun,  2 Jun 2013 08:51:22 -0700 (PDT)\r
  24 X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
  25 Received: from finestructure.net (cpe-76-173-75-86.socal.res.rr.com\r
  26         [76.173.75.86]) (Authenticated sender: jrollins)\r
  27         by fire-doxen-submit (Postfix) with ESMTP id 715772E50E38;\r
  28         Sun,  2 Jun 2013 08:51:17 -0700 (PDT)\r
  29 Received: by finestructure.net (Postfix, from userid 1000)\r
  30         id E8C886176D; Sun,  2 Jun 2013 08:51:16 -0700 (PDT)\r
  31 From: Jameson Graef Rollins <jrollins@finestructure.net>\r
  32 To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org\r
  33 Subject: Re: [PATCH v3 0/6] Make Emacs search use sexp format\r
  34 In-Reply-To: <87sj12yqyu.fsf@maritornes.cs.unb.ca>\r
  35 References: <1370047208-12785-1-git-send-email-amdragon@mit.edu>\r
  36         <87sj12yqyu.fsf@maritornes.cs.unb.ca>\r
  37 User-Agent: Notmuch/0.15.2+155~g7fa0560 (http://notmuchmail.org) Emacs/24.3.1\r
  38         (x86_64-pc-linux-gnu)\r
  39 Date: Sun, 02 Jun 2013 08:51:14 -0700\r
  40 Message-ID: <87r4gk8qa5.fsf@servo.finestructure.net>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: multipart/signed; boundary="=-=-=";\r
  43         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  44 Cc: tomi.ollila@iki.fi\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 List-Id: "Use and development of the notmuch mail system."\r
  49         <notmuch.notmuchmail.org>\r
  50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  53 List-Post: <mailto:notmuch@notmuchmail.org>\r
  54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  56         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  57 X-List-Received-Date: Sun, 02 Jun 2013 15:51:33 -0000\r
  58 \r
  59 --=-=-=\r
  60 Content-Type: text/plain\r
  61 \r
  62 On Sat, Jun 01 2013, David Bremner <david@tethera.net> wrote:\r
  63 > Austin Clements <amdragon@MIT.EDU> writes:\r
  64 >\r
  65 >> This is v3 of id:1369934016-22308-1-git-send-email-amdragon@mit.edu.\r
  66 >> This tweaks the shell invocation as suggested by Tomi and fixes two\r
  67 >> comment typos pointed out by Mark.  It also adds a NEWS patch.  I'm\r
  68 >> going to go ahead and mark this ready because of Tomi's and Mark's\r
  69 >> reviews of v2.\r
  70 >\r
  71 > The first 5 I pushed. The NEWS patch has a conflict.\r
  72 \r
  73 I'm very happy to see the long-coming sexp handling working here.  Good\r
  74 work, folks, particularly to Austin for getting the awesome asynchronous\r
  75 processing stuff working.  Searches are now definitely noticeably\r
  76 faster.\r
  77 \r
  78 I am, however, seeing a couple of issues that we might want to address.\r
  79 \r
  80 * Killing a search buffer that is still in the process of being filled\r
  81   causes errors to be thrown.  I'm seeing both of the following\r
  82   intermittently:\r
  83 \r
  84 [Sun Jun  2 08:26:40 2013]\r
  85 notmuch exited with status killed\r
  86 command: notmuch search --format\=sexp --format-version\=1 --sort\=newest-first to\:jrollins\r
  87 exit signal: killed\r
  88 \r
  89 [Sun Jun  2 08:32:26 2013]\r
  90 notmuch exited with status hangup\r
  91 command: notmuch search --format\=sexp --format-version\=1 --sort\=newest-first to\:jrollins\r
  92 exit signal: hangup\r
  93 \r
  94   This is somewhat understandable, as the notmuch binary exits with an\r
  95   error if it hasn't finished dumping the output, but given how common\r
  96   this particular scenario is I think we should try to avoid throwing\r
  97   errors in this circumstance.  I wonder if we shouldn't just modify the\r
  98   binary to not return non-zero if it was manually killed while\r
  99   processing the output, or at least special-case the particular error\r
 100   caused by manually killing the search.\r
 101 \r
 102 * The next thing I'm seeing is this:\r
 103 \r
 104 Opening input file: no such file or directory, /home/jrollins/tmp/nmerr5390CAY\r
 105 \r
 106   I'm not exactly sure what causes this error, but it looks to me like\r
 107   the temporary error file was removed before we were finished with it.\r
 108 \r
 109 * Finally, something happened that caused *12,000* of the following lines\r
 110   to be sent to the *Notmuch errors* buffer:\r
 111 \r
 112 A Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation\r
 113 \r
 114   Again, this was related to killing a search buffer that was still\r
 115   being filled. I'm pretty sure the database was not modified during\r
 116   this process.\r
 117 \r
 118 Let me know if I can help provide any more info.\r
 119 \r
 120 jamie.\r
 121 \r
 122 --=-=-=\r
 123 Content-Type: application/pgp-signature\r
 124 \r
 125 -----BEGIN PGP SIGNATURE-----\r
 126 Version: GnuPG v1.4.12 (GNU/Linux)\r
 127 \r
 128 iQIcBAEBCAAGBQJRq2nyAAoJEO00zqvie6q8LJsP/2WvgF2Lsuqfue2TOlTOXby6\r
 129 k//nH/vTkHFC98JRGWv9jqvh1tJDQML9wERaEyyneabGTtFPGhUwJ+4P5FMPega3\r
 130 NnYFGfeW+fVAVEhv07zbSm8EQ99cZEor+z0J+dmsqCdntG8OPiGtracw0325I1w5\r
 131 lK8AlFcSNhUzsGnHBh2AQq3KePWXzKa101taMGJJ/bM+VvHRwqUdZapyS0vhfLrY\r
 132 Js6oRxwE4r0dirRM0n8ohu4ID6yqICvYqsNsP7igb36TqSNs9ttU0VNt1VvGEXDj\r
 133 dDU66KNCZgH9Zr0zWjAPAHbLoEZ6UduqWRcVvsnc5EbmDJq49Mg7mN8pisOgwImS\r
 134 lG0KIOnUfH1PPidy4jZzV1m50s8E0OxpQdyiFN+z3SXhgXT1lxnE6JkAJt9KXEk9\r
 135 rmZFlI3oAEcA15Nog90U87xdZx4FvYqy3hREkiqGUIHXQTMXbOZF/D2tI78p/GUF\r
 136 kxHOegbC+rsdfccPLr/76YTrqAn7sGVI4u7Cwr4/RkAKl0V8m62E4yQ0ZCFtyFch\r
 137 vWT2JNLb3HPkg4wGqiDoRIvfhXPIxxhj+YUIp6TC8RJqVgKHKHkUHoCxd/Hrhe/J\r
 138 DA7faRbTCPsvxdwXxF8gBLFrZmV3cAhzxkpeCXrl7itEeIL1yb8ieWlVERTFgsOb\r
 139 21xEmWO/iAi1iEpL2yQp\r
 140 =yi7g\r
 141 -----END PGP SIGNATURE-----\r
 142 --=-=-=--\r