From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: xassert in dispextern.h Date: Wed, 02 Mar 2005 02:38:17 +0100 Message-ID: References: <200503012317.j21NHIj20008@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109727358 12302 80.91.229.2 (2 Mar 2005 01:35:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2005 01:35:58 +0000 (UTC) Cc: jasonr@gnu.org, emacs-devel@gnu.org, Luc Teirlinck , storm@cua.dk, miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 02 02:35:57 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D6Im7-0005XX-UU for ged-emacs-devel@m.gmane.org; Wed, 02 Mar 2005 02:35:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6J4m-0001zR-ON for ged-emacs-devel@m.gmane.org; Tue, 01 Mar 2005 20:55:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6J4W-0001xc-4h for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:54:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6J4U-0001ws-NB for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:54:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6J4U-0001wV-HD for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:54:42 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D6Iod-0006Kq-OP for emacs-devel@gnu.org; Tue, 01 Mar 2005 20:38:19 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1D6Ioc-0000in-SQ; Tue, 01 Mar 2005 20:38:19 -0500 Original-To: snogglethorpe@gmail.com In-Reply-To: (Miles Bader's message of "Wed, 2 Mar 2005 10:17:33 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:34030 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:34030 Miles Bader writes: > On Wed, 02 Mar 2005 02:01:54 +0100, David Kastrup wrote: >> > The argument for disabling xassert assumes that the majority of >> > them are superfluous; clearly if this _isn't_ the case then >> > disabling xassert is a bad idea. >> >> The majority of them clearly _are_ "superfluous" since they assert >> assumptions occuring in the context of earlier, fixed bugs. > > (1) How do you know that? You say yourself that there are so many > xasserts it's hard for anybody to go through them all. It could > very well be that many are testing conditions related to suspected > bugs, not fixed ones. Sure. That's why you put them in. And then you find that they don't get triggered, and you look for something else. > (2) Even if that were the case (which you haven't demonstrated), it > wouldn't make them "superfluous" -- regression testing is very > valuable in the presence of any hacking, and the amount of change in > the redisplay code recently is certainly enough to warrant it > (especially given that nobody really understands it very well). But the persons that are capable of doing useful regression testing are the people reading on this list. We provide a publicly accessible CVS archive, and that is a message that we are at least willing to share what we have, even though we are not yet at release state. Why should we pretend that we are a closed circle and non-members should not expect to be able to use Emacs? >> > In order to demonstrate that the majority are superfluous, one has >> > to actually be able to make exactly the same sort of judgement for >> > each xassert -- so I'm saying, if you can make that judgement, then >> > why not use it on a case-by-case basis to get the best of both >> > worlds? >> >> Because there are lots of cases. grep in the source directory of >> Emacs turns up 1430 of them. > > So how have you made the judgement that the majority are unneeded? Because several people have been running them for several weeks, and this has caused me about a week of completely wasted work for no gain whatsoever. A majority from 1400 asserts would be more than 700. Are you really sure that all of those 700s could be triggered with our current code? But I am not arguing that those asserts should be removed. I am arguing that they should not be enabled in HEAD, but by choice of a competent developer that can actually do something useful when an assertion gets triggered. >> > If, on the other hand, it's the case that nobody can make that >> > judgement for most xasserts, then nobody is in a position to say >> > xassert can safely be disabled either. >> >> That's why we are not deleting the xasserts, but turning them off >> by default, and, among developers, from time to time turning them >> on in order to check whether everything looks as good as last time >> around. > > Experience shows that this is usually not sufficient. Many bugs in > the redisplay code are subtle, and are not going to simply present > themselves when you do a quick check. But they will usually be exhibited by quirks and screen shots and test cases. A picture says more than a thousand words, and a crash does not say much at all. I am the main developer of preview-latex, and this package is about the worst thing to throw at any display engine. I have in the course of 21.1 development provided dozens of test cases demonstrating a bug. And this has only been possible since Emacs displayed nonsense instead of crashing. Yes, redisplay bugs are subtle. But in my experience incited crashes don't help in fixing them. I have had a fair share of involvement with them. >> We are not talking about removing the xasserts: that would be >> foolish. We are talking about not inflicting them by default on a >> larger audience on which their purpose will be completely lost. > > Right, that's why we'll _turn off xassert for the release_. Why don't we turn off public CVS access if people are not supposed to be able to make use of Emacs? It would be better for our reputation. >> But HEAD is a really bad place for such a setting, given that >> others than ourselves are responsible for make-shift >> pseudoreleases. I don't want to sabotage others doing our work for >> us, not if it can be avoided. > > If someone is clueful enough to make a reasonable "psuedorelease" > from the CVS trunk (e.g., judging if today's snapshot is not a > lemon), then I expect they're also clueful enough to turn off > xassert. Well, if you don't consider the developers themselves, the readers of this list, to have the mental capacity to turn assertions on when asked for it, I don't see why non-developers should be expected to be so much more smart. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum