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

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

>
> 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.
>

Ehh ... not sure, I really did mean it all :-) Do you suggest compiling
functions on the fly and storing byte code externally? And mmaping every
single function? Just some points.

- at least on my system (and it is pretty much standard SVR4) process memory
is the list of segments. Every mmap results in adding address segment. To
resolve virtual address, system needs to search this list. mmaping 30-40
functions will add corresponding number of segments - not only is it slow,
but due to alignment restrictions it is going to waste virtual memory.

- I actually meant, that precompiled (standard) functions are installed in
default system location. This all was intended only for those functions,
that come with zsh distribution and can be considered "read only". Doing
this for arbitrary function (or any piece of code) has obvious problem of
keeping two in sync. I am not sure, if it worth troubles.

- in other words, my intention was to have single file with byte code for
distributed functions (that can be included into distribution or generated
as part of build). This will basically predefine all functions, making them
"part" of zsh binary  - without need to autoload it. If user wants to
override them - he can always define function again. (actually, step further
is to load them in memory and dump executable. Sounds familiar, does not it
:-)

/andrej