From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19480 invoked from network); 7 May 2007 05:31:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=no version=3.2.0 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 7 May 2007 05:31:58 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 68848 invoked from network); 7 May 2007 05:31:52 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 May 2007 05:31:52 -0000 Received: (qmail 5184 invoked by alias); 7 May 2007 05:31:49 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23396 Received: (qmail 5175 invoked from network); 7 May 2007 05:31:48 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 7 May 2007 05:31:48 -0000 Received: (qmail 68551 invoked from network); 7 May 2007 05:31:48 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 7 May 2007 05:31:45 -0000 Received: from torch.brasslantern.com ([71.116.88.130]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JHN00041OOUJ798@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Mon, 07 May 2007 00:31:43 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id l475VfGf009185 for ; Sun, 06 May 2007 22:31:41 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id l475VeMc009184 for zsh-workers@sunsite.dk; Sun, 06 May 2007 22:31:40 -0700 Date: Sun, 06 May 2007 22:31:40 -0700 From: Bart Schaefer Subject: Re: [PATCH] Proposal: stat -> zstat In-reply-to: <20070503164614.497b44d1.pws@csr.com> To: zsh-workers@sunsite.dk Message-id: <070506223140.ZM9183@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20070503053952.GA1481@redoubt.spodhuis.org> <070503074822.ZM24666@torch.brasslantern.com> <20070503164614.497b44d1.pws@csr.com> Comments: In reply to Peter Stephenson "Re: [PATCH] Proposal: stat -> zstat" (May 3, 4:46pm) On May 3, 4:46pm, Peter Stephenson wrote: } Subject: Re: [PATCH] Proposal: stat -> zstat } } Bart Schaefer wrote: } > Perhaps what we should be thinking of is a more general utility } } How about the following. This tries quite hard not to break anything. This sounds very much like what I was thinking. Some comments ... } Each module can advertise a set of features it supports. These will } be variables, builtins, conditions or math functions; we'll need a } convention for how to disambiguate. I wouldn't propose to build the } convention into the API, however, just represent each feature by a } string Do I correctly understand that the naming convention has nothing to do with what happens when one asks that feature X of module Z be loaded or enabled? Your suggested -F option implies as much, but presently there are different flags for builtins/conditions/parameters/mathfuncs. I guess the real question is, is there any explicit interaction between -ab/-ac/-af/-ap and -F? Could something bad happen if I ask for a parameter feature but say it should be loaded as a builtin? Conversely (sort of), can features be collections of several builtins/ conditions/etc.? Hypothetically, if I ask zmodload for the "bash-regex" feature, do I get both the =~ condtional and the BASH_REMATCH parameter? (I know, those aren't directly linked in the current implementation, but I needed an example.) } The set of enabled features can be an arbitrary-length array of } unsigned integers with bits giving the enabled status. We can } explicitly limit ourselves to the first 32 bits of each integer for } future proofing. Obviously we need one bit for each feature array } element. I'm not following how this maps to the individual modules. Is there one integer in the array per module, so each module is limited to 32 features? In any event this is an implementation detail and I'm more interested in the shell commands. } zmodload } loads everything (as at present). If the module is already loaded, and } supports features, zmodload will check to see if all features are loaded. } If they are, it's an error. If not, it will enable them all. I've always wondered why zmodload doesn't simply behave by default as if the -i option were provided. What's useful about generating an error if the module is already loaded? } zmodload -F feature1 feature2 } will load the module or cause an error if it's already loaded, } and turn on feature1 and feature2 (only---all others are disabled). How does this interact with autoloading? Can features (or the user, with zmodload -d) declare that they depend on other features (of the same or other modules)? What happens if you try to turn off a feature that some other feature depends on? } zmodload -iF -feature1 feature3 } will load the module if it's not already loaded, turn off feature1 } and turn on feature3, leaving all other features alone. I suggest that this work like options, where a "no" prefix disables the feature. (Hyphens and underscores ignored like options, too.) I'm not strongly opposed to using a leading "-" but if we do I think a leading "+" should also be allowed. Also, what about the -u option? Does "zmodload -uF ..." mean anything? That about covers it ...