bootstrap problem with union Lisp_Object

bootstrap problem with union Lisp_Object

[Ken Raeburn]

I'm still trying to track this down, but just for the record: If I  
build recent sources with CC='gcc -DENABLE_CHECKING - 
DUSE_LISP_UNION_TYPE', bootstrapping fails:

Compiling /var/raeburn/emacs-hacking/fsf/source/lisp/emacs-lisp/byte- 
opt.el
Error: Invalid function: 4
Error: Invalid function: 4
Error: Invalid function: 4
Error: Invalid function: 4
Error: Invalid function: 4
Error: Invalid function: 4

In toplevel form:
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
../../source/lisp/emacs-lisp/byte-opt.el:186:1:Error: Invalid  
function: 4
make[2]: *** [compile] Error 1

With the usual (integral) Lisp_Object type, bootstrapping works fine.

Ken

Re: bootstrap problem with union Lisp_Object

[Ken Raeburn]

> I'm still trying to track this down, but just for the record: If I  
> build recent sources with CC='gcc -DENABLE_CHECKING - 
> DUSE_LISP_UNION_TYPE', bootstrapping fails:

Fixed...  With these options enabled, EQ evaluates its arguments  
twice.  A while back, Stefan changed NILP to use EQ instead of  
XFASTINT, which is cleaner, but it turns out some invocations of NILP  
had non-idempotent arguments.  I've fixed the cases I spotted that  
looked troublesome, especially in the bytecode interpreter; some  
others may still be minor performance issues, like calling intern or  
Ffile_name_directory twice.  Since few people besides me seem to use  
the union-type mode, and I do it mostly to check type-cleanliness of  
the Emacs C code (not blindly mixing int and Lisp_Object), I'm not  
too inclined to go after performance issues that won't come up in a  
"real" build that anyone's actually likely to use.  (Do any platforms  
actually use that configuration any more?)

I'm unsure about this bit in w32select.c:
	  ok = !NILP(render (make_number (current_clipboard_type)));
Someone familiar with the Windows code should please decide whether  
calling render twice is a bad thing, and if so, assign the value to a  
temporary before calling NILP.

With the patches I've checked in, it bootstraps for me on a GNU/Linux  
system with the CC value above.

Ken

Re: bootstrap problem with union Lisp_Object

[Andreas Schwab]

Ken Raeburn <raeburn@raeburn.org> writes:

>> I'm still trying to track this down, but just for the record: If I
>> build recent sources with CC='gcc -DENABLE_CHECKING - 
>> DUSE_LISP_UNION_TYPE', bootstrapping fails:
>
> Fixed...  With these options enabled, EQ evaluates its arguments  
> twice.

I think that should be fixed.  The requirement that arguments of EQ or
NILP need to be side effect free is too easy to forget, since it is
nowhere documented.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bootstrap problem with union Lisp_Object

[Stefan Monnier]

>>> I'm still trying to track this down, but just for the record: If I
>>> build recent sources with CC='gcc -DENABLE_CHECKING - 
>>> DUSE_LISP_UNION_TYPE', bootstrapping fails:
>> 
>> Fixed...  With these options enabled, EQ evaluates its arguments  
>> twice.

> I think that should be fixed.  The requirement that arguments of EQ or
> NILP need to be side effect free is too easy to forget, since it is
> nowhere documented.

The argument of *any* macro should be free of side effects.


        Stefan

Re: bootstrap problem with union Lisp_Object

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> I'm still trying to track this down, but just for the record: If I
>>>> build recent sources with CC='gcc -DENABLE_CHECKING - 
>>>> DUSE_LISP_UNION_TYPE', bootstrapping fails:
>>> 
>>> Fixed...  With these options enabled, EQ evaluates its arguments  
>>> twice.
>
>> I think that should be fixed.  The requirement that arguments of EQ or
>> NILP need to be side effect free is too easy to forget, since it is
>> nowhere documented.
>
> The argument of *any* macro should be free of side effects.

