Re: Precompiled wordcode zsh functions

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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 <name>.zwc, we use that (at this time
> } we could compare the modification times for <name> and <name>.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@xxxxxxxxxxxxxxxxxxxxxxx