gnus-treat-date-local

gnus-treat-date-local

[Kai Haberzettl]

When I set gnus-treat-date-local to t, XEmacs spits out this everytime 
I enter a mail. Doesn't happen with news-articles.

   [parse-time-tokenize, parse-time-string, byte-code, date-to-time, article-make-date-line, article-date-ut, article-date-local, apply, if, save-excursion, gnus-article-date-local, gnus-treat-article, gnus-display-mime, gnus-article-prepare-display, gnus-article-prepare, gnus-summary-display-article, gnus-summary-select-article, gnus-summary-scroll-up, call-interactively]

Kai 
-- 
"We had it tough ... I had to get up at 9 o'clock at night, half
an hour before I went to bed, eat a lump of dry poison, work 29
hours down mill, and when we came home our Dad would kill us,
and dance about on our grave singing Haleleuia ..."  -- Monty Python

Re: gnus-treat-date-local

[Kai Haberzettl]

Kai Haberzettl <khaberz@synnet.de> writes:

> When I set gnus-treat-date-local to t, XEmacs spits out this everytime 
> I enter a mail. Doesn't happen with news-articles.

Actually it does happen with news-articles as well. Not with all of
them though. *shrug*

Kai
-- 
"We had it tough ... I had to get up at 9 o'clock at night, half
an hour before I went to bed, eat a lump of dry poison, work 29
hours down mill, and when we came home our Dad would kill us,
and dance about on our grave singing Haleleuia ..."  -- Monty Python

Re: gnus-treat-date-local

[Lars Magne Ingebrigtsen]

Kai Haberzettl <khaberz@synnet.de> writes:

> When I set gnus-treat-date-local to t, XEmacs spits out this everytime 
> I enter a mail. Doesn't happen with news-articles.
> 
>    [parse-time-tokenize, parse-time-string, byte-code, date-to-time, article-make-date-line, article-date-ut, article-date-local, apply, if, save-excursion, gnus-article-date-local, gnus-treat-article, gnus-display-mime, gnus-article-prepare-display, gnus-article-prepare, gnus-summary-display-article, gnus-summary-select-article, gnus-summary-scroll-up, call-interactively]

This looks like output from an XEmacs with debugging switched on.
Switch it off.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-treat-date-local

[Kai Haberzettl]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> This looks like output from an XEmacs with debugging switched on.
> Switch it off.

Hm. How?
debug-on-error is switched off. But that's not what you mean, right?
 
Kai
-- 
"We had it tough ... I had to get up at 9 o'clock at night, half
an hour before I went to bed, eat a lump of dry poison, work 29
hours down mill, and when we came home our Dad would kill us,
and dance about on our grave singing Haleleuia ..."  -- Monty Python

Re: gnus-treat-date-local

[Lars Magne Ingebrigtsen]

Kai Haberzettl <khaberz@synnet.de> writes:

> debug-on-error is switched off. But that's not what you mean, right?

No -- there's a configure option called --error-checking=none that
should be used if you actually want to use the XEmacs you compile.
--debug=no is also nice.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: gnus-treat-date-local

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> No -- there's a configure option called --error-checking=none that
> should be used if you actually want to use the XEmacs you compile.
> --debug=no is also nice.

Unfortunately, for XEmacs 21beta, it's awfully useful to have
error-checking and debug both enabled, 'cuz 21beta can crash a lot (I
sent in another crash report just a little while ago).  To get rid of
the annoying & pointless miniature stack trace, apply this patch and
rebuild:

