Re: Precompiled wordcode zsh functions

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

I wrote:

> Hm. If we think about one file per function, we should certainly make
> them be found in the directories in $fpath.

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. For wordcode-files that are not to be mapped, it
would be possible to walk through the code and shuffle the bytes
around if need be, but I hope you all agree that the mapped files
should be mapped read-only, so...

With that a standard installation could:

- install only a digest file in a per-machine (machine-type)
  directory, i.e. not shared by all hosts
- install .zwc files for the functions in a directory different from
  the one where the (shared) functions files are (so that the test for 
  which-one-is-newer couldn't be done for them, which is probably not
  too big a problem)
- install the functions in a per-machine directory along with the
  wordcode-files for them

Of course, the first one could be combined with the other two. With
such digest files it would be up to the user to decide if he puts them 
into $fpath (at least that's how I think of them: as a different kind
of `function directory').

Since we can detect the endian-ness used in the wordcode file (this is 
already done in my implementation), we could also allow to install two 
wordcode-files, one for each endian-ness. Or we could make the wordcode-
files contain both versions (there are only two ways unsigned integers 
are stored nowadays, right?). As long as they are properly separated,
so that only one of the two is read/mapped, this shouldn't do much
harm, should it? But still, quite ugly, I think.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de