From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27011 invoked from network); 29 Feb 2000 04:22:54 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Feb 2000 04:22:54 -0000 Received: (qmail 22372 invoked by alias); 29 Feb 2000 04:22:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9917 Received: (qmail 22351 invoked from network); 29 Feb 2000 04:22:44 -0000 From: "Bart Schaefer" Message-Id: <1000229042229.ZM17503@candle.brasslantern.com> Date: Tue, 29 Feb 2000 04:22:29 +0000 In-Reply-To: <200002281007.LAA02352@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Precompiled wordcode zsh functions" (Feb 28, 11:07am) References: <200002281007.LAA02352@beta.informatik.hu-berlin.de> <200002281450.PAA03800@beta.informatik.hu-berlin.de> In-Reply-To: <200002281450.PAA03800@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Precompiled wordcode zsh functions" (Feb 28, 3:50pm) In-Reply-To: Comments: In reply to Zefram "Re: Precompiled wordcode zsh functions" (Feb 28, 6:18pm) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: Precompiled wordcode zsh functions MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 28, 11:07am, Sven Wischnowsky wrote: } Subject: Re: Precompiled wordcode zsh functions } } Hm. If we think about one file per function, we should certainly make } them be found in the directories in $fpath. [...] if getfpfunc() finds } out that one of the strings in $fpath isn't a directory containing } a file with the name searched, it tries to use it as a dump-file } containing multiple functions and checks if it contains the definition } [... b]ut if the directory from $fpath just being handled is a } directory and it contains a file .zwc, we use that (at this time } we could compare the modification times for and .zwc, of } course). Yes. Note that I think the files should have the .zwc extension in both cases; the only difference is whether the loading code opens the file and searches its internal "directory," or simply matches on the file name. On Feb 28, 6:18pm, Zefram wrote: } Subject: Re: Precompiled wordcode zsh functions } } Sven Wischnowsky wrote: } >I forgot: there is a problem with this which I remembered at the } >weekend. The word-code isn't really machine-independent, it depends on } >the endian-ness. } } [...] have saved wordcode files contain wordcode for } both endiannesses. Wordcode files get twice as big, but the unneeded half } can be so completely ignored that it never gets paged in at all. I don't } think that address space usage is a significant concern at this level. Sven suggested that, too, and I think it's the best idea. } Have .zwcb and .zwcl suffixes. We should be friendly to those who compile zsh under Cygwin, or to Amol if he decides to update his NT port, and use only three-letter suffixes. Perhaps .zbw and .zlw for 32-bit ints and .zbl and .zll for 64-bit? Though IMO it'd be better if we could stick to 32 bits and one suffix. } A .zwc file in a directory in $fpath acts exactly like a normal } textual function definition file, except that it is in wordcode } instead of text; it should take precedence over any file (of either } type) further down $fpath, but we may want to do a date comparison } if both textual and wordcode files exist in the same directory. A } digest file should actually be listed in $fpath; its definitions take } precedence over directories (and digest files) further down $fpath. I'm a bit worried about functions getting redefined -- and about functions that *need* to get redefined, e.g. a .zwc file representing a "package" may contain a function whose name clashes with one that the user defined earlier in $fpath. In the current state of the world (without wordcode files) the package clobbers the user's function unless the package author has made an effort to avoid it (as in Completion/User/_cvs). Emacs .el and .elc have that same behavior. What Zefram has suggested for function digest files would behave more like standard path hashing. Do we need some way to express at compile time whether a digest is a package with internal dependencies vs. a mere collection of otherwise unrelated functions? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com