From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 1312A429E58 for ; Sun, 2 Jun 2013 08:51:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sPSOnPf2kLs for ; Sun, 2 Jun 2013 08:51:24 -0700 (PDT) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by olra.theworths.org (Postfix) with ESMTP id D7E88429E55 for ; Sun, 2 Jun 2013 08:51:24 -0700 (PDT) Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1]) by fire-doxen-postvirus (Postfix) with ESMTP id 5F71E2E50E39; Sun, 2 Jun 2013 08:51:22 -0700 (PDT) X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new Received: from finestructure.net (cpe-76-173-75-86.socal.res.rr.com [76.173.75.86]) (Authenticated sender: jrollins) by fire-doxen-submit (Postfix) with ESMTP id 715772E50E38; Sun, 2 Jun 2013 08:51:17 -0700 (PDT) Received: by finestructure.net (Postfix, from userid 1000) id E8C886176D; Sun, 2 Jun 2013 08:51:16 -0700 (PDT) From: Jameson Graef Rollins To: Austin Clements , notmuch@notmuchmail.org Subject: Re: [PATCH v3 0/6] Make Emacs search use sexp format In-Reply-To: <87sj12yqyu.fsf@maritornes.cs.unb.ca> References: <1370047208-12785-1-git-send-email-amdragon@mit.edu> <87sj12yqyu.fsf@maritornes.cs.unb.ca> User-Agent: Notmuch/0.15.2+155~g7fa0560 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Sun, 02 Jun 2013 08:51:14 -0700 Message-ID: <87r4gk8qa5.fsf@servo.finestructure.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: tomi.ollila@iki.fi X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 15:51:33 -0000 --=-=-= Content-Type: text/plain On Sat, Jun 01 2013, David Bremner wrote: > Austin Clements writes: > >> This is v3 of id:1369934016-22308-1-git-send-email-amdragon@mit.edu. >> This tweaks the shell invocation as suggested by Tomi and fixes two >> comment typos pointed out by Mark. It also adds a NEWS patch. I'm >> going to go ahead and mark this ready because of Tomi's and Mark's >> reviews of v2. > > The first 5 I pushed. The NEWS patch has a conflict. I'm very happy to see the long-coming sexp handling working here. Good work, folks, particularly to Austin for getting the awesome asynchronous processing stuff working. Searches are now definitely noticeably faster. I am, however, seeing a couple of issues that we might want to address. * Killing a search buffer that is still in the process of being filled causes errors to be thrown. I'm seeing both of the following intermittently: [Sun Jun 2 08:26:40 2013] notmuch exited with status killed command: notmuch search --format\=sexp --format-version\=1 --sort\=newest-first to\:jrollins exit signal: killed [Sun Jun 2 08:32:26 2013] notmuch exited with status hangup command: notmuch search --format\=sexp --format-version\=1 --sort\=newest-first to\:jrollins exit signal: hangup This is somewhat understandable, as the notmuch binary exits with an error if it hasn't finished dumping the output, but given how common this particular scenario is I think we should try to avoid throwing errors in this circumstance. I wonder if we shouldn't just modify the binary to not return non-zero if it was manually killed while processing the output, or at least special-case the particular error caused by manually killing the search. * The next thing I'm seeing is this: Opening input file: no such file or directory, /home/jrollins/tmp/nmerr5390CAY I'm not exactly sure what causes this error, but it looks to me like the temporary error file was removed before we were finished with it. * Finally, something happened that caused *12,000* of the following lines to be sent to the *Notmuch errors* buffer: A Xapian exception occurred performing query: The revision being read has been discarded - you should call Xapian::Database::reopen() and retry the operation Again, this was related to killing a search buffer that was still being filled. I'm pretty sure the database was not modified during this process. Let me know if I can help provide any more info. jamie. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRq2nyAAoJEO00zqvie6q8LJsP/2WvgF2Lsuqfue2TOlTOXby6 k//nH/vTkHFC98JRGWv9jqvh1tJDQML9wERaEyyneabGTtFPGhUwJ+4P5FMPega3 NnYFGfeW+fVAVEhv07zbSm8EQ99cZEor+z0J+dmsqCdntG8OPiGtracw0325I1w5 lK8AlFcSNhUzsGnHBh2AQq3KePWXzKa101taMGJJ/bM+VvHRwqUdZapyS0vhfLrY Js6oRxwE4r0dirRM0n8ohu4ID6yqICvYqsNsP7igb36TqSNs9ttU0VNt1VvGEXDj dDU66KNCZgH9Zr0zWjAPAHbLoEZ6UduqWRcVvsnc5EbmDJq49Mg7mN8pisOgwImS lG0KIOnUfH1PPidy4jZzV1m50s8E0OxpQdyiFN+z3SXhgXT1lxnE6JkAJt9KXEk9 rmZFlI3oAEcA15Nog90U87xdZx4FvYqy3hREkiqGUIHXQTMXbOZF/D2tI78p/GUF kxHOegbC+rsdfccPLr/76YTrqAn7sGVI4u7Cwr4/RkAKl0V8m62E4yQ0ZCFtyFch vWT2JNLb3HPkg4wGqiDoRIvfhXPIxxhj+YUIp6TC8RJqVgKHKHkUHoCxd/Hrhe/J DA7faRbTCPsvxdwXxF8gBLFrZmV3cAhzxkpeCXrl7itEeIL1yb8ieWlVERTFgsOb 21xEmWO/iAi1iEpL2yQp =yi7g -----END PGP SIGNATURE----- --=-=-=--