0f/af95ca2ae17b5ad65b8aa6d84849ffa40e53d8

   1 Return-Path: <dmitry.kurochkin@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 4CF86429E27\r
   6         for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 07:17:38 -0800 (PST)\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=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 wvXosrMbC0-2 for <notmuch@notmuchmail.org>;\r
  17         Thu, 17 Nov 2011 07:17:37 -0800 (PST)\r
  18 Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com\r
  19         [209.85.214.53]) (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 5D6A3429E26\r
  22         for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 07:17:37 -0800 (PST)\r
  23 Received: by bkaq10 with SMTP id q10so2287236bka.26\r
  24         for <notmuch@notmuchmail.org>; Thu, 17 Nov 2011 07:17:33 -0800 (PST)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
  27         :mime-version:content-type;\r
  28         bh=rhZYyRUQtQeo+uARHhRdeV/BERBMPaCFcQhx7ZldG0I=;\r
  29         b=iOCzkt28RSnCA5XvCcAj9BKGrEIjs9sT1kBlaxKyCIu+a/QFAA8u9yy5kOpxXiQsiO\r
  30         SLsbQ8XCv79dBMHNXlS17NviP3OPA9U9ZM44m0uSIGByhyBPl+z5tAMR+z2OqdQ2+nOl\r
  31         BQoSgSrKZm7upi6G4Y/7WZYKfD6PBSEPCh2H4=\r
  32 Received: by 10.204.136.200 with SMTP id s8mr24848755bkt.49.1321543053233;\r
  33         Thu, 17 Nov 2011 07:17:33 -0800 (PST)\r
  34 Received: from localhost ([91.144.186.21])\r
  35         by mx.google.com with ESMTPS id q6sm41474807bka.6.2011.11.17.07.17.31\r
  36         (version=TLSv1/SSLv3 cipher=OTHER);\r
  37         Thu, 17 Nov 2011 07:17:31 -0800 (PST)\r
  38 From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>\r
  39 To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org\r
  40 Subject: Re: [PATCH 0/9] test: (hopefully) better test prerequisites\r
  41 In-Reply-To: <yf6wrayg83d.fsf@taco2.nixu.fi>\r
  42 References: <1321494986-18998-1-git-send-email-dmitry.kurochkin@gmail.com>\r
  43         <874ny36rhc.fsf@servo.finestructure.net>\r
  44         <yf64ny3gcu4.fsf@taco2.nixu.fi> <8739dmopcu.fsf@gmail.com>\r
  45         <yf6wrayg83d.fsf@taco2.nixu.fi>\r
  46 User-Agent: Notmuch/0.10_rc1+9~g8270095 (http://notmuchmail.org) Emacs/23.3.1\r
  47         (x86_64-pc-linux-gnu)\r
  48 Date: Thu, 17 Nov 2011 19:17:16 +0400\r
  49 Message-ID: <87zkfun5hf.fsf@gmail.com>\r
  50 MIME-Version: 1.0\r
  51 Content-Type: text/plain; charset=us-ascii\r
  52 X-BeenThere: notmuch@notmuchmail.org\r
  53 X-Mailman-Version: 2.1.13\r
  54 Precedence: list\r
  55 List-Id: "Use and development of the notmuch mail system."\r
  56         <notmuch.notmuchmail.org>\r
  57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  60 List-Post: <mailto:notmuch@notmuchmail.org>\r
  61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  64 X-List-Received-Date: Thu, 17 Nov 2011 15:17:38 -0000\r
  65 \r
  66 On Thu, 17 Nov 2011 16:02:46 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  67 > On Thu, 17 Nov 2011 17:22:41 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:\r
  68 > > Hi Tomi.\r
  69 > > \r
  70 > > On Thu, 17 Nov 2011 14:20:19 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:\r
  71 > > > \r
  72 > > > I.e. dynamically, at run-time, re-create test_emacs function...\r
  73 > > > \r
  74 > > \r
  75 > > Could you please add some human-friendly description on what benefits\r
  76 > > the code above has? :)\r
  77 > \r
  78 > "All problems in computer science can be solved by another level of indirection"\r
  79 > \r
  80 > > The only change I see (besides code refactoring) is 30sec timeout (BTW\r
  81 > > you can replace the list of numbers with "seq 30") instead of infinite\r
  82 > > wait loop.  Which may be a good, but unrelated change.\r
  83 > \r
  84 > Can't do `seq 30` it is not portable. BSD world uses different command.\r
  85 > \r
  86 > > As for re-creating functions dynamically, I find the above code more\r
  87 > > complex than the existing one.  I think the current code is more\r
  88 > > shell-style and easier to understand.  Just IMHO.\r
  89 > \r
  90 > Think it as a function pointer (I should have renamed that as test_emacs_p ;)\r
  91 > \r
  92 > Shell is hyper-dynamic being (like python). New functionality can be\r
  93 > written 'on-the-fly' inside functions (often without eval) Even variables \r
  94 > can be referenced as function names. Hmm, even perl4 has this way of \r
  95 > working supported...\r
  96 > \r
  97 > IMHO it is simpler when one get's used to.\r
  98 > \r
  99 \r
 100 I have no problem with thinking about it as a function pointer.  The\r
 101 problem is that shell does not have function pointers :)\r
 102 \r
 103 I am all for abstraction.  And I like lisp and haskell :) But it should\r
 104 make things easier and more clear, not more complex.  IMO the old code\r
 105 is easier to follow.  E.g. at any moment I understand what the function\r
 106 would do, depending on the EMACS_SERVER value.  With functions being\r
 107 dynamically overwritten, I have no idea what code would be executed when\r
 108 the function is called.\r
 109 \r
 110 Another point: EMACS_SERVER variable and the "function pointer" are kind\r
 111 of duplicating each other.  And both have to be in sync which brings\r
 112 possibility for new bugs.\r
 113 \r
 114 If we follow this pattern than all code like:\r
 115 \r
 116   f() {\r
 117     if (!done_once)\r
 118         do_once\r
 119 \r
 120     do_more\r
 121   }\r
 122 \r
 123 Should be rewritten using dynamic functions. I do not think I agree with\r
 124 this :)\r
 125 \r
 126 Anyway, all above is just IMHO.  You should probably go ahead and\r
 127 prepare a patch implementing this approach for others to review.\r
 128 \r
 129 > ... just that the test "framework" needs some refactoring... along the\r
 130 > way all of these "practises" should be defined. code style, variable names\r
 131 > consistency, etc...  \r
 132 > \r
 133 \r
 134 Yeah, there are some rough edges.  But it is just a test suite.  I care\r
 135 more about core notmuch and emacs UI :)\r
 136 \r
 137 > You've done good work with this 'prereq' -thing.\r
 138 \r
 139 Thanks.\r
 140 \r
 141 > It's just hard to see\r
 142 > the elegance here.\r
 143 \r
 144 Come on, it is sooo obvious :)\r
 145 \r
 146 Regards,\r
 147   Dmitry\r
 148 \r
 149 > I know this very well as I have to maintain my\r
 150 > own 'evolutionary' developed code -- when priority is on short-term\r
 151 > cost savings over code consistency..\r
 152 > \r
 153 > > \r
 154 > > Regards,\r
 155 > >   Dmitry\r
 156 > > \r
 157 > > > \r
 158 > > > Tomi\r
 159 > \r
 160 > Tomi\r