Re: PATCH: parser (was: Re: PATCH: Improved _mailboxes)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Feb 24, 10:07am, Sven Wischnowsky wrote:
> } Subject: RE: PATCH: parser (was: Re: PATCH: Improved _mailboxes)
> }
> } 
> } Andrej Borsenkow wrote:
> } 
> } > zcodeload file
> 
> Let's not do that, shall we?  Let's stick with autoload and have a file
> suffix convention, like emacs' .el and .elc, or something.  Heck, there
> could even be separate fpath and compiled_fpath or ...

I was wondering what to do when the directory isn't writable... but a
$COMPILED_FPATH containing one directory would be enough. Hm. Do you
want to say that you actually like the idea? Making everything ready
for the mmap would be quite simple. The only problem I can see is that 
we would need to have a wordcode-verifier (but, of course, that can be 
done). That's yet another reason for having only a scalar containing
only one directory name (so $COMPILED_FDIR might be a better name) --
save compiled functions only if that is set and names an existing,
writable directory. Users would set it to a directory in their account 
so that others can't trick them into using evil code.

> } All this also makes me think about a way to allow multiple zsh's to
> } share other memory bits (like the command table and so on). How
> } portable is anonymous shared mmap or shared mmap on /dev/null?
> 
> Do we really want to go down the road of having e.g. zmodload in one
> zsh suddenly make new builtins available to another zsh?  I don't want
> the behavior of a script that's running in the background to change
> because of something I loaded into my foreground shell ...

Should be configurable, of course. And to be turned on explicitly. If
at all...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx