From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9026 invoked by alias); 14 Dec 2016 11:45:40 -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: 40181 Received: (qmail 6910 invoked from network); 14 Dec 2016 11:45:40 -0000 X-Qmail-Scanner-Diagnostics: from nm33-vm7.bullet.mail.ir2.yahoo.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(212.82.97.112):SA:0(0.0/5.0):. Processed in 1.955023 secs); 14 Dec 2016 11:45:40 -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=FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: okiddle@yahoo.co.uk X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.mail.yahoo.com designates 212.82.97.112 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1481715509; bh=BLPzJEoWV9akdOMSsbuVINuaNb3PVWh1af43wBtjOYI=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=MgTZmWKyw4tCsgxZTuwGHTv+W1qDeuI+3uLlJH9Bb+rWSUYiyh/HPK3qMzDiXqJxxtGyHJ7lsMZdp6yBnnE0BwFlKv6Rjo0uwYM71EkklEkRwGH5N3K2e+W3gKu62hMHkrJoLjesg68dXT4yXLRIQPuOQaI+j4/2ntTBMMn8b28rG+9V6Uv5xCbIatmQrMr2wxiJFKU5qeD/ENwpyy+9SfShbMU5yLr3h1wkDP3aMdQTN1gaclOOmJFCxcZWcI6tMAYmQ4Z65OUpxhtyLjyoGhnCDL+WORJ3gHlf6U8dwnKPCj2LynP8y9a6v9ztvlk36Tu99+H8Ao83Ga0Q2FPvyA== X-Yahoo-Newman-Id: 177147.4329.bm@smtp130.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K0jXU68VM1nuTxTFAd0UM4Px2b1VnICVLQQfYQ9uZyrXvD6 ydRGhYi5aRhR3b3PAnTh4Z3EL4tTx7v_QEzofDpPTazwHjalVOQ4Yyf8jMTh qokZr1Tlo2STwaRdP5IBL_DGsIulYOWViu_vmn1EST_L.fIMMkBvO.nsjHaU P5WvRob4VSGSckTx8NQXSD5foBq.7XzH8m5jW06_Uv3scgIBDMgcZk48waUx rszzwkXmObzeiYZUkwoIe_RbbR_ylNyIPJtOj9CRFrdMYOSWtouETM4BfoQk pMLYnwLnu8LAOEA5VWmRqxjW1p7y0axcDiyr8nr.hmXKJmEmumRI86CpfvtK EstZQ4ngi6Q5kJ9GdY2UxaTxwgXJxBdjIAqDien5lb2IOQc0cbGBrYVkvD3b stHGeomzxcT5yaZQxzntsPq5uLhlR_xJ4kQNNecH5ngcf6pXW5G0EhzEl6CU YAUPXUlyD1drLesaMLlLzE8ZpUg4rdzP1z65E6s_HUBLhQHZsRWXdpMnGfFY kWIOiRQB57QRp2OfIZhKRDebb2GNbuLBMwk6bBoUY X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: From: Oliver Kiddle References: <61b3fb7c-4de6-d8da-29b4-b3802d98b162@mathphys.fsk.uni-heidelberg.de> <20161027013054.GA15799@fujitsu.shahaf.local2> <484fa75d-9361-df92-06b4-54fad37231f4@mathphys.fsk.uni-heidelberg.de> <98208.1478792966@hydra.kiddle.eu> <765413af-36a5-9afb-dd8a-7e1a39d05dde@mathphys.fsk.uni-heidelberg.de> <31607.1478915523@hydra.kiddle.eu> <75905.1479841546@hydra.kiddle.eu> <6472.1481623850@hydra.kiddle.eu> <161213083842.ZM21919@torch.brasslantern.com> <161213092141.ZM22063@torch.brasslantern.com> To: zsh-workers@zsh.org Subject: Re: caching mechanism and Re: PATCH Completion for _yum MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19088.1481715508.1@hydra.kiddle.eu> Date: Wed, 14 Dec 2016 12:38:28 +0100 Message-ID: <19089.1481715508@hydra.kiddle.eu> "Jun T." wrote: > >> if ( [[ ${+_dput_cfhosts} -eq 0 ]] || _cache_invalid dputhosts ) && > >> ! _retrieve_cache dputhosts; then > >> - which makes no sense to me. > I guess what is intended by the original code is to be sure to > regenerate > the data if the cache is invalid, even if the variable _dput_cfhosts > already exists in the current zsh. That's not what that logic does though. Simplify the line to if ( blah blah... ) && ! _retrieve_cache dputhosts and you will see that it only regenerates the cache if _retrieve_cache fails. In practice the effect is that no cache is ever considered stale. > > Whether we want to be keeping caches also in a global variable is a > > different question > keeping the data in a variable may not be a good idea. I'm uneasy about it either way. What about someone who wants to set use-cache to false? It also seems a pity not to keep the variable between _complete and various runs of _correct/_approximate. Perhaps _retrieve_cache could install something in comppostfuncs to clear them. Or it could track them in an associative array with a snapshot of $SECONDS and expire old ones before adding new ones to limit memory usage. Also note that we widely cache completion data in variables without using the _store_cache mechanism. A search for typeset\ -g will give you some idea. Bart wrote: > Using $curcontext would end up meaning that there are different copies > of the cache for different paths into the completion. That's probably > not what's intended. No, there's only ever one copy of the cache. There might be different policies for different contexts (and multiple policy zstyles all specifying the same default). Someone might want to force an update for yum remove but accept an old cache for yum info. > To be honest I've always thought that the design of the caching system > was unnecessarily convoluted. It's trying to be object-oriented and Never much liked it myself, either. And I've tended to ignore it for functions I've written. It often seems like overkill - only applicable if regenerating the cache really takes a noticable amount of time. > the cache says "I think you'll agree the interface is very simple." > Two rounds of discussion with Sven W. later, ...) After the initial part of suggesting things be configurable with styles, it looks like Sven tried to suggest simplifications, specifically: if ! _retrieve_cache RPMs _rpms; then _rpms=(...) _store_cache RPMs _rpms fi Adam's argument against this comes in 12499 but, with reference to a current _perl_modules, I'm not sure I buy the argument. Even if it has validity we should be able to allow the common case to be as simple as Sven suggests. Sven also stated: We decided some time ago that they [completion functions] shouldn't set styles themselves, only look them up. That was apparently ignored. How about we fold the zstyle lookup into _retrieve_cache and add options for specifying a default policy and the tag? Use of _cache_invalid could be deprecated though with some care to allow old usage to still work. A function for the policy is often not the simplest thing either. How about allowing a reference file or age or ... ? So usage: _retrieve_cache [ -t tag ] -p policy_func | -f file | -a age cache_key var... The lack of a policy would be supported only for backward compatibility. The cache-policy style would need extending to cover files an ages. That's a bit messy but a prefix of / o + in the style value could serve that purpose. I'd also suggest adopting a _cache_ prefix on all the variables. Should we perhaps even enforce that in some way? Another option would be to deprecate the old mechanism completely? Oliver