From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10720 invoked by alias); 10 Nov 2013 20:53:02 -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: 31951 Received: (qmail 9278 invoked from network); 10 Nov 2013 20:52:56 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=RjeFpsbljpcKLivVexvJ0fy4B/Xr/1dODo41HuLGFb4=; b=gbRPJJfAWTBopgNjo0B5kuB5kCcUaSrUCfQkaz8LNKLT+cloxpyciLspMUX+US39MR 4QVPufh8GjCLeek7Xbe6YQRVUk8VWFuVz9wJMkltoN/Ertnd39N/k/JQnNqrFb8wMbrG PJcp1EPmfqyexQz4nJPRwiBEI2a7RDSN4xXgLFE3zeXw9GTOwyAZncJ9EJGiaX8+9wul kBSjwLP0jJcqdfTF5sIxzwfrIqc18TPeTxtN7I62BmjSv0jf5erz6q2SMsUB91OsHHN9 djxkaXtvSYGwTRSFjM9rdjT0lVo/5gR1gwT9b1gz0rk473jE9RhRCed3D6jkkPzw712f BpOw== X-Gm-Message-State: ALoCoQloqbmh5K79/LrL1nSya43T5I1AlUaE95cpit7CLNP/WZkfpy2BqfQ6nBk8T2Lnb/65xhBZ X-Received: by 10.180.104.129 with SMTP id ge1mr9732487wib.6.1384116282191; Sun, 10 Nov 2013 12:44:42 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Sun, 10 Nov 2013 20:44:35 +0000 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Errors on module feature [auto]loading (Re: zsh 5.0.2-test-1 is available) Message-ID: <20131110204435.3b761e0c@pws-pc.ntlworld.com> In-Reply-To: <131110120354.ZM21539@torch.brasslantern.com> References: <20131106202321.4a48c77b@pws-pc.ntlworld.com> <20131107153315.GW3544@sym.noone.org> <20131107160551.7aa195dc@pwslap01u.europe.root.pri> <20131107191806.GA85153@redoubt.spodhuis.org> <131107173627.ZM24325@torch.brasslantern.com> <20131108071627.GA6216@redoubt.spodhuis.org> <20131108093822.1534aa88@pwslap01u.europe.root.pri> <131108063903.ZM25660@torch.brasslantern.com> <20131108161109.6e373049@pwslap01u.europe.root.pri> <131108181143.ZM26121@torch.brasslantern.com> <20131109223250.706e20fb@pws-pc.ntlworld.com> <131110120354.ZM21539@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 10 Nov 2013 12:03:54 -0800 Bart Schaefer wrote: > [> workers] > > On Nov 9, 10:32pm, Peter Stephenson wrote: > } > } Suppose we load builtin bar from zsh/foo at some point, doesn't matter > } how, then run "zmodload -a bar zsh/foo". We find that a builtin bar > } exists. We can then check that zsh/foo is already loaded, and is > } already providing builtin bar. > > And conversely we can tell that a builtin bar already exists that is not > provided by zsh/foo ? This is the part that I thought for some reason > was difficult. We can tell a builtin is loaded easily enough --- this is the test that's currently reporting the error if the builtin is already provided by anything at all. The new trick is that we then look to see if zsh/foo is loaded already, and if so whether it's providing that builtin, which we can do e.g. by querying the features. (That's probably the best way without straining the standard module interface, I think.) If this says that b:bar is present and enabled, we know that zsh/foo is providing it, because zsh/foo wouldn't have said it was enabled otherwise, it would have reported an error instead. If it isn't enabled as a feature from zsh/foo, then something else is providing the builtin; we don't care what, this is an error. This is generic to any sort of feature, so exactly the same applies to the other types of feature. > I'm OK with this given the precondition. Do all the rules about warning > on circular dependency, etc., apply? If I try to explicitly autoload > from zsh/foo a feature that would implicitly be provided by zsh/bar, > when if ever would an error occur? Hmm... I don't know how this works at the moment, but it's not really relevant because zsh/bar won't show the builtin as a feature --- unless a dependent module is providing a conflicting builtin, but that's a configuration problem, not a user problem. The method doesn't care about dependencies, it cares that you specified the right module, which I think is reasonable --- the documentation tells you. > Aside: Should we update the manual to say that the right way to test for > module existence is "zmodload -F module" (with no feature arguments)? This > checks that the module could be loaded without enabling anything, whereas > "zmodload [-i] module" enables all the default features. It doesn't just test for it, it does in fact load it, but without enabling any of the features. If you didn't want anything in the module at that point you'd need to unload it again, but the combined operation should be free of side effects. That might be worth mentioning. pws