From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 20 19:13:05 2022 Received: (at submit) by debbugs.gnu.org; 21 Feb 2022 00:13:05 +0000 Received: from localhost ([127.0.0.1]:34158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLwK9-0000jV-B7 for submit@debbugs.gnu.org; Sun, 20 Feb 2022 19:13:05 -0500 Received: from lists.gnu.org ([209.51.188.17]:35670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLwK7-0000jN-If for submit@debbugs.gnu.org; Sun, 20 Feb 2022 19:13:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56246) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLwK7-0008A7-E4 for bug-gnu-emacs@gnu.org; Sun, 20 Feb 2022 19:13:03 -0500 Received: from mout.web.de ([217.72.192.78]:48551) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLwK3-00070a-S8 for bug-gnu-emacs@gnu.org; Sun, 20 Feb 2022 19:13:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1645402377; bh=Z0wyedJDx7ZN4ykkfA7EL8PJA35qrLd7EB/yNI280ZM=; h=X-UI-Sender-Class:From:To:Subject:Date; b=dh2txheEMRffzujn8clQF7hESOgcf2X3zXIR8iJmq192U34+RqPeXXJhcD27IYRVl Y06wAp42fmJHUwBTtukAFjCep8/Zz8h/3q8yYTtJZmQtwrS3Om7dvFaoGZAWJr72pd 5XpWLFHzfk5vXPYdd1KcG08gF1dfI7uohlZ62Bm8= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MumNN-1oCFze2DND-00rZr4 for ; Mon, 21 Feb 2022 01:12:57 +0100 From: Michael Heerdegen To: bug-gnu-emacs@gnu.org Subject: 29.0.50; Method dispatching eratically fails Date: Mon, 21 Feb 2022 01:12:56 +0100 Message-ID: <87bkz113hz.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:r/HgOUoAOmTT58RAIMz4f4O4dgF4f8Bj3kTHkq6tCoc4wA/3Ddc IvW+lxIrHEUXRBljcdPO+W896D0I1BNo3kYslYz+23y6PLguSWzlG8zP9FKalj+mnSk6qIy LQGyR+3YzJEz5MPRmT8EVkTrvZ2Hwip6MaJK9v0uvN4eDKgQXPllMMPnalPCDrVBDi4IJp6 7LfJ/0itoHqoBgDFLHA9g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:N9FS4o/XEoc=:pmABrarSl//HnM9ZrDDGAr Ogbg7WC6fFDVwkFS2bz2t3nmc+zyO0qZUB2qJSIp5SvenfhEuqBZXeYrMbXedhXduxLHOaiai X9p1lSJsZfpMQ0ZLiBw/Lir3exiAxIPqDSaFhGwKaHuJqT65hrzzyPx2S9z+Bo8WK2/YMSziG Lsgm3Lg+zo/0Ofly/CUXJ2IRQz120u2lcNL5VqfiReWtWJHNq6RR122/GC8Acu9DXvAGZTGWu RK5xLBfp7w+Mvb7n3QIng9POoWVESpkedapGZHNLvYVUxkvvJ97r2xFX/SERqQ63z4ZtFoT4Y 3mKiwPuPzNDqw25RXYNUDTZdvnd/YjJjjjE48c5PgfcQN9tA8kLt1BwwUq6Tmagb7/xxuPgpi Yy+/3CHEfgk41huDUbhFgc0DcPZSYR009rTLPdXh9mfzv+MJrUtpyXyr73GThwwFAKPKHWKv2 XWQLtGmfQFhJ/M94Lc3ZzFMumIMdHRacrm7nkjCsP1MNTjwYn17xo5jy7ynejL9Du68ZQhNTF HeWWNbYyqGovjEvbqOWMqLXJSbDIuPVdC3sGfVulpSLWb4snCP8nkwyYJAL9BTMH3zZaRN6mR PBa5ivYNGpUhRE5noUL2oMcm7AO8bDzxzsZ+HW2AFyLwSXof2sqWtKGSSohlcHklDEJPeYwl7 FV5N41FHWxy3SkyuZkED+hj14a95GQCTRT5bAT8khz35Gbo8Y/15rdHPDwIto76Ul5yMdS780 et9emRFPVKFpV+Ex8xjZ59AAqo7HM+Nrwkk9oaM8b683Me+lfaoBlutc8dd2cmko9yaGSEoZt DatSKX4Z3IQz8k9LYxbG8Q4JkXOG44JJXXp6bVtXdtqjM2p/3EWXRED5TZO+WVLR8zsTFivZs YU86lTU3ywxfFLVqSOtUPz9eI+PuA0l1mQPNUSh+hKeA8ju4A1k8JkTTfFSG/65Xjxftjl7YP GLjmt5MwMclUz0Xn1leZG2nht8bzvPzTEIUDaq/ncYrO1TKe7Ct2OUebt4HOfN4hajV3UQaih 8BFO82L9+ItsIpRaMh+XA++ok7UeAgRkj4dsqu9j8c2HmohM4GlpIU1xIA7dMvRovotzi7LiG QJBOpANwQhS7b8= Received-SPF: pass client-ip=217.72.192.78; envelope-from=michael_heerdegen@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, this happens on trunk. I extended register.el with new register content types. This involves a lot of method definitions like (cl-defmethod register-val-jump-to ((val TYPE) arg)) where TYPE refers to some of my self defined container types for register contents. I byte compile my init file (where these definitions live). My problem: the dispatching of these methods is often erratically broken. The methods then are not used although their type should match. The according test for VAL being of the TYPE, e.g. by using the according type predicate, succeeds. This happens randomly. Sometimes it's broken from the beginning of a session, sometimes not, sometimes it breaks later while working. When it happens, sometimes not all types are affected. Sometimes reloading my init file fixes the problem, sometimes not. I don't see a clear pattern. Maybe there is a relation to the symbol-with-position patch (just guessing)? That's all I can say. So far I failed to reproduce something like this in emacs -Q, I don't have a recipe, and maybe it's even my fault, I have no clue. Maybe the behavior depends on what was loaded (and how, and in which order) before the file is compiled. TIA, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 20 20:14:25 2022 Received: (at 54079) by debbugs.gnu.org; 21 Feb 2022 01:14:25 +0000 Received: from localhost ([127.0.0.1]:34253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLxHU-0004YS-Mr for submit@debbugs.gnu.org; Sun, 20 Feb 2022 20:14:25 -0500 Received: from mout.web.de ([217.72.192.78]:54179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLxHE-0004Xy-43 for 54079@debbugs.gnu.org; Sun, 20 Feb 2022 20:14:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1645406041; bh=EMrGV0t0BhQbBd8XD0yKikGHq9BLDhhKzdybJqmklA4=; h=X-UI-Sender-Class:From:To:Subject:References:Date:In-Reply-To; b=VWhl2eumxK3ffqRsD1KehgBDlns0AVMQmeZUncf9B+Hidek2T0kob4U4JvhRSHz5o jyx2q4gLN5J1KKegOIaXuL6kSTpK4uj1cOOclJQkGe1L1N0Andzb8OF8OlLHdifVu2 /5lybGbFcfRKAe+UnFb9p3UxRFuZO47kLzyGLa+k= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MODmV-1nbaJE2mNN-00OHHn; Mon, 21 Feb 2022 02:14:01 +0100 From: Michael Heerdegen To: 54079@debbugs.gnu.org Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> Date: Mon, 21 Feb 2022 02:14:01 +0100 In-Reply-To: <87bkz113hz.fsf@web.de> (Michael Heerdegen's message of "Mon, 21 Feb 2022 01:12:56 +0100") Message-ID: <871qzx10o6.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:DKzWA3zQc0XueWaWv5T4Wqf0gY97UNVWlzHnO+4Wzbrtp1ugRv1 of/kjgRIcbCV4KmOJbn2iGPiz6thk9dCQm7nO2054XDwaBlhYTbErqdbebwzsZnwnr0e5T3 YwqwHDj55IDS8WJ895SkpuOuPVpgK8p5c9j7QwC3WOE1riQU7z4E3NuOavPTwlMDohmtSz3 YhbTybehUTkAUZTXEIY7w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:2cf4e2ZTwPc=:5E0L0/cqHOpj+jhTIhboYA A2Zo0k3WbSqYdOSW/ANaQCUBQEBYD3xLqHZBgoM7uQdwc/y5M+r08f6n9AzQuHK4XAk5WRYUl hvJgIdNyO6gFqH2/qx7deoSCAb9J4BanNs6/5KWfrL54dLRd04wD+P8fW///fShHx1p5eAjJs ysLn9LzVZ5EId6OgtIIufy1n7qAVlOGUW1vE72DBGHhb7WsH8aI9nZWjacMssJcN82dXOR05o zx80F/gnlujLCJwtln/wE7U0I3+aQn7V4IYl0AnXUA14XzBTNmuxMHFdCcrFAvw/o/kMayHeR ehag7CcHKwy8RFLiHxU2k01kQ0+EOo2uTtUApMs2gXEbx5A2YiQdcTYHpUMACMm0EtaLze5vd /3R9yeCeVqB71Px0KUtSDvF25nmpCYwFEMPloj5x/bzo/PtSHGQDLbyyuPtetUHovQsmZ9HHo gE/h/siIs6CWoe5e86y9WUJLAGb3F9iAKvU/LjRqVVSenpCC8mI4AkjV5F3uhMh65Ccb7gSW1 89Zx3p2qUhXsg5c8qFoBQqfIh78kP0Yf5MfOPgr+2TZFmm0dLkCWwEN8F8dca2Q11hsRVdRnP 3moyzGr++yxlNhjsuJzvnEeBJ1C2j5EYA/aFU35sdF2XzYvY7GPV/9zPZv1SAaaCYKqpaz7/o 3nSTPxj9w7fXFPAGdJg8+BIJXDbAyBFdwglawn8Y9IjRaj5LuDMSCvadfuBT8MzwEwBD8XxRT CK5+peJB5GBaKTPRhKfnOpnqI0Td1rSO6HFlBpLxdNlkgZW0REjcPtxbBDPvGP7q9/iB5gsho rEm0GpheyIHOy9wLJ8xXCZwwISB/kb+IuiizKdz3fl7YSeHCLPjIUkKApEv9dv3FoljqPyFHc 90bISDX5WPgFWd3/6hwpvAvQ6O/+JAB+c4zrtiTq4xJgIffb+juaSC0Tc5TSZ/CRJre+GBMgK nenGp6j2RACN1n5uyJd03tvn7YJjUxLEHz04fsuBax6YSaehPVKKjpMDmlzYFsDjR377Ni5QV daaN90VM8JMvyScjs8xk0VV0aME69R4uL+tPhxrpe07cy9rJRyAUAa8T5XeZbga6zXpeSkVkQ jNOGc/kUA5lKgY= X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 54079 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Heerdegen writes: > That's all I can say. So far I failed to reproduce something like this > in emacs -Q, I don't have a recipe, and maybe it's even my fault, I have > no clue. Maybe the behavior depends on what was loaded (and how, and in > which order) before the file is compiled. Or even just recompiling the file has an impact, I do that often. BTW, I sometimes saw symbols with positions in the `symbol-function' binding of related stuff - dunno if that is normal or even part of the problem. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 20 22:16:37 2022 Received: (at 54079) by debbugs.gnu.org; 21 Feb 2022 03:16:37 +0000 Received: from localhost ([127.0.0.1]:34336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLzBl-0003Y2-2v for submit@debbugs.gnu.org; Sun, 20 Feb 2022 22:16:37 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20285) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLzBi-0003Xn-Jc for 54079@debbugs.gnu.org; Sun, 20 Feb 2022 22:16:35 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 47A081001CB; Sun, 20 Feb 2022 22:16:28 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C825510012E; Sun, 20 Feb 2022 22:16:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1645413386; bh=bSDSm66t4FpBvNDrJbe9MthNwWASnjEVx/5ueDrb+LA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nqR7HCu8XoZzscIJ5zQg1jAhDtCRGeW7z4i/UucGuNk0d8n1mwBxRHrqfn6t/DAiA MDEc6hT6wRQrW1P6nnbyVB03kA59PddKxckpYuEWUN2a9OCz42BPculV9uxMSf6LqH s8vh6lX5Jm3ioRRjAWDulDKpSVNIZ7OEw3bf12fU34asvkaG1nOjwWhqrF6G0U16cK 9X0nQLGUmwUU6hFIEpnkIpA5sON3sEBzqV8CZ6V8W2byrzD9W4pjOJJBjLEASIC3bs lFfWIBFD9Tw8C8CpO801pyMVZmrvkEx8GT+SiNgWyrtJr2BYk6TYUvJm6SgSmXcP9E a3m//IqQKBonA== Received: from pastel (unknown [45.72.237.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9A64D120813; Sun, 20 Feb 2022 22:16:26 -0500 (EST) From: Stefan Monnier To: Michael Heerdegen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> Date: Sun, 20 Feb 2022 22:16:25 -0500 In-Reply-To: <87bkz113hz.fsf@web.de> (Michael Heerdegen's message of "Mon, 21 Feb 2022 01:12:56 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.045 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen [2022-02-21 01:12:56] wrote: > I extended register.el with new register content types. This involves a > lot of method definitions like > > (cl-defmethod register-val-jump-to ((val TYPE) arg)) > > where TYPE refers to some of my self defined container types for > register contents. Can you show the actual code (the bodies of the `cl-defmethod`s aren't important, but the TYPE part could, or maybe if they're inside something else (maybe an `eval-and-compile` or something like that?))? How is the type defined? `cl-defstruct`? `defclass`? > My problem: the dispatching of these methods is often erratically > broken. The methods then are not used although their type should match. > The according test for VAL being of the TYPE, e.g. by using the > according type predicate, succeeds. What does `type-of` return on VAL? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 20 23:21:31 2022 Received: (at submit) by debbugs.gnu.org; 21 Feb 2022 04:21:31 +0000 Received: from localhost ([127.0.0.1]:34467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nM0CZ-0003aY-4S for submit@debbugs.gnu.org; Sun, 20 Feb 2022 23:21:31 -0500 Received: from lists.gnu.org ([209.51.188.17]:33080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nM0CX-0003aR-14 for submit@debbugs.gnu.org; Sun, 20 Feb 2022 23:21:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46704) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nM0CW-0006OY-4q for bug-gnu-emacs@gnu.org; Sun, 20 Feb 2022 23:21:28 -0500 Received: from mout.web.de ([217.72.192.78]:52549) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nM0CT-0001pE-UH for bug-gnu-emacs@gnu.org; Sun, 20 Feb 2022 23:21:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1645417273; bh=ltiofyErOqSNf/yOU6xoduXFn8zD+vujgwpgbFfliqk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=G8Z0A4k1Sijiutbk4kaBiBvus8r9q+pYyNlf/Wb3Mvs+/JtMOon2POIX9DA1BR8sK U7wrDG8Suy9fdfzFjLpOzsTMv1nPnf90LM2PcL4s5Udwpwtb+ufrNszffvWdprg9ws 1+gDWt/VUdXVrK91oPY2muGPUGGaqUKTUh9fyJ4s= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1M4KJX-1nLj560Ru5-000ICH; Mon, 21 Feb 2022 05:21:13 +0100 From: Michael Heerdegen To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> Date: Mon, 21 Feb 2022 05:21:11 +0100 In-Reply-To: (Stefan Monnier via's message of "Sun, 20 Feb 2022 22:16:25 -0500") Message-ID: <87mtik3l54.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:OxLMoOis+2fM71p+7Mnyu8ZKdm+elLsdymStRWV1K00JAvF2m/x UGaTtt9hWjMUTp9oxKj00OPy+ZkarUc28fWT1u0HP/sk/e9xpY64S52mOf0k2dLXyGFPW/B ahGKtRn+BW7rXgXZ4lY1u7pyavGc0tVDo1o4RTR/oBwS/gH8KnYpOXalq3BMprarNjZzByI L5rUhmTUENCrEH2eL7M1g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:3CaZH2PPX0w=:Q2ePDO+8yO8uBbXzGBg0ro 1YLiUfJabVSDMdiVL2UY/GKZK5b0EGd7TjkgTTzGa2qrUqbJf49q7PfnyA2EttcUzJP1pAoYC PG71UiNSs0B2ULMgECDgVSyr8xRYB/ldpmwZfofL3p16grqm4DyTU9vugVrkAvgXOGOMtPhzU a3o0YVra0+8QkNnUO0fHVjzVTXHWN74xSffADuH2tfatAWA+ZzoQjV0XpJ6ymGbIv2HFLxMZg SF4i/SI4dFWq4q6rRr5QcVPHiSSw5qx4Eee2fTKrp51zEOkaJtZxMLqXZ2sUTCL1F29h93Isf 8Itj9+VDzzcqVcpK+oPw0QFpQBh22avnpgF/iRdy0W15AF5UP7MyPr8UhZJmr+2fTaRgn9SUO BKL/J33oTqGzjCropjnuD6Cd58KPfnj9ZugF4Sf9GSIY0jZG9dPbz34cCygcsJFsjoNhDtyUC caz6MA6j58Pb7B5jl0FfdByW8nDZ9rJfW2cON2eWQfNvSOUHXli+ICsoJh+MjTcIuLwVipgDL VLjABG9J3LoMY4wuoKV0sfARfIhakEAA1GLbb/lOt9pADNbBL+iwtYDu6wLXwXCRmtxEf92QF Crxk/kt2ZL+4vyP+0HmTMvJGUO/okj+RfewRkj3hix1FdnyC8LOx0z3rxlWWytr4IiHbKoyJd UoW+0O+sxomqNoIHpgf59xQwjH0k0XYGcwPbyJF5JKGec8JneMTOMEQ+DTPfWVOSRiJutwu5T WjaPD+yKKgpsHECaFfk9VVluk1kN0fdWU2N+oYiXbgEkEWDiFp/xF+2gbnBQd+W0igwDrUlOq X4cJJL62VcxPEVQfH4TqRzW02UJ5Dje12haEgcr2Np4E1cOPTgks7lAMo/8xxC1rXacg9LR4U dKFSuVR24j/ss0C5uoikk0nJG0lAOIbaBSPRD03WKvaAeqCKU+AxepDMygrNc6VDcnneZrEni 0QnXvLpPprrJRIuMvNlKJmsxV4/Gt3EK/jUoQR2khjgiS0ym/qsr+L7TzNmjKLujhrOwsYoEu WRI9ne1JBosP719fPlEtl47EwVsU31zY8kV8AJ2oGDuqGWcZnn0m8n9ICE1nrPjpA9z5kxylV XzVEwKO+gkTUr4= Received-SPF: pass client-ip=217.72.192.78; envelope-from=michael_heerdegen@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: 54079@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Can you show the actual code (the bodies of the `cl-defmethod`s aren't > important, but the TYPE part could, The TYPE parts all simply look like (val my-command-register) where my-command-register is defined with `cl-defstruct'. > or maybe if they're inside something > else (maybe an `eval-and-compile` or something like that?))? Some definitions are wrapped in a lambda and pushed to `after-init-hook' using this macro: (defmacro after-init (&rest args) `(add-hook 'after-init-hook (lambda () ,@args) 'append)) The others things are top-level definitions. > What does `type-of` return on VAL? Will answer that when it happens the next time. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 22 18:55:38 2022 Received: (at submit) by debbugs.gnu.org; 22 Feb 2022 23:55:38 +0000 Received: from localhost ([127.0.0.1]:43019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMf0L-0004Lc-Jv for submit@debbugs.gnu.org; Tue, 22 Feb 2022 18:55:37 -0500 Received: from lists.gnu.org ([209.51.188.17]:52624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMf0J-0004LV-N4 for submit@debbugs.gnu.org; Tue, 22 Feb 2022 18:55:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMf0J-0002Oh-FP for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 18:55:35 -0500 Received: from mout.web.de ([212.227.15.3]:41929) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMf0H-0006fg-Lo for bug-gnu-emacs@gnu.org; Tue, 22 Feb 2022 18:55:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1645574119; bh=FRyKgJOir2WwPD+y9SDICRP4ZUNeGQG7wTJZkYgB1EY=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=XbA6q5ctT3IeU5U0fy3ZRM2zlkWFugI3MaX4xWTNMmeHCBIiAhdKRxetaGT2TJetm sEcbQti853r1Z95NC3N2ou6sDYZoWPAemnatbuYBo971p+s27peYjXx1a0MnrMooKz q0XwyOjXKjBkdDHxYo4yFjTzBSSIhUvUVe9ZedUc= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MVJNT-1nm7f62f3P-00SCLC; Wed, 23 Feb 2022 00:55:19 +0100 From: Michael Heerdegen To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> Date: Wed, 23 Feb 2022 00:55:18 +0100 In-Reply-To: <87mtik3l54.fsf@web.de> (Michael Heerdegen's message of "Mon, 21 Feb 2022 05:21:11 +0100") Message-ID: <87ilt6bgnt.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:1NsKLTEypXWyKO6Zhcj3iTVGLRhqCnU4OMCetIfUrXkMRMJNY0Q 7itmHu1wByZUKv6CQFTSUqIKKLFu/nWhJuLr9p44Lx3I4cEg/eKj5IhhV9eRbKxRJ2xPCBZ 0L7fNH3TEPur0U6sYPSZ6an3K3mZV4ayrzngGxqo6D4ky7qTXe+zb1JawIThT5PW8Kb6T6W +cpTVVSa+BpqhRsOpmM0g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AtRJWCJCRCU=:ttL/a2HV7plHFf0DV8d1XA IpK4jAIMZGzz0j7Fop6do9v/m7Da1bXj4h5Y06UgAytU5IV93dpvr6D/rFYwNW8suDVjJOPYb Ib5LlVTTuHg/oc+rJX+I1TqNN5XZUL+UibsoJWSV7MtdpPDCqDAsQVyIZnBi5SZztDqSUeTGz Sx1xAGOA9ojqAHUoJfBW9U45LGM2KbFANHiGt8PA2qcUmkCmcrAj1Bhrg4+4evTgxDxGrytSt R+EzD46XdYlOAYv8CM8Nerl0RQF7Fm/kD/JePCUrInyAGQlJ5cZLUYBjyoxkuPfec0BM276vI rbXdbdGvD20S5N1/vdNHPX7XcVies6eNEFQHs9t8169CnQcUjVt0puVS7WOckWL03RPKBYsPH IE7aUBIJumz7UNWFf6wUYLBkMYgfBMsOaWrEFWpaMH4h69XLc3c00bQpZJD0Q+5ePF1xE8i8s qdfUDaoN/+WepmuOFvJwnW2zLoeFmvOmvPyXq940eQVA+JaDaNiHp7GvuLYYjo8QiS2IWMQoX dZ7+39JUI092Rt0bQgxIzdLcSSHhBWMdAmG9rHTjHjJyPAkIx5zmB0rZPLmbVHRoJZxJo1DBT VBmmXJtZA0gIfbSHIk0pN8vfWaeojOL9kEi2p8OwZJ2i+jHx+GWi3y3cxpL4uFDr0KHsyXAoz mBuZJ9oRb8ZQ8v8Sxrp8bJBTjP+n+eznI1owSAIjHU08DcIpk5oRJRP5DLhcJm6nBBZUlcJm3 bvjixgLNZ2iS4DZn7njqV/zpulR0rhJb/z2EVmR0ZtViX7d8LmZXmzIjAW2+tQOVYw6Fqbog6 HKSZ4Kl/L0wti+YakX4hDYeoVhVpu6aXoOqTS8vxmKs6tS6YXMLOLf2y2GfK16/EtUPml4iL1 E955OsKQqFd/YifukS4LfInGTMMxgRFwZ9iCFUC9wGxrVsxzBV0b89LL6no5M9GZ+dYRb3UsH 46/jtnSJ0q7GN8bFjIMTGIqlL8mOg6LCfB0rxyqZs71h9bz14b/e50rg4jWGZemWdOXeN6Ve6 yTWklOBoxQTbOtZ/n3xRJ7HEZ867XW34tIOaUQ8BgEIA+uLXYzMHLP+63UDUC2pGK9t9hj64m ttj5GzXMHXFJO0= Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=212.227.15.3; envelope-from=michael_heerdegen@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: 54079@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Michael Heerdegen writes: > > What does `type-of` return on VAL? `type-of' returns the expected value, the symbol which is the name of the class. The return value is not different whether it works or not. This for example returns t: (eq (type-of (cdr (assoc ?A register-alist))) 'my-window+pos-register) OTOH, in the *trace-output* I am currently seeing this: 1 -> (my-register-val-describe-nicely #s(# :# # :# #)) 00:41:15.227 (my-register-val-describe-nicely #s(# :# # :# = #)) (register-val-describe #s(# :#<= symbol window at 704894> # :# #) nil) (describe-register-1 65) (register-describe-oneline 65) (my-register-preview (65 . #s(#= :# # :# #))) (my-register-preview-function (65 . #s(# :# # :# #))) (my-register-preview--around-ad #f(compiled-function (buffer &optional s= how-empty) "Pop up a window to show register preview in BUFFER.\nIf SHOW-E= MPTY is non-nil show the window even if no registers.\nFormat of each entr= y is controlled by the variable `register-preview-function'." #) "*Register Preview*") (register-preview "*Register Preview*") (timer-event-handler [t 25109 29850 770721 nil #f(compiled-function () #= ) nil nil 4000 nil]) (read-key #("Jump to register: " 0 18 (face minibuffer-prompt))) (register-read-with-preview "Jump to register: ") (command-execute jump-to-register) 1 <- my-register-val-describe-nicely: nil Definitions are (cl-defstruct my-window+pos-register "Doc" window pos) and (cl-defgeneric my-register-val-describe-nicely (val) "Alternative to `register-val-describe' - the return value is used from = this one." ;; This should support colors at least for some preview functions (ignore val) nil) (cl-defmethod my-register-val-describe-nicely ((val my-window+pos-register= )) (my-register-val-describe-nicely (my-window+pos-register-pos val))) The default implementation is used and the matching implementation is ignored. I have now re-evaluated some of the definitions. Sometimes this helps - ATM it didn't. It made the symbols with positions disappear in the trace however, now lines are traced like (my-register-val-describe-nicely #s(my-window+pos-register :window # :pos #)) So I'm not sure if symbols with positions are related. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 22 19:27:27 2022 Received: (at 54079) by debbugs.gnu.org; 23 Feb 2022 00:27:27 +0000 Received: from localhost ([127.0.0.1]:43060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMfV9-0005CM-4Z for submit@debbugs.gnu.org; Tue, 22 Feb 2022 19:27:27 -0500 Received: from mout.web.de ([212.227.15.3]:45953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMfV7-0005C9-1E for 54079@debbugs.gnu.org; Tue, 22 Feb 2022 19:27:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1645576036; bh=vFLkR77NdCMcPYgYv5cSVSfMwX4eg6WSdfxscb4/0DU=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=Gcpl1CK40cNZIsxjDs8unAwajDZU7OzpfZHxlVzP4iTrGH325cGOoE1KcpKdE236s TR61Rzu7LbRCQReuVdMFUE004gUZMgJMX0oX/knISAJXG+9SRdi/DSrLbYCD7/SaQC pkjsqp13WDY58jms+HoC5IeDZF1g8rN0zuoBKB58= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MNfYN-1ncFDT1KCh-00PCJc; Wed, 23 Feb 2022 01:27:16 +0100 From: Michael Heerdegen To: 54079@debbugs.gnu.org Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> Date: Wed, 23 Feb 2022 01:27:15 +0100 In-Reply-To: <87ilt6bgnt.fsf@web.de> (Michael Heerdegen's message of "Wed, 23 Feb 2022 00:55:18 +0100") Message-ID: <87sfsapgv0.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:DH4CSxggExS4aEjhc3+wboAGIsZJxW/J8kfq2HMIO6nhd4R547K tRi80WheXwFQVi2yU9EJkeTdCyiBxE5gcfZi0P2w3LUcEt4kxtCmQ3tpSP8YW51NS4MNRRA u2JbnxVZIodifPBZV/CYqW9RSewmTB7ngLOQLHGfzulpw9YcDP2BOUXZcjZX2nDQsQbTDHk yz/JobicD1PDD26h/kQtw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:41iRSnkZ5Os=:EfwGhPT3JszGKzxjni2Lkh GKegES2BmfUHTjB3CXNjpWwV9T+R2vpYAiNWxBqTllkGRiUzDYJEAhZB61sA8xs2om+/jb3Fc q7PEPnagdqDmcNDIRv67cdGDbRKSVHZ8VIKlM7lENzISuqQ9ZfgU2oMdxysD1GWSKWFNZ5/2w z1NJk+hdLSoz01xJ0poIxNT5zNAvV6b0hq3ydRlnCIlwNFC9M1gyAPQ3xOPLRgrH8JPQIBdZP TqjeaJxJlYcTvNwTcx1HQ88Q/mguLEWLej3mDt+pZhW174Abmxo5D5YaHurVWjyeDU5r0Fg+g gL9Jen1fRhhE8NSP0+Pct2AHZIO4aTAoOz1qrG51VHDTys6N+KKYkdJZEr3FfyJbZ7lO+6b32 VkW7NFT9fDw6qz4dthZ4E4uSY2rfxaQh2aF/VPsn8qw//rVv7j6wFrZ2xdsjZnQ0ToYFBwRWn GUvHkhdLUpKEqWymRJGJXxg9J14Dhf5tTmvlQ2iSWsSpPwdOMkjoTzL0BAaRA9qazZX9tcZc9 /gHQAso4h6sSVwyLc3tcI3WpN8/OI5yN3/q/toljYhf8QNc1WPtxZWQxsOuJAhZGhZIZdlDu0 7CdDx79ryOtn1EVFJ7wApAuhr1bF/k/GFk5hOmuNuQSsoXJZO5OiFpalyhmfjG3FrXCIsf38L 2rZTxa1P+OJIpWavFm+rB3Fn9IyC4PEQq0Mr41r1cPutp7gPs9DchycgJg+/0U1K8Ipf6NM7v A8I+xJodSEjWnoNTLmoXgWwEmy5otMDXf7UW56a4B4w0305pIyULHJ2+9nyUkf2cIhlNqBINK ZcaX8MtoPVW0br5IRyaZkhbX9lNNavjmYL8vbLi8c6dAJ2xC3msILTHvFRggmxMppe3zC1F59 lUVaT5SSu0pDHidt2Xk9VY/WO/LNPFHbhUfN8/AlXZ1edJ92ohCOSVHZZ8Wa9v2/YdrG8TEya h1P6U9vw85BvVD2IdyH40B7rUIUjxSRRWgffKillb00fcwhDAgtfUlVAB8nQYmDz1zesu13xk bgtUaH+5UbI/0eiLuIoBHzj0ZMcUBjEgM6m3IKbMGI2eqyD9M4G2wrYz7P++kT7LQt/UKPEKs fd1XIU8unzJeDo= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 54079 Cc: monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Heerdegen writes: > So I'm not sure if symbols with positions are related. Dunno if and how this is related: I found out that when I byte-compile cl-generic.el in current Emacs session, trying to M-x gnus suddenly gives me: | Debugger entered--Lisp error: (invalid-function #) | (# ((# nil) (# nil) (# #)) (let ((--dolist-tail-- #)) (while --dolist-tail-- (let ((# (car --dolist-tail--))) (setq # (cons (cond (... ...) (... ...) (t ...)) #)) (setq --dolist-tail-- (cdr --dolist-tail--))))) (# (# #) (# (# nil #)))) | (cl--generic-split-args (engine artlist criteria)) | (cl-generic-define gnus-search-grep-search (engine artlist criteria) nil) | (byte-code "\300\301\302\301\303\304#\305#\210\306\301\304\307\304\310%\210\300\311\312\313!\"\210\300\314\315\313!\"\210\300\316\314\"\210\317\316\320\321#\210\322\313\323\314#\324\313..." [defalias gnus-search-grep-search cl-generic-define (engine artlist criteria) nil "Run a secondary grep search over a list of prelimi..." cl-generic-define-method ((engine gnus-search-grep) artlist criteria) #f(compiled-function (engine artlist criteria) #) gnus-search-process-p eieio-make-class-predicate gnus-search-process gnus-search-process--eieio-childp eieio-make-child-predicate gnus-search-process-child-p make-obsolete "use (cl-typep ... 'gnus-search-process) instead" "25.1" define-symbol-prop cl-deftype-satisfies eieio-defclass-internal ((proc-buffer :initarg :proc-buffer :type buffer :documentation "A temporary buffer this engine uses for its\n se...")) (:abstract t :documentation "A mixin class for engines that do their searching ...")] 6) | (require gnus-search) | (eval-buffer # nil "/home/micha/gnu-emacs/.gnus.el" nil t) ; Reading at buffer position 231 | (load-with-code-conversion "/home/micha/gnu-emacs/.gnus.el" "/home/micha/gnu-emacs/.gnus.el" nil t) | (load "/home/micha/gnu-emacs/.gnus.el" nil t) | (gnus-read-init-file) | (gnus-1 nil nil nil) | (gnus nil) Never saw this until now. No problem when I do not compile cl-generic.el in the session. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 22 19:47:15 2022 Received: (at 54079) by debbugs.gnu.org; 23 Feb 2022 00:47:16 +0000 Received: from localhost ([127.0.0.1]:43078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMfoJ-0005jp-Pe for submit@debbugs.gnu.org; Tue, 22 Feb 2022 19:47:15 -0500 Received: from mout.web.de ([212.227.17.11]:43579) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nMfoH-0005jV-V5 for 54079@debbugs.gnu.org; Tue, 22 Feb 2022 19:47:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1645577225; bh=fC/aelu7u0ndptoOKs7ANWlX4XHvGCRyuS6fau2u6l0=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=O+9HKCJPiFgOzyEk7G6s7SjfeO/wEHR+8UH/Tf0ti747rpC4Gx6H9Gw/jMkpUSw6J EGnJiLpDhEp8fF85IGWGv4Qf6aLS4/1lngqQPoVcimWZL6Jpqa3nGwrj5K8HNwsXnm 66CiqtE6r7nIyDW7oaQ3PzPIQLpZ57O8YKoCAf18= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MpCmT-1o1ZHK06dr-00qiE5; Wed, 23 Feb 2022 01:47:05 +0100 From: Michael Heerdegen To: 54079@debbugs.gnu.org Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> Date: Wed, 23 Feb 2022 01:47:04 +0100 In-Reply-To: <87sfsapgv0.fsf@web.de> (Michael Heerdegen's message of "Wed, 23 Feb 2022 01:27:15 +0100") Message-ID: <87o82ypfxz.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:PjhJyBYaofOYIsw0dkiaazbD4gSyQJG9iQtjQimQHYg6G+u2a9P yT+kQ3z1BeCcs5WgGy4dDFBrnifK+Xvy5IIgM9bbfNA7/24drrQZl9AllAjAHoWR1zBNh6i y5M0m3RbVMWHwrYRDX0WI+y7MOVEks2ZN41dpjo8SzkEJRqW5zWTP2jSgtYXZsblgfn0Mw/ RG8F8L1IvxNFbh4/81Onw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:+lKHrbwoAUQ=:RtJwYcY1J1Z9S1DPwMZ2rQ xKCWRAQXIoAe3IyY06VOcMsqb27N0IMSAuPw30vTToUtp8wwl+y51F02lb5Al/8/5kINnnmMc Ui6yF8lSue8wdSFOicXmMe/HxMpxuc6i92ilPiavg9WzjbK99w+D8vKOZAN9FOZq6EaKSKRrm 6EgWP7rEmXKJGM4oZIwv4kchcHvyMBjUx4JFqhR0HPO2rsgcv8Ql66wp7dioHek99d2KVuFYH c09lEAxtQ5vRb3yer3LIbsnSfhyMUrkUlTPcKvlYsanYJbsyJETlf27xh9x7A0adZ82T4k4YC 2QfkoQ6596/fbVU1zR+520pWG52GrckBlPizWo4soRTBfE3FdDXL89MybfpPMQY2qbaRzAtjc Kn83MMNTBVpgDvcLHMe62lXG7iEae7oA/NaT/72SUNU+itsQTHa1NfxTk5M1aatcZt8KCpihJ AXkMsqC3N0r2/GGPhfvFHU6ZZ9YV43O4ZfQ9wASmkX9ODPBhCDV/eOdSuCUvPTwztrAOmE0M0 OSfqd7wldwKG5EORAisZbAq3NZGGN0swBCIM6Y/qaNaTElepGHu9TP9xU89yaCFMEqxcLMrpQ ItKo3naoDjNhdLTV2Iwj0FODSW79E1CvAKttAGy0B24EQKYodOHl5WByTQDZ/N7HeGgf1OXxW +Wov6kbK0a9eJ8rdBSqY30rQilQg3fcZkXjZ8gzqIJHkslAhctZDMutHPZGCp346UghmG59o6 OoUS8uFLuEQafxB6FExBPhFC31z1t0eX92r6OgE8jo7v+pdPuJaCQqt7XxO4pZUYBDfTR2luU gjd9CGgyJC9ViRjzeZIJ/PJjsF5XK//63UBBg5h6+RO6N335WujoKF5dTDdqlicY4yZTyS/Dm GvY5cokppDqhY7KBahKuN+a6TzIJPY4D+QNUhZ7R+3L4mp2BTnDku9dF5vAftaD8I4xaamyP5 lYu9ACqlIAnu6CDhInUHDkNnixu3OWDJM2EwHdt/imceVpr59DGnCDQbBOFDNnTo3GbXxcVc4 gjI6H+CLJKGIYXqLW81qUWv9CmWQQoLBhniwlM5mtk2OCo/CTJ2jGgAOSyfQ+L+PtBG0zBxlM QqnhVg0fxJBk8k= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Never saw this until now. No problem when I do not compile > cl-generic.el in the session. This short recipe gives me the same error in emacs -Q: (byte-compile-file "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") (require 'gnus-search) "Same error" means same error message. I didn't get a backtrace in emacs -Q because even the debugger didn't function: M-: (debug) also errors. Ok - hope we now have something to start with. Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 03 21:08:18 2022 Received: (at 54079) by debbugs.gnu.org; 4 Mar 2022 02:08:18 +0000 Received: from localhost ([127.0.0.1]:44258 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nPxMg-0005b8-FB for submit@debbugs.gnu.org; Thu, 03 Mar 2022 21:08:18 -0500 Received: from mout.web.de ([217.72.192.78]:33195) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nPxMe-0005av-8y for 54079@debbugs.gnu.org; Thu, 03 Mar 2022 21:08:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1646359686; bh=1wDxMGScq97JNtVkJnMviSkqPCIPVpLUvcnc798GX4s=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=YYXuMKjI/QE5P2iGGkxq0DftdlLhW343oOwK/PYISZxssTI/gSKH78SP0INt96gsG ZGg1dN3JwT87GWsCfQyTGOaGSbafdg61oAxpnMLk8+MmPBsViaRLC5loDmM2hksCFg BJKrO9xXqAb8x2FlnBIbOuznP5I/rQuulqYKx/pY= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MEUW8-1nOGYG3DXW-00Fzf9; Fri, 04 Mar 2022 03:08:06 +0100 From: Michael Heerdegen To: 54079@debbugs.gnu.org Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> Date: Fri, 04 Mar 2022 03:08:05 +0100 In-Reply-To: <87o82ypfxz.fsf@web.de> (Michael Heerdegen's message of "Wed, 23 Feb 2022 01:47:04 +0100") Message-ID: <875youbhbu.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:VcxtFUxdAUb3PxzyaEJYe7VloDzRyhMSmf7aYaNvDL9L8g0DPNV sEZ6yX5fOOB6dUEDwbGUFWYrkL6joxt8Uv+QH1u/p20qTGYVlYlJaEL33WqmVNtsdQtXx1K oGLh5JubIgI5JwzG5dM9bF322yMFtZhpKcy/TSGPN2vUYjV5bckp9z26r7LlNkU0FDuUAgf Ql4SlHF/fUakGi3qe5UpQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:9FXfxAyudhY=:Ah9g39D7/fD47ssf4HYGXb t/C6P33/SQZPK59OvyVWY9wJfjklygMxkSAMN4MNXV374e61wrTzgUZD/aH2GHRb1i+485ahg SeXJSGyCqSbHszu7J3yzg6AYoOYECwbkTf6acPMkAwmT2IY5owz0otvzZYVzRxKz7ZNdLwQia vXcQBr0Z2Ze7J8BXOajgvLKq8L3ENEgxhMM5RFLdreefxOESsMafA/THjXam2M4TK38WHl7gC j8h2odRm8Y984Umg3sd+ZwVB8RerwYzUvs6eDSHce8FwbBfZCXnkaAcHsHaFdGzON76xY+Be8 3DZhIk9dXOOtGtEEYDbuKhGidjn1knLko3n2e8+0DX/NVNGNBtl/oug30qSWFWiZelQW+SAAS sRazi5ofpeAYqHIz+Nkj9n61lJ2XQxUgnOh5ENP79oNaCaCUrotfGHEGiFusybaW3z2LeFJfm Vv52GtO6yjjqMKv6TSJM0yLu+nAMS4OjCHp1a/HfeC/+UrtpbfIgjcmoqkdwo6Urh7+HwlJtT /SBsToAy1ldIxTpYBhWPKc7gNVFZqT2kYLy2QiLVb5vjvCzOBdaewLXTU0RUlNtSLmVx4Dr+1 Eugbt71BTsLx/0D/dJbTqIChfvWX+3I5kCjedoe0LphGJhIykCJ7txQH6G1lWctfY1Qb3thNd Ky/GA8zzgdBKF4BG5e3v0AMrtfqIQSXKaWIZQymXp6IO1KyY7cJnscPiWBJxZuZgYR+HOrqGO 0WbXko4mqEUKzz1X0064Lnh8Y+EQHNj+TUPOeKsGQplgKcSyszUFuUf8hpUuy312b22zfcUuF FFGuCiYjaqxPTRmTqV2PvqG0rUW4DB/hdATUhDthRUsJAyGzfFHnc7PWfvGdy8fAZwmmZ3s4i u3UwS6pCib/E/k1CXxL3CjmajdZWiexIq2ctpbmsHlSa/Wm3f/YBRloPW9cTDC0rxO5JOF/3B KhWysWWU1xVqPFGP3FVrZxztRSVCM0ymlulKTarCQ4IqU+o1gOoQS8p4JUs6yI7R+8kDvq5mg fe02BjLUHc65yzd0QzK+vd+rmbwdB07yoHEuBJHybJRJCmjASxmPHd3i7VqY2Ds16zMJPz9Gp 1MIbBZHL6M/VNE= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 54079 Cc: monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Heerdegen writes: > This short recipe gives me the same error in emacs -Q: > > (byte-compile-file > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > (require 'gnus-search) Small addition: it seems that all issues mentioned disappear when I avoid any byte compilation in my session. Compilation of `defstruct's seems to be the culprit (hypothesis). Would be good to fix this problem not too late. I think it will irritate or distract other people, too. Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 04 11:12:42 2022 Received: (at 54079) by debbugs.gnu.org; 4 Mar 2022 16:12:42 +0000 Received: from localhost ([127.0.0.1]:46698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQAXq-0008NC-0c for submit@debbugs.gnu.org; Fri, 04 Mar 2022 11:12:42 -0500 Received: from quimby.gnus.org ([95.216.78.240]:54778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQAXo-0008N0-2h for 54079@debbugs.gnu.org; Fri, 04 Mar 2022 11:12:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DqvgDbRnK3z309GOzaguvoyhN0AcE36chvR7bWJ073o=; b=ucY6ywI16qJhrXdPCRyxNA4XM+ NAmlq3RezvDJIL4z5I2wlHPm0tdQarf//gFzUxphTV3oPoKIiZm+H9TSx77p+uTUNf6Dbi31S7gXK iN3N/Wtbwj9F3te+fYASEXIwPrIYjALFsWVe/ZTc0cPnXH1bHFeeOma22c/WD7B6HQsU=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQAXg-0006V1-7Z; Fri, 04 Mar 2022 17:12:34 +0100 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <871qzx10o6.fsf@web.de> X-Now-Playing: Moor Mother's _Circuit City_: "Act 1: Working Machine" Date: Fri, 04 Mar 2022 17:12:31 +0100 In-Reply-To: <871qzx10o6.fsf@web.de> (Michael Heerdegen's message of "Mon, 21 Feb 2022 02:14:01 +0100") Message-ID: <87czj1elxs.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > BTW, I sometimes saw symbols with positions in the `symbol-function' > binding of related stuff - dunno if that is normal or even part of the > problem. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Alan Mackenzie , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: > BTW, I sometimes saw symbols with positions in the `symbol-function' > binding of related stuff - dunno if that is normal or even part of the > problem. I've seen this issue, too, and it involved symbols with positions for me, too. I've added Alan to the CCs; perhaps he has some comments. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 04 14:11:38 2022 Received: (at 54079) by debbugs.gnu.org; 4 Mar 2022 19:11:38 +0000 Received: from localhost ([127.0.0.1]:46833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQDL0-0002a2-JJ for submit@debbugs.gnu.org; Fri, 04 Mar 2022 14:11:38 -0500 Received: from colin.muc.de ([193.149.48.1]:15411 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nQDKz-0002Zn-Mo for 54079@debbugs.gnu.org; Fri, 04 Mar 2022 14:11:38 -0500 Received: (qmail 89869 invoked by uid 3782); 4 Mar 2022 19:11:30 -0000 Received: from acm.muc.de (p4fe15940.dip0.t-ipconnect.de [79.225.89.64]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 04 Mar 2022 20:11:30 +0100 Received: (qmail 15195 invoked by uid 1000); 4 Mar 2022 19:11:29 -0000 Date: Fri, 4 Mar 2022 19:11:29 +0000 To: Michael Heerdegen , Lars Ingebrigtsen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875youbhbu.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Michael and Lars. On Fri, Mar 04, 2022 at 03:08:05 +0100, Michael Heerdegen wrote: > Michael Heerdegen writes: > > This short recipe gives me the same error in emacs -Q: > > (byte-compile-file > > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > > (require 'gnus-search) Thanks for such an easy to use recipe (despite the troubles you had coming up with it ;-). > Small addition: it seems that all issues mentioned disappear when I > avoid any byte compilation in my session. Compilation of `defstruct's > seems to be the culprit (hypothesis). The biggest clue is in that error message # .. At position 15662 in file cl-generic.el, there is indeed a `let'. It's the first symbol inside a defun, and that defun is inside an eval-and-compile. It seems that the positions are not being removed from the evaluation of the defun form done by eval-and-compile. This is the bug. > Would be good to fix this problem not too late. I think it will > irritate or distract other people, too. It irritates me. ;-) I'll fix it. Maybe this evening, maybe over the weekend. > Michael. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 11:37:27 2022 Received: (at 54079) by debbugs.gnu.org; 5 Mar 2022 16:37:27 +0000 Received: from localhost ([127.0.0.1]:48942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQXPL-0008Sx-76 for submit@debbugs.gnu.org; Sat, 05 Mar 2022 11:37:27 -0500 Received: from colin.muc.de ([193.149.48.1]:49354 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nQXPJ-0008Sj-9Y for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 11:37:25 -0500 Received: (qmail 64429 invoked by uid 3782); 5 Mar 2022 16:37:17 -0000 Received: from acm.muc.de (p2e5d5265.dip0.t-ipconnect.de [46.93.82.101]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Mar 2022 17:37:17 +0100 Received: (qmail 31510 invoked by uid 1000); 5 Mar 2022 16:37:16 -0000 Date: Sat, 5 Mar 2022 16:37:16 +0000 To: Michael Heerdegen , Lars Ingebrigtsen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875youbhbu.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: acm@muc.de, 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Michael. On Fri, Mar 04, 2022 at 03:08:05 +0100, Michael Heerdegen wrote: > Michael Heerdegen writes: > > This short recipe gives me the same error in emacs -Q: > > > > (byte-compile-file > > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > > (require 'gnus-search) > Small addition: it seems that all issues mentioned disappear when I > avoid any byte compilation in my session. Compilation of `defstruct's > seems to be the culprit (hypothesis). > Would be good to fix this problem not too late. I think it will > irritate or distract other people, too. I think this problem can only happen for defuns/defvars/defconts inside eval-when-compile or eval-and-compile. Would you try out the following patch, please, which I believe fixes the bug. Thanks! diff --git a/src/data.c b/src/data.c index 1526cc0c73..0854b4efb4 100644 --- a/src/data.c +++ b/src/data.c @@ -942,6 +942,13 @@ The return value is undefined. */) (register Lisp_Object symbol, Lisp_Object definition, Lisp_Object docstring) { CHECK_SYMBOL (symbol); + /* If we're in a byte compilation, ensure the definition's symbols + are stripped of their positions. */ + if (symbols_with_pos_enabled + && SYMBOL_WITH_POS_P (symbol) + && Ffboundp (Qbyte_run_strip_symbol_positions)) + call1 (Qbyte_run_strip_symbol_positions, definition); + if (!NILP (Vpurify_flag) /* If `definition' is a keymap, immutable (and copying) is wrong. */ && !KEYMAPP (definition)) @@ -4352,6 +4359,8 @@ This variable cannot be set; trying to do so will signal an error. */); Bind this to non-nil in applications such as the byte compiler. */); symbols_with_pos_enabled = false; + DEFSYM (Qbyte_run_strip_symbol_positions, "byte-run-strip-symbol-positions"); + DEFSYM (Qwatchers, "watchers"); DEFSYM (Qmakunbound, "makunbound"); DEFSYM (Qunlet, "unlet"); diff --git a/src/eval.c b/src/eval.c index 294d79e67a..1b1fde3a20 100644 --- a/src/eval.c +++ b/src/eval.c @@ -794,6 +794,12 @@ usage: (defvar SYMBOL &optional INITVALUE DOCSTRING) */) if (!NILP (XCDR (tail)) && !NILP (XCDR (XCDR (tail)))) error ("Too many arguments"); Lisp_Object exp = XCAR (tail); + /* If we're in a byte compilation, ensure the definition's + symbols are stripped of their positions. */ + if (symbols_with_pos_enabled + && SYMBOL_WITH_POS_P (sym) + && Ffboundp (Qbyte_run_strip_symbol_positions)) + call1 (Qbyte_run_strip_symbol_positions, exp); tem = Fdefault_boundp (sym); tail = XCDR (tail); @@ -861,6 +867,14 @@ usage: (defconst SYMBOL INITVALUE [DOCSTRING]) */) } Finternal__define_uninitialized_variable (sym, docstring); + + /* If we're in a byte compilation, ensure the definition's symbols + are stripped of their positions. */ + if (symbols_with_pos_enabled + && SYMBOL_WITH_POS_P (sym) + && Ffboundp (Qbyte_run_strip_symbol_positions)) + call1 (Qbyte_run_strip_symbol_positions, XCAR (XCDR (args))); + tem = eval_sub (XCAR (XCDR (args))); if (!NILP (Vpurify_flag)) tem = Fpurecopy (tem); > Michael. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 12:57:25 2022 Received: (at 54079) by debbugs.gnu.org; 5 Mar 2022 17:57:25 +0000 Received: from localhost ([127.0.0.1]:49018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQYej-0004Ey-9q for submit@debbugs.gnu.org; Sat, 05 Mar 2022 12:57:25 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25959) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQYeh-0004Ek-TK for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 12:57:24 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8D4FD8067F; Sat, 5 Mar 2022 12:57:17 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2CC8380298; Sat, 5 Mar 2022 12:57:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646503036; bh=3VTL1G5+79eAhQrfZG+ktwxKM3J99Uk9P/xN4Q1wJVc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=bj6q6C26xFPtAFvHa88Sad7t0Iu1cOTGSwiL2FXgqhfUR/3H7IDzTnkZ79qJZ9cBy av0ae5Fk3nu+QtXdCkSwNLEZtimviUkUlQ7JqnP3us5eNMNgvVamnfvcNfS47XKk8J KF5evmlH54u7CoqYGlXC59U9fiMuzjjSN1cuuRMLAlq72CruDlUvhy/lkwRM50O+HZ TiX3mGzOzByoy1FP35n4zh2+pW3W0rWPtc2ZoiXDaVWAaTd6F/oLdtkDqPbpSbgoR+ 6v+6Qq+oIcO5eAZp1cDy4OvHUyUPF5KI5faWhfhVoZ4GqmynRBnvfjDshxLXbHSFmS OWBdLE7s2yqeQ== Received: from pastel (unknown [45.72.208.76]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CD3DE1201F4; Sat, 5 Mar 2022 12:57:15 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> Date: Sat, 05 Mar 2022 12:57:09 -0500 In-Reply-To: (Alan Mackenzie's message of "Sat, 5 Mar 2022 16:37:16 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.809 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I think this problem can only happen for defuns/defvars/defconts inside > eval-when-compile or eval-and-compile. > Would you try out the following patch, please, which I believe fixes the > bug. Any chance we could fix it in `bytecomp.el` by calling `byte_run_strip_symbol_positions` before evaluating the contents of those forms? Maybe we should have a function to check for the absence of sympos which we could call (when in debugging mode only) from defvar/defalias and friends, which could give us useful backtraces showing where/when the sympos "leak"? Stefan > diff --git a/src/data.c b/src/data.c > index 1526cc0c73..0854b4efb4 100644 > --- a/src/data.c > +++ b/src/data.c > @@ -942,6 +942,13 @@ The return value is undefined. */) > (register Lisp_Object symbol, Lisp_Object definition, Lisp_Object docstring) > { > CHECK_SYMBOL (symbol); > + /* If we're in a byte compilation, ensure the definition's symbols > + are stripped of their positions. */ > + if (symbols_with_pos_enabled > + && SYMBOL_WITH_POS_P (symbol) > + && Ffboundp (Qbyte_run_strip_symbol_positions)) > + call1 (Qbyte_run_strip_symbol_positions, definition); > + > if (!NILP (Vpurify_flag) > /* If `definition' is a keymap, immutable (and copying) is wrong. */ > && !KEYMAPP (definition)) > @@ -4352,6 +4359,8 @@ This variable cannot be set; trying to do so will signal an error. */); > Bind this to non-nil in applications such as the byte compiler. */); > symbols_with_pos_enabled = false; > > + DEFSYM (Qbyte_run_strip_symbol_positions, "byte-run-strip-symbol-positions"); > + > DEFSYM (Qwatchers, "watchers"); > DEFSYM (Qmakunbound, "makunbound"); > DEFSYM (Qunlet, "unlet"); > diff --git a/src/eval.c b/src/eval.c > index 294d79e67a..1b1fde3a20 100644 > --- a/src/eval.c > +++ b/src/eval.c > @@ -794,6 +794,12 @@ usage: (defvar SYMBOL &optional INITVALUE DOCSTRING) */) > if (!NILP (XCDR (tail)) && !NILP (XCDR (XCDR (tail)))) > error ("Too many arguments"); > Lisp_Object exp = XCAR (tail); > + /* If we're in a byte compilation, ensure the definition's > + symbols are stripped of their positions. */ > + if (symbols_with_pos_enabled > + && SYMBOL_WITH_POS_P (sym) > + && Ffboundp (Qbyte_run_strip_symbol_positions)) > + call1 (Qbyte_run_strip_symbol_positions, exp); > > tem = Fdefault_boundp (sym); > tail = XCDR (tail); > @@ -861,6 +867,14 @@ usage: (defconst SYMBOL INITVALUE [DOCSTRING]) */) > } > > Finternal__define_uninitialized_variable (sym, docstring); > + > + /* If we're in a byte compilation, ensure the definition's symbols > + are stripped of their positions. */ > + if (symbols_with_pos_enabled > + && SYMBOL_WITH_POS_P (sym) > + && Ffboundp (Qbyte_run_strip_symbol_positions)) > + call1 (Qbyte_run_strip_symbol_positions, XCAR (XCDR (args))); > + > tem = eval_sub (XCAR (XCDR (args))); > if (!NILP (Vpurify_flag)) > tem = Fpurecopy (tem); > > >> Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 13:20:50 2022 Received: (at 54079) by debbugs.gnu.org; 5 Mar 2022 18:20:50 +0000 Received: from localhost ([127.0.0.1]:49043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQZ1N-00072b-LN for submit@debbugs.gnu.org; Sat, 05 Mar 2022 13:20:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQZ1L-00072N-Sx for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 13:20:48 -0500 Received: from [2001:470:142:3::e] (port=34586 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nQZ1E-0007tA-86; Sat, 05 Mar 2022 13:20:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=m6bfS4XYCGEJLljUHTVr6QtBgo6WmHaM9cTPwcZdvXk=; b=DxhSQDtnlgZi CSs9rnstjTAYuadryLmrsQzIogon9EK5tijt9Gt08ZrRokvMfXaZpwQMjhntK2MLh/U35iVlH863j bxod3xbJ/osQ6ck/3XFZFB0iI+UfTs/OCl3ihnAoyWQeSQNAi0TJEWltQAty54CMrgRlZ6w7ust4I RGftDrARTd0Y1Fz+NGSUPC2gvt+6gHdJsn7KXsGXZ2yaROQF+eXAP5/Fpv8dRAnugFR1FDGX312kw gSaSRrhU6WjalWphqmjujDk9Of9CeVHBQ2r9r1ak5KOG+3CLfvz5N65lipwf1EyTBfn0I3I8J8AxY SWZmfu7+AuoV5FPxTCExxg==; Received: from [87.69.77.57] (port=1233 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nQZ0Y-0005vK-HS; Sat, 05 Mar 2022 13:20:33 -0500 Date: Sat, 05 Mar 2022 20:19:43 +0200 Message-Id: <83ilssgt34.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 5 Mar 2022 16:37:16 +0000) Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: michael_heerdegen@web.de, acm@muc.de, larsi@gnus.org, 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 5 Mar 2022 16:37:16 +0000 > From: Alan Mackenzie > Cc: acm@muc.de, 54079@debbugs.gnu.org, monnier@iro.umontreal.ca > > CHECK_SYMBOL (symbol); > + /* If we're in a byte compilation, ensure the definition's symbols > + are stripped of their positions. */ > + if (symbols_with_pos_enabled > + && SYMBOL_WITH_POS_P (symbol) > + && Ffboundp (Qbyte_run_strip_symbol_positions)) > + call1 (Qbyte_run_strip_symbol_positions, definition); The first two conditions should be in reverse order, for speedier code, shouldn't they? From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 14:00:59 2022 Received: (at 54079) by debbugs.gnu.org; 5 Mar 2022 19:00:59 +0000 Received: from localhost ([127.0.0.1]:49073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQZeF-00081z-5K for submit@debbugs.gnu.org; Sat, 05 Mar 2022 14:00:59 -0500 Received: from colin.muc.de ([193.149.48.1]:53300 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nQZeD-00081j-Fr for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 14:00:58 -0500 Received: (qmail 59763 invoked by uid 3782); 5 Mar 2022 19:00:50 -0000 Received: from acm.muc.de (p2e5d5265.dip0.t-ipconnect.de [46.93.82.101]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Mar 2022 20:00:49 +0100 Received: (qmail 6795 invoked by uid 1000); 5 Mar 2022 19:00:49 -0000 Date: Sat, 5 Mar 2022 19:00:49 +0000 To: Stefan Monnier Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Sat, Mar 05, 2022 at 12:57:09 -0500, Stefan Monnier wrote: > > I think this problem can only happen for defuns/defvars/defconts inside > > eval-when-compile or eval-and-compile. > > Would you try out the following patch, please, which I believe fixes the > > bug. > Any chance we could fix it in `bytecomp.el` by calling > `byte_run_strip_symbol_positions` before evaluating the contents of > those forms? I've spent quite a large part of the day trying to get that to work, without success. The point is, we want to strip the positions here only when we're writing the value to a defun/defvar/defconst. eval-when/and-compile doesn't know what its forms will be doing, and there's no easy way to find out - for example, there might be a defun in a nested eval-when/and-compile. Checking in the defun/defvar/defconst special forms is direct and economical. > Maybe we should have a function to check for the absence of > sympos which we could call (when in debugging mode only) from > defvar/defalias and friends, which could give us useful backtraces > showing where/when the sympos "leak"? That's an interesting idea. Such a function would differ from byte-run-strip-symbol-positions only a little bit. > Stefan [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 14:07:54 2022 Received: (at 54079) by debbugs.gnu.org; 5 Mar 2022 19:07:54 +0000 Received: from localhost ([127.0.0.1]:49094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQZkw-0008DH-3y for submit@debbugs.gnu.org; Sat, 05 Mar 2022 14:07:54 -0500 Received: from colin.muc.de ([193.149.48.1]:53511 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nQZku-0008D2-1u for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 14:07:52 -0500 Received: (qmail 65351 invoked by uid 3782); 5 Mar 2022 19:07:46 -0000 Received: from acm.muc.de (p2e5d5265.dip0.t-ipconnect.de [46.93.82.101]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 05 Mar 2022 20:07:45 +0100 Received: (qmail 6827 invoked by uid 1000); 5 Mar 2022 19:07:45 -0000 Date: Sat, 5 Mar 2022 19:07:45 +0000 To: Eli Zaretskii Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <83ilssgt34.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ilssgt34.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: michael_heerdegen@web.de, larsi@gnus.org, 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, Mar 05, 2022 at 20:19:43 +0200, Eli Zaretskii wrote: > > Date: Sat, 5 Mar 2022 16:37:16 +0000 > > From: Alan Mackenzie > > Cc: acm@muc.de, 54079@debbugs.gnu.org, monnier@iro.umontreal.ca > > > > CHECK_SYMBOL (symbol); > > + /* If we're in a byte compilation, ensure the definition's symbols > > + are stripped of their positions. */ > > + if (symbols_with_pos_enabled > > + && SYMBOL_WITH_POS_P (symbol) > > + && Ffboundp (Qbyte_run_strip_symbol_positions)) > > + call1 (Qbyte_run_strip_symbol_positions, definition); > The first two conditions should be in reverse order, for speedier > code, shouldn't they? Maybe. A slight slowdown would happen if the first condition was true whilst the second was not. Yes, that could happen whilst `require'ing a ..elc file, which will happen regularly. I'll swap them around. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 18:02:10 2022 Received: (at 54079) by debbugs.gnu.org; 5 Mar 2022 23:02:10 +0000 Received: from localhost ([127.0.0.1]:49366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQdPd-0007r8-Mv for submit@debbugs.gnu.org; Sat, 05 Mar 2022 18:02:09 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55964) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQdPc-0007le-0Q for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 18:02:08 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 124578067F; Sat, 5 Mar 2022 18:02:02 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A970A8001A; Sat, 5 Mar 2022 18:02:00 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646521320; bh=5Kr4exDVcoImOG6/emXsN/m/zGjHL+yKNs0BDUU4rkQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=KCPILXtIFUFTj9MMDBFq8DiycjFStJ1KVbHe942yLUVr7zLr3ymCROanEv2GsjZoC cLJDgeQnjh3cHW0hDC2m9Fg4i0/K621W8bNj4lYgurU/apLjiEVtwM65p/XOh2tmvv tr5KicQ6mMHlf8Hl92gf3c1dxE/P3FrSFSxtnmqt8uPJHTszfS3eqA6rKAC/Tlygrq w3K732PJzYd3H7sIJKdk4noL4rGBo3jObm4VbwBzc1qS0aGDLU0rVv5j7WzAlAwHje MZF6NRtIZvVjaQjNRmBRblaqqSzYh7v0OoDTD4jTy8omZOCshMpI0KHCOGJky/kq91 Bg9rutPNrRvPA== Received: from pastel (unknown [45.72.208.76]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 739D81202C5; Sat, 5 Mar 2022 18:02:00 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> Date: Sat, 05 Mar 2022 18:01:59 -0500 In-Reply-To: (Alan Mackenzie's message of "Sat, 5 Mar 2022 19:00:49 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.058 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > eval-when/and-compile doesn't know what its forms will be doing, and > there's no easy way to find out - for example, there might be a defun in > a nested eval-when/and-compile. I don't think we need to find out: whatever they do, they should do it on stripped symbols. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 05 21:19:17 2022 Received: (at 54079) by debbugs.gnu.org; 6 Mar 2022 02:19:18 +0000 Received: from localhost ([127.0.0.1]:49545 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQgUP-0002o9-NG for submit@debbugs.gnu.org; Sat, 05 Mar 2022 21:19:17 -0500 Received: from mout.web.de ([212.227.17.11]:51037) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nQgUM-0002nu-SL for 54079@debbugs.gnu.org; Sat, 05 Mar 2022 21:19:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1646533144; bh=fk7hh8+ODdeJPplQvv0UGHxlkTIeaO8Ff3wNU4esQYk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=rLhu56dwIAHj1vQVHQene2qEFpVo44rCAtHuDQUrWCJIn+Dqe3DWYSy14xpvBx125 IL6Pv1UP37HELi2ALE8qr3SMUsWS8KKo1gqabQdyl3m5X5XWBxVvuedx6mabBblUgc kBsSOQEvrgaCynXDfhEaUOQ4crdZIltr36YLD56Q= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb106 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MGgNU-1nMqjq09je-00DoYn; Sun, 06 Mar 2022 03:19:04 +0100 From: Michael Heerdegen To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> Date: Sun, 06 Mar 2022 03:19:02 +0100 In-Reply-To: (Alan Mackenzie's message of "Sat, 5 Mar 2022 16:37:16 +0000") Message-ID: <87k0d7257t.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:sDf/EuCCEsB3+oxwhcQ1bF6hF+WmXIrY3WvZ/MAXPvnBBwFWm3L MPj3rRehMYZamO/ksZZBOq5mrrlrZFXl/fnsHNhngcqGiMRFKVeSmJlYnh13CKUQ0rCDq4/ PbayefUeI+ERVQReShSaQ0ynQ1NRRYueYHFH+YINIlyELkPuCvkE34h4cmdLHnBqKjwTl6x NpENiYeCQMLDWgc5i8A7A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:F82PpDGaoKs=:MtRVGeTtPPwYjAEz6SQP5W Vm+kpP9OOcHh2UUKcJb3LcRFc/VKf36Je++CKLyq811nL22riSRLKyMTwHNdgYo4jwa3qQgi7 yy7KhLPOAQVmiTQqeyMRGOUBpyRxqtHmWnoslYeCs6FqOVSx/zv/NpWcpmaxOMISyHXIKZe+R WX0eW6QfotP2urJiDyJeKyr1x0EfXswH9EUbbUMG/d4Roqu5I04KG5P2dcYrDnkYE9dENaqY5 VcMCEyOTuLsKaS8zesQpLRNm1rFsfOmCDFuDGgCDGOHOxIDPeoD1+uh0ofR6/37EiHrcbhKwG R9C5bNM3829ESYSqh0Ww+REzUV3bfP4/Qxm1vPz3QRw39gUUCZBK4IK3HTckhrvAPIL1azuMU bfymD5MuZwcdhvS0f1nF1tgxx77ZIarac+Ta9EjssJOXl+Zz94ZV7xOz/9qGgG0vPzyv0Cc9U /jtwMDep9QL+BOACyI/qLuNqa//bS8lfyQ25FcRiAwEvmBaNKxbPgKv4/ZQEnlgzapiVTFE2I HEDVV8AzUSc55r6Pkv5k7tQK1gogkH800R5WQ719zvLmMDYGx4DBi9NdyAhyN1B8BlR70Gq6Y rSo1vyv4v5oQb3yUhCH822dUZCjH9iabWXwjhShYL5mExgh7b4pXEajKwLEfoeU/SBvylEfrr oxxjp5k+Y7RExunH981a5Ha5+wIRdmXKqPL/NwlIGOfutBuItkIXz+mTm3kbTyPOhCS5HjyWV kegAMWR1k7tR3SAOt5okJFLvTpV5fljQDWIUDRiOuR0CojmPhzyZOlglRBpVcgdnBKLm5zwPL oNVuxmGo9dURMDNbbEgBItYnSPdSEcQOJ8h4wvq1/BNSqcwzwbxv+cXVB3G3rVmtRt8XUznrC Bg2poVB8k/dGbhEk9s6DsY7BOBpP8kMKZdXN/TgMmKbR/rvm/cGF30DdftV4uSDB1vUj9lPqy /jza3uxu0G/8fdaZr2KmUjavw2JWjw6IFR9D/C+itom7rYN+0rS0FxLU5eh2r8aA/uPoziplT EPPXR679rPkJ2yZ93wQyntGNs3aw9Zrolvy4uXQkMS/Ou4XXxSBGRmDRevX1yNAsO3GwosQKA EUxMRVZ8vlpgbM= X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Alan Mackenzie writes: > > > (byte-compile-file > > > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > > > (require 'gnus-search) > Would you try out the following patch, please, which I believe fixes the > bug. > [...patch...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [212.227.17.11 listed in psbl.surriel.com] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael_heerdegen[at]web.de) 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [212.227.17.11 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 54079 Cc: Lars Ingebrigtsen , 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.7 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Alan Mackenzie writes: > > > (byte-compile-file > > > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > > > (require 'gnus-search) > Would you try out the following patch, please, which I believe fixes the > bug. > [...patch...] Content analysis details: (1.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [212.227.17.11 listed in wl.mailspike.net] 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [212.227.17.11 listed in psbl.surriel.com] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael_heerdegen[at]web.de) 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Alan Mackenzie writes: > > > (byte-compile-file > > > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > > > (require 'gnus-search) > Would you try out the following patch, please, which I believe fixes the > bug. > [...patch...] That fixed the above case - but unfortunately not the failing method dispatching for my register stuff after compiling some unrelated random files. Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 08 14:28:39 2022 Received: (at 54079) by debbugs.gnu.org; 8 Mar 2022 19:28:39 +0000 Received: from localhost ([127.0.0.1]:57964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRfVf-0004Xi-82 for submit@debbugs.gnu.org; Tue, 08 Mar 2022 14:28:39 -0500 Received: from colin.muc.de ([193.149.48.1]:60044 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nRfVb-0004XR-RJ for 54079@debbugs.gnu.org; Tue, 08 Mar 2022 14:28:37 -0500 Received: (qmail 57003 invoked by uid 3782); 8 Mar 2022 19:28:28 -0000 Received: from acm.muc.de (p4fe15889.dip0.t-ipconnect.de [79.225.88.137]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 08 Mar 2022 20:28:28 +0100 Received: (qmail 7554 invoked by uid 1000); 8 Mar 2022 19:28:28 -0000 Date: Tue, 8 Mar 2022 19:28:27 +0000 To: Michael Heerdegen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k0d7257t.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Lars Ingebrigtsen , 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Michael. On Sun, Mar 06, 2022 at 03:19:02 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > > > (byte-compile-file > > > > "/home/micha/software/emacs/lisp/emacs-lisp/cl-generic.el") > > > > (require 'gnus-search) > > Would you try out the following patch, please, which I believe fixes the > > bug. > > [...patch...] > That fixed the above case - but unfortunately not the failing method > dispatching for my register stuff after compiling some unrelated random > files. Sorry for not making more substantial progress on this bug. With the patch for bug #54248 in place (the bug you closed), does the following patch do anything for the current bug? diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 9be44a8d5a..fb9f70bd67 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -499,9 +499,10 @@ byte-compile-initial-macro-environment (byte-compile-new-defuns byte-compile-new-defuns)) (setf result - (byte-compile-eval + (byte-run-strip-symbol-positions + (byte-compile-eval (byte-compile-top-level - (byte-compile-preprocess form))))))) + (byte-compile-preprocess form)))))))) (list 'quote result)))) (eval-and-compile . ,(lambda (&rest body) (byte-compile-recurse-toplevel @@ -512,9 +513,10 @@ byte-compile-initial-macro-environment ;; or byte-compile-file-form. (let* ((print-symbols-bare t) ; Possibly redundant binding. (expanded - (macroexpand--all-toplevel - form - macroexpand-all-environment))) + (byte-run-strip-symbol-positions + (macroexpand--all-toplevel + form + macroexpand-all-environment)))) (eval expanded lexical-binding) expanded))))) (with-suppressed-warnings If not, could you possibly come up with a repeatable recipe for reproducing the bug? Or have you done this already? > Michael. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 08 14:53:19 2022 Received: (at 54079) by debbugs.gnu.org; 8 Mar 2022 19:53:19 +0000 Received: from localhost ([127.0.0.1]:57977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRftX-0005Cz-8Z for submit@debbugs.gnu.org; Tue, 08 Mar 2022 14:53:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34131) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRftV-0005Cl-DZ for 54079@debbugs.gnu.org; Tue, 08 Mar 2022 14:53:18 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ECBCE8062B; Tue, 8 Mar 2022 14:53:10 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D83C780009; Tue, 8 Mar 2022 14:53:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646769188; bh=O7z8RY6GpG7RE/xo2Jr/ZfpRTFqS/sjnAzuWytpDJDU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=gbDnAB8pP/VGPl4hNNAIun2hjIgVLC5PZxIMu9meKcC0RPP23YvUTVQa5g9DxqqGJ XJ8FKomGDfRjS+UfEfzb/y8O542XONMZzetvqv5W6UOyioeXnZL1vwr1DszlOKLgya 5ouOogCkWaxeM9QzxYq3zg+69R/oP7fw40ebY3s9VHvIcpmY0pbUQt3i2H6uKs6KKc xpIAqIfw8pCtcaV8dEpt+cELacbWSHSSY9e4V9mTt4RcI+4fc9deTvLO+/ZBdzEvOI Zz9Gzkq+W548VIkNR4CHG8O+FN10AkRx5bCR+fHOuWwa8BvtLkFoYKjXeCOzBBKkWv u4yqFVWKGzWiA== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A1EF31202C1; Tue, 8 Mar 2022 14:53:08 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> Date: Tue, 08 Mar 2022 14:53:07 -0500 In-Reply-To: (Alan Mackenzie's message of "Tue, 8 Mar 2022 19:28:27 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.058 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > index 9be44a8d5a..fb9f70bd67 100644 > --- a/lisp/emacs-lisp/bytecomp.el > +++ b/lisp/emacs-lisp/bytecomp.el > @@ -499,9 +499,10 @@ byte-compile-initial-macro-environment > (byte-compile-new-defuns > byte-compile-new-defuns)) > (setf result > - (byte-compile-eval > + (byte-run-strip-symbol-positions > + (byte-compile-eval > (byte-compile-top-level > - (byte-compile-preprocess form))))))) > + (byte-compile-preprocess form)))))))) I'd expect the reverse: strip first and then eval the result. Why should we not strip the form passed to `byte-compile-eval`? Does `byte-compile-top-level` already return a stripped form of code? And why bother stripping the result of `byte-compile-eval`? > @@ -512,9 +513,10 @@ byte-compile-initial-macro-environment > ;; or byte-compile-file-form. > (let* ((print-symbols-bare t) ; Possibly redundant binding. > (expanded > - (macroexpand--all-toplevel > - form > - macroexpand-all-environment))) > + (byte-run-strip-symbol-positions > + (macroexpand--all-toplevel > + form > + macroexpand-all-environment)))) > (eval expanded lexical-binding) > expanded))))) > (with-suppressed-warnings Fundamentally, `eval` should always strip before doing its job. Yes, I know, it might be a bit expensive, but we should probably define a local function in `bytecomp.el` which does strip+eval and use that instead of `eval` (both here and in `byte-compile-eval`). WDYT? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 08 15:48:33 2022 Received: (at 54079) by debbugs.gnu.org; 8 Mar 2022 20:48:33 +0000 Received: from localhost ([127.0.0.1]:58011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRgkz-0006eZ-6r for submit@debbugs.gnu.org; Tue, 08 Mar 2022 15:48:33 -0500 Received: from colin.muc.de ([193.149.48.1]:62161 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nRgkx-0006eK-DW for 54079@debbugs.gnu.org; Tue, 08 Mar 2022 15:48:32 -0500 Received: (qmail 8958 invoked by uid 3782); 8 Mar 2022 20:48:24 -0000 Received: from acm.muc.de (p4fe15889.dip0.t-ipconnect.de [79.225.88.137]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 08 Mar 2022 21:48:23 +0100 Received: (qmail 8225 invoked by uid 1000); 8 Mar 2022 20:48:23 -0000 Date: Tue, 8 Mar 2022 20:48:23 +0000 To: Stefan Monnier Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , acm@muc.de, Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Tue, Mar 08, 2022 at 14:53:07 -0500, Stefan Monnier wrote: > > diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el > > index 9be44a8d5a..fb9f70bd67 100644 > > --- a/lisp/emacs-lisp/bytecomp.el > > +++ b/lisp/emacs-lisp/bytecomp.el > > @@ -499,9 +499,10 @@ byte-compile-initial-macro-environment > > (byte-compile-new-defuns > > byte-compile-new-defuns)) > > (setf result > > - (byte-compile-eval > > + (byte-run-strip-symbol-positions > > + (byte-compile-eval > > (byte-compile-top-level > > - (byte-compile-preprocess form))))))) > > + (byte-compile-preprocess form)))))))) > I'd expect the reverse: strip first and then eval the result. > Why should we not strip the form passed to `byte-compile-eval`? It's an edge case either way, but the form being evaluated might be a `byte-compile', in which case it's (much) better to leave the positions in place during this operation. > Does `byte-compile-top-level` already return a stripped form of code? Compiled code is always stripped, at least since the weekend! > And why bother stripping the result of `byte-compile-eval`? Because it might be the result of evaluating a defun (or defvar or defconst). This was the situation which gave rise to the bug. > > @@ -512,9 +513,10 @@ byte-compile-initial-macro-environment > > ;; or byte-compile-file-form. > > (let* ((print-symbols-bare t) ; Possibly redundant binding. > > (expanded > > - (macroexpand--all-toplevel > > - form > > - macroexpand-all-environment))) > > + (byte-run-strip-symbol-positions > > + (macroexpand--all-toplevel > > + form > > + macroexpand-all-environment)))) > > (eval expanded lexical-binding) > > expanded))))) > > (with-suppressed-warnings > Fundamentally, `eval` should always strip before doing its job. Except when what it's evaluating is a defun, defmacrro, defsubst, etc. Then it would be better to evaluate SWPs (which would work, since we're inside a compilation, where enable-symbols-with-pos has been bound). But here EXPANDED has been stripped before being evaluated, so I'm not sure what you're saying here. > Yes, I know, it might be a bit expensive, but we should probably > define a local function in `bytecomp.el` which does strip+eval and use > that instead of `eval` (both here and in `byte-compile-eval`). WDYT? I don't think stripping is really all that expensive. There are one or two .el files in Emacs (ucs-normalize.el springs to mind) which have very large lists with vectors in them, yet they don't seem noticeably to slow down the Emacs build. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 08 16:03:24 2022 Received: (at 54079) by debbugs.gnu.org; 8 Mar 2022 21:03:24 +0000 Received: from localhost ([127.0.0.1]:58028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRgzM-00073L-7C for submit@debbugs.gnu.org; Tue, 08 Mar 2022 16:03:24 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64998) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRgzJ-000738-JJ for 54079@debbugs.gnu.org; Tue, 08 Mar 2022 16:03:22 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1C78F1001CB; Tue, 8 Mar 2022 16:03:15 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A2333100120; Tue, 8 Mar 2022 16:03:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646773393; bh=C0UMlKVrymdKlvY1AdKgPGT4KjguZZxzBbLcSzEpHUY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=dDkUdgaf3sbx6O9Iw6x0gRU8MBjz11+a0Caj3fp1/H3TPjrsnZ4U8tqxbkGamGGnE QVo/wOnNpy0JBFsrUj8f2KRAxtQyIDSww20wqi0wydSiGScXwc3Y+nRnVSJcyTx8Gz /KRdYOLk8O1gIOehccZF0BVgOZLeWX33wi+HiS1D3GytzzPaFD9bRSb14wYbmVuS/z p3H4yNBZSFkYWIxdObkqgZaLv+2I8kWDjADDSMhEzvUmVbLq+87XO5tdvmKu8pwaEo pZplbMpjoQo9BP+lw5Wk+i2ze6mSQiP+phNRhHyIlJgzy36z/uxmNfWodtSDd3xSLr X4exUbeNIXh9Q== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6CBD312022E; Tue, 8 Mar 2022 16:03:13 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> Date: Tue, 08 Mar 2022 16:03:12 -0500 In-Reply-To: (Alan Mackenzie's message of "Tue, 8 Mar 2022 20:48:23 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.046 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I'd expect the reverse: strip first and then eval the result. >> Why should we not strip the form passed to `byte-compile-eval`? > It's an edge case either way, but the form being evaluated might be a > `byte-compile', in which case it's (much) better to leave the positions > in place during this operation. I don't understand the scenario you're thinking of. Are you thinking of something like `(eval-when-compile (byte-compile ...))? Does that ever happen in real life? >> Does `byte-compile-top-level` already return a stripped form of code? > Compiled code is always stripped, at least since the weekend! OK, so no need to strip, go. >> And why bother stripping the result of `byte-compile-eval`? > Because it might be the result of evaluating a defun (or defvar or > defconst). AFAIK sympos should only appear within the compiler pipeline between the "read" and the "emit resulting bytecode". They may be passed to various functions and macros along the way, but I can't think of any scenario where they'd end up returned by `(byte-compile-)eval`. > This was the situation which gave rise to the bug. Could you give some details about how it played out? [ Either here or as a comment in the code. ] >> Fundamentally, `eval` should always strip before doing its job. > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. Why? > Then it would be better to evaluate SWPs (which would work, since we're > inside a compilation, where enable-symbols-with-pos has been bound). > But here EXPANDED has been stripped before being evaluated, so I'm not > sure what you're saying here. I was suggesting to move the strip from the computation of `expanded` to the `eval` call. >> Yes, I know, it might be a bit expensive, but we should probably >> define a local function in `bytecomp.el` which does strip+eval and use >> that instead of `eval` (both here and in `byte-compile-eval`). WDYT? > I don't think stripping is really all that expensive. There are one or > two .el files in Emacs (ucs-normalize.el springs to mind) which have > very large lists with vectors in them, yet they don't seem noticeably to > slow down the Emacs build. So maybe we should redefine `eval` as "strip and then eval"? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 08 23:10:31 2022 Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 04:10:31 +0000 Received: from localhost ([127.0.0.1]:58269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRneh-0002l3-Jx for submit@debbugs.gnu.org; Tue, 08 Mar 2022 23:10:31 -0500 Received: from mout.web.de ([212.227.15.14]:51543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nRnee-0002ko-W3 for 54079@debbugs.gnu.org; Tue, 08 Mar 2022 23:10:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1646799018; bh=oxv0tXSilZxEYJ4smxdxv1oi3kQiub67oRuG9NQwoks=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=OfekNC2cJwvO3GN8BCU7R2CBHR1gBCCmZJmGt8m6Ohn8Vjg5mNPKnCNCL4KW5/Agc w5gviKHa5GDNHDRdI1TQu95cTHQuJpmqaWNu02CCd8GkpKOtSRP+fESCkZnXbHjmpy EdtV7c5+GIjq0gMS6YBVzAUOlydUcXEa4mbV0xNs= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1Mav2l-1nzkp70LDH-00c3bj; Wed, 09 Mar 2022 05:10:18 +0100 From: Michael Heerdegen To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87bkz113hz.fsf@web.de> <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> Date: Wed, 09 Mar 2022 05:10:16 +0100 In-Reply-To: (Alan Mackenzie's message of "Tue, 8 Mar 2022 19:28:27 +0000") Message-ID: <87wnh3zryv.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:aUKmC+F6sVgaBvKV+8bb6vAn3e9+z/kKc5kuCweZkXzZ13evd8I BYM0RsurIpfcWLeI+m6DDd+5YEqguB6AFtylKF6q2ZgbpDJcBfGfuaqjUq3SkIN5r4sCNvm cKrNtXOgixLe/BexM1V//UnCSpHX2g46Nxl3ESirMl6yHLdZIu4jVXALEAVeZgU/zHyQ2HU R+yohvuJtdWQ+VeWiTgng== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:MqIeqM9v+y0=:06sIEo3o9Yd1epLC/aob2B OpDPwzDbFGsn1VJXanEabJPvY37xW702qgjfe6U/qz38wukF6e8W9Ied8AnXF70X/1/s9Icgz r6/cUhwg2CfxFW1YVUdyGw1rETgoNzU+0xZbyEzJHvr4gMNcwM5nPf4W9hhwb0YIyZLnUWo37 MPZ3JkUckx7ALu2zFAlDtc/YvMWbLc4ZJw+xMi/wbs5GR7zdomwmgG/xqIVtzeQkl/gY+7YWz USrlfRtYXlSU3DvxNg+pUEgwR3+E5YKbsHENeOatv8F5UuHlI4E/YdQ4Zk+9qt+NjAERYXqqU M13loBwKS1f2iELbfL6MiC2zLo7+KA1Y+CiMZU6NM8RhS/5jbbegMSBWnHTD9V4HLIUzb4d/Q z82sjCD9znkWWjv1upVzKcSmerg8qlwHg5L91jndSIebrt6w0cE0QgUMO1/slB3FAOLWoA2MH oKqX7ASAlaj7HMCtXSlkSJb/GhK4t8p3Ww04R7iQe/z0PoyWwCC+Utbv2pxthdQhAQY2MEt2k aTy1UmImraagQmsNDxfjMKuugf+uCo9EJnb3G212YVPnZkfSnWKp2R244Q37pTqRt1ptx8BV5 WCWnioZl1B1HMs83QCCcl8BhOe4OvbcLz2rG1hL5WZN/eIwqvg3wwtC93TJBKYBTusrnuiPF7 kei2Xnl3+W8kXJA+unUdgLWe8DaOhRcMscwipm0QERlHr4vsFGKDut6QIyJL+QtVYYxSlfD/N fCD8GsT4wYaH25hsVO0GBi8NVLXd6IZXyNbjQJBebSA2sLebLgv88imZ5CUYwMvaSDpfv5kBi vswKA6jnpExkNC3TIERHgCwwiTdlw92OGAZiNp/mPhWNEpbwKrCUhwmMzOSraahZuKdGcGygZ 7C5A7MBk/FTkNABfwueyjeUeYy2hhetB1AZHbpwGsHL5x4uNgVhq51RhMX06MLheOKO4OiOCS KBl2iIQjG+6/WSAi/LTcTrRl3cZ4ULcChriE4bUn7FSwWYtI+4FnIsGnJnXZeKzPZjdK4IoM9 slRp8Cd4gfX3rKv6LUfgwuKUE9XW2yl7SilN8Bvjcz0OvdwqI67GJsWebbeU2xO3zfaMOzyz1 TsJdN+T5GkUflo= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 54079 Cc: Lars Ingebrigtsen , 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Alan Mackenzie writes: > With the patch for bug #54248 in place (the bug you closed), does the > following patch do anything for the current bug? Could be...I quickly tried several times and the issue didn't show up. But I will have to use the patch for a while to be sure. Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 09 12:29:38 2022 Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 17:29:38 +0000 Received: from localhost ([127.0.0.1]:60633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS082-0003JE-CI for submit@debbugs.gnu.org; Wed, 09 Mar 2022 12:29:38 -0500 Received: from colin.muc.de ([193.149.48.1]:40049 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nS081-0003Ij-3A for 54079@debbugs.gnu.org; Wed, 09 Mar 2022 12:29:37 -0500 Received: (qmail 93262 invoked by uid 3782); 9 Mar 2022 17:29:30 -0000 Received: from acm.muc.de (p4fe15624.dip0.t-ipconnect.de [79.225.86.36]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 09 Mar 2022 18:29:29 +0100 Received: (qmail 5635 invoked by uid 1000); 9 Mar 2022 17:29:29 -0000 Date: Wed, 9 Mar 2022 17:29:29 +0000 To: Michael Heerdegen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> <87wnh3zryv.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wnh3zryv.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: acm@muc.de, Lars Ingebrigtsen , 54079@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Michael. On Wed, Mar 09, 2022 at 05:10:16 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > With the patch for bug #54248 in place (the bug you closed), does the > > following patch do anything for the current bug? > Could be...I quickly tried several times and the issue didn't show up. > But I will have to use the patch for a while to be sure. OK. So the longer I hear nothing from you, the better. ;-) Thanks! > Thanks, > Michael. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 09 12:43:06 2022 Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 17:43:06 +0000 Received: from localhost ([127.0.0.1]:60672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS0L4-0003i9-Dt for submit@debbugs.gnu.org; Wed, 09 Mar 2022 12:43:06 -0500 Received: from colin.muc.de ([193.149.48.1]:40455 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nS0L2-0003hT-0b for 54079@debbugs.gnu.org; Wed, 09 Mar 2022 12:43:04 -0500 Received: (qmail 2165 invoked by uid 3782); 9 Mar 2022 17:42:57 -0000 Received: from acm.muc.de (p4fe15624.dip0.t-ipconnect.de [79.225.86.36]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 09 Mar 2022 18:42:56 +0100 Received: (qmail 5677 invoked by uid 1000); 9 Mar 2022 17:42:56 -0000 Date: Wed, 9 Mar 2022 17:42:56 +0000 To: Stefan Monnier Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Tue, Mar 08, 2022 at 16:03:12 -0500, Stefan Monnier wrote: > >> I'd expect the reverse: strip first and then eval the result. > >> Why should we not strip the form passed to `byte-compile-eval`? > > It's an edge case either way, but the form being evaluated might be a > > `byte-compile', in which case it's (much) better to leave the positions > > in place during this operation. > I don't understand the scenario you're thinking of. > Are you thinking of something like `(eval-when-compile (byte-compile ...))? Yes. > Does that ever happen in real life? Probably exceedingly seldomly. What's to be gained by not catering to this unusual case? What do we lose? > >> Does `byte-compile-top-level` already return a stripped form of code? > > Compiled code is always stripped, at least since the weekend! > OK, so no need to strip, go. > >> And why bother stripping the result of `byte-compile-eval`? > > Because it might be the result of evaluating a defun (or defvar or > > defconst). > AFAIK sympos should only appear within the compiler pipeline between the > "read" and the "emit resulting bytecode". They may be passed to various > functions and macros along the way, but I can't think of any scenario > where they'd end up returned by `(byte-compile-)eval`. > > This was the situation which gave rise to the bug. > Could you give some details about how it played out? > [ Either here or as a comment in the code. ] Michael byte compiled cl-generic.el. This created cl-generic.elc correctly, but also left uncompiled forms in the function cells of the symbols defun'd inside an eval-{when,and}-compile. These forms contained symbols with positions. > >> Fundamentally, `eval` should always strip before doing its job. > > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. > Why? Because that evaluated form might later be byte compiled, and the SWPs will be needed for that. > > Then it would be better to evaluate SWPs (which would work, since we're > > inside a compilation, where enable-symbols-with-pos has been bound). > > But here EXPANDED has been stripped before being evaluated, so I'm not > > sure what you're saying here. > I was suggesting to move the strip from the computation of `expanded` to > the `eval` call. > >> Yes, I know, it might be a bit expensive, but we should probably > >> define a local function in `bytecomp.el` which does strip+eval and use > >> that instead of `eval` (both here and in `byte-compile-eval`). WDYT? > > I don't think stripping is really all that expensive. There are one or > > two .el files in Emacs (ucs-normalize.el springs to mind) which have > > very large lists with vectors in them, yet they don't seem noticeably to > > slow down the Emacs build. > So maybe we should redefine `eval` as "strip and then eval"? Isn't `eval' already complicated enough, with lexical-binding as an argument? Stripping SWPs is not a part of evaluation. It is something else. eval should "do one thing and do it well". > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 09 13:06:22 2022 Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 18:06:22 +0000 Received: from localhost ([127.0.0.1]:60694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS0ha-0004Nn-Hk for submit@debbugs.gnu.org; Wed, 09 Mar 2022 13:06:22 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54477) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS0hY-0004NZ-Ey for 54079@debbugs.gnu.org; Wed, 09 Mar 2022 13:06:21 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 454ED10020C; Wed, 9 Mar 2022 13:06:14 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A818C100009; Wed, 9 Mar 2022 13:06:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646849172; bh=IdK0nG4WzjzKA2Sn4Gz2AQwdwpXraZITxF0/vH3hhis=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=L6s0gprZ+zgwFJWilng4rfA7qBhtQOv+6R85bLPmY/spiFQjhSb+dnH0kTPZ6wqQ4 Y3PKRwgtK0W0+11aGwhwkeXapaFO9RHb2Znkvd2jjl6nXcwff5YUS7anWfgRckL70j HtQVLWH+QJyge2ttdzVENip7RwE0pxE1rD9UwZSrWNyNn20R5LHAw8XLMSXassI2uL JgnMd4zRmUDymqBAZSQ50ilULS7FqArPUH0wz3sfuD2K32U3u3qwNWzPBg0BI4ocXl brDedQybMdwwykYUMqdSMoeKWp9eNtJLfUK8C1HUp08zRYuVjeWwTPYTaYjRXVxN7Y AtK6IRbxfBKVw== Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9520E120263; Wed, 9 Mar 2022 13:06:12 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> Date: Wed, 09 Mar 2022 13:06:11 -0500 In-Reply-To: (Alan Mackenzie's message of "Wed, 9 Mar 2022 17:42:56 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.174 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I don't understand the scenario you're thinking of. >> Are you thinking of something like `(eval-when-compile (byte-compile ...))? > Yes. >> Does that ever happen in real life? > Probably exceedingly seldomly. > What's to be gained by not catering to this unusual case? What do we > lose? We lose making it work right for the 99% other cases that *do* occur? >> >> And why bother stripping the result of `byte-compile-eval`? >> > Because it might be the result of evaluating a defun (or defvar or >> > defconst). > >> AFAIK sympos should only appear within the compiler pipeline between the >> "read" and the "emit resulting bytecode". They may be passed to various >> functions and macros along the way, but I can't think of any scenario >> where they'd end up returned by `(byte-compile-)eval`. > >> > This was the situation which gave rise to the bug. > >> Could you give some details about how it played out? >> [ Either here or as a comment in the code. ] > > Michael byte compiled cl-generic.el. This created cl-generic.elc > correctly, but also left uncompiled forms in the function cells of the > symbols defun'd inside an eval-{when,and}-compile. These forms > contained symbols with positions. Hmm... we're talking about stripping the result of `byte-compile-eval`. This function is only used for `eval-when-compile`, not `eval-and-compile`. And nothing in your above description indicates that the sympos appeared in the resulting value of `eval-when-compile` (as opposed to appearing in the slot of functions and variables that were set during the course of the evaluation). >> >> Fundamentally, `eval` should always strip before doing its job. >> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. >> Why? > Because that evaluated form might later be byte compiled, and the SWPs > will be needed for that. I don't understand the scenario you're thinking of. Are thinking of a case like: - something causes the execution of (eval '(defun foo ...)) - the user types `M-x byte-compile RET foo RET` If so, then: - I don't think we should care about this case because it's extremely rare and fundamentally broken (the symbol's function cell contains a function *value* (i.e. a closure) and not a function's source code, so in general we need `byte-compile--reify-function` which implements a heuristic to go back to something like a source form, which can break in various ways in corner cases). - If we don't strip before calling the `M-x byte-compile` then the code may/will bisbehave because of the presence of the sympos. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 09 15:33:08 2022 Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 20:33:09 +0000 Received: from localhost ([127.0.0.1]:60853 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS2zc-0008Ls-JU for submit@debbugs.gnu.org; Wed, 09 Mar 2022 15:33:08 -0500 Received: from colin.muc.de ([193.149.48.1]:45175 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nS2za-0008LN-LW for 54079@debbugs.gnu.org; Wed, 09 Mar 2022 15:33:07 -0500 Received: (qmail 22385 invoked by uid 3782); 9 Mar 2022 20:32:59 -0000 Received: from acm.muc.de (p4fe15624.dip0.t-ipconnect.de [79.225.86.36]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 09 Mar 2022 21:32:59 +0100 Received: (qmail 8990 invoked by uid 1000); 9 Mar 2022 20:32:59 -0000 Date: Wed, 9 Mar 2022 20:32:59 +0000 To: Stefan Monnier Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Wed, Mar 09, 2022 at 13:06:11 -0500, Stefan Monnier wrote: > >> I don't understand the scenario you're thinking of. > >> Are you thinking of something like `(eval-when-compile (byte-compile ...))? > > Yes. > >> Does that ever happen in real life? > > Probably exceedingly seldomly. > > What's to be gained by not catering to this unusual case? What do we > > lose? > We lose making it work right for the 99% other cases that *do* occur? How would it not work right for such a case? Can you give an example? > >> >> And why bother stripping the result of `byte-compile-eval`? > >> > Because it might be the result of evaluating a defun (or defvar or > >> > defconst). > >> AFAIK sympos should only appear within the compiler pipeline between the > >> "read" and the "emit resulting bytecode". They may be passed to various > >> functions and macros along the way, but I can't think of any scenario > >> where they'd end up returned by `(byte-compile-)eval`. > >> > This was the situation which gave rise to the bug. > >> Could you give some details about how it played out? > >> [ Either here or as a comment in the code. ] > > Michael byte compiled cl-generic.el. This created cl-generic.elc > > correctly, but also left uncompiled forms in the function cells of the > > symbols defun'd inside an eval-{when,and}-compile. These forms > > contained symbols with positions. > Hmm... we're talking about stripping the result of `byte-compile-eval`. > This function is only used for `eval-when-compile`, not `eval-and-compile`. > And nothing in your above description indicates that the sympos appeared > in the resulting value of `eval-when-compile` (as opposed to appearing > in the slot of functions and variables that were set during the course > of the evaluation). OK, sorry, I was mistaken. These forms with SWPs arose from evan-AND-compile, which doesn't use byte-compile-eval. > >> >> Fundamentally, `eval` should always strip before doing its job. > >> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. > >> Why? > > Because that evaluated form might later be byte compiled, and the SWPs > > will be needed for that. > I don't understand the scenario you're thinking of. > Are thinking of a case like: > - something causes the execution of (eval '(defun foo ...)) > - the user types `M-x byte-compile RET foo RET` Sorry again, I've lost the thread here. Weren't we talking about eval-{when,and}-compile, not eval? Inside these two special forms, we should preserve the SWPs as long as possible (i.e. as long as they won't cause any errors). > If so, then: > - I don't think we should care about this case because it's extremely > rare and fundamentally broken (the symbol's function cell contains > a function *value* (i.e. a closure) and not a function's source code, > so in general we need `byte-compile--reify-function` which implements > a heuristic to go back to something like a source form, which can > break in various ways in corner cases). Really? After evaluating a defun, etc., we have a lisp form in the function cell, which may be a closure. The function byte-compile compiles an arbitrary form, doesn't it? > - If we don't strip before calling the `M-x byte-compile` then the code > may/will bisbehave because of the presence of the sympos. How? byte-compile is designed to use SWPs. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 09 17:04:19 2022 Received: (at 54079) by debbugs.gnu.org; 9 Mar 2022 22:04:19 +0000 Received: from localhost ([127.0.0.1]:60984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS4Pn-0004cz-9W for submit@debbugs.gnu.org; Wed, 09 Mar 2022 17:04:19 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nS4Ph-0004cf-8l for 54079@debbugs.gnu.org; Wed, 09 Mar 2022 17:04:14 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 472EC8012F; Wed, 9 Mar 2022 17:04:03 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 77277802FF; Wed, 9 Mar 2022 17:04:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1646863441; bh=COpiJ7DR8BwqOfBUPX+p9vcnIjYiW7BmmTAR1Gw2aF4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=W41vY1GRBMdfxaCQCQqusmhN04Hm9IVRFzsSTLjMBZYsPNbjpedimM3EG1BWXquir /tdCayEClZI6SGYILV8JP2obeIf09M7yycvM7pR1Gxaf/6JOEs5tFg4u3yWBZjuxoh IPbZGHmkLYOs2+pOBa5zehoIxNJ+C9GcTkCaWfAoRmqUsomBmfdkCnHHCaM4sYKFMU c76duFV1f1gDjUuOXNHE+TtCafm0RnJm5F7Npl/n4TewBsd0d3EUpCniFa64JXFjFj tZ6OdR+Wt6BrjY5JpeN6KZdd8BdOL8iMtpRxEn8wlDl3aGHaPk9zGVQoZPthktYby1 ls1hQ0bVILh7g== Received: from alfajor (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5D5D81202B9; Wed, 9 Mar 2022 17:04:01 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> Date: Wed, 09 Mar 2022 17:04:00 -0500 In-Reply-To: (Alan Mackenzie's message of "Wed, 9 Mar 2022 20:32:59 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.208 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Alan Mackenzie [2022-03-09 20:32:59] wrote: > On Wed, Mar 09, 2022 at 13:06:11 -0500, Stefan Monnier wrote: >> >> I don't understand the scenario you're thinking of. >> >> Are you thinking of something like `(eval-when-compile (byte-compile ...))? >> > Yes. >> >> Does that ever happen in real life? >> > Probably exceedingly seldomly. >> > What's to be gained by not catering to this unusual case? What do we >> > lose? > >> We lose making it work right for the 99% other cases that *do* occur? > How would it not work right for such a case? Can you give an example? I'm not sure what "such a case" you're thinking of. But in general, evaluation of code doesn't expect symbols to have positions: it may test `eq` between symbols and it may be run without having the magical `symbols-with-pos-enabled`. So as a general rule we should strip symbols before we pass it to `eval`. >> >> >> And why bother stripping the result of `byte-compile-eval`? >> >> > Because it might be the result of evaluating a defun (or defvar or >> >> > defconst). > >> >> AFAIK sympos should only appear within the compiler pipeline between the >> >> "read" and the "emit resulting bytecode". They may be passed to various >> >> functions and macros along the way, but I can't think of any scenario >> >> where they'd end up returned by `(byte-compile-)eval`. > >> >> > This was the situation which gave rise to the bug. > >> >> Could you give some details about how it played out? >> >> [ Either here or as a comment in the code. ] > >> > Michael byte compiled cl-generic.el. This created cl-generic.elc >> > correctly, but also left uncompiled forms in the function cells of the >> > symbols defun'd inside an eval-{when,and}-compile. These forms >> > contained symbols with positions. > >> Hmm... we're talking about stripping the result of `byte-compile-eval`. >> This function is only used for `eval-when-compile`, not `eval-and-compile`. >> And nothing in your above description indicates that the sympos appeared >> in the resulting value of `eval-when-compile` (as opposed to appearing >> in the slot of functions and variables that were set during the course >> of the evaluation). > > OK, sorry, I was mistaken. These forms with SWPs arose from > evan-AND-compile, which doesn't use byte-compile-eval. OK, now can we get back to the question: And why bother stripping the result of `byte-compile-eval`? >> >> >> Fundamentally, `eval` should always strip before doing its job. >> >> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. >> >> Why? >> > Because that evaluated form might later be byte compiled, and the SWPs >> > will be needed for that. > >> I don't understand the scenario you're thinking of. >> Are thinking of a case like: > >> - something causes the execution of (eval '(defun foo ...)) >> - the user types `M-x byte-compile RET foo RET` > > Sorry again, I've lost the thread here. Weren't we talking about > eval-{when,and}-compile, not eval? No, the text you cited even included my original statement: Fundamentally, `eval` should always strip before doing its job. > Inside these two special forms, we should preserve the SWPs as long as > possible (i.e. as long as they won't cause any errors). We should preserve them while macroexpanding and compiling their contents, yes, but then we should strip the symbols before we pass the result to `eval`. >> If so, then: >> - I don't think we should care about this case because it's extremely >> rare and fundamentally broken (the symbol's function cell contains >> a function *value* (i.e. a closure) and not a function's source code, >> so in general we need `byte-compile--reify-function` which implements >> a heuristic to go back to something like a source form, which can >> break in various ways in corner cases). > > Really? After evaluating a defun, etc., we have a lisp form in the > function cell, which may be a closure. A closure is not "a Lisp form". In general passing a closure to `eval` may signal an error because it may very well be an invalid form. The body of a closure is a Lips form, yes. But that's not what's inside a symbol's function cell. > The function byte-compile compiles an arbitrary form, doesn't it? Try the following: ;; -*- lexical-binding: t -*- (let ((x 0)) (defun my-inc1 () (interactive) (message "x=%S" (setq x (1+ x)))) (defun my-inc2 () (interactive) (message "x=%S" (setq x (1+ x))))) load that file. Then try `M-x my-inc1` and `M-x my-inc2` and you'll see that they correctly increment the same counter. Now do `M-: (byte-compile 'my-inc1)`. And try `M-x my-inc1` and `M-x my-inc2` and you'll see that suddenly they each have their own counter. That's because it's one of the corner cases that `byte-compile--reify-function` can't handle correctly. >> - If we don't strip before calling the `M-x byte-compile` then the code >> may/will bisbehave because of the presence of the sympos. > How? byte-compile is designed to use SWPs. The misbehavior I'm referring to is what happens when you call the function before you byte-compile it (or, more likely, when you never end up byte-compiling it), because the presence of sympos in the function will mess up its semantics (because `symbols-with-pos-enabled` won't be set any more when it's called). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 11 17:01:52 2022 Received: (at 54079) by debbugs.gnu.org; 11 Mar 2022 22:01:52 +0000 Received: from localhost ([127.0.0.1]:38555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nSnKa-0004km-Ap for submit@debbugs.gnu.org; Fri, 11 Mar 2022 17:01:52 -0500 Received: from colin.muc.de ([193.149.48.1]:13547 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nSnKY-0004kX-1K for 54079@debbugs.gnu.org; Fri, 11 Mar 2022 17:01:51 -0500 Received: (qmail 20729 invoked by uid 3782); 11 Mar 2022 22:01:42 -0000 Received: from acm.muc.de (p4fe157a5.dip0.t-ipconnect.de [79.225.87.165]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 11 Mar 2022 23:01:42 +0100 Received: (qmail 9193 invoked by uid 1000); 11 Mar 2022 22:01:41 -0000 Date: Fri, 11 Mar 2022 22:01:41 +0000 To: Stefan Monnier Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87k0d7257t.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , acm@muc.de, Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Wed, Mar 09, 2022 at 17:04:00 -0500, Stefan Monnier wrote: > Alan Mackenzie [2022-03-09 20:32:59] wrote: > > On Wed, Mar 09, 2022 at 13:06:11 -0500, Stefan Monnier wrote: > >> >> I don't understand the scenario you're thinking of. > >> >> Are you thinking of something like `(eval-when-compile (byte-compile ...))? > >> > Yes. > >> >> Does that ever happen in real life? > >> > Probably exceedingly seldomly. > >> > What's to be gained by not catering to this unusual case? What do we > >> > lose? > >> We lose making it work right for the 99% other cases that *do* occur? > > How would it not work right for such a case? Can you give an example? > I'm not sure what "such a case" you're thinking of. One of the "99% other cases that *do* occur" that you referred to in your previous paragraph. You say that these wouldn't "work right". I'm asking you for an example of such a "not working right". > But in general, evaluation of code doesn't expect symbols to have > positions: The evaluation is completely indifferent to the SWPs, when symbols-with-pos-enabled is t. This is the case whilst eval-{when,and}-compile is being evaluated during a compilation. > ... it may test `eq` between symbols and it may be run without having > the magical `symbols-with-pos-enabled`. I've lost the thread here. What scenario are you considering? I thought we were talking only about the `eval' within eval-{when,and}-compile. > So as a general rule we should strip symbols before we pass it to `eval`. I don't see this, due to all the confusion we're experiencing. As a general rule, within byte compilation, symbol stripping should be postponed as long as possible whilst a compilation of the form is still possible. But, looking at the code, I don't think byte-compile binds symbols-with-pos-enabled to t. This could be a bug. > >> >> >> And why bother stripping the result of `byte-compile-eval`? > >> >> > Because it might be the result of evaluating a defun (or defvar or > >> >> > defconst). > >> >> AFAIK sympos should only appear within the compiler pipeline between the > >> >> "read" and the "emit resulting bytecode". They may be passed to various > >> >> functions and macros along the way, but I can't think of any scenario > >> >> where they'd end up returned by `(byte-compile-)eval`. > >> >> > This was the situation which gave rise to the bug. > >> >> Could you give some details about how it played out? > >> >> [ Either here or as a comment in the code. ] > >> > Michael byte compiled cl-generic.el. This created cl-generic.elc > >> > correctly, but also left uncompiled forms in the function cells of the > >> > symbols defun'd inside an eval-{when,and}-compile. These forms > >> > contained symbols with positions. > >> Hmm... we're talking about stripping the result of `byte-compile-eval`. > >> This function is only used for `eval-when-compile`, not `eval-and-compile`. > >> And nothing in your above description indicates that the sympos appeared > >> in the resulting value of `eval-when-compile` (as opposed to appearing > >> in the slot of functions and variables that were set during the course > >> of the evaluation). > > OK, sorry, I was mistaken. These forms with SWPs arose from > > evan-AND-compile, which doesn't use byte-compile-eval. > OK, now can we get back to the question: > And why bother stripping the result of `byte-compile-eval`? (This is in eval-when-compile only.) That result may contain SWPs. For example: (eval-when-compile (cons 'foo 'bar)) .. I don't think the stripping happens anywhere else, though I might be mistaken, here. > >> >> >> Fundamentally, `eval` should always strip before doing its job. > >> >> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc. > >> >> Why? > >> > Because that evaluated form might later be byte compiled, and the SWPs > >> > will be needed for that. > >> I don't understand the scenario you're thinking of. > >> Are thinking of a case like: > >> - something causes the execution of (eval '(defun foo ...)) > >> - the user types `M-x byte-compile RET foo RET` > > Sorry again, I've lost the thread here. Weren't we talking about > > eval-{when,and}-compile, not eval? > No, the text you cited even included my original statement: > Fundamentally, `eval` should always strip before doing its job. You mean, by "always", you meant ALWAYS??? I understood you to mean "always, when in the context of eval-{when,and}-compile". If we're not inside a compilation, and thus there're no SWPs hanging around, stripping symbols from an expression will just mean a loss of time for a null operation. > > Inside these two special forms, we should preserve the SWPs as long as > > possible (i.e. as long as they won't cause any errors). > We should preserve them while macroexpanding and compiling their > contents, yes, but then we should strip the symbols before we pass the > result to `eval`. At the moment, I disagree with you. I don't think you have given an example of a form FOO which will only work if stripping is done before evaluation in (eval-when-compile FOO) or (eval-and-compile FOO) .. At the moment, I still think it is better to strip the positions after the evaluation. > >> If so, then: > >> - I don't think we should care about this case because it's extremely > >> rare and fundamentally broken (the symbol's function cell contains > >> a function *value* (i.e. a closure) and not a function's source code, > >> so in general we need `byte-compile--reify-function` which implements > >> a heuristic to go back to something like a source form, which can > >> break in various ways in corner cases). > > Really? After evaluating a defun, etc., we have a lisp form in the > > function cell, which may be a closure. > A closure is not "a Lisp form". In general passing a closure to `eval` > may signal an error because it may very well be an invalid form. > The body of a closure is a Lisp form, yes. But that's not what's inside > a symbol's function cell. > > The function byte-compile compiles an arbitrary form, doesn't it? > Try the following: > ;; -*- lexical-binding: t -*- > (let ((x 0)) > (defun my-inc1 () > (interactive) > (message "x=%S" (setq x (1+ x)))) > (defun my-inc2 () > (interactive) > (message "x=%S" (setq x (1+ x))))) > load that file. Then try `M-x my-inc1` and `M-x my-inc2` and you'll see > that they correctly increment the same counter. > Now do `M-: (byte-compile 'my-inc1)`. > And try `M-x my-inc1` and `M-x my-inc2` and you'll see that suddenly > they each have their own counter. > That's because it's one of the corner cases that > `byte-compile--reify-function` can't handle correctly. > >> - If we don't strip before calling the `M-x byte-compile` then the code > >> may/will bisbehave because of the presence of the sympos. > > How? byte-compile is designed to use SWPs. > The misbehavior I'm referring to is what happens when you call the > function before you byte-compile it (or, more likely, when you never end > up byte-compiling it), because the presence of sympos in the function > will mess up its semantics (because `symbols-with-pos-enabled` won't be > set any more when it's called). I'm puzzled. Are we still talking about eval-{when,and}-compile, here? If so, how can a form with SWPs get into a symbol's function cell? The positions are stripped inside the e-w/a-compile. If not, the only function which produces SWPs is read-positioning-symbols (in lread.c). (There are other functions which _can_ produce SWPs, but they're used only by the compiler, I think.) read-positioning-symbols is called only by the byte compiler, so how can an uncompiled form with SWPs get into a symbol's function cell? I think the only answer to either of the above two paragraphs is a bug. Ah, maybe not. I think you're thinking of something like (eval-when-compile (fset 'foo '(defun bar ....))) , where SWPs will escape into foo. Again, this is presumably a vanishingly unlikely thing to write, except for the writing of test suites. ;-) Maybe we will need to make strip-symbol-positions available to (advanced) users, after all (having renamed it from byte-run-strip-symbol-positions). > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 11 23:24:02 2022 Received: (at 54079) by debbugs.gnu.org; 12 Mar 2022 04:24:02 +0000 Received: from localhost ([127.0.0.1]:38956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nStIQ-00087Y-0j for submit@debbugs.gnu.org; Fri, 11 Mar 2022 23:24:02 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nStIN-00086z-So for 54079@debbugs.gnu.org; Fri, 11 Mar 2022 23:24:00 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ED0258051E; Fri, 11 Mar 2022 23:23:53 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E563C802B7; Fri, 11 Mar 2022 23:23:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1647059031; bh=wVa+IGET3DORLjBd397nifoRzQ7qb7E5hwzk2dfwfFI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pMF41OaAtCbFwEJdW+P3jEPY4xA5RyMcyD2TJd68wldPazKdW9YSSZloNCl8ieyKi N1lZMyQMhCl3x4TL14EmqlTrU0FIyNLPoK+gW5lD8x2opcpy6dg0dpEy/c/3Sr/WjR oUBnihOCDqV79I89tcR7l/6MpN9EGRdxb5T1N0iN8M2qszfezN8oAdYEvabW9ExmN2 UHDg7sdbuLKslUAA+vBYnO4MjZe43NTFUfq5/rK6qXhk1HNZVPsHz787Ygoz3WsvKE k6ELFxKpacodFIAyuSpDmxWP3oMFDk4jD3czlr6jE0+U0aLwRawRTPamizZs9G4VZe 21gHD6M+gidGA== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AC0AC120235; Fri, 11 Mar 2022 23:23:51 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87k0d7257t.fsf@web.de> Date: Fri, 11 Mar 2022 23:23:50 -0500 In-Reply-To: (Alan Mackenzie's message of "Fri, 11 Mar 2022 22:01:41 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.058 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I'm not sure what "such a case" you're thinking of. > > One of the "99% other cases that *do* occur" that you referred to in your > previous paragraph. You say that these wouldn't "work right". I'm > asking you for an example of such a "not working right". (defalias 'FOO BAR) >> But in general, evaluation of code doesn't expect symbols to have >> positions: > > The evaluation is completely indifferent to the SWPs, when > symbols-with-pos-enabled is t. While evaluating (defalias 'FOO BAR) everything will be dandy. But when you later call FOO while `symbols-with-pos-enabled` is not t anymore, then things go haywire. Same with (put FOO BAR (lambda ...)) or (add-hook FOO (lambda ...)) or (setcdr FOO (lambda ...))) or ... Of course, similar thing will go wrong without `lambda` because for example (setq FOO 'bar) will set FOO to `bar`-with-pos, so when you later compare FOO to `bar` you will find that `eq` will say nil. Etc... the list goes on and on. >> ... it may test `eq` between symbols and it may be run without having >> the magical `symbols-with-pos-enabled`. > I've lost the thread here. What scenario are you considering? I thought > we were talking only about the `eval' within eval-{when,and}-compile. Whatever appears in the code passed through `eval-{when,and}-compile` can survive that code, so the fact that `symbols-with-pos-enabled` is non-nil while evaluating it doesn't make it correct. >> So as a general rule we should strip symbols before we pass it to `eval`. > I don't see this, due to all the confusion we're experiencing. As a > general rule, within byte compilation, symbol stripping should be > postponed as long as possible whilst a compilation of the form is still > possible. `eval` is exactly this "as long as possible" point where we know the code won't be compiled because it's about to be interpreted. > But, looking at the code, I don't think byte-compile binds > symbols-with-pos-enabled to t. This could be a bug. Maybe not: it has no reason to presume that its argument has positions. If it does, then it must be because the caller explicitly arranged for it to happen and so the caller could be in charge of binding that variable. >> And why bother stripping the result of `byte-compile-eval`? > > (This is in eval-when-compile only.) That result may contain SWPs. For > example: > > (eval-when-compile (cons 'foo 'bar)) But the result is then passed to the compiler anyway, so this is the same as writing '(foo bar) which will come "with pos", so I still don't see why we'd need to strip pos from the result here. Even more so because the code passed to `byte-compile-eval` is compiled so it presumably doesn't have any sympos anyway, so there shouldn't be any sympos in its output either anyway. >> Fundamentally, `eval` should always strip before doing its job. > You mean, by "always", you meant ALWAYS??? Yes. > I understood you to mean "always, when in the context of > eval-{when,and}-compile". If we're not inside a compilation, and thus > there're no SWPs hanging around, stripping symbols from an expression > will just mean a loss of time for a null operation. That's right: the only cases where not stripping the arg of `eval` is OK is when we know that stripping would do nothing. IOW it's an optimization. > At the moment, I disagree with you. I don't think you have given an > example of a form FOO which will only work if stripping is done before > evaluation in > > (eval-when-compile FOO) > > or > > (eval-and-compile FOO) > > .. At the moment, I still think it is better to strip the positions after > the evaluation. And I still haven't heard any good reason why stripping them after the evaluation would be of any use since that result is passed to the compiler which is perfectly happy to accept code-with-pos. >> The misbehavior I'm referring to is what happens when you call the >> function before you byte-compile it (or, more likely, when you never end >> up byte-compiling it), because the presence of sympos in the function >> will mess up its semantics (because `symbols-with-pos-enabled` won't be >> set any more when it's called). > > I'm puzzled. Are we still talking about eval-{when,and}-compile, here? No. We're talking about a hypothetical case where `(eval '(defun foo ...))` is executed somehow and where the `(defun foo ...)` part somehow contains symposes. I used it as an example of why `eval` should conceptually always strip its argument (or if `eval` doesn't do it, then its caller should make sure that the code passed to it doesn't contains symposes). >From what I understand you suggested that in that cases `eval` should preserve the symposes in the hope that the user later calls `(byte-compile 'foo)` which can then benefit from those symposes to give better warnings. And I pointed out that this still means that (until that `byte-compile` call comes) the code of `foo` will likely be broken so any uses of `foo` will likely misbehave. > If so, how can a form with SWPs get into a symbol's function cell? > The positions are stripped inside the e-w/a-compile. Hmm... I agree that the positions *should* be stripped inside e-w/a-compile before passing the code to `eval`, but the code I see right now in bytecomp.el says: (eval-and-compile . ,(lambda (&rest body) (byte-compile-recurse-toplevel (macroexp-progn body) (lambda (form) ;; Don't compile here, since we don't know ;; whether to compile as byte-compile-form ;; or byte-compile-file-form. (let* ((print-symbols-bare t) ; Possibly redundant binding. (expanded (macroexpand--all-toplevel form macroexpand-all-environment))) (eval expanded lexical-binding) expanded))))) I don't see where the symbols are stripped before passing the code to `eval`. So if `form` is of the form `(defun foo ...)` I think we have a problem. > (eval-when-compile > (fset 'foo '(defun bar ....))) > > , where SWPs will escape into foo. Why do you need the `put` in there? Doesn't the same problem show up with (eval-and-compile (defun bar ....)) which does not seem "vanishingly unlikely" at all. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 13 12:50:10 2022 Received: (at 54079) by debbugs.gnu.org; 13 Mar 2022 16:50:10 +0000 Received: from localhost ([127.0.0.1]:43178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTRQ1-0003ak-Uf for submit@debbugs.gnu.org; Sun, 13 Mar 2022 12:50:10 -0400 Received: from colin.muc.de ([193.149.48.1]:24797 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nTRPz-0003a6-Jj for 54079@debbugs.gnu.org; Sun, 13 Mar 2022 12:50:08 -0400 Received: (qmail 75965 invoked by uid 3782); 13 Mar 2022 16:50:00 -0000 Received: from acm.muc.de (p4fe157ef.dip0.t-ipconnect.de [79.225.87.239]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Mar 2022 17:50:00 +0100 Received: (qmail 8817 invoked by uid 1000); 13 Mar 2022 16:49:58 -0000 Date: Sun, 13 Mar 2022 16:49:58 +0000 To: Stefan Monnier Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Fri, Mar 11, 2022 at 23:23:50 -0500, Stefan Monnier wrote: [ .... ] > Whatever appears in the code passed through `eval-{when,and}-compile` > can survive that code, so the fact that `symbols-with-pos-enabled` is > `eval` is exactly this "as long as possible" point where we know the > code won't be compiled because it's about to be interpreted. > non-nil while evaluating it doesn't make it correct. OK, you've persuaded me. ;-) Lisp forms need to be stripped of SWPs before being passed into `eval'. > > But, looking at the code, I don't think byte-compile binds > > symbols-with-pos-enabled to t. This could be a bug. > Maybe not: it has no reason to presume that its argument has positions. More to the point, I don't think it can assume that there aren't SWPs in the form. > If it does, then it must be because the caller explicitly arranged for > it to happen and so the caller could be in charge of binding > that variable. The caller could be any lisp function. It's just that binding symbols-with-pos-enabled in byte-compile is cheap and harmless, and there might well be legitimate cases that need it. I can't think of any at the moment, though. > >> And why bother stripping the result of `byte-compile-eval`? I think this point is moot if the form has been stripped before going into byte-compile-eval. In that case, there will be no need to strip the result. [ .... ] > >> Fundamentally, `eval` should always strip before doing its job. > > You mean, by "always", you meant ALWAYS??? > Yes. > > I understood you to mean "always, when in the context of > > eval-{when,and}-compile". If we're not inside a compilation, and thus > > there're no SWPs hanging around, stripping symbols from an expression > > will just mean a loss of time for a null operation. > That's right: the only cases where not stripping the arg of `eval` is OK > is when we know that stripping would do nothing. > IOW it's an optimization. It's NOT an optimisation. It's a straightforward implementation of the design. To add unnecessary stripping of non-existent symbol positions would be a pessimisation, a possibly measurable slowing down of Emacs. The whole essence of the SWP design was to minimise the influence of the SWPs on code which isn't the compiler. Always stripping before calling `eval' would not be in accordance with that design. There are a lot of places where `eval' is called. Inserting byte-run-strip-symbol-positions before each of them would be tedious in the extreme. Instead damaging `eval', to make it do two disparate things which just happen to follow on from eachother sometimes, would be worse; it would likely involve adding an extra &optional argument meaning "strip". [ .... ] > >> The misbehavior I'm referring to is what happens when you call the > >> function before you byte-compile it (or, more likely, when you never end > >> up byte-compiling it), because the presence of sympos in the function > >> will mess up its semantics (because `symbols-with-pos-enabled` won't be > >> set any more when it's called). > > I'm puzzled. Are we still talking about eval-{when,and}-compile, here? > No. We're talking about a hypothetical case where `(eval '(defun foo ...))` > is executed somehow and where the `(defun foo ...)` part somehow > contains symposes. Modulo bugs, I think that could only happen in a macro, where the (defun foo ...) bit was an argument, and the macro takes steps to preserve that argument beyond its natural scope. > I used it as an example of why `eval` should conceptually always strip > its argument (or if `eval` doesn't do it, then its caller should make > sure that the code passed to it doesn't contains symposes). I think it will be rare. [ .... ] I will prepare another patch which strips the forms of SWPs before the `eval' in eval-{when,and}-compile. Apologies if I've inadvertently failed to answer any open points. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 14 08:10:16 2022 Received: (at 54079) by debbugs.gnu.org; 14 Mar 2022 12:10:16 +0000 Received: from localhost ([127.0.0.1]:44286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTjWh-0007C2-Tn for submit@debbugs.gnu.org; Mon, 14 Mar 2022 08:10:16 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nTjWf-0007Bg-Jo for 54079@debbugs.gnu.org; Mon, 14 Mar 2022 08:10:14 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9F6C510020C; Mon, 14 Mar 2022 08:10:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4387B10012C; Mon, 14 Mar 2022 08:10:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1647259806; bh=UPcoGCji847AkvSeCuKGNmIf1KF+2MIKxKSk3U03yCs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=X+DNUmbxA82qe5PEHb8gfODWeN6got4BtJp2ky4zDees4Qd1euiNdkCET4Zc+KkZ0 4k71OuRCV8PIy03vZBWEqsDvhTtZHZDEch0zhJoMgMRLCPoenLxGxTit+HO7FoLDq3 bnMSWuW2soHXwtqOLq2X/YSZCCIJp5COY6yQ/GN75UeGWrA+1jCK9+k0yo/Mjw9mu9 vJyWR6vtug+2xQyPW4SHEb9n/dqfMRNcu0eM33iM1cS2/Zm55SB/xG30ACs8C3TWTD pdrat1F5h36kYg9cYBqy1WDTYwFUXm3P1ByyhjXbNFnefa1OaQ8Pz1EkEM5a//dKvF zz9wIPMut/Eaw== Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA264120189; Mon, 14 Mar 2022 08:10:05 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: Date: Mon, 14 Mar 2022 08:10:04 -0400 In-Reply-To: (Alan Mackenzie's message of "Sun, 13 Mar 2022 16:49:58 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.047 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 54079 Cc: Michael Heerdegen , Lars Ingebrigtsen , 54079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> If it does, then it must be because the caller explicitly arranged for >> it to happen and so the caller could be in charge of binding >> that variable. > The caller could be any lisp function. Yes, but if there are symposes, it can only be because somewhere up the call chain, someone decided to use sympos, and that someone should be the one responsible to bind `symbols-with-pos-enabled`, I think. > It's just that binding symbols-with-pos-enabled in byte-compile is > cheap and harmless, Agreed. > and there might well be legitimate cases that need it. I can't think > of any at the moment, though. Fair enough. >> That's right: the only cases where not stripping the arg of `eval` is OK >> is when we know that stripping would do nothing. >> IOW it's an optimization. > It's NOT an optimisation. It's a straightforward implementation of the > design. To add unnecessary stripping of non-existent symbol positions > would be a pessimisation, a possibly measurable slowing down of Emacs. We violently agree. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 15 21:44:22 2022 Received: (at 54079) by debbugs.gnu.org; 16 Mar 2022 01:44:22 +0000 Received: from localhost ([127.0.0.1]:49937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUIi6-0001rO-0v for submit@debbugs.gnu.org; Tue, 15 Mar 2022 21:44:22 -0400 Received: from mout.web.de ([212.227.17.12]:45979) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUIi2-0001r7-W1 for 54079@debbugs.gnu.org; Tue, 15 Mar 2022 21:44:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1647395048; bh=BADpF7ZCCwtaL3Cv6YEKljGb/cfjuzmSfEzdfvK1k5Q=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ehq3uquBThhlpVPJHV2yKs4T1AIjVdiQqyJBrJnOMjd67KQlFtiTKXEiBKZTOXOHl hdmnWedzFU7aPvi8bLcnSfCUrymUSi1QU7f8fpOGm86hGJ7aYlbNY64h5B7vAHUKMn a77V/h3g1VtLBQ5VEcN5F3yrqhjGa9/HghirdB78= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1N6K1b-1o9x5t0LAv-016TTw; Wed, 16 Mar 2022 02:44:08 +0100 From: Michael Heerdegen To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87mtik3l54.fsf@web.de> <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> <87wnh3zryv.fsf@web.de> Date: Wed, 16 Mar 2022 02:44:07 +0100 In-Reply-To: (Alan Mackenzie's message of "Wed, 9 Mar 2022 17:29:29 +0000") Message-ID: <87sfri1xjs.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:LQR4EbpeE73EsO/hyPNnyqkpw3xZyz3DyTdhp883jNANRjCL1qv yVCIG51uACtatSrO0XvOW/oAhPqShZ5btpOoVKxy6bBu7t8ub0lw6iIMAIHMHqpRsXvpUY6 /RAktsT90B6tIe+QlmfZma3SB+zcoEf9/cRswNQ580W11V0dl4Nh2zJHd7+JB89lIuhtBMh KR91nRumICECtKZGtTKPw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:vwSxaNgdqcE=:vtQSxjdHn7qNuJqezgcWX0 iheDnJcozqEPH3PKWsHrvlfJ/HR4buFFKQ5GLGz0FV3lS0ogFG20yKEJUvu7AfR7UC6WaGQJk 0oEIWl/awSKVS0zpz30wj8XIWsFPhWQ/8JAhUhcMyc3mmnpxjKwabDuFI05hUGk/T5XvzDklj UKn1IWvmr2/o5FZnE93TlzxdUV1m/ShoO+XhJ3qsZcoIZRi4tCOGkgK2/TZgHVe/jl2cu+3QY JK2MpNOHOQKPkLcq9L54/Wz6ImJvlMLaO4X9YNpCnu/Lzus8ODo4bsCBH7C8pbZjXXWUtHq6L L+S2QLZNRS0/I3kvsKZ4yPz9IwhaI6dfLxisIv4nB5jyTB2CtosTiHjinzORKwg4ru3n92A5A O7OL4hoN94mjsij33T0jt5mEDvlEY94mGDzFhykAM49moSNrChOw+rXPeRIKEK6bWVwSfQvIb IjUvESjvEmftkxB1xIq3YHLXkMNcPagIFjWEkv+p3VoxhTE9IOS5dMatn8Byt+ePKwKQUvnkp Qg5Thadfx+1k7EWvG2SwZxxD8dRBJNx2iICKrcC9F46H+NYZG7Gx0U9b7vMELgtekSTX+4x08 kISd3IZOw8uaPHu7ttgx1g82HQwboOlmSfSaY1wWb6LjfnjOWoFKabX+HG1kKbiuvsmBGqREc 7IkNSrJ1KU4NOUqEDe1ZX2hZErcNaEET8bmUXP3m1nqh9njfrtAdr6eQVg4SxsDp/YkJO23Mx QsIobD7026zQMGVZujS6xT6nlJHGkppc/a0HwVHX/V76yog3XAuiWJu41CsAfwEAYas1vD+p4 jNRL9mOWpSwDQZCH2cGY40cFleiz4AAjzY3aoS6AZHFlrP9fI1Sp8ZuKYGFiKE64BEf2Bhqh7 Zil/tz5lyGrdo403iKli2eC+skuV3DQlwAKVuSJNPoIKu4Mpn5Izp4dGWtYtn2WXYLe9AV+is BFeOxTfKKAgl6QBy269csagGaomdCy27z9Cg2wTtYfgDKhTJX0i392pfbYW6JEFPPTgb8J6FJ tZnHrfyvmbyOSIuGJ0J889EHMgdybjsmTvC9NaydKyDaP4h6NkUKQKHCkw/ct9GZne092ghfa aaWM3no6ogGeZA= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: John Wiegley , Lars Ingebrigtsen , 54079@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > OK. So the longer I hear nothing from you, the better. ;-) Thanks! Hope is was long enough :-) I now tried to debug the other thing that is still happening for me - failing compilation with async-bytecomp.el when updating packages with M-x list-packages (I CC the maintainers). In my currently running session I get #+begin_src emacs-lisp (async-inject-variables "\\`\\(?:load-path\\'\\|byte-\\)") ==> (setq byte-set-marker 147 byte-optimize--dynamic-vars '(# # ...) ...) #+end_src These symbols with position in that sexp seem to be the, or one, cause of the trouble. The symbols directly come from a `mapatoms' call, and AFAIK this sexp is then `print'ed and sent to another emacs process, where it causes a `read' error. What has to be done to fix this one? TIA, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 16 07:52:39 2022 Received: (at 54079) by debbugs.gnu.org; 16 Mar 2022 11:52:39 +0000 Received: from localhost ([127.0.0.1]:50404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUSCk-0000MN-Ue for submit@debbugs.gnu.org; Wed, 16 Mar 2022 07:52:39 -0400 Received: from colin.muc.de ([193.149.48.1]:15156 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nUSCj-0000M9-DU for 54079@debbugs.gnu.org; Wed, 16 Mar 2022 07:52:38 -0400 Received: (qmail 44412 invoked by uid 3782); 16 Mar 2022 11:52:30 -0000 Received: from acm.muc.de (p4fe15cb0.dip0.t-ipconnect.de [79.225.92.176]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 16 Mar 2022 12:52:30 +0100 Received: (qmail 7734 invoked by uid 1000); 16 Mar 2022 11:52:29 -0000 Date: Wed, 16 Mar 2022 11:52:29 +0000 To: Michael Heerdegen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> <87wnh3zryv.fsf@web.de> <87sfri1xjs.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sfri1xjs.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: John Wiegley , Lars Ingebrigtsen , acm@muc.de, 54079@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Mar 16, 2022 at 02:44:07 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > OK. So the longer I hear nothing from you, the better. ;-) Thanks! > Hope it was long enough :-) Indeed it was! Thanks! As you'll have gathered, I've been debating the final form of the patch with Stefan M. for the last week. The patch I'll actually be committing will be slightly different from the one from last week, but not in any way which should affect the success of the problem fix. > I now tried to debug the other thing that is still happening for me - > failing compilation with async-bytecomp.el when updating packages with > M-x list-packages (I CC the maintainers). > In my currently running session I get > #+begin_src emacs-lisp > (async-inject-variables "\\`\\(?:load-path\\'\\|byte-\\)") > ==> > (setq byte-set-marker 147 byte-optimize--dynamic-vars > '(# > # ...) > ...) > #+end_src > These symbols with position in that sexp seem to be the, or one, cause > of the trouble. The symbols directly come from a `mapatoms' call, and > AFAIK this sexp is then `print'ed and sent to another emacs process, > where it causes a `read' error. > What has to be done to fix this one? I don't know, as yet. Almost certainly, the symbols with position are somehow escaping from the compilation context. It looks like something in magit. Possibly, I'll need to ask the magit maintainer to call byte-run-strip-symbol-positions (which _surely_ ought to be renamed to strip_symbol_positions) where these SWPs escape. (Possibly in a macro). In the meantime, could you possibly raise a fresh bug report for this one, please, and give a complete recipe for reproducing the bug. Thanks! > TIA, > Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 16 15:22:25 2022 Received: (at 54079) by debbugs.gnu.org; 16 Mar 2022 19:22:25 +0000 Received: from localhost ([127.0.0.1]:52334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUZE0-0002Q9-UH for submit@debbugs.gnu.org; Wed, 16 Mar 2022 15:22:25 -0400 Received: from mout.web.de ([212.227.15.3]:56819) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUZDz-0002Pu-GR for 54079@debbugs.gnu.org; Wed, 16 Mar 2022 15:22:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1647458535; bh=w9ds/uBOoAgvmppMEaDhvo7TJWaAwnuy7H7A0em4t5M=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ZNOw+N8jdFEH55Xj4Q+hE1HsRxaqqoIBn/hzb773Yj76icH3n0zMohzHZxiOV+mbE SbcQiyYAMTDWs/qA81SqnFgYrqGFPnpCFNYSATSYpL+j+RwTL6sM3U1GEBrt2LBFDu GhpEwE81EgZrauNZvUEghlbEtAey5tRM1LoKdIPg= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1M28SL-1nX2CM08ev-002RV8; Wed, 16 Mar 2022 20:22:15 +0100 From: Michael Heerdegen To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> <87wnh3zryv.fsf@web.de> <87sfri1xjs.fsf@web.de> Date: Wed, 16 Mar 2022 20:22:14 +0100 In-Reply-To: (Alan Mackenzie's message of "Wed, 16 Mar 2022 11:52:29 +0000") Message-ID: <87fsnh7leh.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:5hKukZx7Y7pOgIujxjWU6vNsFs4JfqTGTHgEECrM6yrrpYaECVn iOp2wzOjcx2D3gr+KZOrWccx/WhlvUs5sdDYsBrg41VUbZpasORY4T4T0xZ1B1qA3VketRT kPoxUxETyCc8AflseSEsgHvXbcMwGYZX5JqW3ViShg8IVplgz6d36TksfDwB16hBMhQDe9d XjiA9b6jd312ZArTnUTEQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CNJ7U4w0L8k=:JV+HUHnWZTWtmoZKIZU6ZW B3zqX0dul2oplgZIW32iDGyyMgx7wldCnunJLb/SjkSDneaS1PZdCHd42uLNFL67pTObwh4tm cO4+4K0Ix5JZdf/08EFFtl5N/IgMRtihKK4LXpm5n7VzypHCvKnX6O2gcmGruDSQz6rTiPaEi H0Unf0ecmKoME9AHdvPir28B0dUw4RVB8atg/HFxCjt7rySzOoCQHOiNomSyNZwrEZFJTrCO0 rzRDwnlkUAA1v8FtR5mwiQxl+OhTPZYKZkQDVy0lhll78Z3Fe5LJGHP7rg0aL3N6TLU8zZ7/s /p6GA71LIXC4P2CSDWFIRzVZ+dPWsot9g1q/Cw+gYuWnacmZP9dwnX8MxZXj0B8i/cbP4Hqno 920aOYllk3iVRKdoLxrEbubjJAMYWuDg5ldsJQGsWnu4/TmoqFqmkc5JMJDe7/cRs6Fg+NqBO Ipquei0+yq+L5gB/DebeYotm8qwXA05gQoVRi/Wm/MqygpQgA45mMeuJSPaT0RH0DeWmtgFNp DW8zCRCbro6j9gdO8l0Pu2TAhY/vS+/8Q2yfxWtg5GpAyF3WL7d6GUrWCocVkKCQEf5f4qHIl dmp3+J13SML3UGk+Yi7hk+3n+Z1Yl/0CAPBbp71R381D6+1Gk/tFTon1VPiIWnt1nL5E1h5Wp Erh0RRQTQ48RuxiknHYGBOa1a3EoxIfAjCfr4t06OqnkqeVTBimVrSg63P+JiqVaTkubOdbC8 Hy7q7whK6w/FVX2QRGzBcUIvtJ19QS8ABIZlwYHNk1ndEbcA84KKSkMX4DKxfLpLBsV8OBHT6 kyfwWv7W4EQMI7siNRaJ+hILkjrA02IYarbFj5HqeCaaEHD7DlsMdo7afuBOZxUmeydDNoj4p qAjJF8AMOcl8dqKUyzWeta51C5Pn4FDZ/BffXs3GBYzpu9V3Td55WLsmXF6MlzAy6Y1W1bMGf AILhG5YaS7IqZLbCj7JQxhY3EegDy4EcKaKf+srjKT1OUuRvqa7W/lumjd/WoA5Ez4X/wxUVC bXHy+Uly2Dxo+QsuIGV8JTB/mBwsJURw/1CGfW9YcofqJ2ReQuGFam3IXu1XS/21+KJ+CaH7h 4nIonDgkr8wgjs= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 54079 Cc: John Wiegley , Lars Ingebrigtsen , 54079@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Alan Mackenzie writes: > I don't know, as yet. Almost certainly, the symbols with position are > somehow escaping from the compilation context. It looks like something > in magit. Possibly, I'll need to ask the magit maintainer to call > byte-run-strip-symbol-positions (which _surely_ ought to be renamed to > strip_symbol_positions) where these SWPs escape. (Possibly in a macro). Evaluating the following expression gives me a result containing symbols with positions. Is this expected? Does not happen in emacs -Q, but in my session. #+begin_src emacs-lisp (let ((include-regexp "\\`\\(?:load-path\\'\\|byte-\\)") (bindings)) (mapatoms (lambda (sym) (let* ((sname (and (boundp sym) (symbol-name sym))) (value (and sname (symbol-value sym)))) (when (and sname (or (null include-regexp) (string-match include-regexp sname)) (not (string-match "-syntax-table\\'" sname))) (unless (or (stringp value) (memq value '(nil t)) (numberp value) (vectorp value)) (setq value `(quote ,value))) (setq bindings (cons value bindings) bindings (cons sym bindings)))))) bindings) #+end_src That gives me: (# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # my-helm-eww-input-history # # # # # # # # dg-date # # # # # # # # # # # # # # # # # # # # # # # # cl-struct-my-command-register-tags # # # # # # # # # # uncached mark default-low default-high default score) Doesn't look magit specific. > In the meantime, could you possibly raise a fresh bug report for this > one, please, and give a complete recipe for reproducing the bug. Still appropriate with the new information? TIA, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 16 15:29:50 2022 Received: (at 54079-done) by debbugs.gnu.org; 16 Mar 2022 19:29:50 +0000 Received: from localhost ([127.0.0.1]:52338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUZLB-0002bQ-Rk for submit@debbugs.gnu.org; Wed, 16 Mar 2022 15:29:49 -0400 Received: from colin.muc.de ([193.149.48.1]:27268 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nUZLA-0002bB-Ib for 54079-done@debbugs.gnu.org; Wed, 16 Mar 2022 15:29:49 -0400 Received: (qmail 52604 invoked by uid 3782); 16 Mar 2022 19:29:41 -0000 Received: from acm.muc.de (p4fe15cb0.dip0.t-ipconnect.de [79.225.92.176]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 16 Mar 2022 20:29:41 +0100 Received: (qmail 19297 invoked by uid 1000); 16 Mar 2022 19:29:40 -0000 Date: Wed, 16 Mar 2022 19:29:40 +0000 To: Michael Heerdegen Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails Message-ID: References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> <87wnh3zryv.fsf@web.de> <87sfri1xjs.fsf@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sfri1xjs.fsf@web.de> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079-done Cc: John Wiegley , Lars Ingebrigtsen , acm@muc.de, 54079-done@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Michael. On Wed, Mar 16, 2022 at 02:44:07 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > OK. So the longer I hear nothing from you, the better. ;-) Thanks! > Hope it was long enough :-) Yes, thanks! I've committed a patch (slightly different from the one you tested ;-), and I'm closing the bug with this post. [ .... ] > Michael. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 16 22:58:57 2022 Received: (at 54079) by debbugs.gnu.org; 17 Mar 2022 02:58:57 +0000 Received: from localhost ([127.0.0.1]:52674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUgLp-00027C-L1 for submit@debbugs.gnu.org; Wed, 16 Mar 2022 22:58:57 -0400 Received: from mout.web.de ([212.227.17.12]:37919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nUgLn-00026x-G4 for 54079@debbugs.gnu.org; Wed, 16 Mar 2022 22:58:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1647485925; bh=0Vl2WMf89wlM3D8mTUJ4s2mVvskx2uMW+NUd5bJVWTA=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=o5nkq34l4IkfGWWAORTqDMNIReUXPBMy65d/GaPPOZMHmkRRMxJ2nQf4yFprH6fuJ Cc6hWKFKkQfuMVB8b3+cJ8Y82+QwsjJdspLNqb4g1EjY07Uno+Yia4t+ZdFgtE02zW vToX/57djAhVBeOrIsFljbinjRVEz3mQfsoNy+ds= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.60.174.212]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MG994-1nKmJl0FX2-00GhoF; Thu, 17 Mar 2022 03:58:45 +0100 From: Michael Heerdegen To: Alan Mackenzie Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails References: <87ilt6bgnt.fsf@web.de> <87sfsapgv0.fsf@web.de> <87o82ypfxz.fsf@web.de> <875youbhbu.fsf@web.de> <87k0d7257t.fsf@web.de> <87wnh3zryv.fsf@web.de> <87sfri1xjs.fsf@web.de> Date: Thu, 17 Mar 2022 03:58:43 +0100 In-Reply-To: (Alan Mackenzie's message of "Wed, 16 Mar 2022 11:52:29 +0000") Message-ID: <875yodnv30.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:BNkLi42+n8BTsvEx66QiNoA4GwEWLAVPOpfQkJNo92fmNSJGmNP PvtV1vohrsW5aExZt0U8JY+uZaRvDjBXkGk/kani7QSk543d+l8MqdQ5+V96X1D1d5u0cKI RMWbha/q6j8FpR3VWQnEYaF1d5TwL98P55ovPr1nQaNtx9kh4xh/M9p5odwpQZW4J0sCqiT a+qdvTLSHxYtl0hecwmOA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AIprKfrhWD4=:glh12U1zVJSgLNETgJLjRr siLdskk1eGuInTKAFd4GJq7DxnQidpThSr5ek3kWDd1546F5oekWyHSD0PoY6wdA5m9vLuV7V uUALcWakkaYeDLqwXyU21mG/z9CB6s/fD2fCU6AW8tlRAIFlZKCEsP39gsVuh2KTou2wOVuYv o+uf75b5V2IetAZF/P9k5pJdSQr1c/R0lS50J2ZTzRKk68qfdWJ8Io4tENSZKwY0uD3M/LCDx zsy30mNbSZrtccHXqpVxdJKGBTPBJ3Nsd2NEEJdBH1Cl9QZuBOyx03/d/2G+nfK4OAk51XHv4 RO/OLX8KBrl6210cqRg47wibQ4KQVA7pokWZsljhBuL1dxMR2gbvXNsIP1hM8rQ8Jkiav+ZvR m6asUPTONTMMN6+b7pXxNCjFL2CluOhe6DLGMyT9M4MLvw6QdUW/zUkg1ayaP7a9JlK+Iww+l wuWNgT2ztRNPDXaf0b9y04a6bLrdtVwTl3crS19VnMm08CC4nDjidPc8EXtZMCVFxjPLe5wvz YXNn5Oy3Xr5vCB73Fjwq5tYU5mJFGRRZQGDJoPILWATa1BFzIRLahq9zllEUkqBawsP2RhyuR eIpWyknf68tcUXb2eRTC9IoTg5jveQNMiY2db1iAtPle52mjV7LF1ET8lEeGpN7O+zdsS8lRR aqYQdstk1eFrWLWZ60Eal3I7YHsnQ1k6An04kcJHsZI0liGCjJz9s4/wKNXUC4ZAr52vTpNRM 71na3oDkFaz+fkAMpuP8y/qMwFSSwWD937ZdocZkLamRPEf9mlZc3FxvNvx/uyVwQRIGVGrqI bFj/BFpIZBSUqw5G8BGEBFAkDT+Vz1K7v45/zj7hxIA9jRQd18grmQFtqDR1hUJ5nq1bXXAgD f7yTwRzlOkPLg0Qx3l3EZ0Su9Lh97puxzwgMCjjGvggWTzVFUpCOaPRNfzS6mAqfz1/bIAm4I eAmzHH2+Dl4MSq4g6E4XpcCeiIRIMNs7jxCINX181TGydqxUpWKLsKRDCL4HJ57mTWstiKXI9 0nInbBLIwnF91a1F0PBxez6BhIPGX6w0rh74CBAZwxeMM1Lsvn2AbXE+xwARXOQ2mgcmzduUl QmukvgZnwkG6eM= X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 54079 Cc: John Wiegley , Lars Ingebrigtsen , 54079@debbugs.gnu.org, Thierry Volpiatto X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > In the meantime, could you possibly raise a fresh bug report for this > one, please, and give a complete recipe for reproducing the bug. > Thanks! Done now - see bug#54433: 29.0.50; Invalid read syntax: "#<" with async-bytecomp. And thanks for fixing this one! Regards, Michael. From unknown Fri Jun 20 07:23:22 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 14 Apr 2022 11:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator