Re: Precompiled wordcode zsh functions

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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.

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