Michael Petch <[email protected]> writes: > As for why this seems somewhat fixed in 1.02.000 is not because of an > actual change in the code, but a change in compiling. In 1.02.000 this > Changelog entry now applies:
> 2013-07-22 Michael Petch <[email protected]> > Add a new configure option --enable-gasserts . Previously > g_assert macros have been enabled by default. They are now > disabled by default. This option is used to enable those > macros. > g_asserts within the GNUBG code are off by now, the GTK ones are > unchanged. So the hard failure that use to exist because of a g_assert > is not reached, but a future GTK one is unmasked. Ah! Yes, that makes perfect sense now that you point that out. I think this behavior (at least in this case) is better, since the original bug report was about the information loss from having gnubg crash in the middle of a long match, and this avoids the crash. Not displaying the dialog makes sense to me. I agree that people probably aren't looking for this information; the bug reporter ran into it by accident. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
