From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Federico Tedin Newsgroups: gmane.emacs.devel Subject: Re: Patch to remove a bit of duplicated code in eval.c Date: Fri, 17 Sep 2021 22:08:34 +0200 Message-ID: <8735q3x8vx.fsf@gmail.com> References: <87h7ekxkb1.fsf@gmail.com> <83k0jf8xsw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19027"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 17 22:09:24 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mRKAm-0004mi-D0 for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Sep 2021 22:09:24 +0200 Original-Received: from localhost ([::1]:47738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRKAk-0000yN-UT for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Sep 2021 16:09:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56444) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRKA3-0000GK-CR for emacs-devel@gnu.org; Fri, 17 Sep 2021 16:08:39 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:39818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRKA1-0006Ma-Ma; Fri, 17 Sep 2021 16:08:39 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id 196-20020a1c04cd000000b002fa489ffe1fso10825694wme.4; Fri, 17 Sep 2021 13:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=nZulcIj2KodNEe+Iz7BDvtrGPOw4aFF8NAKQwSMfLKE=; b=okCw4o806w5J7qffpmhfZRI3DY4ZNYlP+uAg2wd8YToffSA+njd/tSMaB3GVqSvG6h R5Ay3YBOCUVtbQ9wHR2clUpUkExJG2k13JmHRGVlWdKug2onxz4FEwlHfkX6yxiP4nqI n7j8ADGA6TvoYS8GAuXtEbJl1QzeBob+FQm97qYb61tBih/PythauDGHR5ynddU472OH 8bX77gx9BU9sTAY3wi7GsT4f4WA2VZDVmmyoga6umPRZW1X0avgfJXy7Natcq/k8rhe6 uDr3+zNjKij79oCHudRF2dUt2I8pETh1SDYA+9R2EewyZZbVykeqQAG8BEddIR+w2XIj YeAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=nZulcIj2KodNEe+Iz7BDvtrGPOw4aFF8NAKQwSMfLKE=; b=ByT9XAIp+OP7p63iOiag0Q2T43eoPOHm2OqvkWXZDCX3Ej84Ul+YjUz2A6q1Nz8RFr nt5rE578d6Pz1eZ6qF3eUz4TbMVN+uaqwnI4nvBxj1IW7vkdvNvnhN+haBSkSvTJ5axv oDktuBtph1584zuk88hZYLjYhYYq1fTMesOmryXaWY+q5SL0jretByXMZ26lJT6DpHLK AgJK75viYn6xKc/3GsWW73br2RmfO9A59cwOlYDqkebvfu2QD/6oCDEqcvb2Jmw8h6xD hAQGSd8xIIkhhjG4VNgHvxiTWgetDKW2kKjQvfWmE8p55ZpzztKppWDghDb5qMmLacI2 QRIQ== X-Gm-Message-State: AOAM5339fwfKbdqIeEcPOFRSycZXKoUuvbpykhTwiu4fJmk7QFhBgNRq qi9rulQYY3aI2WGHLXO9MpYhWfLU0mmYzQ== X-Google-Smtp-Source: ABdhPJxYAKduvVjxsptUOQcyb5StNeA+GBcEy3BAkGFxp/tqsh/quvXDy6W6RFEc+4aZc7pBPbXT9w== X-Received: by 2002:a1c:f002:: with SMTP id a2mr16864494wmb.79.1631909315619; Fri, 17 Sep 2021 13:08:35 -0700 (PDT) Original-Received: from gehirn (ip5b4202e5.dynamic.kabel-deutschland.de. [91.66.2.229]) by smtp.gmail.com with ESMTPSA id f18sm9260263wrw.63.2021.09.17.13.08.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 13:08:35 -0700 (PDT) In-Reply-To: <83k0jf8xsw.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 17 Sep 2021 10:29:35 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=federicotedin@gmail.com; helo=mail-wm1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:274933 Archived-At: >> My concerns now are: >> 1) Could I have broken anything without realizing it, since this is such >> a central function in Lisp code evaluation? Everything seems to be >> compiling fine (without warnings) and so far I haven't had any crashes. > > I tried to compare the old and the new code, and their differences are > not trivial to audit. For example, you remove this part: > >> - else if (XSUBR (fun)->max_args == UNEVALLED) >> - val = (XSUBR (fun)->function.aUNEVALLED) (args_left); > > but I don't immediately see how you have something equivalent and at > the right opportunity in the new code. This part in particular is handled by the else-case in 'apply_subr'. Functionally it should be the same because I'm just taking the value of 'args_left' and passing it to 'funcall_subr' (through the 'arg_vector' array of Lisp_Objects, with fixed size 1). Then 'funcall_subr' just calls 'aUNEVALLED' with that single Lisp_Object, which corresponds to the section you pointed out. > I'm not saying I already see something you have broken, I'm saying > these changes are not easy to audit for correctness, at least not for > me. They are not a mechanical move of code from one place to another, > they really change the flow of control and processing. > > So I think we'd like to have tests for each of the cases supported by > the code to make sure nothing is broken. Is it feasible to write such > tests? On this I am not very sure. There are some tests for this file on eval-tests.el, however they don't seem to cover subroutines stuff. However it seems like some stuff could be tested; for example, I have realized that my patch evaluates all arguments before doing an arguments length check, which is already different to the current implementation (but would be easy to fix also). I will look into adding relevant tests to other parts I feel I might have affected as well. >> 2) I removed a comment that made reference to Bug#21245, but it seems >> like it makes sense since the variable it refers to is no longer needed. > > If the reason for the comment is gone, no need to keep the comment. > >> 3) Have I maybe made Emacs slower by always using SAFE_ALLOCA_LISP for >> the subroutine arguments (instead of only for 'max_args=MANY')? > > This should be measured. Sounds good. I also thought about it again and realized that if max_args!=MANY, then I can use simply use a Lisp_Object argvals[8]... like in the code I removed. So in that case the behavior should be exactly the same as before, and the change was a mistake on my side. > In any case, let's delay installing this patch until after the > emacs-28 release branch is cut, so as not to destabilize Emacs 28 > unnecessarily. Yes good point! I will re-visit this patch on the following days to see how I can improve it, alongside with Stefan's feedback. Thanks for your feedback!