From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2791 invoked from network); 29 Feb 2000 07:45:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Feb 2000 07:45:26 -0000 Received: (qmail 26416 invoked by alias); 29 Feb 2000 07:45:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9921 Received: (qmail 26385 invoked from network); 29 Feb 2000 07:45:17 -0000 Date: Tue, 29 Feb 2000 08:45:16 +0100 (MET) Message-Id: <200002290745.IAA08900@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 29 Feb 2000 04:22:29 +0000 Subject: Re: Precompiled wordcode zsh functions Bart Schaefer wrote: > 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. I've hacked more yesterday, reaching the state Zefram talked about, sans the endian-ness-independence. Like you two I favour the approach with files containing two versions. I hope to find the time for that this evening. Oh, and currently the shell does not check the extension of a digest file and it doesn't compare the file times for compiled/non-compiled functions... yet. > ... > > } 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. I definitely want to stay with 32 bits. Although currently it is dependent of the size of integers, I hope to make that architecture independent and took care to always use the type `wordcode' instead of `int'. I still have to check -- do we have a configure test for the size of ints? > } 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. Yep. In my implementation digest files are really only one-file- directories. I.e. they are searched like normal directories by getfpfunc() (more precisely a utility function used by it). It will not define all functions in the digest file immediatly. I really prefer that behaviour because a user has to worry about nothing when, for example, he wants to override one of the functions with his own definition in a directory earlier in $fpath. > 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? I don't think so, if we keep the current behaviour. Oh, and, btw, for testing purposes I set the threshold (when a function gets mapped instead of being read) to 4096 bytes. The result was that only very few functions (around ten) would be mapped. If we use two pages as the threshold (or one page on a box with page-size == 8192), no function will be mapped. I don't really have an opinion about this, because I'll use it with one big wordcode file for the whole completion system (and other functions I have)... so I won't do much testing there, leaving it to all of you to decide (once I have the patch in representable shape, so that you can play with it). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de