Re: [COMMIT] Keep around gensym correspondence information through entire bytecomp files
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?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches