Vin> As the maintainer of the current stable release, I must concur. Steve Vin> Youngs (I know you're out of touch at the moment, perhaps you'll Vin> comment when you get back) please build with the latest stable Vin> release, in this case 21.1. It is a very serious bug if XEmacs 21.2-compiled code can't run on 21.1. I can't reproduce it. Vin> It is now impossible to use M-x calendar. The exact error message I Vin> get when doing M-x calendar is: Vin> invalid lazy-loaded byte code: k��� Vin> The file calendar.elc is generated by XEmacs 21.2 (beta36). It appears Vin> that the output of this byte compiler is not entirely compatible with Vin> XEmacs 21.1.8. I think that's unlikely. What happens if you start up a NEW 21.1.8 xemacs process, and try M-x calendar? I believe there is a bug here, but it is that lazy-loading of bytecode and docstrings does not check the timestamps of updated files, and would happen with any xemacs version. Workaround: shut down your running xemacs and start up a new one. Vin> For pacakges to work, this sort of thing *has* to be avoided. Either Vin> by using separate package directories for separate versions of XEmacs Vin> or by recompiling packages as they are retreived if they are not Vin> precompiled with a compatible version of XEmacs. I agree completely.

DB> [I wrote the original report that ended up in comp.emacs.xemacs] DB> The calendar package works fine for me in a freshly started XEmacs. Thanks. This confirms my diagnosis that there is no _new_ bug in XEmacs 21.2. DB> Although it was not the case this time, it *is* possible that some DB> packages will not work in "the wrong" version of XEmacs. I've written DB> one myself that compiles differently (mainly different macro DB> definitions) depending on which version of Emacs (or XEmacs) is used. DB> This is done for performance reasons and really does help. I've been making byte-compiler perfomance improvements to 21.2. All should generate completely compatible code to 21.1. But XEmacs and Emacs generate completely incompatible byte code these days, especially if Mule is involved. DB> How would I go about packaging something like that? Sorry, you have to provide two packages if you need multiple pre-byte-compiled packages for XEmacs and Emacs. Or you might be able to compile with a byte-compiler from a very old emacs. Needs testing.

mb> I've been making byte-compiler perfomance improvements to mb> 21.2. All should generate completely compatible code to 21.1. SJT> How quickly you forget. :-( SJT> Granted, you have to write perverted code to tickle those differences. SJT> But people tweaking code across Emacs versions for performance reasons SJT> are surely not "normal". David is probably not going to run into SJT> problems due to your optimization of (+ x 0), but he's more likely to SJT> do so than the average bear, Booboo. :-/ Completely compatible in the sense that if someone's code stops working when compiled with the 21.2 compiler and run under 21.1, then it also stops working when run under 21.2! Broken _compatibly_. I'm sure a smart guy like David wouldn't use (+ x 0) to turn a marker into an integer...

mb> I'm sure a smart guy like David wouldn't use (+ x 0) to turn a mb> marker into an integer... SJT> No, but a macro that he wrote, called with an argument of 0, very well SJT> might, if I understand the process correctly. Surely a human would SJT> write (marker-position 0). The byte-compiler used to be smart enough SJT> to do that, now it has been lobotomized. Again, IUTPC. ^^^^ ^^^^^ what? ????? You mean (defmacro fast-marker-position (x) (+ x 0)) as a speed hack? Yes, I can see someone (like me?!) doing this. Good point. SJT> I thought it was clear that that's what worried me all along. I still think optimizing (+ x 0) to x was the Right Thing to do.

