Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs

Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs

[Eli Zaretskii]

What is the reason for this change in src/Makefile.in?  Are you
saying that the default value of PURESIZE is large enough to load
*.el files in source form?

    - /* Build a temacs with a sufficiently large PURESIZE to load the
    -    Lisp files from loadup.el in source form.  */
    - 
    - bootstrap-temacs: 
    - 	LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
    - 

Also, is it wise to avoid building DOC during the bootstrap?  Are we
sure it will never be used?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs

[Stefan Monnier]

> What is the reason for this change in src/Makefile.in?  Are you
> saying that the default value of PURESIZE is large enough to load
> *.el files in source form?
> 
>     - /* Build a temacs with a sufficiently large PURESIZE to load the
>     -    Lisp files from loadup.el in source form.  */
>     - 
>     - bootstrap-temacs: 
>     - 	LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
>     - 

Overflowing the pure area is not a problem.  It's only a performance
issue, which is irrelevant during bootstrap.  Check my patch to
alloc.c committed around the same time.

> Also, is it wise to avoid building DOC during the bootstrap?  Are we
> sure it will never be used?

The DOC file built during bootstrap is not 100% correct and has
to be scrapped and rebuilt once we have the elc files.

I think it'd be a bug if compiling a .el file requires the DOC file.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
> Date: Mon, 25 Mar 2002 11:29:04 -0500
> 
> > What is the reason for this change in src/Makefile.in?  Are you
> > saying that the default value of PURESIZE is large enough to load
> > *.el files in source form?
> > 
> >     - /* Build a temacs with a sufficiently large PURESIZE to load the
> >     -    Lisp files from loadup.el in source form.  */
> >     - 
> >     - bootstrap-temacs: 
> >     - 	LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
> >     - 
> 
> Overflowing the pure area is not a problem.  It's only a performance
> issue, which is irrelevant during bootstrap.  Check my patch to
> alloc.c committed around the same time.

Sorry, I still don't understand.  Can you please epxlain in a few
more words?  The comment in Makefile.in seems to indicate that more
pure storage is needed for loading *.el files--are you saying that
the comment is inaccurate?

Btw, the change in alloc.c makes the comment immediately preceding
check_pure_size, the function you've changed, inaccurate: it still
says we signal an error.

> I think it'd be a bug if compiling a .el file requires the DOC file.

I thought about a (remote) possibility that someone needs to run the
half-bootstrapped Emacs to debug or investigate some problem.  If
they do, they might want documentation features to work.  Not a big
deal, obviously, but so is building DOC.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs

[Stefan Monnier]

> > From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
> > Date: Mon, 25 Mar 2002 11:29:04 -0500
> > 
> > > What is the reason for this change in src/Makefile.in?  Are you
> > > saying that the default value of PURESIZE is large enough to load
> > > *.el files in source form?
> > > 
> > >     - /* Build a temacs with a sufficiently large PURESIZE to load the
> > >     -    Lisp files from loadup.el in source form.  */
> > >     - 
> > >     - bootstrap-temacs: 
> > >     - 	LC_ALL=C $(MAKE) $(MFLAGS) temacs ALL_CFLAGS="$(ALL_CFLAGS) -DPURESIZE=5000000 -I../src"
> > >     - 
> > 
> > Overflowing the pure area is not a problem.  It's only a performance
> > issue, which is irrelevant during bootstrap.  Check my patch to
> > alloc.c committed around the same time.
> 
> Sorry, I still don't understand.  Can you please epxlain in a few
> more words?  The comment in Makefile.in seems to indicate that more
> pure storage is needed for loading *.el files--are you saying that
> the comment is inaccurate?

It is inaccurate now.  It does use more memory and can make use of
more pure memory, but that's not enough justification to build
a separate temacs.

It used to be that if there wasn't enough pure memory and we
tried to allocate some pure storage Emacs would just halt.
Now it keeps going, allocating in non-pure storage instead and
signalling that the pure storage overflowed.  This way the
use of pure storage is just an optimization issue.  So the
PURESIZE is optimized for the non-bootstrap case but still
works for the bootstrap case.

