9:19 a.m.
[ removed -review from Cc list ]
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Gunnar" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
Gunnar> - a variable (say, inhibit_autoloads) is declared in
Gunnar> emacs.c directly in C with 'int inhibit_autoloads;' no
Gunnar> DEFVAR macros involved!
Huh? emacs.c, line 3393. The DEFVAR isn't an issue because of the
initialization; it's a problem because it imports the variable to pdump
land. This allows the pdumper to overwrite the user's command line
settings.
What I meant is that this macro is not called directly anymore when an
xemacs that will read a pdump file is started. I wrote this when I
still thought DEFVAR was actually initialising the C variable, but as
you point out it isn't.
Gunnar> note it doesn't get initialised to anything.
It's a global. I thought globals were guaranteed to be initialized to
zero---that's what `Internals | Rules When Writing New C Code | Adding
Global Lisp Variables' says. Is that incorrect?
Maybe it's stylistically bad, but technically it should work, right?
No, I'm sure it is correct. I just don't do that kind of thing in my
own programs and had thus forgotten. Sorry.
Gunnar> In particular all this breaks for values which get set
to
Gunnar> 1 by default in vars_of_emacs(), like
Gunnar> inhibit_site_[lisp|modules] (at least depending on
Gunnar> configure time constants).
This is incorrect implementation of configure constants if the
variable is settable from the command line, I believe. I should have
caught and fixed that. (Et tu, Olivier! ;-)
It's clear I did the wrong thing in conditionalizing the saves. For
variables that are settable by command line option, the saves/restores
should be unconditional, and the conditional initialization should be
moved to the declaration.
Wouldn't it be easier to move the command line parsing for the relvant
variable after the loading of the dump file? This would be more like
the initialisation in a traditional dumped xemacs.
Gunnar
9:41 a.m.
New subject: -no-autoloads broken in 21.2.35 --pdump
On Wed, Nov 22, 2000 at 09:19:10AM +0000, Gunnar Evermann wrote:
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp>
writes:
> I should have
> caught and fixed that. (Et tu, Olivier! ;-)
:-P
Wouldn't it be easier to move the command line parsing for the
relvant
variable after the loading of the dump file? This would be more like
the initialisation in a traditional dumped xemacs.
You have to detect -nd before trying to load the dump file. So you'd
have to split the command parsing in two stages. Not nice.
OG.
10:23 a.m.
New subject: -no-autoloads broken in 21.2.35 --pdump
I wrote:
> It's clear I did the wrong thing in conditionalizing the
saves.
> For variables that are settable by command line option, the
> saves/restores should be unconditional, and the conditional
> initialization should be moved to the declaration.
>>>> "Gunnar" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
Gunnar> Wouldn't it be easier to move the command line parsing for
Gunnar> the relvant variable after the loading of the dump file?
Gunnar> This would be more like the initialisation in a
Gunnar> traditional dumped xemacs.
Most command line parsing is either done that way or doesn't involve
Lisp variables.
The problem with these variables is that they could theoretically
affect the dump process. noninteractive (-batch) is definitely used
in the dump process; that had better get unstomped. I could imagine
somebody wanting to dump packages and make sure they weren't shadowed
by development versions in ~/.xemacs or debug paths in the dump process.
It's probably easier to just protect the variables rather than figure
out whether we want to support these things or document how they're
not supported.
Also, they can't just be moved around; they have to be moved en bloc
or the sort order changed. That's not a reason not to do it, just
something we have to remember to deal with.
Gunnar> Also I think the save&restore changes the semantics as
Gunnar> changes to the variables made in the lisp executed before
Gunnar> dumping are unconditionally tossed.
If it does, it changes them to what users expect, and what is
documented.
I think this pretty much covers everything? Patch forthcoming (maybe
two days) unless somebody else wants to take it.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
9:39 a.m.
New subject: Command line parsing is buggy [was: -no-autoloads broken ...]
>>>> "Gunnar" == Gunnar Evermann
<ge204(a)eng.cam.ac.uk> writes:
> variables that are settable by command line option, the
> saves/restores should be unconditional, and the conditional
> initialization should be moved to the declaration.
Gunnar> Wouldn't it be easier to move the command line parsing for
Gunnar> the relvant variable after the loading of the dump file?
Gunnar> This would be more like the initialisation in a
Gunnar> traditional dumped xemacs.
Now that I've looked more carefully at the code, I agree. However,
doing this right is something I don't have time to do right now. Any
takers?
A light audit of the command line parsing code reveals the following
apparent bugs and issues:
1. There is a comment in startup.el indicating that some unidentified
hacker would like to move as much command line parsing as possible
out of C and into Lisp. I agree; among other things, it would
obviate all pdump issues with command args.
The command args that absolutely can't be moved into Lisp right away:
-nd, -sd, -batch, -d, -t, -nw: Used in emacs.c. I suspect that
with some effort -d and -nw could be moved into Lisp, but I doubt
it's trivial.
As far as I can tell, all the rest could be moved into Lisp by
creating a `really_very_early_command_line' function to be called
from `normal-top-level' rather than from `command-line'. But I
haven't checked terribly carefully.
2. The presence of -NXhost or -MachLaunch in the command line will
hose processing of all lower-priority args parsed in C.
3. Some C-parsed args have the same priority; if they come in the
wrong order in the command-line, the earlier one will be ignored,
as will all lower priority C-parsed args. This applies to
repetition of C-parsed args as well. (Any parsing done in Lisp
should not be affected.)
4. -debug-paths appears twice in the standard_args table in emacs.c
with different priorities, and is parsed twice in main_1 with
different semantics.
5. I haven't checked carefully, but I think that some options are
ordered differently in standard_args priority and in main_1.
There are probably more.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8764
days inactive
8766
days old
3 comments
3 participants
participants (3)
-
Gunnar Evermann -
Olivier Galibert -
Stephen J. Turnbull