From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Policy on pure space-related fixes Date: Sat, 30 Jul 2022 07:45:21 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f724dd05e5044dda" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25429"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 30 13:47:01 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHkvs-0006Pt-N1 for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 13:47:00 +0200 Original-Received: from localhost ([::1]:50510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHkvq-000656-Vc for ged-emacs-devel@m.gmane-mx.org; Sat, 30 Jul 2022 07:46:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHkuZ-000582-8A for emacs-devel@gnu.org; Sat, 30 Jul 2022 07:45:39 -0400 Original-Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]:40852) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHkuX-0003oG-H4 for emacs-devel@gnu.org; Sat, 30 Jul 2022 07:45:38 -0400 Original-Received: by mail-pl1-x631.google.com with SMTP id x7so6665290pll.7 for ; Sat, 30 Jul 2022 04:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=KA15fqcH1mG/l/uRpxA2hLPC/HLV5gC44SAZjNa+et4=; b=MNyHYqzLeI0061YcuqgKiCIAQI9XryGAld8jSpaqSaAfEULkmZgJWc7z41hJA4UtUH CWa1Ca/TKH9Hzf5lY1RF0p/iRVzuNk2jitKQ9wblqWMFlY9RGhKzyoxPcXhecb06tnVD gWc3j3wjhD35EHwQSrwaw1y7BWhPWQVP3nvyafnpZN0W/cfXFvHOZZVUk82YQ9hhxAUW bxfePc8c/Wdr82O7TzrLw7BDTwQ0a5MUiGSyGXQjn1SZSMDE91JNCUc0MUPJKS/YgoUN u9EX72IzE9HyymBn9UytzJjpejtf2EgvBuxmfUS3497QmV1ycJJBteDA9bj52Udka8Jk vTMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KA15fqcH1mG/l/uRpxA2hLPC/HLV5gC44SAZjNa+et4=; b=gTC0PgtaW3tsf4BMaXyrCM64azd8ncfTbm7vQeCBbby3+LgTA0qrFJc82TRsnPCviY +jdhiPeJy6qS9DtzDkAd3PLK8taIC/WMJZrUkq4swEwxO/b4U36U5TKDz81LAh0okrMk BUmhG5AzEJA2aYBBojdF3QDVcsCWVM9BZnMja9uAMhdrQNAhW4i9A/1hMFMHVI62zU+f 3Q9bKcDIAfXqqQaKiXDwwjj0jY1TG+lPZaNwoyEHNtGJJFn/KkBQ9T6em64ousy3qZKX Sb2rSKsJs3EsTN9i+jvl/lN67mw98blBzyaD4h4gRybaHIVhUd3xlEjtcXkHIjigWNAA Dm4g== X-Gm-Message-State: ACgBeo3pksh9fLi7fYgea6IxvRol9rFkPMnB2niLCy4izutjA1BrFNxt /xP9/HkHvhX4q0Iss8YvaxacQjYeEB4sNv6Oohdlh242 X-Google-Smtp-Source: AA6agR7YKgrXeBF+8XGpir92DWpfij2Fgh4elSZjt5Ge5iSOj2mK+hRMjKL04XDnb5Zto7H7VrnJgpFwrr8f19RFc2U= X-Received: by 2002:a17:902:900c:b0:16d:28ad:29e1 with SMTP id a12-20020a170902900c00b0016d28ad29e1mr7964525plp.93.1659181534223; Sat, 30 Jul 2022 04:45:34 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::631; envelope-from=owinebar@gmail.com; helo=mail-pl1-x631.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292866 Archived-At: --000000000000f724dd05e5044dda Content-Type: text/plain; charset="UTF-8" Hi, I reported a couple of bugs related to pure space. One was a duplicate that had been closed as "won't fix". The other hasn't gotten any response, though that could be due to the lack of details. The one closed as "won't fix" ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) should really be fixed, even if not by the originally submitted patch. The response from Eli that prompted that status was along the lines of "why not just increase the pure space"? The answer is: I didn't see any warnings about pure space being exhausted, even though it turned out I was at least 12MB short. The fix should just do away with the "small size" increment and allocate whatever is needed, under the assumption that the user will have to increase pure space and recompile regardless. There are too many assumptions in the code that test purity by distance from the base pure address to rely on a dump where pure space is exhausted. The other issue arose from record created by eieio that pun the type of a class descriptor class to itself. purecopy does not track cyclic structures, so diverges and causes a segmentation fault. I put in a special case check that prevents the immediate problem, but a real solution would have to memoize the input structure if the intent of hash consing is to create singletons and not just read-only constants. The singleton property is what seems to be of interest for eieio class descriptor records. Generally, are fixes to pure space worth submitting, given the plan to decommission it, or will they just be ignored? I'm still waiting on clearance from my employer to submit patches, unfortunately. Lynn --000000000000f724dd05e5044dda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I reported a couple of bugs rela= ted to pure space.=C2=A0 One was a duplicate that had been closed as "= won't fix".=C2=A0 The other hasn't gotten any response, though= that could be due to the lack of details.
The one c= losed as "won't fix" (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D= 46916) should really be fixed, even if not by the originally submitted = patch.=C2=A0 The response from Eli that prompted that status was along the = lines of "why not just increase the pure space"?=C2=A0 The answer= is: I didn't see any warnings about pure space being exhausted, even t= hough it turned out I was at least 12MB short.=C2=A0=C2=A0
The fix should just do away with the "small size" incremen= t and allocate whatever is needed, under the assumption that the user will = have to increase pure space and recompile regardless.=C2=A0 There are too m= any assumptions in the code that test purity by distance from the base pure= address to rely on a dump where pure space is exhausted.
The other issue arose from record created by eieio that pun the type = of a class descriptor class to itself.=C2=A0 =C2=A0purecopy does not track = cyclic structures, so diverges and causes a segmentation fault.=C2=A0 I put= in a special case check that prevents the immediate problem, but a real so= lution would have to memoize the input structure if the intent of hash cons= ing is to create singletons and not just read-only constants.=C2=A0 The sin= gleton property is what seems to be of interest for eieio class descriptor = records.
Generally, are fixes to pure space worth su= bmitting, given the plan to decommission it, or will they just be ignored?= =C2=A0 I'm still waiting on clearance from my employer to submit patche= s, unfortunately.=C2=A0=C2=A0

Lynn

--000000000000f724dd05e5044dda--