all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: emacs-devel@gnu.org, Jason Rumney <jasonr@gnu.org>
Subject: Re: xassert in dispextern.h
Date: Tue, 01 Mar 2005 23:02:50 +0100	[thread overview]
Message-ID: <x54qfvkos5.fsf@lola.goethe.zz> (raw)
In-Reply-To: <m3sm3fm5hw.fsf@kfs-l.imdomain.dk> (Kim F. Storm's message of "Tue, 01 Mar 2005 22:16:27 +0100")

storm@cua.dk (Kim F. Storm) writes:

> Jason Rumney <jasonr@gnu.org> 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	other threads:[~2005-03-01 22:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-01 16:47 xassert in dispextern.h David Kastrup
2005-03-01 17:08 ` David Kastrup
2005-03-01 18:58   ` Jason Rumney
2005-03-01 19:41     ` David Kastrup
2005-03-01 21:32       ` Kim F. Storm
2005-03-01 21:51         ` David Kastrup
2005-03-01 22:50           ` Miles Bader
2005-03-01 23:14             ` Kim F. Storm
2005-03-02  0:52               ` David Kastrup
2005-03-03  2:29               ` Richard Stallman
2005-03-01 23:17             ` Luc Teirlinck
2005-03-02  0:35               ` Miles Bader
2005-03-02  1:01                 ` David Kastrup
2005-03-02  1:17                   ` Miles Bader
2005-03-02  1:38                     ` David Kastrup
2005-03-02  9:13                 ` Kim F. Storm
2005-03-02  9:47                   ` Miles Bader
2005-03-02 11:42                     ` Kim F. Storm
2005-03-02 12:21                     ` Andreas Schwab
2005-03-01 21:16     ` Kim F. Storm
2005-03-01 22:02       ` David Kastrup [this message]
2005-03-01 17:13 ` David Kastrup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x54qfvkos5.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=jasonr@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.