--- src/data.c.~1~	Sat Dec  5 11:55:27 1998
+++ src/data.c	Mon Jan 25 08:35:39 1999
@@ -77,6 +77,7 @@
 int
 eq_with_ebola_notice (Lisp_Object obj1, Lisp_Object obj2)
 {
+#if 0
   if (debug_issue_ebola_notices != -42 /* abracadabra */ &&
       (((CHARP (obj1) && INTP (obj2)) || (CHARP (obj2) && INTP (obj1)))
        && (debug_issue_ebola_notices >= 2
@@ -90,6 +91,7 @@
       write_c_string (")\n", Qexternal_debugging_output);
       debug_short_backtrace (debug_ebola_backtrace_length);
     }
+#endif /* 0 */
   return EQ (obj1, obj2);
 }
 

Re: gnus-treat-date-local

[Kai Haberzettl]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> No -- there's a configure option called --error-checking=none that
> should be used if you actually want to use the XEmacs you compile.

Oh, OK. My XEmacs is actually configured with this option.

./configure  '--with-toolbars=no' '--with-session=yes' '--with-mule=yes' '--with-offix=yes' '--error-checking=none' '--with-scrollbars=motif' '--with-dialogs=motif' '--prefix=/opt/xemacs'

> --debug=no is also nice.

I'll try that as well as Karl's patch. Thanks.

Kai
-- 
"We had it tough ... I had to get up at 9 o'clock at night, half
an hour before I went to bed, eat a lump of dry poison, work 29
hours down mill, and when we came home our Dad would kill us,
and dance about on our grave singing Haleleuia ..."  -- Monty Python

XEmacs error checking and Ebola notices

[Hrvoje Niksic]

Karl Kleinpaste <karl@justresearch.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> > No -- there's a configure option called --error-checking=none that
> > should be used if you actually want to use the XEmacs you compile.
> > --debug=no is also nice.
> 
> Unfortunately, for XEmacs 21beta, it's awfully useful to have
> error-checking and debug both enabled, 'cuz 21beta can crash a lot

Karl, you must be misunderstanding the notion of error checking in
this context.  Despite the name, "error checking" will cause your
XEmacs to crash *more*, not less.  The idea is that the beta testers
compile with error checking, which will make their XEmacs much slower,
and make it crash at the first sign of error, so the bug can get
diagnosed and fixed (the alternative being a seemingly mysterious
crash at an unrelated place.)  Take, for instance, this expression:

    Lisp_Object foo = XCAR (somecons);

When you write this, you get speedy inline code, and you promise that
`somecons' indeed contains a cons.  Without error-checking (and
assuming no union type), it will expand to something like:

    Lisp_Object foo = (((struct Lisp_Cons *)somecons)->car);

This means that if there is a bug in the code, and somecons happens
not to contain a valid cons, foo can get junk, and you get a crash at
a totally unrelated place later.

With error checking, the above would expand to something like:

    Lisp_Object foo = error_check_cons (somecons)->car;

...where error_check_cons() aborts if not passed a Lisp_Object of type 
cons.

For this reason, it is *very* important that XEmacs beta testers
attempt to run with error checking (on by default in beta XEmacsen),
so that freshly introduced bugs get noticed and fixed before they are
unleashed to the public at large.

The (now almost totally bogus and obsolete) Ebola notices get
triggered by `--debug' (also default in betas).  The debug code is
rarely useful, except for very esoteric purposes of running gdb and
stuff, so it should be fine to compile without it.

I think there should be a configure flag to just disable Ebola notices 
without touching those other internal debugging facilities.

> --- src/data.c.~1~	Sat Dec  5 11:55:27 1998
> +++ src/data.c	Mon Jan 25 08:35:39 1999
> @@ -77,6 +77,7 @@
>  int
>  eq_with_ebola_notice (Lisp_Object obj1, Lisp_Object obj2)
>  {
> +#if 0
>    if (debug_issue_ebola_notices != -42 /* abracadabra */ &&
>        (((CHARP (obj1) && INTP (obj2)) || (CHARP (obj2) && INTP (obj1)))
>         && (debug_issue_ebola_notices >= 2
> @@ -90,6 +91,7 @@
>        write_c_string (")\n", Qexternal_debugging_output);
>        debug_short_backtrace (debug_ebola_backtrace_length);
>      }
> +#endif /* 0 */
>    return EQ (obj1, obj2);
>  }

I think you should rather turn off the code in lisp.h:

    #ifdef DEBUG_XEMACS
    extern int debug_issue_ebola_notices;
    int eq_with_ebola_notice (Lisp_Object, Lisp_Object);
    #define EQ_WITH_EBOLA_NOTICE(obj1, obj2)				\
      (debug_issue_ebola_notices ? eq_with_ebola_notice (obj1, obj2)	\
       : EQ (obj1, obj2))
    #else
    #define EQ_WITH_EBOLA_NOTICE(obj1, obj2) EQ (obj1, obj2)
    #endif

I leave creating a patch as an excercise to the reader.  :-)

Re: gnus-treat-date-local

[Kai Haberzettl]

Karl Kleinpaste <karl@justresearch.com> writes:

> Unfortunately, for XEmacs 21beta, it's awfully useful to have
> error-checking and debug both enabled, 'cuz 21beta can crash a lot (I
> sent in another crash report just a little while ago).  To get rid of
> the annoying & pointless miniature stack trace, apply this patch and
> rebuild:

OK, this did the job. The messages are gone.
Thanks!

Kai
-- 
"We had it tough ... I had to get up at 9 o'clock at night, half
an hour before I went to bed, eat a lump of dry poison, work 29
hours down mill, and when we came home our Dad would kill us,
and dance about on our grave singing Haleleuia ..."  -- Monty Python

Re: XEmacs error checking and Ebola notices

[Karl Kleinpaste]

I understand just fine, right down to maximally-early crash in the
face of the slightest internal error.  My point is that I want all
that nifty error-checking and debugging code, *but* the ebola notices
are raw noise and nothing more.  So my little 2-line patch is for the
minimal source tweak so as to stop that notice and nothing more,
leaving all other beta-tester magic in place -- notably, I don't want
to touch lisp.h.

Re: XEmacs error checking and Ebola notices

[Didier Verna]

Karl Kleinpaste writes:

Karl> I understand just fine, right down to maximally-early crash in the face
Karl> of the slightest internal error. My point is that I want all that nifty
Karl> error-checking and debugging code, *but* the ebola notices are raw noise
Karl> and nothing more. So my little 2-line patch is for the minimal source
Karl> tweak so as to stop that notice and nothing more, leaving all other
Karl> beta-tester magic in place -- notably, I don't want to touch lisp.h.

	The real problem is that Ebola is not smart enough. For instance, if
you're comparing with different elements of a list containing chars, ints,
conses etc, you probably know what you're doing and Ebola should shut up. So
if we had something to do about Ebola, it would be to make it smarter ... or
to get rid of it ... definitively.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: XEmacs error checking and Ebola notices

[Hrvoje Niksic]

Karl Kleinpaste <karl@justresearch.com> writes:

> I understand just fine, right down to maximally-early crash in the
> face of the slightest internal error.

Sorry, I must have misread your message.

> My point is that I want all that nifty error-checking and debugging
> code, *but* the ebola notices are raw noise and nothing more.

I agree.  The usefulness of Ebola messages is behind us, and they
should be eliminated, at least by default.  And there should
*definitely* be a separate `#ifdef EBOLA' flag in lisp.h instead of
the generic `#ifdef DEBUG_XEMACS'.

> So my little 2-line patch is for the minimal source tweak so as to
> stop that notice and nothing more, leaving all other beta-tester
> magic in place -- notably, I don't want to touch lisp.h.

Touching lisp.h is OK in this case, I think.