Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: wordcode files
- X-seq: zsh-workers 10019
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: wordcode files
- Date: Thu, 9 Mar 2000 10:37:02 +0100 (MET)
- In-reply-to: "Bart Schaefer"'s message of Thu, 2 Mar 2000 16:43:23 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
[ I was away for a couple of days, trying to catch up... ]
Bart Schaefer wrote:
> On Mar 2, 11:03am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: wordcode files
> }
> } I wrote:
> }
> } > Bart Schaefer wrote:
> } >
> } > > This all sounds fine, although I lean towards requiring that the .zwc
> } > > extension appear in the $fpath listing. What happens, for example, if
> } > > I have both a ~/zshfun/ and ~/zshfun.zwc and I list ~/zshfun in $fpath?
> } >
> } > You get the functions in ~/zshfun because you named that. But we can
> } > change that to be more consistent (I mean: requiring the extension).
> }
> } This'll do?
>
> I'm not exactly sure. It looks like that patch forces zcompile to tack
> the .zwc extension on to the end of the name (and to only look for
> wordcode in files that have the .zwc extension). Is that right?
>
> That's fine, but ...
>
> How does that help with the situation where I have a directory named
> "foo" and a file named "foo.zwc" both within the same parent directory?
>
> What *I* meant was, fpath=(foo) would look only for directories named
> "foo", so I'd have to use fpath=(foo.zwc) if I really wanted the file;
> but if there was a file foo/func.zwc then "autoload func" would still
> find it. That's independent of whether a non-.zwc file might contain
> wordcode.
I realised that the patch didn't do exactly what you wanted when I was
away already... sorry.
Zefram wrote:
> Bart Schaefer wrote:
> >How does that help with the situation where I have a directory named
> >"foo" and a file named "foo.zwc" both within the same parent directory?
>
> One logical way to handle this (if .../foo is in $fpath) is that the
> digest file is treated as a cache of the directory in the same way that
> individual wordcode files cache individual text files. So if autoloading
> `bar' from that $fpath entry, zsh would date-compare (a) .../foo/bar (text
> file), (b) .../foo/bar.zwc (individual wordcode), and (c) .../foo.zwc
> (entry for `bar' in digest file), and use the newest of the three.
>
> I'm not necessarily recommending this, it's just something to think about.
Either there was no reply or I accidentally deleted it...
This sounds very reasonable to me and I'd like to implement it (plus
the change Bart wanted) -- and it wouldn't interfere with the
currently possible uses of digest files either.
On a slightly different topic, Bart Schaefer wrote:
> On Mar 2, 10:09am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: wordcode files
> }
> } So, to make this work for sourced files, we would only have to change
> } the name handling a bit.
>
> It sounds worthwhile, then.
Good. I still haven't checked which are the problems (or if there are
none) because of the stuff in loop(), but maybe we should just try it
because it is so easy to implement (and back out).
There is also another thing I finally remembered again: since we can
now read from wordcode files, the #ifdef's in parse.c could be changed
so that on systems wihtout mmap() we at least read functions from
wordcode files.
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author