From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8581 invoked from network); 25 Feb 2000 09:56:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Feb 2000 09:56:32 -0000 Received: (qmail 6376 invoked by alias); 25 Feb 2000 09:56:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9873 Received: (qmail 6323 invoked from network); 25 Feb 2000 09:55:39 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de) From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: PATCH: parser (was: Re: PATCH: Improved _mailboxes) Date: Fri, 25 Feb 2000 12:55:32 +0300 Message-ID: <000601bf7f76$74847710$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200002250841.JAA25219@beta.informatik.hu-berlin.de> > > 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