Karl> Byte compile the following two programs and look at the output. (setq blah1 (eval-when-compile (require 'regexp-opt) (regexp-opt '("blah" "oink" "blah2" "blah3")))) (setq blah2 (eval-when (compile eval) (require 'regexp-opt) (regexp-opt '("blah" "oink" "blah2" "blah3")))) Karl> Why don't they produce the same thing? Because I haven't committed the following patch, which fixes it. Unfortunately, I can generate such patches faster than I can test them. My apologies to Martin Stjernholm as well as to Karl. Note that someone may be relying on this XEmacs bug, and it's also an FSF Emacs bug, so a proper bug fix involves getting Gerd to agree it's a bug, bytecompile all .el files in the universe pre- and post-patch, compare the generated .elc files, and audit any that show differences. Would anyone like to volunteer to do the testing job? Index: lisp/bytecomp.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/bytecomp.el,v retrieving revision 1.8.2.16 diff -u -w -r1.8.2.16 bytecomp.el --- lisp/bytecomp.el 2000/10/12 07:22:37 1.8.2.16 +++ lisp/bytecomp.el 2000/11/01 04:47:20 ＠＠ -447,8 +447,7 ＠＠ '((byte-compiler-options . (lambda (&rest forms) (apply 'byte-compiler-options-handler forms))) (eval-when-compile . (lambda (&rest body) - (list 'quote (eval (byte-compile-top-level - (cons 'progn body)))))) + (list 'quote (eval (cons 'progn body))))) (eval-and-compile . (lambda (&rest body) (eval (cons 'progn body)) (cons 'progn body))))

mb> Would anyone like to volunteer to do the testing job? SJT> I just updated xemacs-packages and 21.2-HEAD, and am doing a make SJT> world anyway. So I'll apply Martin's patch and do a second round of SJT> byte-compiling. I'll package up the .elcs, but I am not competent to SJT> do the audit. SJT> As a summary, will forcing diff to treat .elcs as text Do The Right SJT> Thing? Or should I just do a diff -q? Because I'm excessively careful, I've done a similar exercise in the past. You want to compare two elc files for differences in the generated bytecode. Here's my program elc-cmp (additional hacking may be required): : #-*- Perl -*- # Copyright (C) 2000 Martin Buchholz # This program is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by the # Free Software Foundation; either version 2, or (at your option) any # later version. # # This program is distributed in the hope that it will be useful, but WITHOUT # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or # FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License # for more details. # # You should have received a copy of the GNU General Public License # along with XEmacs; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. eval 'exec perl -w -S $0 ${1+"$＠"}' if 0; use strict; use FileHandle; use Carp; (my $myName = $0) =~ s＠.*/＠＠; my $usage=" Usage: $myName FILE1 FILE2 Compares two elc files for equivalence, discarding randomness introduced by the byte-compiler, such as time stamps and gensyms.\n"; die $usage unless ＠ARGV == 2; if (ELCFileContents ($ARGV[0]) eq ELCFileContents ($ARGV[1])) { exit 0; } else { warn "Files differ: ＠ARGV\n"; WriteStringToFile ("$ARGV[0].1", ELCFileContents ($ARGV[0])); WriteStringToFile ("$ARGV[0].2", ELCFileContents ($ARGV[1])); exit 1; } sub ELCFileContents { my $contents = FileContents ($_[0]); $contents =~ s/^;.*\n//gmo; # Remove comments $contents =~ s/\#:[a-z0-9-]+//gmo; # Remove gensyms # Following should be REAL gensyms $contents =~ s/G[0-9][0-9][0-9][0-9][0-9]?//gmo; $contents =~ s/\#\$ \. -?[0-9]+//gmo; $contents =~ s/\#\＠[0-9]+//gmo; return $contents; } sub SafeOpen { open ((my $fh = new FileHandle), $_[0]); confess "Can't open $_[0]: $!" if ! defined $fh; return $fh; } sub SafeClose { close $_[0] or confess "Can't close $_[0]: $!"; } sub FileContents { local $/ = undef; open (FILE, "< $_[0]") or confess "$_[0]: $!"; return scalar <FILE>; } sub WriteStringToFile { my $fh = SafeOpen ("> $_[0]"); print $fh $_[1] or confess "$_[0]: $!\n"; SafeClose $fh; }

mb> Because I'm excessively careful, I've done a similar exercise mb> in the past. You want to compare two elc files for mb> differences in the generated bytecode. mb> Here's my program elc-cmp (additional hacking may be mb> required): SJT> Not too much. Time to quit, though; I'll send the files tomorrow. SJT> The differences found were in (core) lisp/bytecomp.elc (I haven't SJT> checked if it is merely the patch), and (packages) SJT> gnus/gnus-start.elc, calc/calc.elc, w3/w3-display.elc, and SJT> w3/w3-parse.elc. Thanks. This is quite useful. I expected more. SJT> I will say, as an aside, that the last few months of hacking on the SJT> package build process have been a massive step backward. Several SJT> targets that used to work for me now fail. It is also certain that an SJT> attempt to start from the bare metal with CVS checkouts of xemacs and SJT> xemacs-packages will fail (several packages require an installed SJT> package hierarchy to be available), but I don't know how screwed up SJT> that is yet. This also used to work for me, with the caveat that some SJT> tweaking was required to get VM and skk to build their manuals. SJT> :-( Paging Steve Youngs... I have certain release criteria for 21.2 beta, like successful C++ compiles and clean `make check's. I would hope package releases would have similar release critieria. Martin

* "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp&gt; writes: SJT> I will say, as an aside, that the last few months of hacking SJT> on the package build process have been a massive step SJT> backward. :-( I have this dream of autoconf'ing the package build process. :-) mb> Paging Steve Youngs... mb> I have certain release criteria for 21.2 beta, like successful mb> C++ compiles and clean `make check's. I would hope package mb> releases would have similar release critieria. Yes I do follow similar procedures for package releases. Stephen> I don't think this is a Steve Youngs problem, unless he wants to claim Stephen> it. If it's package related, I don't mind taking it on. Stephen> missing statement of purpose. Is there a "statement of purpose" for the core distribution? Where's it at? Perhaps I can knock something up for packages. Stephen> We don't have a review procedure for Stephen> changes to the package infrastructure. I don't know whether the Stephen> package system should be treated like the stable branch, with a single Stephen> gatekeeper, but we should consider that (if we can find somebody who Stephen> is willing to own the Makefiles, package-compile.el, etc). I I think taking a leaf out of Vin's book would be a good idea for the packages. I'll gladly adopt the Makefiles etc. Stephen> We need a Mule policy What are your thoughts on this, Stephen? -- |---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---| | XEmacs - It's not just an editor... | | It's a way of life. | |----------------------------------<mailto:youngs＠xemacs.org>---|

mb> Here's my program elc-cmp (additional hacking may be mb> required): me> The differences found were in (core) lisp/bytecomp.elc (I me> haven't checked if it is merely the patch), and (packages) me> gnus/gnus-start.elc, calc/calc.elc, w3/w3-display.elc, and me> w3/w3-parse.elc. SJT> The calc/calc.elc turns out to be a false alarm; calc kept a build SJT> time-stamp in a form Martin's script didn't catch. SJT> A tarball containing the five files (including calc) that showed SJT> differences in .el, .elc pre-Martin-patch, and .elc post-Martin-patch SJT> forms is available at SJT> http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bytecomp-diffs.tar.gz I've looked at these, and they show that unfortunately, this patch is not yet ready for prime time. I should have mentioned that you should have also diffed all the byte-compiler warnings pre and post. They will show significant differences. One problem is that (eval-when-compile (defvar foo)) (defun bar () foo) should not give a warning. It does. I'm looking at the byte-code diffs - they seems to be harmless, based on whether source or bytecode is inlined - only a very very small possible performance difference. Martin

Steve Youngs added because it might be useful to him to have my logs for the package builds for comparison. me> A tarball containing the five files (including calc) that me> showed differences in .el, .elc pre-Martin-patch, and .elc me> post-Martin-patch forms is available at me> http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bytecomp-diffs.tar.gz To this I have added the logs from the builds (core and packages, pre and post) and `diff -u $i.err.pre $i.err.post' for i = core, packages. http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bytecomp-logs.tar.gz The executive summary is (1) The diffs are shorter than I expected. Very little in core, in fact. (2) Lots of new "unbound variable" or "free variable" warnings. I didn't recognize anything else, these seem to be what Martin expected. (3) func-menu.el blows chunks badly, I believe because the macro fume-bomb-proof is not eval-when wrapped. I may have done this to myself, but cvs diff shows me up-to-date. This accounts for much of the length of the packages diff, since none of the rest of the edit-utils package gets built in "post-patch" version. (4) skk is a mess. (Why am I not surprised?) (5) Library maintainers [Hi, Steve Youngs!] may want to look at the logs as well as the diffs, because at least VM blows up the same way in pre and post Martin patch byte compiles. So AFAICT this is not related to Martin's patch, but perhaps of interest anyway. [Caveat on VM: I have hacked my VM, and this is probably not the same as the official XEmacs package. But VM is the only package I do hack on. Other errors are in the official versions. (Edict is mine, so I update it when I hack on it.)] (6) The packages show a lot more compile warnings than the core libraries do. (That is no surprise.) me> for the curious. (I'll mail it on request, but I didn't want me> to just post a 350kB tarball to me> not-necessarily-that-interested parties.) Again I will mail if someone prefers that to wget. me> The XEmacs 21.2 and xemacs-packages were fresh updates from me> CVS as of approximiately 2000-11-1 07:00 UTC. This is true as far as it goes. It also turns out that I had a sticky r21-2-36 tag, so this is not current CVS, but the beta release version 21.2.36 "Notus". The xemacs packages were fresh updates. I am going to update to CVS current now, plus Martin's patch. I'll let you know if anything interesting appears. -- 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." -- 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."

KMH> Byte compile the following two programs and look at the output. (setq blah1 (eval-when-compile (require 'regexp-opt) (regexp-opt '("blah" "oink" "blah2" "blah3")))) (setq blah2 (eval-when (compile eval) (require 'regexp-opt) (regexp-opt '("blah" "oink" "blah2" "blah3")))) KMH> Why don't they produce the same thing? Actually, read the Lisp standard. Here is Chapter and Verse: http://www.xanalys.com/software_tools/reference/HyperSpec/Body/speope_eva... (eval-when (compile)) is supposed to do NOTHING at compile time, unless it's a top-level form. This is a Common Lisp thing, not an XEmacs invention. I didn't try to understand why. Martin