From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13778 invoked by alias); 8 Jul 2017 21:43:06 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41405 Received: (qmail 15425 invoked from network); 8 Jul 2017 21:43:06 -0000 X-Qmail-Scanner-Diagnostics: from mail-qk0-f180.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.220.180):SA:0(0.5/5.0):. Processed in 1.603384 secs); 08 Jul 2017 21:43:06 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM,SPF_PASS, T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.220.180 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WULwXmV4spoid2/wBSd/xHVEISzw73DFqydogsBAMMk=; b=I0RJzyJwm7y1TdSd6mIHZio/CH2o0LOOhFNXn8lxOQrFTlrPjb+nuEt5ZGgcaH4knx xInse/W9AuS768mY9TGyYtlP4EIpE+rr6wd0TRlSuH7WkwPacIMe6zx625eXIfkzKqvO kQsk271zc842geBF7KxeWJq29pNj3UvK3JbP6f1U/yYJWOYQHI2baIUjYHD3pHwSmKCu OUqFx+m5yIoCBCGRu7Jke3A6ePBD5qQ6P5DrxMQZG3joG1tVdBi4aoYS7BshbT1X/c2a IBVGquwGGbss/D8i7VejU9ciKTdcQvAzDVCG2nHr7DhE6JY7kbhkFT2QjG7GrPDdn2ls /GAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=WULwXmV4spoid2/wBSd/xHVEISzw73DFqydogsBAMMk=; b=uRdKgdfFdZgufihh0SadSrdbJCVsUJWltAju8Rs1ALro4PMLgAc72lnnDThP3w0OgU azCoV2jWE+mWW16CJGFjbCWYf+aFZrHwvkSoA7gR4cRE89h4yg/Yk0YyBCxDITqf+joc 7pg9DdKR7FQ/qcIcm0mW9cvc6rVK35bXDAPLPZqhR6wRzKONcaHNRzswP4EyS4Xk/pxr XU4Rd7HU1Sv8sbhfPKRXT+QlVbmC7b8TJ+zdDUDtZm1iXanFxoTF/1uwua6stFvhLnx1 6fzKJ5eq/c1RfVJaKOmELV+2yXV+1RvR4WEuuulltDXgxgR5R4+DOMTdi5cVpC1d3H0t 1NmA== X-Gm-Message-State: AKS2vOzgu5Rhu+jBWhHQkfXUqgc35WVsO2jXgkDMmB3jjcUEJF5igZCs QvVxSfZQ0Lok/yRWaxxh0sjp4cPqtIRx X-Received: by 10.55.4.139 with SMTP id 133mr69763174qke.259.1499550179947; Sat, 08 Jul 2017 14:42:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Bart Schaefer Date: Sat, 8 Jul 2017 14:42:59 -0700 Message-ID: Subject: Re: Question about ingetc() vs. word-code To: "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" On Wed, Jul 5, 2017 at 4:37 AM, Sebastian Gniazdowski wrote: > Hello, > I noticed quite large number of ingetc() calls ingetc() is the central function used for reading any shell input that has to undergo alias expansion or any other sort of lookahead -- stdio only provides one byte of input "put-back" [ungetc()], but in order to properly manage aliases and to differentiate things like "((..." [as either two subshells or one math expression], the shell lexer may need to read, put back, and then re-read an arbitrary amount of the input stream. > Why the compiled, not-eval source still exist in hunks in ingetc() input? Many times. The eval-code also appears, but this is probably expected. The compiled wordcode includes all the original text of most strings and identifiers, so that XTRACE and VERBOSE output can be properly reproduced. Only shell lexical tokens are turned into numeric codes. Identifiers that are referenced as well as assigned will appear at each $NAME expansion or function name call. A possible optimization for compiling whole digests of related functions would be to build an identifier dictionary and refer to the identifiers by a wordcode value followed by an offset into the dictionary, but this would be wasteful for most small/single-function compilations and would complicate the XTRACE playback.