>>>>> "mb" == Martin Buchholz <martin(a)xemacs.org&gt; writes: SJT> been lobotomized. Again, IUTPC. mb> ^^^^ ^^^^^ what? ????? SJT> "If I Understand The Process Correctly." (I seem to have dropped an I SJT> there.) mb> You mean mb> (defmacro fast-marker-position (x) (+ x 0)) mb> as a speed hack? SJT> I had more in mind something like SJT> (defmacro total-line-width (this-start column-width) SJT> `(progn SJT> (do-side-effects ,this-start ,column-width) SJT> (+ ,this-start ,column-width))) SJT> which might get called as (total-line-width (current-column) 0) at the SJT> right margin, since there's no space to add another text column. SJT> AFAICT what the byte compiler sees after macro expansion is SJT> (progn SJT> (do-side-effects (current-column) 0) SJT> (+ this-start 0)) SJT> which gets optimized to SJT> (progn SJT> (do-side-effects (current-column) 0) SJT> this-start) This particular example is not a problem since (current-column) is an integer. And the default for most operations is to use integers (e.g. (point)), rather than markers (e.g. (point-marker)), which means that markers tend to only be used where they their markerness is needed. And markers can be used almost everywhere that the equivalent integers can, so leaving the markers unconverted is usually OK. SJT> I thought it was clear that that's what worried me all along. mb> I still think optimizing (+ x 0) to x was the Right Thing to mb> do. SJT> *shrug* SJT> Maybe this will not occasion a bug report for decades. But SJT> mathematical certainty is such a rare and wonderful thing, I thought SJT> I'd advocate it. Anyways, let's spend some time fixing Real Bugs. No shortage of those.

David> All it takes is a macro definition in the base set of David> packages that changes in an incompatible way between XEmacs David> versions since macro definitions get expanded at compile David> time. "Packages" change incompatibly all the time. There's not much we can do about that, and support packages too. However, I assume you mean what we now call "core Lisp" (the libraries distributed with the XEmacs source code and compiled binaries)? In general, this is not as big a problem as it appears. As long as the APIs called from a macro don't change, calls to the macro in compiled code should continue behaving the same (since it is pre-expanded code). This means that "incompatible" changes should be fairly rare, and not due to changes in the macro itself (unless your code is depending on an unspecified side effect, which is pretty undesirable in itself), but rather in the functions it uses. And we are supposed to be careful about making such changes in C code or core Lisp. David> The point is that in my case (and potentially others), the David> output of the 21.1.8 byte compiler might not run properly David> in 21.2 and vice versa. With a few exceptions (somewhat more aggressive optimization in the most recent devel versions is one), this is considered a bug in XEmacs. The byte codes themselves and their specified semantics have not changed. That doesn't help you in practice, I know, except that you can tell users to avoid the "buggy" versions. David> I was simply wondering how to deal with this sort of David> problem in packages for XEmacs. Can I have uncompiled David> package and have the Emacs getting the package David> automatically build it? Not yet. This has been considered low priority so far, since one of the original goals of the package system was making it possible for there to be many more "official" packages and to be able to distribute them in binary form. One problem is specifying how to do this, since for historical reasons the installed tree is {etc,info,lib,lisp}/$PACKAGE, while the source tree is $PACKAGE/{etc,info,lib,lisp}. This means that you effectively need two different makefiles, one for building in the source tree and one for building in the installed tree. If you have thoughts about how to deal with this, let us know. -- 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."

DB> I was simply wondering how to deal with this sort of problem DB> in packages for XEmacs. Can I have uncompiled package and have DB> the Emacs getting the package automatically build it? mb> This is really a question for the package system experts. But mb> I don't think there's currently any support for install-time mb> frobbing beyond untarring. What we could do, for a case like David's, is provide (1) a skeleton source tree (with XEmacs.rules etc, and the standard subdirectories and their Makefiles), and (2) source rather than binary packages. Then we should make sure the install-to-installed-hierarchy target is bullet-proof; I think it probably is already, but I haven't done much with the package system lately. The package system could easily be taught to get the src package if a pkg package is unavailable, and install it to the local package sources hierarchy. Then the user should build it themselves. (Mostly this could be done automatically, but I don't think it should be automatic until we decide how to support it.) This would avoid the need for a separate makefile for "build-in-place". -- 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."