Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: autoload

On 09/21/2015 08:19 PM, Bart Schaefer wrote:
You're not asking for a precompiled function to act like a sourced
function.  A sourced function, to the extent that means anything at all,
does nothing but become defined.  But "sourcing" a function (which you
actually can't do, you can only source a *file*) and "calling" a
function are two completely distinct things.
I understand, I just chose the wrong word.
   Rather, you ask for
compiling a whole file full of defined functions, to behave like
creating a bunch of undefined ones.

An undefined function (created with "functions -u" aka autoload) does
both of the source and call operations, but it only knows the one name
(its own).  So the file (to be sourced) and the function (to be called)
both have to be identified by that single name.

Could we have created an entire distinct data structure that stores
both a file name and a function name, and means "oh by the way, when
you try to run foo, you actually have to go read the file bar" ?
Yes, we could.  We didn't.  We re-used the existing data structure
of a function, because one field for the name seemed like enough,
and the path-search mechanism seemed like a good existing model for
finding the file.
Ok. I admit that my notion does presume a table linking functions with their

raysfunc    /directory/raysfunc.zwc    line1
somefunc  /directory/all/allfunc.zwc  line40
otherfunc  /directory/all/allfunc.zwc  line200

I get a glimpse of how you did what you did within existing structures. If I understood that fully I'd grok the limitations of the system. I guess it's a bit outrageous of me, but I presumed that in the hash table that links functions to where ever they are,
a sort of pointer to a line in a .zwc file would not be a huge problem.

Further, the point of autoloading was to read into memory exactly
those functions that are actually used.  If to get foo you have to
source bar and do everything bar contains, you may end up reading
(and storing) a hundred functions in order to call one of them.
Not what we wanted to encourage.  So, one function per file.

That is so insightful, cuz I had exactly the opposite as the supposed goal--to
have functions available but not sourced *just in case* you might need them.
I never understood:

    autoload -U colors && colors

... because I'm thinking to myself: 'Why would you 'autoload' something that you are just going to plain vanilla load anyway? Why not just load it and be done with it?' (It doesn't work with compinit. It seems because compinit will
be looking on FPATH for the rest of itself autoloaded, so it's committed to
that method--but you understand my thought.)

zcompile lets you do two things:  compile a single file to be read by
source (*) or pack multiple files into an archive to be processed
by autoload.  But the latter doesn't change the fact that autoload
needs to match one file (one thing packed in the archive) to one
function name.

But ... if we have several functions packed in one .zwc it is not logically possible for the name of the file to match the name of more than one of the functions which breaks my head as far as this one-to-one function-file thing. You tell me that
there is this function name - file name requirement but then violate that
commandment by packing in several functions to one .zwc. I get that if a script is autoloaded it will/must be 'named' after the file it came from. One script!
But with functions?  The rule is not followed.

And the former doesn't magically grant the ability
to explode the single file into multiple archive entries. (**)

(*) But this is constrained in that both the original file and the
compiled file have to exist size-by-side, so that source can choose
the newer of the two.  This constraint isn't strictly necessary.
Well therewego. Previously you're saying that these .zwc should not be in the same dir, now they should be in the same dir. Nuts, they are created in the same dir. I tested that by touching the files--as you say, it finds the newest. But then you tell me that best practice is to move the thing :-( And, speaking of philosophy, here is a case of hand-holding. The first command found on the path is the one used, and too bad for you if a newer version exists somewhere lower down. It doesn't scan the whole path and load the newest file. I'm expecting that if I autoload
something then it's active and too bad if there's a newer file:

    $ autoload my_function
    $ source /functions/myfunction

... I get the sourced version.

    $ source /functions/myfunction
    $ autoload my_function

... I get the version in the .zwc found on FPATH. If I want the newer version
then I should source it.

(**) "zcompile -c" can explode functions that are already in memory
into multiple "files" that then go into the archive, but that's as
close as it gets.

When I revisit this, I'll read your posts backwards. This one is the one that would come first in the HOWTO. The first thing to understand is why, when and where we'd want to use autoload. What is it for? Why did God make it on the seventh day? Then, it's constraints and why they are what they are, then the implementation with examples.

Looking back, I've misunderstood the whole point of the thing. Like the C-head that I am, I'm thinking: 'What a good idea! We can boil down our functions to '.obj' files for faster loading, pack them together into one file for more speed yet, and best of all, have them unloaded in memory until they are actually called at which time they are 'autoloaded' automagically. How elegant, I says to myself, it's like a .zip--all compressed and packed together, and just as you can extract a single file from a .zip so you can source a single function from a .zwc and zsh will even do it automatically for you if you autoload that function cuz zsh will keep a table of where that
function is found and source it only when you call for the function.

It's all Sebastian's fault ;-)

Seriously sir, I exhaust your patience. For now the one thing I know is that I don't
want to autoload anything, it's too obscure.

Messages sorted by: Reverse Date, Date, Thread, Author