From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8621 invoked from network); 9 May 2007 17:47:35 -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; 9 May 2007 17:47:35 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 24151 invoked from network); 9 May 2007 17:47:30 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 9 May 2007 17:47:30 -0000 Received: (qmail 5276 invoked by alias); 9 May 2007 17:47:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23404 Received: (qmail 5267 invoked from network); 9 May 2007 17:47:27 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 9 May 2007 17:47:27 -0000 Received: (qmail 23867 invoked from network); 9 May 2007 17:47:27 -0000 Received: from cluster-d.mailcontrol.com (217.69.20.190) by a.mx.sunsite.dk with SMTP; 9 May 2007 17:47:23 -0000 Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly21d.srv.mailcontrol.com (MailControl) with ESMTP id l49HlIKU024899 for ; Wed, 9 May 2007 18:47:19 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 18:47:18 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.13.8/8.13.4) with ESMTP id l49HlIAb026043 for ; Wed, 9 May 2007 18:47:18 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.13.8/8.13.8/Submit) with ESMTP id l49HlF1x026040 for ; Wed, 9 May 2007 18:47:18 +0100 Message-Id: <200705091747.l49HlF1x026040@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: Zsh hackers list Subject: Re: [PATCH] Proposal: stat -> zstat In-reply-to: <070509101921.ZM12391@torch.brasslantern.com> References: <20070503053952.GA1481@redoubt.spodhuis.org> <070503074822.ZM24666@torch.brasslantern.com> <20070503164614.497b44d1.pws@csr.com> <070506223140.ZM9183@torch.brasslantern.com> <20070508154018.9043aaca.pws@csr.com> <070509101921.ZM12391@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Wed, 09 May 2007 10:19:21 -0700." Date: Wed, 09 May 2007 18:47:15 +0100 From: Peter Stephenson X-OriginalArrivalTime: 09 May 2007 17:47:18.0402 (UTC) FILETIME=[166CAE20:01C79262] Content-Type: text/plain MIME-Version: 1.0 X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.68.0.131 Bart Schaefer wrote: > This is also related to the question of whether a module feature can > represent a collection of things. Could > > zmodload -Fa zsh/nosh turtleteeth > > mean e.g. "autoload anything related to turtleteeth"? I suppose that > would mean loading zsh/nosh immediately, but with everything disabled, > in order to find out what is contained in that feature. (And then > unloading it again? Hrm.) Or else abstract features are in their > own category, but then how do you know when to autoload them? For the > first pass, or even the second, perhaps abstract features should not > be auto-loadable. That last suggestion is likely to be the case. It's hard to think of a general mechanism where the shell would know what autoloading an abtract feature means. It may be best done (a little like Emacs' hooks) with a shell function that simply sets up regular autoloads for any concrete features. > Which brings up a point: Previously modules were either all there or > all not, except insofar as certain bits could be hidden by explicitly > using "disable" after loading. With the features change we can get > into the condition of the module being present, but invisible. Yes, but there still there to zmodload, so it's detectable. An option to unload automatically when all features are disabled isn't difficult, I don't think; it can be done locally in the main shell's feature handler. This should be transparent to future feature requests, and easy to add later on. > What happens if both -Fa b:turtleteeth and -ab turtleteeth have been > executed prior to the first attempt to find turtleteeth? The easy way > out is to do the maximal load that has been previously requested. Yes, that shouldn't be too hard. > Random possibly unrelated thought: > We might want to think ahead to the possibilty of module scopes (like > the local parameter scope). It's quite hairy to define what the scope is, and also pretty hairy to implement it since builtins, math functions and conditions don't have a scope at the moment. > } Presumably > } > } zmodload -ab zsh/nosh b:fishfingers > } > } should generate an error > > Since ":" isn't valid in an identifier I think that's OK. (Have we yet > discussed whether symbolic conditionals like "=~" could be autoloaded?) That needs some tweaking in the main shell; I vaguely feel leaving them in the form of -special-tests and not polluting the normal shell syntax might be preferable. > I'm actually most concerned with the C definition of the module being > able to specify dependencies, rather than the user being able to do so > with some tangled zmodload -d syntax. Internally this is similar, but deciding what the dependencies actually are is probably messier in general; since, as I said, we typically need all of a service module for the next level up this doesn't seem to arise yet. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview