From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: The poor quality of Emacs's backtraces Date: Wed, 19 Jul 2023 15:45:54 +0000 Message-ID: References: <3D901B62-4826-4783-B684-968E6890E75A@gmail.com> <6CB5E709-8F5A-4015-9F2C-337A87916C66@gmail.com> <909FC7C1-5473-4746-97E4-B067E6C2B271@gmail.com> <5382C438-D871-4C79-820C-DCA17C59CBCA@gmail.com> <327EA767-4E97-433C-894A-021B3845B86C@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35419"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Mattias =?iso-8859-1?Q?Engdeg=E5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 19 17:47:32 2023 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 1qM9Ok-0008uq-In for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Jul 2023 17:47:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qM9NU-0004BI-F0; Wed, 19 Jul 2023 11:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM9NR-0004AC-BN for emacs-devel@gnu.org; Wed, 19 Jul 2023 11:46:09 -0400 Original-Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM9NH-0002L8-Pd for emacs-devel@gnu.org; Wed, 19 Jul 2023 11:46:09 -0400 Original-Received: (qmail 78661 invoked by uid 3782); 19 Jul 2023 17:45:55 +0200 Original-Received: from acm.muc.de (p4fe159a7.dip0.t-ipconnect.de [79.225.89.167]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 19 Jul 2023 17:45:54 +0200 Original-Received: (qmail 9155 invoked by uid 1000); 19 Jul 2023 15:45:54 -0000 Content-Disposition: inline In-Reply-To: <327EA767-4E97-433C-894A-021B3845B86C@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307973 Archived-At: Hello, Mattias. On Wed, Jul 19, 2023 at 12:33:51 +0200, Mattias Engdegård wrote: > 17 juli 2023 kl. 21.02 skrev Alan Mackenzie : > > Well, I've committed the code (see below). Please actually measure it > > and point out where it is actually slow, > That is your obligation, not ours. You cannot demand that other people > accept your assertion that it is fast or have to prove otherwise. > Measuring performance properly is actual work. You've distorted my point by inappropriate snipping of the context. > > And please don't exaggerate the "ease" with which it was written. > I'm sure it was most taxing work. > > I don't agree, at least not at the moment. The function object, all > > three varieties, is big enough to hold all the information it needs > > to hold. Should it need to become marginally bigger, so be it. > It's apparently not big enough since you had to enlarge it. You've misunderstood the English usage, here. "is big enough to hold all the information ...." is talking about the design principle. We don't decide how big a function object should be, then see how much information we can pack into this. > Now please remember that the current closure problem is not your > fault: it's an unsatisfactory set of data structures that we would > like to clean up. But it is what we have to work with for the time > being, and it's unclear when we will be able to do something about it > (it's a considerably bigger task). What closure problem? Has this been expounded in a post on emacs-devel? (A reference would be appreciated if so). Who is the "we" in this context? Why do you think it will be such a big task to fix it? > > These are all things that can be changed later. The main danger is doing > > nothing but talk, talk, talk, .... > This kind of argument is unhelpful. Implying that there is an urgency > and that we therefore should accept your solution without delay does > not go down well. Nor does attempts to brush away valid criticism as > things that can be changed later. > There is no crisis, and rushing through changes will be of benefit to > nobody in the long run. Note that nobody in this thread has countered my argument with "I find the Emacs backtrace perfectly satisfactory, and don't think any change is needed.". > > That "faulting operation" is merely one > > of the things I want. I would not be satisfied by just that. The > > identity of the code referred to by each backtrace line is also > > essential. > There is a difference between what you personally want, and what you > reasonably can expect to impose upon others. I get the feeling I am being enticed into a fight with you. You've replied to things in my posts, giving them meanings and nuances that they weren't intended to carry in the first place, partly by selective snipping of the context. I don't want to play this game with you. I've produced working code, you have given no sign that you've actually tried it, or looked at it, yet you don't seem short of disparagement for it. > > Whatever we do will involve "maintenance costs". > You misunderstand. I'm talking about adding a feature which we cannot > easily undo or even change once it's in place. Whenever we do that, we > will have to be certain that it's the right one. That involves looking at it and trying it out. This will be my last post in this arm of the thread. -- Alan Mackenzie (Nuremberg, Germany).