From: David Kastrup <dak@gnu.org>
Cc: jasonr@gnu.org, emacs-devel@gnu.org,
Luc Teirlinck <teirllm@dms.auburn.edu>,
storm@cua.dk, miles@gnu.org
Subject: Re: xassert in dispextern.h
Date: Wed, 02 Mar 2005 02:38:17 +0100 [thread overview]
Message-ID: <x5vf8aj08m.fsf@lola.goethe.zz> (raw)
In-Reply-To: <fc339e4a0503011717145890a@mail.gmail.com> (Miles Bader's message of "Wed, 2 Mar 2005 10:17:33 +0900")
Miles Bader <snogglethorpe@gmail.com> writes:
> On Wed, 02 Mar 2005 02:01:54 +0100, David Kastrup <dak@gnu.org> 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
next prev parent reply other threads:[~2005-03-02 1:38 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x5vf8aj08m.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jasonr@gnu.org \
--cc=miles@gnu.org \
--cc=storm@cua.dk \
--cc=teirllm@dms.auburn.edu \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).