Re: [PATCH 0/9] test: (hopefully) better test prerequisites
authorDmitry Kurochkin <dmitry.kurochkin@gmail.com>
Thu, 17 Nov 2011 15:17:16 +0000 (19:17 +0400)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:40:18 +0000 (09:40 -0800)
0f/af95ca2ae17b5ad65b8aa6d84849ffa40e53d8 [new file with mode: 0644]

diff --git a/0f/af95ca2ae17b5ad65b8aa6d84849ffa40e53d8 b/0f/af95ca2ae17b5ad65b8aa6d84849ffa40e53d8
new file mode 100644 (file)
index 0000000..cfc3f18
--- /dev/null
@@ -0,0 +1,160 @@
+Return-Path: <dmitry.kurochkin@gmail.com>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4CF86429E27\r
+       for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 07:17:38 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.799\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+       FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id wvXosrMbC0-2 for <notmuch@notmuchmail.org>;\r
+       Thu, 17 Nov 2011 07:17:37 -0800 (PST)\r
+Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com\r
+       [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 5D6A3429E26\r
+       for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 07:17:37 -0800 (PST)\r
+Received: by bkaq10 with SMTP id q10so2287236bka.26\r
+       for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 07:17:33 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
+       h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
+       :mime-version:content-type;\r
+       bh=rhZYyRUQtQeo+uARHhRdeV/BERBMPaCFcQhx7ZldG0I=;\r
+       b=iOCzkt28RSnCA5XvCcAj9BKGrEIjs9sT1kBlaxKyCIu+a/QFAA8u9yy5kOpxXiQsiO\r
+       SLsbQ8XCv79dBMHNXlS17NviP3OPA9U9ZM44m0uSIGByhyBPl+z5tAMR+z2OqdQ2+nOl\r
+       BQoSgSrKZm7upi6G4Y/7WZYKfD6PBSEPCh2H4=\r
+Received: by 10.204.136.200 with SMTP id s8mr24848755bkt.49.1321543053233;\r
+       Thu, 17 Nov 2011 07:17:33 -0800 (PST)\r
+Received: from localhost ([91.144.186.21])\r
+       by mx.google.com with ESMTPS id q6sm41474807bka.6.2011.11.17.07.17.31\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Thu, 17 Nov 2011 07:17:31 -0800 (PST)\r
+From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>\r
+To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH 0/9] test: (hopefully) better test prerequisites\r
+In-Reply-To: <yf6wrayg83d.fsf@taco2.nixu.fi>\r
+References: <1321494986-18998-1-git-send-email-dmitry.kurochkin@gmail.com>\r
+       <874ny36rhc.fsf@servo.finestructure.net>\r
+       <yf64ny3gcu4.fsf@taco2.nixu.fi> <8739dmopcu.fsf@gmail.com>\r
+       <yf6wrayg83d.fsf@taco2.nixu.fi>\r
+User-Agent: Notmuch/0.10_rc1+9~g8270095 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Thu, 17 Nov 2011 19:17:16 +0400\r
+Message-ID: <87zkfun5hf.fsf@gmail.com>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 17 Nov 2011 15:17:38 -0000\r
+\r
+On Thu, 17 Nov 2011 16:02:46 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
+> On Thu, 17 Nov 2011 17:22:41 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:\r
+> > Hi Tomi.\r
+> > \r
+> > On Thu, 17 Nov 2011 14:20:19 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
+> > > \r
+> > > I.e. dynamically, at run-time, re-create test_emacs function...\r
+> > > \r
+> > \r
+> > Could you please add some human-friendly description on what benefits\r
+> > the code above has? :)\r
+> \r
+> "All problems in computer science can be solved by another level of indirection"\r
+> \r
+> > The only change I see (besides code refactoring) is 30sec timeout (BTW\r
+> > you can replace the list of numbers with "seq 30") instead of infinite\r
+> > wait loop.  Which may be a good, but unrelated change.\r
+> \r
+> Can't do `seq 30` it is not portable. BSD world uses different command.\r
+> \r
+> > As for re-creating functions dynamically, I find the above code more\r
+> > complex than the existing one.  I think the current code is more\r
+> > shell-style and easier to understand.  Just IMHO.\r
+> \r
+> Think it as a function pointer (I should have renamed that as test_emacs_p ;)\r
+> \r
+> Shell is hyper-dynamic being (like python). New functionality can be\r
+> written 'on-the-fly' inside functions (often without eval) Even variables \r
+> can be referenced as function names. Hmm, even perl4 has this way of \r
+> working supported...\r
+> \r
+> IMHO it is simpler when one get's used to.\r
+> \r
+\r
+I have no problem with thinking about it as a function pointer.  The\r
+problem is that shell does not have function pointers :)\r
+\r
+I am all for abstraction.  And I like lisp and haskell :) But it should\r
+make things easier and more clear, not more complex.  IMO the old code\r
+is easier to follow.  E.g. at any moment I understand what the function\r
+would do, depending on the EMACS_SERVER value.  With functions being\r
+dynamically overwritten, I have no idea what code would be executed when\r
+the function is called.\r
+\r
+Another point: EMACS_SERVER variable and the "function pointer" are kind\r
+of duplicating each other.  And both have to be in sync which brings\r
+possibility for new bugs.\r
+\r
+If we follow this pattern than all code like:\r
+\r
+  f() {\r
+    if (!done_once)\r
+        do_once\r
+\r
+    do_more\r
+  }\r
+\r
+Should be rewritten using dynamic functions. I do not think I agree with\r
+this :)\r
+\r
+Anyway, all above is just IMHO.  You should probably go ahead and\r
+prepare a patch implementing this approach for others to review.\r
+\r
+> ... just that the test "framework" needs some refactoring... along the\r
+> way all of these "practises" should be defined. code style, variable names\r
+> consistency, etc...  \r
+> \r
+\r
+Yeah, there are some rough edges.  But it is just a test suite.  I care\r
+more about core notmuch and emacs UI :)\r
+\r
+> You've done good work with this 'prereq' -thing.\r
+\r
+Thanks.\r
+\r
+> It's just hard to see\r
+> the elegance here.\r
+\r
+Come on, it is sooo obvious :)\r
+\r
+Regards,\r
+  Dmitry\r
+\r
+> I know this very well as I have to maintain my\r
+> own 'evolutionary' developed code -- when priority is on short-term\r
+> cost savings over code consistency..\r
+> \r
+> > \r
+> > Regards,\r
+> >   Dmitry\r
+> > \r
+> > > \r
+> > > Tomi\r
+> \r
+> Tomi\r