Not necessarily.  Making macros safe on side effects is usually not hard,
and in the case of EQ it is trivial too:

#define EQ(x, y) ((x).i == (y).i)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bootstrap problem with union Lisp_Object

[Stefan Monnier]

>> The argument of *any* macro should be free of side effects.
> Not necessarily.

Like everything, there are exceptions, of course.  But then people who come
and want to change the macro suffer.  I know because I've added an `eassert
(INTEGERP (x))' to the XINT macro (as you may have noticed by looking at
some of the commits I've done a while back).

So please, just move side effects out of macro arguments, even if they don't
hurt with the current definition of the macro.

> Making macros safe on side effects is usually not hard,

Try it with asserts (and without GCC extensions, of course).


        Stefan

Re: bootstrap problem with union Lisp_Object

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Making macros safe on side effects is usually not hard,
>
> Try it with asserts (and without GCC extensions, of course).

IMHO it would be reasonable to require GCC when building with
-DENABLE_CHECKING.  In any case I think that least the basic macros like
NILP and EQ should be side effect safe.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    I'm still trying to track this down, but just for the record: If I  
    build recent sources with CC='gcc -DENABLE_CHECKING - 
    DUSE_LISP_UNION_TYPE', bootstrapping fails:

    Compiling /var/raeburn/emacs-hacking/fsf/source/lisp/emacs-lisp/byte- 
    opt.el
    Error: Invalid function: 4

First step: try running it under GDB with a breakpoint at Fsignal, and
see the immediate cause of that error.

Re: bootstrap problem with union Lisp_Object

[Benjamin Riefenstahl]

Hi Ken,

Ken Raeburn writes:
> I'm unsure about this bit in w32select.c:
> 	  ok = !NILP(render (make_number (current_clipboard_type)));
> Someone familiar with the Windows code should please decide whether
> calling render twice is a bad thing, and if so, assign the value to
> a temporary before calling NILP.

Calling render twice shouldn't cause bugs, but the problem is that
it's a pretty expensive call.

I can make the changes, but I really wonder if a basic and often-used
functionality like NILP should be so dangerous.

benny

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    Fixed...  With these options enabled, EQ evaluates its arguments  
    twice.  A while back, Stefan changed NILP to use EQ instead of  
    XFASTINT, which is cleaner, but it turns out some invocations of NILP  
    had non-idempotent arguments.

Why doesn't EQ use XFASTINT?  We want it to be as fast as possible.

Re: bootstrap problem with union Lisp_Object

[Stefan Monnier]

>     Fixed...  With these options enabled, EQ evaluates its arguments
>     twice.  A while back, Stefan changed NILP to use EQ instead of
>     XFASTINT, which is cleaner, but it turns out some invocations of NILP
>     had non-idempotent arguments.
> Why doesn't EQ use XFASTINT?  We want it to be as fast as possible.

XFASTINT is "slow" (identical to XINT, in the now default case of
USE_LSB_TAG) and incorrect (it fails to check that the tag bits are equal).

