From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6070 invoked by alias); 24 Jun 2017 04:56:26 -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: 41354 Received: (qmail 6541 invoked from network); 24 Jun 2017 04:56:26 -0000 X-Qmail-Scanner-Diagnostics: from aok120.rev.netart.pl 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(85.128.245.120):SA:0(0.0/5.0):. Processed in 2.211936 secs); 24 Jun 2017 04:56:26 -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.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: psprint@zdharma.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at zdharma.org does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new using ClamAV (15) Date: Sat, 24 Jun 2017 06:56:14 +0200 From: Sebastian Gniazdowski To: Bart Schaefer , zsh-workers@zsh.org Message-ID: In-Reply-To: <170623205312.ZM27285@torch.brasslantern.com> References: <170623013643.ZM7546@torch.brasslantern.com> <1498253451.3581506.1019483080.3F968E2D@webmail.messagingengine.com> <170623205312.ZM27285@torch.brasslantern.com> Subject: Re: [PATCH] 2 modules, zsh/db, zsh/gdbm, bug-fixes X-Mailer: Airmail (442) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. The folding helps in redis module, where set of GSU objects is devoted to 6 different types. > } The #if 0 looks alarming. > > It's around code that was never present in db_gdbm.c before, and protects > 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 essential. I've reported bug report to GDBM (before writing [PATCH] mail). Got response with correct address to send the report. The problem is: gdbm_reorganize doesn't work correctly on NFS filesystems. Short test code: https://github.com/zdharma/hacking-private/tree/master/gdbm Effect on NFS: https://asciinema.org/a/ocjBIM9sEcvnNovA9AkStSwsQ > 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.) Yes me too had hard time deciding on this. I can add some names, no problem. -- Sebastian Gniazdowski psprint /at/ zdharma.org