From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12711 invoked by alias); 9 Nov 2013 22:33:04 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 18131 Received: (qmail 22739 invoked from network); 9 Nov 2013 22:32:59 -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=X4pwvT/ABgargUNhln1Hkf7XJGCyp/FMUJiisDQDZeA=; b=VmKXUbDvI5YLIUlGtMArK2P/MVX3QUoIeoF10SX0huvv53LhTtGooZeAkzUMuXjeo1 Gm5ItIVwzreMy9k83ZAbXsKXigXxM5niyCw7V+M7ds/0GKVfhidbJcgwfZJvSIEIen6Q m5LiFJ/UgGhiDK7rnO5IQjhgJr2usYaz3cCSneAarlpIp2YWJTHV3qWksuAnLNqThz7q 3bPc5B5jGNCzTl9uPBEO4lvWiZcEPVJsQqHBcvjqqZH9F79LdRtW6x7genIjhJKpD5QN s9ZmNnAz4AnRiWwpy1S12+4jqeTC2ghG1kS2MIt6vZxZA3vbJIz/JwF7EQPUxQyHvCkv 2M+w== X-Gm-Message-State: ALoCoQmt97mWdB4DGCSHF8JzLBL57bkZlrbhqlme7//+wSvbMq7aG+407v2ZNPyTv8FFdeC24mPw X-Received: by 10.194.109.68 with SMTP id hq4mr17242291wjb.12.1384036373348; Sat, 09 Nov 2013 14:32:53 -0800 (PST) X-ProxyUser-IP: 86.6.157.246 Date: Sat, 9 Nov 2013 22:32:50 +0000 From: Peter Stephenson To: Zsh Users Subject: Re: zsh 5.0.2-test-1 is available Message-ID: <20131109223250.706e20fb@pws-pc.ntlworld.com> In-Reply-To: <131108181143.ZM26121@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> 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 Fri, 08 Nov 2013 18:11:43 -0800 Bart Schaefer wrote: > On Nov 8, 4:11pm, Peter Stephenson wrote: > } > } It seems to me it's equally not an error to mark zstat as a builtin from > } zsh/stat if it's already loaded as a builtin from zsh/stat. It would > } only be an error if there's a conflict. > } > } That's how "autoload" works, after all: it can't check for a conflict > } (without major faff) but it does check if a function's already loaded. > > > I'm confused; these statements seem contradictory, so I must be missing > something. If we can't check for a conflict, how can we suppress the > error message? I.e., how do we know that zstat is already loaded as a > builtin from the same module we're now loading? For functions, autoload (the builtin of that name) works this way, suppressing an error message if a functiona already exists, but it can't check for a conflict because it would have to scan the path, load the file it found, and check that the loaded file compared the same as the already loaded file. This is as much work as deleting the file and reloading it when "autoload" is encountered again. So it silently assumes if a function is loaded that it's the function you wanted. I was using this case as the paradigm of how an autoload of any sort works, to point out that, when whatever-it-is is already loaded, generating an error on a new autoload isn't necessarily the right thing to do. For autoloads from modules, which may be builtins, conditions, math functions or parameters, we can actually do a bit better, with a little more work but nothing like to the same extent (no additional loading is required). 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. It seems to me, based on the argument from functions, that it would be entirely natural just to ignore the zmodload -a as redundant rather than report it as an error; and, furthermore, given that you can check by this means the effect really *is* redundant rather than a conflict, it seems to me there is no harmful side effect of any sort. (Obviously, contradictory indications are invited.) I hope that's clear now. I started looking at this on Friday but I need to be careful which builtins flying around are which, so will get back to it at some point. pws