> Btw, the change in alloc.c makes the comment immediately preceding
> check_pure_size, the function you've changed, inaccurate: it still
> says we signal an error.

Oops!

> > I think it'd be a bug if compiling a .el file requires the DOC file.
> 
> I thought about a (remote) possibility that someone needs to run the
> half-bootstrapped Emacs to debug or investigate some problem.  If
> they do, they might want documentation features to work.  Not a big
> deal, obviously, but so is building DOC.

Well, if you feel strongly about it, put it back in with a little comment.
I personally would rather see less bootstrap-specific code.


	Stefan

PS: I almost got bootstrapping to work without a `bootstrap-emacs'
    executable (by byte-compiling with `temacs' instead)
    but hit a problem where `temacs -batch' freezes in call-process:
    the problem is that the SIGCHLD handler is not installed in that
    case (probably because it might introduce problems when we dump).
    As for why `call-process' is called: vc.el does
    (eval-when-compile (require 'ediff-util)) and ediff-util.el
    ends up loading all the ediff*.el files (also from within
    `eval-when-compile' clauses) and ediff-ptch.el runs patch with a few
    different args to determine the default value of a config variable.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs

[Eli Zaretskii]

On Mon, 25 Mar 2002, Stefan Monnier wrote:

> It used to be that if there wasn't enough pure memory and we
> tried to allocate some pure storage Emacs would just halt.
> Now it keeps going, allocating in non-pure storage instead and
> signalling that the pure storage overflowed.

Thanks for the explanation.

I think we should do something to avoid the warning in the bootstrap 
case, then.  Users who don't know these details might become spooked by 
the warning, especially if they were used to get a fatal error with the 
same language before.

> PS: I almost got bootstrapping to work without a `bootstrap-emacs'
>     executable (by byte-compiling with `temacs' instead)
>     but hit a problem where `temacs -batch' freezes in call-process:
>     the problem is that the SIGCHLD handler is not installed in that
>     case (probably because it might introduce problems when we dump).

Yes, I think that's the reason why signals aren't caught.

>     As for why `call-process' is called: vc.el does
>     (eval-when-compile (require 'ediff-util)) and ediff-util.el
>     ends up loading all the ediff*.el files (also from within
>     `eval-when-compile' clauses) and ediff-ptch.el runs patch with a few
>     different args to determine the default value of a config variable.

We could prevent this by binding some special variables during bootstrap, 
no?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

bootstrap (was: Emacs-diffs digest, Vol 1 #508 - 12 msgs)

[Stefan Monnier]

> I think we should do something to avoid the warning in the bootstrap 
> case, then.  Users who don't know these details might become spooked by 
> the warning, especially if they were used to get a fatal error with the 
> same language before.

An alternative is to just do

	(if ...bootstrapping...
	  (setq purify-flag nil))

at the beginning of loadup.el.

> > PS: I almost got bootstrapping to work without a `bootstrap-emacs'
> >     executable (by byte-compiling with `temacs' instead)
> >     but hit a problem where `temacs -batch' freezes in call-process:
> >     the problem is that the SIGCHLD handler is not installed in that
> >     case (probably because it might introduce problems when we dump).
> 
> Yes, I think that's the reason why signals aren't caught.
> 
> >     As for why `call-process' is called: vc.el does
> >     (eval-when-compile (require 'ediff-util)) and ediff-util.el
> >     ends up loading all the ediff*.el files (also from within
> >     `eval-when-compile' clauses) and ediff-ptch.el runs patch with a few
> >     different args to determine the default value of a config variable.
> 
> We could prevent this by binding some special variables during bootstrap, no?

As I said I'd rather have less bootstrap-specific code than more, so it
doesn't sound like an attractive solution.  Other solutions are:
- create `eval-only-when-compile' since the (require 'ediff-util) is only
  done to get rid of some compiler warnings (it doesn't provide any
  macros used by vc.el as far as I can tell).

- check !noninteractive||initialized in call-process and return nil
  without running any program otherwise (since the SIGCHLD handler
  is not installed).

- check !noninteractive||initialized in call-process and install
  the SIGCHLD handler if the check fails.

Obviously the first solution is the only one that's really
non-bootstrap-specific.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel