* 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).