From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14002 invoked from network); 25 Feb 2000 17:36:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Feb 2000 17:36:14 -0000 Received: (qmail 10336 invoked by alias); 25 Feb 2000 17:36:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9883 Received: (qmail 10321 invoked from network); 25 Feb 2000 17:35:58 -0000 From: "Bart Schaefer" Message-Id: <1000225173553.ZM22872@candle.brasslantern.com> Date: Fri, 25 Feb 2000 17:35:53 +0000 In-Reply-To: <200002251042.LAA25724@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: Precompiled wordcode zsh functions" (Feb 25, 11:42am) References: <200002251042.LAA25724@beta.informatik.hu-berlin.de> 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 25, 11:42am, Sven Wischnowsky wrote: } Subject: Re: Precompiled wordcode zsh functions } } Add a builtin (`zcompile' if you wish), that gets a list of } filenames. The first one is used as the file to write the code for all } functions named by the other filenames into. These have to name } existing function files (not necessarily in $fpath). So the generated } file is a kind of digest containing the code for multiple functions. } } Then: $fpath may also contain names of such digest files. So far so good, though I'd still prefer if such a file could just sit inside a directory in $fpath (or some other searched path) and be loaded like any other autoloaded function. (Which means there needs to be some sort of convention for choosing the compiled file if both compiled and uncompiled functions are present.) } In getfpfunc() (that's where we load autoloaded functions), if the } name of a digest file in $fpath is found, the file is searched for } the definition of the function we are seeking. If it contains this } function, the thing is mapped and the Eprog is set up. Hmm. Probably there'd have to be a "directory" at the top of the file with the names and offsets (or some such) of all the functions therein. That header could also contain some flags determined at compile time, such as whether the file should be mmap'd or merely read. Such a flag would normally be computed by the compiler based on the size or some such criteria, but could be overridden by an option to the "zcompile" (or whatever) builtin. Thus if one wanted to have a lot of small files with only one function each, the result would not be a zillion mmaps. } One problem: should there be some warning if the digest file is older } than the function file (if that is reachable through $fpath)? I.e. do } we have to test that? I *think* emacs detects that condition only when the .el and .elc are in the same directory. Certainly we shouldn't go searching the entire fpath to verify every compiled function, particularly if there is more than one function in each wordcode file. } Second problem: functions like _cvs that essentially just define lots } of functions and re-define themselves[1]. I saw your follow-up, but one remark: That technique would no longer be necessary because loading the wordcode file would immediately define all the functions therein without having to execute one of them first. Random thought: How about .zwc (zsh word code) for the file extension? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com