emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xassert in dispextern.h


From: David Kastrup
Subject: Re: xassert in dispextern.h
Date: Tue, 01 Mar 2005 23:02:50 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> Jason Rumney <address@hidden> writes:
>>
>> What's completely backwards is to turn off a feature that helps us
>> find bugs so that people can treat the CVS HEAD as a stable release
>> of Emacs.
>
> I agree with David that the benefits from the xasserts do not
> justify the costs at this stage of development.  IIRC, even 21.1 was
> released without having xasserts defined by default during pretest.

The problem with assertions is that they are usually are put in
because of a particular suspicion.  Then the stuff gets tested, and
the suspicion confirmed or not.  That is the most active life time of
an assertion.  After that, it mainly remains for what amounts to
regression testing purposes: making sure that one does not reintroduce
old bugs.  But that usually can be done by checking just occasionally
with assertions enabled, in particular if old problems resurface.

With the kind of display crashes I had recently, the only way to debug
this is to make a test case.  We currently have some situations where
using the line movement or scrolling commands does not make progress.
This is a bit of a nuisance.  Only a few of those cases now cause
crashes due to xasserts.  But the cases causing crashes in no way are
more important than the others.  This is shifting priorities in the
wrong way: the behavior of Emacs-21.4 in that regard was _much_ worse
than what we have now.  Crashes make a problem top priority, and the
crashes that I had did not make sense: the problem was known and
accessible even before the crashes, and is in Kim's ballpark, more or
less.  It is important, but not necessarily release-critical.  If one
movement command in some special situation does not make progress, it
is easy enough to use another one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

[Prev in Thread] Current Thread [Next in Thread]