zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: wordcode files
Date: Thu, 9 Mar 2000 10:37:02 +0100 (MET)	[thread overview]
Message-ID: <200003090937.KAA18657@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Thu, 2 Mar 2000 16:43:23 +0000


[ 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@informatik.hu-berlin.de


             reply	other threads:[~2000-03-09 12:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-09  9:37 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-03-02 10:03 Sven Wischnowsky
2000-03-02 16:28 ` Bart Schaefer
2000-03-02 16:43 ` Bart Schaefer
2000-03-02 17:52   ` Zefram
2000-03-02  9:09 Sven Wischnowsky
2000-03-03  4:09 ` Bart Schaefer
2000-03-01 16:00 Sven Wischnowsky
2000-03-01 10:06 Sven Wischnowsky
2000-03-01 15:24 ` Tanaka Akira
2000-03-01 16:58 ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200003090937.KAA18657@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).