From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18751 invoked by alias); 25 Jun 2017 00:50:34 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41359 Received: (qmail 16744 invoked from network); 25 Jun 2017 00:50:34 -0000 X-Qmail-Scanner-Diagnostics: from out3-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.27):SA:0(-0.7/5.0):. Processed in 2.648047 secs); 25 Jun 2017 00:50:34 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bkUAw1 KYUxbouWUhmkBy7zdifIR5OJ08DIdmbO0VS8Q=; b=D1QURhpIEdztVnfMOQA/g2 c33yKKRJFhUsoVd4J3YPO9v/zJ6xjGTqms13S0qr/mB+v4SnCHvWsl/SP5PTZFzo PMxVSR6FUGUPtxd51Ii8E64rGDq4wgFnxOw09/21cCSW53DeWKtxQlZg/zSo+XWy FZbvQJMJmQYOwgaycf1pjDc8H7EqTpHxN1pmj/Ufe+IQDlr/o/n19cCc9x7HCtpd NQUm7LgIVFxwXhtDLryQr/Hfs1FyhaORcHaZzm7A9pdDU9tzFx2qEV8LfuEAnmhe XpqwaSHopZDrsuH8lLqJ50aQmQboKxOLKmL+6eGsu6kHtlvMuYQjGK+mVBwrHhjA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bkUAw1 KYUxbouWUhmkBy7zdifIR5OJ08DIdmbO0VS8Q=; b=r3WVzJ9F8jwqSXG0st1kTz NGzsN/P9I55JJGoGsyVaZRQJpC3gjjaTM/AnTWeVz6D5zjZj6n7SLHHPyjFyy+4M HAAC/j82SQr9vDtFxmA9myGXFE7qbu2vea+dVrKiL8hj4GqXC16leEZAssU1LVW5 36V++guz3FwNb+ypp8knxnNge8X//4nDNa8PoSY7l/qbRo+c6spYsWNAuH7q5ZdB 6xoTigvfgwc9IYOn/6F9ICugAxZMwMGZPcLtW1ORPQOGe3OV2KNjc/5WvCc7DrDH 22Ti1Ss5azchhQ9v5IFWYXlGtIkntFbpeTFmDA1Rq95plW2uqUe1Ta2451JX34gw == X-ME-Sender: Message-Id: <1498351823.3885761.1020291288.35C72F4E@webmail.messagingengine.com> From: Daniel Shahaf To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-72841c42 References: <170623013643.ZM7546@torch.brasslantern.com> <1498253451.3581506.1019483080.3F968E2D@webmail.messagingengine.com> <170623205312.ZM27285@torch.brasslantern.com> Date: Sun, 25 Jun 2017 00:50:23 +0000 Subject: Re: [PATCH] 2 modules, zsh/db, zsh/gdbm, bug-fixes In-Reply-To: Sebastian Gniazdowski wrote on Sat, 24 Jun 2017 06:56 +0200: > On 24 czerwca 2017 at 05:53:12, Bart Schaefer (schaefer@brasslantern.com)= wrote: > > Yes, I would also prefer the vim folding be removed, and the use of > > CamelCapsVariableNames be made more like the rest of the code, but > > both of those seemed unnecessarily picky. I don't think calling out the folding is picky. It's perhaps a higher degree of attention to detail than is usually seen on this list, but it's a valid coding style issue. (More on this below) > The folding helps in redis module, where set of GSU objects is devoted to= 6 different types. >=20 Two things. Firstly, I'm not sure why you need the markers at all. Vim's =C2=AB:set foldmarker=3Dsyntax=C2=BB works well and doesn't require any markers. Secondly, I have no objection to editor-supporting markup added, provided that it is unobtrusive=E2=80=A6 which these markers are not. They= get in the way of reading the code (they look like comments, and people who read the code read comments). They're liable to get out of date (functions get split and renamed), and it won't scale to have every $EDITOR's style of markers. So I would rather they weren't added to the VCS tree. (but feel free to use them on your own machine, of course) > > } The #if 0 looks alarming. > >=20 > > It's around code that was never present in db_gdbm.c before, and protec= ts > > a function call that's "new" (in a historical sense) to the library. I > > think it's also nothing but an optimization, and therefore not essentia= l. >=20 > [...] The problem is: gdbm_reorganize doesn't work correctly on NFS > filesystems. Short test code: >=20 > https://github.com/zdharma/hacking-private/tree/master/gdbm >=20 > Effect on NFS: >=20 > https://asciinema.org/a/ocjBIM9sEcvnNovA9AkStSwsQ >=20 Isn't there a permanent link to a description of the bug? Preferably in the gdbm bug tracker, or at least on their mailing list? That's needed so people in the future can know why the workaround was added and judge whether it can be removed. (Both of these links are susceptible to rot: they may not work in a few years) > > I've had a hard time deciding which of the warning functions is the > > right one to use in a given situation. zwarnnam() is usually meant to > > prefix the message with the name of a command that caused the error; > > it's not obvious that it should be used in a context where there is no > > command involved. (I haven't dug into whether that is the case for > > the instances you've called out.) >=20 > Yes me too had hard time deciding on this. I can add some names, no probl= em. My reasoning was that every error/warning message should be signed by its originator. That's useful when the error is generated a few layers away from the commmand the user actually invoked: . % f() g % g() h % h() i % i() echo "j not found" >&2 % f j not found % . where f, g, h are each a separate project. If we don't know the name of the command or parameter/variable, then we can at least sign with the name of the module. Cheers, Daniel