* Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs
[not found] <E16oZ1I-0001u2-00@fencepost.gnu.org>
@ 2002-03-23 9:53 ` Eli Zaretskii
2002-03-25 16:29 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2002-03-23 9:53 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs
2002-03-23 9:53 ` Emacs-diffs digest, Vol 1 #508 - 12 msgs Eli Zaretskii
@ 2002-03-25 16:29 ` Stefan Monnier
2002-03-25 20:10 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2002-03-25 16:29 UTC (permalink / raw)
Cc: Stefan Monnier, emacs-devel
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs
2002-03-25 16:29 ` Stefan Monnier
@ 2002-03-25 20:10 ` Eli Zaretskii
2002-03-25 22:40 ` Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2002-03-25 20:10 UTC (permalink / raw)
Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs
2002-03-25 20:10 ` Eli Zaretskii
@ 2002-03-25 22:40 ` Stefan Monnier
2002-03-26 5:58 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Monnier @ 2002-03-25 22:40 UTC (permalink / raw)
Cc: monnier+gnu/emacs, emacs-devel
> > 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs-diffs digest, Vol 1 #508 - 12 msgs
2002-03-25 22:40 ` Stefan Monnier
@ 2002-03-26 5:58 ` Eli Zaretskii
2002-03-26 15:31 ` bootstrap (was: Emacs-diffs digest, Vol 1 #508 - 12 msgs) Stefan Monnier
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2002-03-26 5:58 UTC (permalink / raw)
Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bootstrap (was: Emacs-diffs digest, Vol 1 #508 - 12 msgs)
2002-03-26 5:58 ` Eli Zaretskii
@ 2002-03-26 15:31 ` Stefan Monnier
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2002-03-26 15:31 UTC (permalink / raw)
Cc: Stefan Monnier, emacs-devel
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-03-26 15:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <E16oZ1I-0001u2-00@fencepost.gnu.org>
2002-03-23 9:53 ` Emacs-diffs digest, Vol 1 #508 - 12 msgs Eli Zaretskii
2002-03-25 16:29 ` Stefan Monnier
2002-03-25 20:10 ` Eli Zaretskii
2002-03-25 22:40 ` Stefan Monnier
2002-03-26 5:58 ` Eli Zaretskii
2002-03-26 15:31 ` bootstrap (was: Emacs-diffs digest, Vol 1 #508 - 12 msgs) Stefan Monnier
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).