Pkgs built with 21.5 can't be used in 21.4 (or SXEmacs)

[Steve Youngs]

Hey Peeps!

First up, I wish to apologise for not jumping on this when it first
happened (I think the changes that are the root cause happened quite a
while ago).

OK, so here's the problem... elisp that has been byte-compiled with
XEmacs 21.5 cannot be loaded with XEmacs 21.4, or SXEmacs.

Why? Because...

XEmacs 21.5: (special-form-p 'throw) => t
XEmacs 21.4: (special-form-p 'throw) => nil
SXEmacs: (special-form-p 'throw) => nil

It would seem that somebody thought it was a good idea to make Fthrow()
take "possibly unevalled" arguments. I don't understand the reasoning
behind that and I'd certainly love to know.

However, that by itself, isn't the whole reason. XEmacs 21.5 has a
#'byte-compile-throw in bytecomp.el (which 21.4 and SXEmacs don't have)
that injects a test into the top of ELCs...

(or (and (featurep 'xemacs) (null (function-max-args 'throw)))
(error "Loading this file requires xemacs, (null (function-max-args 'throw))"))

That test fails for 21.4 and SXEmacs because our Fthrow() doesn't use
UNEVALLED args.

May I ask, what is the thinking behind this test? If it is to ensure
that only certain versions of (S)XEmacs can load the lib wouldn't it be
far easier (and give finer control) to inject something like this...

(or (and (featurep 'xemacs)
(emacs-version>= 21 5 35))
(error "Loading this file requires XEmacs >= 21.5.35"))

It just seems really odd (and annoying for me) that XEmacs would rely on
the definition of a function as a means of restricting where a elisp can
be loaded.

Explain it to me guys so that I can decide what, if anything, SXEmacs
needs to do.

For further reading see: http://issues.sxemacs.org/show_bug.cgi?id=171
though I don't think that there's anything there that I haven't covered
here.

Thanks!

[Stephen J. Turnbull]

@Aidan:

You're CC'd because I'm wondering if there isn't a better way to
implement the bytecode compatibility test. Ie, maybe we should have a
"Vimplemented_bytecodes" bitvector for this kind of test to make it
clear what's really happening.

Of course, "inquiring minds" are waiting with baited breath for
answers to Steve's questions, too. :-)

Post by Steve Youngs
OK, so here's the problem... elisp that has been byte-compiled with
XEmacs 21.5 cannot be loaded with XEmacs 21.4, or SXEmacs.

Yup. In theory, it's been that way since the very beginning, although
it was as late as August 2009 when the door actually got nailed shut.
That's why we insist that official packages be built with 21.4 (or
SXEmacs should do, but I think Norbert does use 21.4).

Post by Steve Youngs
Why? Because...
XEmacs 21.5: (special-form-p 'throw) => t
XEmacs 21.4: (special-form-p 'throw) => nil
SXEmacs: (special-form-p 'throw) => nil
It would seem that somebody thought it was a good idea to make Fthrow()
take "possibly unevalled" arguments. I don't understand the reasoning
behind that and I'd certainly love to know.

Aidan done it. I don't know exactly why, either. The ChangeLog
indicates it's related to Common Lisp compatibility, specifically real
multiple values. It involved new bytecodes, so if those are used,
21.4 (and presumably SXEmacs) are in big trouble (probably a crash).

Post by Steve Youngs
May I ask, what is the thinking behind this test? If it is to
ensure that only certain versions of (S)XEmacs can load the lib
wouldn't it be far easier (and give finer control) to inject
something like this [version test].

I don't think so. Feature tests are preferred for this kind of thing,
especially during development when features may be enabled or not for
different builds, and when several branches are active (and therefore
feature presence does not respect a total order of versions).

Post by Steve Youngs
It just seems really odd (and annoying for me) that XEmacs would
rely on the definition of a function as a means of restricting
where a elisp can be loaded.

Elisp can be loaded anywhere. Byte-compiled lisp is loadable only
where the runtime is compatible with the compiler used.

Whether this particular incompatibility was a good decision or not is
something you'll have to debate with Aidan. I tend to side with Aidan
on the grounds that there's a good workaround for code that should and
does run on both 21.4/SXEmacs and 21.5: compile with 21.4 or SXEmacs.

Note that as far as the multiple values feature goes, Aidan added code
to 21.4 and/or xemacs-base that makes code using multiple values work
on 21.4 and 21.5 without change or checks other than the check for
unknown bytecodes (that's what the check on `throw' really does).

[Steve Youngs]

Post by Stephen J. Turnbull

Post by Steve Youngs
OK, so here's the problem... elisp that has been byte-compiled with
XEmacs 21.5 cannot be loaded with XEmacs 21.4, or SXEmacs.

Yup. In theory, it's been that way since the very beginning, although
it was as late as August 2009 when the door actually got nailed shut.
That's why we insist that official packages be built with 21.4 (or
SXEmacs should do, but I think Norbert does use 21.4).

Well, here's the thing, the reason this issue came to my notice was
because some of the packages currently in "Pre-release" were built by
Norbert on 21.5.

,----[ from cc-mode's auto-autoloads.elc ]
| ;;; compiled by ***@vserv.viteno.net
| ;;; from file /usr/users/nk/pkg-build/test/xemacs-packages/cc-mode/auto-autoloads.el
| ;;; emacs version 21.5 (beta34) "kale" cb65bfaf7110 XEmacs Lucid.
| ;;; bytecomp version 2.28 XEmacs; 2009-08-09.
| ;;; optimization is on
`----

[Stephen J. Turnbull]

Post by Steve Youngs
Well, here's the thing, the reason this issue came to my notice was
because some of the packages currently in "Pre-release" were built by
Norbert on 21.5.

Aha! I suppose there is reason for that, but again, we'll have to
think about all this.

BTW, are you following xemacs-review? If not, you probably should
take a look.

Steve

[Steve Youngs]

Post by Stephen J. Turnbull
BTW, are you following xemacs-review? If not, you probably should
take a look.

Okie doke