ron@clarity.Princeton.EDU (Ronald Beekelaar) (11/24/89)
Hi everyone, I have a problem with a function I wrote to sort Subjects on number of lines of the article. I changed gnus-Subject-sort-by-number a little bit, using nntp-header-lines instead of nntp-header-number as the sorting criteria. Apparently nntp-header-lines and nntp-header-number are macro's (?). The problem is that after loading my own sort function and calling it in Subject mode, everything works fine, and the headers are sorted. As soon as I load a byte-compiled version of this function, it doesn't work anymore!!! It gives me the message: Invalid function: (macro lambda etc....) How come it worked uncompiled and doesn't compiled and what can I do about it so it will work compiled? Thanks for any help. -- ------ ron ------
deven@rpi.edu (Deven T. Corzine) (11/27/89)
On 23 Nov 89 21:26:40 GMT, ron@clarity.Princeton.EDU (Ronald Beekelaar) said: ron> As soon as I load a byte-compiled version of this function, it ron> doesn't work anymore!!! It gives me the message: ron> Invalid function: (macro lambda etc....) ron> How come it worked uncompiled and doesn't compiled and what can I ron> do about it so it will work compiled? I have run across this before. Actually, it is Emacs-related, not specific to gnus. Apparently it is a problem where the byte-compiler will try to compile a macro as a function. (hence the "lambda") The solution appears to be to load the uncompiled Emacs-Lisp library (with GNUS, you should probably load ALL parts of GNUS...) _before_ attempting to byte-compile the library. After loading it, then byte-compile the library. Then the byte-compiler appears to get it straight, and the compiled code works correctly. Give it a try, anyway. [(ESC ESC) Eval: (load "gnus") and then Eval: (byte-compile-file "gnus.el"), basically.] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
sra@lcs.mit.edu (Rob Austein) (11/29/89)
Remember that macros used in functions that are byte-compiled are expanded when the function is byte-compiled, not when the byte-compiled form of the function is evaluated. The interaction between byte-compilation and the various auto-loading mechanisms (autoload, require, and any private hacks) is complicated and arguably incorrect for a package that's spread into multiple files like GNUS, but the basic idea is that you'd better make sure all the relevant macro definitions are available to macroexpand (an emacs primitive) before attempting to byte-compile anything. Which is what Deven said, basicly. --Rob Austein, MIT
tale@cs.rpi.edu (Dave Lawrence) (12/08/89)
In <DEVEN.89Nov26122502@netserv2.rpi.edu>, deven@rpi (Deven T. Corzine) writes: > The solution appears to be to load the uncompiled Emacs-Lisp library > (with GNUS, you should probably load ALL parts of GNUS...) _before_ In article <12037@phoenix.Princeton.EDU> greg@phoenix (greg Nowak) writes: > This is unneccesary. I've run into the same problem. All you have to do is > load "prims.el" before you byte-compile anything. I believe Weemba > documented this in a strange place, like in the comments on sources.el. Since neither prims.el nor sources.el are part of either the standard lisp distribution of GNU Emacs or that of GNUS, this is erroneous information. Deven was quite correct in stating that GNUS must be loaded first; there are no macros defined in either gnuspost.el or gnusmisc.el, though, so you don't need to have them loaded too. Dave -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))