From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25073 invoked by alias); 22 Sep 2015 17:33:48 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20624 Received: (qmail 17556 invoked from network); 22 Sep 2015 17:33:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Authority-Analysis: v=2.1 cv=X+5rdgje c=1 sm=1 tr=0 a=k/Ul6poetjvk+AIrzykQxA==:117 a=k/Ul6poetjvk+AIrzykQxA==:17 a=N659UExz7-8A:10 a=c38irNOFMvsW6HEZa-8A:9 a=pILNOxqGKmIA:10 Message-id: <560190F4.8020404@eastlink.ca> Date: Tue, 22 Sep 2015 10:33:40 -0700 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-version: 1.0 To: zsh-users@zsh.org Subject: Re: autoload References: <55FAE223.2080502@eastlink.ca> <150917103419.ZM10067@torch.brasslantern.com> <150918171441.ZM27212@torch.brasslantern.com> <55FD7982.9030505@eastlink.ca> <150919092922.ZM28214@torch.brasslantern.com> <55FDA5D3.9020304@eastlink.ca> <150919142243.ZM23634@torch.brasslantern.com> <55FE04AD.1070304@eastlink.ca> <150919224120.ZM4736@torch.brasslantern.com> <55FF3F7E.4060906@eastlink.ca> <150920211840.ZM31871@torch.brasslantern.com> <5600386E.7060201@eastlink.ca> <150921111746.ZM388@torch.brasslantern.com> <56006401.5060902@eastlink.ca> <150921201943.ZM707@torch.brasslantern.com> In-reply-to: <150921201943.ZM707@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit 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 .zwc: 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.