[COMMIT] Keep around gensym correspondence information through entire bytecomp files
kehoea at parhasard.net
Mon Jan 14 10:22:43 EST 2008
Ar an dara lá de mí na Nollaig, scríobh Stephen J. Turnbull:
> > * bytecomp.el (byte-compile-output-file-form):
> > Bind print-gensym to a cons, to tell the Lisp printer not to clear
> > print-gensym-alist on exit from #'print. This is appropriate
> > because #'byte-compile-output-file-form may be called multiple
> > times for a given output file, and re-using the
> > #1=#:... placeholders in that context is inappropriate.
> do you mean "reusing placeholders is APPROPRIATE" here? I think you
> should be a little more explict if not. Do you mean something like
> "continuing to increment the placeholders is appropriate" rather than
> "reusing the placeholders is inappropriate"?
This ChangeLog was unclear and muddled because I was trusting the
implementation of the (eq t print-gensym) behaviour to not be buggy--I
thought the problem was in the byte compiler. That wasn’t it, though; the
behaviour of the Lisp printer when you revert this change and recompile
mule/*.elc is what’s broken. The non-boilerplate code of greek.elc if you do
that looks like this:
(byte-code "[byte codes omitted]" [#1=#:G79030 #2=#:G79075 #3=#:G79053 #4=#:G79031 #5=#:G79029 [lots and lots of constants omitted] #1=#:G79032 upper lower greek latin-1 case-table syntax-table case-fold-search] 12)
This means that somewhere in the guts of the printing of those [lots and
lots of constants], one of the print functions reset print-gensym-alist
where it shouldn’t have. A bit of browsing doesn’t tell me which, but it
should be possible to set a watchpoint on it and work it out. The Cygwin GDB
isn’t being co-operative with me in this right now, though.
We (and GNU) normally don’t see this problem because for defvars, defuns,
defmacros, defconst and autoloads, print-gensym was always bound to a cons,
so the print-gensym-as-t behaviour wasn’t thoroughly tested.
This is actually, slightly to my surprise, independent of the emacs-w3m
problem. The issue with the latter is that readevalloop resets Vread_objects
with each new top level form--see lread.c:1490--so it is impossible to
re-use an uninterned symbol from one call to (byte-code ...) to the next.
One #'custom-declare-variable call using one uninterned symbol followed by
another re-using the same symbol will always break.
> A comment at the point of change would be appropriate, here.
> Does this change the behavior of byte-compiled libraries?
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
More information about the XEmacs-Beta