If Lisp_Object=int (or long), we want to use "=" directly, which is exactly
what happens with `EQ'.


        Stefan

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    I can make the changes, but I really wonder if a basic and often-used
    functionality like NILP should be so dangerous.

I think this change should be made.  Is there any reason not to
make it?

*** lisp.h	20 Nov 2005 08:36:34 -0500	1.546
--- lisp.h	07 Dec 2005 10:35:10 -0500	
***************
*** 454,460 ****
  extern Lisp_Object make_number P_ ((EMACS_INT));
  #endif
  
! #define EQ(x, y) ((x).s.val == (y).s.val && (x).s.type == (y).s.type)
  
  #endif /* NO_UNION_TYPE */
  
--- 454,460 ----
  extern Lisp_Object make_number P_ ((EMACS_INT));
  #endif
  
! #define EQ(x, y) ((x).i == (y).i)
  
  #endif /* NO_UNION_TYPE */

Re: bootstrap problem with union Lisp_Object

[Ken Raeburn]

On Dec 6, 2005, at 10:52, Andreas Schwab wrote:
> Not necessarily.  Making macros safe on side effects is usually not  
> hard,

Not sure I agree with that part, as Stefan pointed out...

> and in the case of EQ it is trivial too:
>
> #define EQ(x, y) ((x).i == (y).i)

Yes, I think that would work... I'll try a bootstrap just to be sure,  
but it looks fine.

Ken

Re: bootstrap problem with union Lisp_Object

[Ken Raeburn]

On Dec 6, 2005, at 11:30, Andreas Schwab wrote:
>> Try it with asserts (and without GCC extensions, of course).
>
> IMHO it would be reasonable to require GCC when building with
> -DENABLE_CHECKING.

If people think this is a good idea, I could start changing those  
macros that use eassert (XSET, XCONS, XVECTOR, ...) to have GCC and  
non-GCC versions, with the GCC versions using statement expressions  
(inline functions wouldn't preserve the file and line number) and  
temporary variables, and error out if ENABLE_CHECKING is defined but  
GCC isn't used.  Should be straightforward, about a dozen places or  
so to change I think.

>   In any case I think that least the basic macros like
> NILP and EQ should be side effect safe.

It would be nice.  CAR and CDR already fail that test for other  
reasons, though.  With ENABLE_CHECKING, most of the basic Lisp object  
manipulation macros do, because they double-check that the type is  
correct before extracting data.

Ken

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    If people think this is a good idea, I could start changing those  
    macros that use eassert (XSET, XCONS, XVECTOR, ...) to have GCC and  
    non-GCC versions, with the GCC versions using statement expressions  
    (inline functions wouldn't preserve the file and line number) and  
    temporary variables, and error out if ENABLE_CHECKING is defined but  
    GCC isn't used.  Should be straightforward, about a dozen places or  
    so to change I think.

Is this really necessary now?  I hope not.

Re: bootstrap problem with union Lisp_Object

[Ken Raeburn]

On Dec 7, 2005, at 23:54, Richard M. Stallman wrote:
>     If people think this is a good idea, I could start changing those
>     macros that use eassert (XSET, XCONS, XVECTOR, ...) to have GCC  
> and
>     non-GCC versions, with the GCC versions using statement  
> expressions
>     (inline functions wouldn't preserve the file and line number) and
>     temporary variables, and error out if ENABLE_CHECKING is  
> defined but
>     GCC isn't used.  Should be straightforward, about a dozen  
> places or
>     so to change I think.
>
> Is this really necessary now?  I hope not.

No, but without such a thing -- or some other approach like replacing  
some of these macros with functions -- the ENABLE_CHECKING version of  
these macros will evaluate arguments more than once.  As far as I  
know, most if not all of the actual uses are cases where this doesn't  
cause much trouble except perhaps for performance.

Ken

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    No, but without such a thing -- or some other approach like replacing  
    some of these macros with functions -- the ENABLE_CHECKING version of  
    these macros will evaluate arguments more than once.  As far as I  
    know, most if not all of the actual uses are cases where this doesn't  
    cause much trouble except perhaps for performance.

There isn't a pressing need to change them, so we will leave them
alone.

Please, everyone, stop suggesting changes merely because they might be
improvements.  That's not a sufficient reason to suggest a change now.
We need to focus on the work that NEEDS to be done: fixing bugs,
and tuning the new features.

Please see etc/FOR-RELEASE.

I am always a day behind in answering email.   I therefore ask
the others on this list to help focus activities, by reminding
people of this policy faster than I can.  If you see someone
make a suggestion which is not about fixing a bug or tuning a new
feature, please respond by saying, politely, that now is the
wrong time to propose such issues and would people please
refrain from further discussion of the inappropriate proposal.

Re: bootstrap problem with union Lisp_Object

[Stefan Monnier]

> Please, everyone, stop suggesting changes merely because they might be
> improvements.  That's not a sufficient reason to suggest a change now.
> We need to focus on the work that NEEDS to be done: fixing bugs,
> and tuning the new features.

> Please see etc/FOR-RELEASE.

I don't see why those things need to all be fixed before we start
the pretest.


        Stefan

Re: bootstrap problem with union Lisp_Object

[Henrik Enberg]

> > Please, everyone, stop suggesting changes merely because they might be
> > improvements.  That's not a sufficient reason to suggest a change now.
> > We need to focus on the work that NEEDS to be done: fixing bugs,
> > and tuning the new features.
> 
> > Please see etc/FOR-RELEASE.
> 
> I don't see why those things need to all be fixed before we start
> the pretest.

On he subject of FOR-RELEASE, the "C-h v warning-type-format gives
"Search failed"." item was fixed by Luc Teirlinck with his 2005-11-21
change to startup.el.

Re: bootstrap problem with union Lisp_Object

[Luc Teirlinck]

Henrik Enberg wrote:

   On he subject of FOR-RELEASE, the "C-h v warning-type-format gives
   "Search failed"." item was fixed by Luc Teirlinck with his 2005-11-21
   change to startup.el.

Thanks.  I removed the item.  (I did not realize that it was listed in
FOR-RELEASE.)

Sincerely,

Luc.

Re: bootstrap problem with union Lisp_Object

[Juri Linkov]

>> > Please see etc/FOR-RELEASE.
>> 
>> I don't see why those things need to all be fixed before we start
>> the pretest.
>
> On he subject of FOR-RELEASE, the "C-h v warning-type-format gives
> "Search failed"." item was fixed by Luc Teirlinck with his 2005-11-21
> change to startup.el.

Same question about the item removed from FOR-RELEASE:

    ** Update what needs to be updated now that Global Font Lock mode and
       File Name Shadow mode are enabled by default.

The node (info "(emacs)Font Lock") currently says:

    Global Font Lock mode can also be set using the menu bar Options menu,
    specifying first Syntax Highlighting and then Save Options.

but I can't find such menu item.  If this menu item is not necessary anymore,
then the whole sentence should be removed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    I don't see why those things need to all be fixed before we start
    the pretest.

Because we aim to make a release with all known bugs fixed.
It makes no sense to postpone debugging the bugs we know about
in order to discover more bugs.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    On he subject of FOR-RELEASE, the "C-h v warning-type-format gives
    "Search failed"." item was fixed by Luc Teirlinck with his 2005-11-21
    change to startup.el.

Thanks for pointing that out.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I don't see why those things need to all be fixed before we start
>     the pretest.
>
> Because we aim to make a release with all known bugs fixed.
> It makes no sense to postpone debugging the bugs we know about
> in order to discover more bugs.

That is illogical.  If we're going to discover more bugs, it is better
to do it earlier than later.  You're implying that the Emacs
developers are all busy fixing bugs.  I don't think this is accurate.

In fact, the main thing holding the release (by your
fix-every-known-bug criteria) is the string_free_list issue.  So far,
the only way we have of debugging this is exchanging emails with the
only user currently known to experience the crash.  This is an
inherently slow process, and in the meantime we're sitting around
twiddling our thumbs -- exactly the opposite scenario!

Holding the pretest will not help resolve the string_free_list bug.
On the contrary; if we started the pretest now, there would at least
be a few more bug reports coming in, which can be worked on in the
meantime, bringing us closer to the release.

(The short way of saying this is that bug-fixing takes place in
parallel, not in series.)

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    The node (info "(emacs)Font Lock") currently says:

	Global Font Lock mode can also be set using the menu bar Options menu,
	specifying first Syntax Highlighting and then Save Options.

    but I can't find such menu item.

That menu item was deleted, so I agree this sentence should
be deleted.  I did.

I don't see any other thing in that node which needs changing.

Re: bootstrap problem with union Lisp_Object

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Fri, 09 Dec 2005 16:14:26 -0500
> Cc: schwab@suse.de, raeburn@raeburn.org, emacs-devel@gnu.org
> 
>     I don't see why those things need to all be fixed before we start
>     the pretest.
> 
> Because we aim to make a release with all known bugs fixed.

Starting the pretest is not the same as making a release.  As others
have pointed out, the couple of bugs that are still in FOR-RELEASE can
be worked on during the pretest; as a matter of fact, the pretest
could actually _help_ us debug them because it could reveal more users
who can reproduce the bugs and provide useful information about it.

> It makes no sense to postpone debugging the bugs we know about
> in order to discover more bugs.

Of course it does: people who work on fixing bugs do that in parallel,
not sequentially.  So the more bugs are known at any given point, the
sooner will we release Emacs 22 with all those bugs fixed.

Re: bootstrap problem with union Lisp_Object

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I don't see why those things need to all be fixed before we start
>     the pretest.
>
> Because we aim to make a release with all known bugs fixed.

How can we do that without some kind of bug tracking system?
And who decides what is a "bug" and what is a "missing feature" or
"enhancement request".

May I suggest that you (RMS) add _all_ bugs that you want to be fixed
before the release to FOR-RELEASE, and then change the above to:

"Because we aim to make a release with all the bugs listed in
FOR-RELEASE fixed."


Or even better, we should make a file etc/KNOWN_BUGS which we can keep
up-to-date with known, unresolved bugs.

Then we can _at any time_ decide that the bugs listed in KNOWN_BUGS
are not severe enough to justify delaying the release.

And we should distribute KNOWN_BUGS with the release, so users can
look in that file to see if we already know about a bug (M-x
report-emacs-bug could point users to that file).


> It makes no sense to postpone debugging the bugs we know about
> in order to discover more bugs.

Who's talking about postponing debugging of known bugs?

So I disagree!  Some bugs are more severe than others, and one of the
most severe has yet to be resolved -- the more people who test
the software, the better the chance of narrowing in on that bug.

So let's start the pretest NOW!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Pretest? [was: Re: bootstrap problem with union Lisp_Object]

[Nick Roberts]

 > > It makes no sense to postpone debugging the bugs we know about
 > > in order to discover more bugs.
 > 
 > Who's talking about postponing debugging of known bugs?
 > 
 > So I disagree!  Some bugs are more severe than others, and one of the
 > most severe has yet to be resolved -- the more people who test
 > the software, the better the chance of narrowing in on that bug.
 > 
 > So let's start the pretest NOW!

We've been here nearly two years ago but I guess things have moved forward
enough so that ideas rejected then might be acceptable now.

When the pretest is released, hopefully soon, I suggest that a branch is cut.
I may be wrong but I think this is usual practice.  I don't think this will
mean that effort will be taken away from the release as many developers have
expressed an interest in seeing one.  It will, however, discourage adding
further changes which are not really bug fixes, and indeed, may introduce new
bugs.  In fact, I think there should be a strict rule that only changes that
relate to identified bugs be allowed on this branch.  There will also an
incentive to get the release out, so that normal development can resume on the
trunk.

Nick

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    Starting the pretest is not the same as making a release.  As others
    have pointed out, the couple of bugs that are still in FOR-RELEASE can
    be worked on during the pretest;

LOTS of bugs have been reported in the past two weeks, and I think
many have not been worked on at all.  We are already out about more
bugs faster than we are fixing them, and the cause is simple: we are
not working enough on fixing them.  To help us move towards a release,
please fix some of these bugs!

There is also other work in FOR-RELEASE which is just straightforward
work, rather than debugging.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Starting the pretest is not the same as making a release.  As others
>     have pointed out, the couple of bugs that are still in FOR-RELEASE can
>     be worked on during the pretest;
>
> LOTS of bugs have been reported in the past two weeks, and I think
> many have not been worked on at all.  We are already out about more
> bugs faster than we are fixing them, and the cause is simple: we are
> not working enough on fixing them.  To help us move towards a release,
> please fix some of these bugs!

As Kim has mentioned, it is unclear what bugs you are referring to.
There are only a couple of bugs listed in FOR-RELEASE.  The bugs in
emacs-pretest-bug, which are usually minor problems, get fixed at
about the same rate as they are being reported, i.e. after a few days.
Maybe the reason you have the idea that bugs aren't being fixed
because developers sometimes don't send a follow-up email to the list
when they check their fix into CVS.

Because CVS Emacs is already widely used, there is going to be a
constant stream of bug reports/feature requests.  Without a more
explicit and reasonable criteria for the release, the impression
you're sending is that there is no end in sight for the Emacs 22
release process.  This is a severe disincentive to working on Emacs.

Note that most of the other key Emacs developers have chimed in with
similar sentiments in this thread.

> There is also other work in FOR-RELEASE which is just straightforward
> work, rather than debugging.

Can you be more specific about what you're referring to?

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    May I suggest that you (RMS) add _all_ bugs that you want to be fixed
    before the release to FOR-RELEASE, and then change the above to:

I keep track of bugs, and when nobody works on a bug report for a few
weeks, I do put it into FOR-RELEASE.

I don't do this immediately.  Usually I either ask a specific
appropriate person to work on the bug, or I wait a while, since often
someone will fix the bug.

    Or even better, we should make a file etc/KNOWN_BUGS which we can keep
    up-to-date with known, unresolved bugs.

That would be somewhat more work than what I am doing now.  I have no
objection to maintaining a file admin/KNOWN_BUGS if someone wants to
do it.  That file should not be part of the release.

    Who's talking about postponing debugging of known bugs?

I'm the only one talking about it, but lots of people appear
to be doing it ;-{.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    > There is also other work in FOR-RELEASE which is just straightforward
    > work, rather than debugging.

    Can you be more specific about what you're referring to?

Work on various kinds of documentation, for instance.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    As Kim has mentioned, it is unclear what bugs you are referring to.
    There are only a couple of bugs listed in FOR-RELEASE.  The bugs in
    emacs-pretest-bug, which are usually minor problems, get fixed at
    about the same rate as they are being reported, i.e. after a few days.
    Maybe the reason you have the idea that bugs aren't being fixed
    because developers sometimes don't send a follow-up email to the list
    when they check their fix into CVS.

I hope soon to have time to recheck the saved mail.
But there are several messages I have posted more than once on
this list, with no response, which will go into FOR-RELEASE
when I get future reminders.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

>     > There is also other work in FOR-RELEASE which is just straightforward
>     > work, rather than debugging.
>
>     Can you be more specific about what you're referring to?
>
> Work on various kinds of documentation, for instance.

Do you mean checking the manuals?  Almost all the manual files have
been checked by two people, and all have been checked by at least one.
Any remaining mistakes in there will be minor details, not big
problems.  Why should this hold the pretest?

Starting the pretest would also get more people to read the manuals,
to unearth mistakes there.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     As Kim has mentioned, it is unclear what bugs you are referring to.
>     There are only a couple of bugs listed in FOR-RELEASE.  The bugs in
>     emacs-pretest-bug, which are usually minor problems, get fixed at
>     about the same rate as they are being reported, i.e. after a few days.
>     Maybe the reason you have the idea that bugs aren't being fixed
>     because developers sometimes don't send a follow-up email to the list
>     when they check their fix into CVS.
>
> I hope soon to have time to recheck the saved mail.
> But there are several messages I have posted more than once on
> this list, with no response, which will go into FOR-RELEASE
> when I get future reminders.

That does not mean no one is working on fixing those few bugs; just
that they have not been fixed yet.  It is not an argument against
starting the pretest.  As people have pointed out several times, it is
better to know about bugs earlier rather than later, since bug fixing
takes place in parallel, not sequentially.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    Do you mean checking the manuals?  Almost all the manual files have
    been checked by two people, and all have been checked by at least one.

I wish I could be so confident, but Luc just checked custom.texi
and found many gross errors.  I updated the Lisp manual systematically
a year ago, but have not done the Emacs manual at all.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    That does not mean no one is working on fixing those few bugs; just
    that they have not been fixed yet.

It does not prove no one is working on fixing those bugs,
but I suspect that nobody is.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     That does not mean no one is working on fixing those few bugs; just
>     that they have not been fixed yet.
>
> It does not prove no one is working on fixing those bugs,
> but I suspect that nobody is.

You snipped my main point:

  It is not an argument against starting the pretest.  As people have
  pointed out several times, it is better to know about bugs earlier
  rather than later, since bug fixing takes place in parallel, not
  sequentially.

You still haven't given any argument against starting the pretest,
apart from some kind of gut feeling that the Emacs developers aren't
working hard enough to fix bugs.

Re: bootstrap problem with union Lisp_Object

[Stefan Monnier]

> It does not prove no one is working on fixing those bugs,
> but I suspect that nobody is.

I'm not working hard on fixing bugs, indeed, because I pretty demotivated by
the never ending "preparation for pretest" and because those non-trivial
bugs don't have nearly enough info: we need more testers.



        Stefan

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    You still haven't given any argument against starting the pretest,
    apart from some kind of gut feeling that the Emacs developers aren't
    working hard enough to fix bugs.

That is the reason.  I think it is a good reason.
I hear that you don't.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     You still haven't given any argument against starting the pretest,
>     apart from some kind of gut feeling that the Emacs developers aren't
>     working hard enough to fix bugs.
>
> That is the reason.  I think it is a good reason.
> I hear that you don't.

Actually, I think it's the worst possible reason you could give; but
apparently my opinion, and the opinions of every other Emacs hacker
who's weighed in on this topic, don't count for anything.  So be it.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    I'm not working hard on fixing bugs, indeed, because I pretty demotivated by
    the never ending "preparation for pretest" and because those non-trivial
    bugs don't have nearly enough info: we need more testers.

That would be a good point, if not for the fact that we seem to have a
person who can give us useful feedback now.  Yidong is working
effectively on that particular bug.  Meanwhile, there are all the others
which are not nearly so hard, but do take work.

Re: bootstrap problem with union Lisp_Object

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It does not prove no one is working on fixing those bugs,
>> but I suspect that nobody is.
>
> I'm not working hard on fixing bugs, indeed, because I pretty demotivated by
> the never ending "preparation for pretest" and because those non-trivial
> bugs don't have nearly enough info: we need more testers.

I agree. 

With Richard's aim of fixing all known bugs before even starting the
pretest, the release is practically delayed forever, so I'm close to
giving up and find something more productive to spend my time on.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     I'm not working hard on fixing bugs, indeed, because I pretty demotivated by
>     the never ending "preparation for pretest" and because those non-trivial
>     bugs don't have nearly enough info: we need more testers.
>
> That would be a good point, if not for the fact that we seem to have a
> person who can give us useful feedback now.  Yidong is working
> effectively on that particular bug.

I'm not going to keep working on this for much longer if there's going
to be no tangible result.  Even if that bug is fixed, I'm not
confident that there will be an Emacs 22 release.  Bug reports, big or
little, will keep coming in, there will always be something else to
delay the release.  At some point, either you have to say "we'll fix
only the critical regressions from now till the release", or the
release will be delayed forever.  That's the experience of successful
free software projects, such as gcc, firefox, and linux.  What makes
you think Emacs or its developers are so special?

The "fix all bugs" policy probably worked well back in the days when
the development source was closed to all but a handful of developers.
Nowadays, CVS Emacs is used by a large number of users, several orders
of magnitude more than before (effectively, it's *already* gone
through more testing than any previous closed-door Emacs pretest).
Like I said, if you're unable to adapt to the new situation, then so
be it; I'll be sad if Emacs goes into stagnation, but there are other
ways for me to spend my time.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    The "fix all bugs" policy probably worked well back in the days when
    the development source was closed to all but a handful of developers.

The rate at which we're getting bug reports is not unusual for pretests.
back when I did all the work myself, I often got bug reports at that
rate or even faster.  But I had time to fix them.

When we start a pretest, and we get more people trying it, the rate of
bug reporting normally increases.  In the old days, I would fix all
the reported bugs before making each pretest.  And before making the
final release, too.  Normally that would take just a few weeks each
time.  (It usually got faster as the pretest process advanced.)

The difference now is that not that we get more bug reports
but that we fix them more slowly.

Does that mean we have to abandon the practice of making pretests and
releases with all bugs fixed?  Many people are taking that for granted.
I have been hoping, rather, to convince people to do more fixing
so that we could maintain our old standards.

Re: bootstrap problem with union Lisp_Object

[Stefan Monnier]

> Does that mean we have to abandon the practice of making pretests and
> releases with all bugs fixed?  Many people are taking that for granted.
> I have been hoping, rather, to convince people to do more fixing
> so that we could maintain our old standards.

A never ending pre-pre-test, with a complete lack of feature freeze, is
a complete turn off for me to try and fix bugs.  So instead I just keep
on hacking.


        Stefan

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    A never ending pre-pre-test, with a complete lack of feature freeze,

Your discouragement is speaking--exaggerating the situation.  I am
rejecting even small featurelets nowadays, and the we can have a
pretest soon if you start fixing more bugs.

Re: bootstrap problem with union Lisp_Object

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     A never ending pre-pre-test, with a complete lack of feature freeze,
>
> Your discouragement is speaking--exaggerating the situation.  I am
> rejecting even small featurelets nowadays, and the we can have a
> pretest soon if you start fixing more bugs.

We more or less have had a feature freeze since May 2004, and have
been "fixing more bugs" ever since in preparation for the pretest.  

So I don't see any evidence that "fixing more bugs" will actually lead
to a pretest.

I believe that emacs 22.x (via CVS downloads) has already received
infinitely more testing than any previous emacs pretest has achieved,
so the bugs we see now are the bugs that previously (with the closed
development model of 21.1) would have been discovered (long time)
after the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    We more or less have had a feature freeze since May 2004, and have
    been "fixing more bugs" ever since in preparation for the pretest.  

In May 2004 we had a lot of tasks to do before we could make a
release, including finishing updating the manual.  Everyone wanted a
release, but few people helped update the manual.  We also had various
other serious problems to be solved, some of which you have helped
solve.  We are much closer now.  We are even making progress on those
horrible memory clobbering bugs--but this occurred because I've
pressured for it.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

>     We more or less have had a feature freeze since May 2004, and have
>     been "fixing more bugs" ever since in preparation for the pretest.  
>
> In May 2004 we had a lot of tasks to do before we could make a
> release, including finishing updating the manual.  Everyone wanted a
> release, but few people helped update the manual.  We also had various
> other serious problems to be solved, some of which you have helped
> solve.  We are much closer now.

By 2008, I'm sure we will be even closer; and still closer in 2010,
2012, etc.

Re: bootstrap problem with union Lisp_Object

[Chong Yidong]

"Richard M. Stallman" <rms@gnu.org> writes:

> Does that mean we have to abandon the practice of making pretests and
> releases with all bugs fixed?  Many people are taking that for granted.
> I have been hoping, rather, to convince people to do more fixing
> so that we could maintain our old standards.

GCC, Firefox, Linux, and many other projects use a "critical
regressions only" policy to get releases out more quickly.  I've never
heard anyone complaining about this practice, whereas many people are
dissatisfied with the slow rate of Emacs releases.

Re: bootstrap problem with union Lisp_Object

[Richard M. Stallman]

    By 2008, I'm sure we will be even closer; and still closer in 2010,
    2012, etc.

Please don't exaggerate.