* Re: Change in bytecomp.el breaks Gnus [not found] ` <b9yd5ymkq11.fsf@jpl.org> @ 2004-11-11 7:40 ` Katsumi Yamaoka 2004-11-11 11:18 ` Katsumi Yamaoka 0 siblings, 1 reply; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-11 7:40 UTC (permalink / raw) Cc: emacs-pretest-bug, ding >>>>>> In <877jouepy8.fsf@telia.com> Henrik Enberg wrote: >> Version 2.157 of bytecomp.el causes Gnus to fail with the following >> backtrace: >> Debugger entered--Lisp error: (void-function t) >> t("nnml+sent:news" (1 . 888)) >> gnus-activate-group("nnml+sent:news" scan) >> gnus-get-unread-articles(nil) >> gnus-setup-news(nil nil nil) > [...] >> gnus-1(nil nil nil) >> gnus() >>>>> In <b9yd5ymkq11.fsf@jpl.org> Katsumi Yamaoka wrote: > I got the same error last night (in Japan) and noticed removing > gnus-start.elc seems to help. I don't think it's a Gnus' fault. > Now I'm using the version 2.156 and rebuilt Emacs. I found that the problem is caused if a Lisp source contains the following forms: (eval-when-compile (defsubst foo ())) (defun bar () (foo)) Where `foo' is surrounded by `eval-when-compile' since there is no necessity of using it at run-time. In that case, the function definition for `foo' is registered into the `byte-compile-function-environment' variable as `(foo . t)', and the byte compiler complains as follows: In bar: foobar.el:4:8:Warning: attempt to inline `t' before it was defined foobar.el:4:8:Warning: `t' called as a function In end of data: foobar.el:4:1:Warning: the function `t' is not known to be defined. I used this technique in many places of some packages including Gnus in oder to reduce useless function symbols at run-time. If such a technique is forbidden, I will get into a plight. Could you also support the `(eval-when-compile (defsubst ...' forms? Thanks in advance. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-11 7:40 ` Change in bytecomp.el breaks Gnus Katsumi Yamaoka @ 2004-11-11 11:18 ` Katsumi Yamaoka 2004-11-11 17:45 ` Luc Teirlinck 0 siblings, 1 reply; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-11 11:18 UTC (permalink / raw) Cc: emacs-pretest-bug, ding >>>>> In <b9ysm7gq1dm.fsf@jpl.org> Katsumi Yamaoka wrote: > I found that the problem is caused if a Lisp source contains the > following forms: > (eval-when-compile > (defsubst foo ())) > (defun bar () (foo)) Although I'm not sure of it, the following patch seems to solve the problem. *** bytecomp.el~ Tue Nov 9 21:53:14 2004 --- bytecomp.el Thu Nov 11 11:17:58 2004 *************** *** 3720,3726 **** (if (and (consp (cdr form)) (consp (nth 1 form)) (eq (car (nth 1 form)) 'quote) (consp (cdr (nth 1 form))) ! (symbolp (nth 1 (nth 1 form)))) (let ((constant (and (consp (nthcdr 2 form)) (consp (nth 2 form)) --- 3720,3727 ---- (if (and (consp (cdr form)) (consp (nth 1 form)) (eq (car (nth 1 form)) 'quote) (consp (cdr (nth 1 form))) ! (symbolp (nth 1 (nth 1 form))) ! (not (byte-code-function-p (nth 2 form)))) (let ((constant (and (consp (nthcdr 2 form)) (consp (nth 2 form)) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-11 11:18 ` Katsumi Yamaoka @ 2004-11-11 17:45 ` Luc Teirlinck 2004-11-11 21:55 ` Stefan 0 siblings, 1 reply; 28+ messages in thread From: Luc Teirlinck @ 2004-11-11 17:45 UTC (permalink / raw) Cc: emacs-pretest-bug, ding Katsumi Yamaoka wrote: Although I'm not sure of it, the following patch seems to solve the problem. Your patch does not seem to solve a related problem I reported earlier on emacs-devel, so it probably is not a complete solution: Changes in byte compilation which must be less than a day old, have strange effects. `winner' is no longer usable when winner.elc is used, but still seems to work fine when winner.el is used. After `emacs -q' I get the following ielm run: *** Welcome to IELM *** Type (describe-mode) for help. ELISP> (load "winner") t ELISP> (winner-sorted-window-list) *** Eval error *** Symbol's function definition is void: t ELISP> (load "winner.el") t ELISP> (winner-sorted-window-list) (#<window 3 on *ielm*>) ELISP> Byte compiling winner.el produces: Compiling file /home/teirllm/emacscvsdir/emacs/lisp/winner.el at Tue Nov 9 08:32:15 2004 Entering directory `/home/teirllm/emacscvsdir/emacs/lisp/' winner.el:52:14:Warning: Function `gensym' from cl package called at runtime winner.el:56:10:Warning: Function `gensym' from cl package called at runtime In winner-sorted-window-list: winner.el:125:10:Warning: attempt to inline `t' before it was defined winner.el:124:4:Warning: `t' called as a function In winner-make-point-alist: winner.el:284:33:Warning: attempt to inline `t' before it was defined winner.el:285:44:Warning: `t' called as a function In end of data: winner.el:488:1:Warning: the function `t' is not known to be defined. Comments: The first two warnings are probably legitimate. The function `t' stuff appears to be a bug in byte compilation. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-11 17:45 ` Luc Teirlinck @ 2004-11-11 21:55 ` Stefan 2004-11-11 22:41 ` Luc Teirlinck 2004-11-12 0:22 ` Katsumi Yamaoka 0 siblings, 2 replies; 28+ messages in thread From: Stefan @ 2004-11-11 21:55 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, ding > Your patch does not seem to solve a related problem I reported earlier > on emacs-devel, so it probably is not a complete solution: > Changes in byte compilation which must be less than a day old, have > strange effects. `winner' is no longer usable when winner.elc is > used, but still seems to work fine when winner.el is used. > After `emacs -q' I get the following ielm run: > *** Welcome to IELM *** Type (describe-mode) for help. ELISP> (load "winner") > t ELISP> (winner-sorted-window-list) > *** Eval error *** Symbol's function definition is void: t ELISP> (load "winner.el") > t ELISP> (winner-sorted-window-list) > (#<window 3 on *ielm*>) Hmm... the problem seems to be related to the fact that some `defsubst's are first turned into `defalias' but that the new defalias code gets surprised when it encounters those `defalias'es. I've installed the patch below which I think does The Right Thing(tm). But the distinction between top-level and non-top-level forms as well as several aspects of the byte-compiler are still a bit fuzzy in my mind. I think the patch not only fixes the problem but also fixes an older "problem" which is that code such as: (defun toto () (foobsfg x) (if toto (defalias 'foobsfg 'y))) did not complain about calling an unknown function `foobsfg'. Can someone who's already played a bit with bytecomp.el do a reality check? Stefan --- bytecomp.el 09 Nov 2004 09:27:47 -0500 2.157 +++ bytecomp.el 11 Nov 2004 16:35:49 -0500 @@ -3614,7 +3613,6 @@ (byte-defop-compiler-1 defconst byte-compile-defvar) (byte-defop-compiler-1 autoload) (byte-defop-compiler-1 lambda byte-compile-lambda-form) -(byte-defop-compiler-1 defalias) (defun byte-compile-defun (form) ;; This is not used for file-level defuns with doc strings. @@ -3716,7 +3714,8 @@ (error "`lambda' used as function name is invalid")) ;; Compile normally, but deal with warnings for the function being defined. -(defun byte-compile-defalias (form) +(put 'defalias 'byte-hunk-handler 'byte-compile-file-form-defalias) +(defun byte-compile-file-form-defalias (form) (if (and (consp (cdr form)) (consp (nth 1 form)) (eq (car (nth 1 form)) 'quote) (consp (cdr (nth 1 form))) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-11 21:55 ` Stefan @ 2004-11-11 22:41 ` Luc Teirlinck 2004-11-11 22:54 ` Luc Teirlinck 2004-11-12 0:22 ` Katsumi Yamaoka 1 sibling, 1 reply; 28+ messages in thread From: Luc Teirlinck @ 2004-11-11 22:41 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, ding Stefan Monnier wrote: I've installed the patch below which I think does The Right Thing(tm). Do you mean that you are going to install it, or that you did install it? I do not see it on Savannah. Sincerely, Luc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-11 22:41 ` Luc Teirlinck @ 2004-11-11 22:54 ` Luc Teirlinck 0 siblings, 0 replies; 28+ messages in thread From: Luc Teirlinck @ 2004-11-11 22:54 UTC (permalink / raw) Cc: monnier, emacs-pretest-bug, yamaoka, ding From my last message: Do you mean that you are going to install it, or that you did install it? I do not see it on Savannah. I saw it now. Sincerely, Luc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-11 21:55 ` Stefan 2004-11-11 22:41 ` Luc Teirlinck @ 2004-11-12 0:22 ` Katsumi Yamaoka 2004-11-12 3:57 ` Stefan Monnier 1 sibling, 1 reply; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-12 0:22 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding >>>>> In <m17jos12x6.fsf-monnier+emacs@gnu.org> Stefan wrote: > Hmm... the problem seems to be related to the fact that some `defsubst's are > first turned into `defalias' but that the new defalias code gets surprised > when it encounters those `defalias'es. That looks to be the right interpretation, but... [...] > Can someone who's already played a bit with bytecomp.el do a reality check? I rebuilt Emacs and found the following case causes the `t' error. (defalias 'foo (lambda (s) (message "%s" s))) (defun bar (s) (inline (foo s))) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-12 0:22 ` Katsumi Yamaoka @ 2004-11-12 3:57 ` Stefan Monnier 2004-11-12 4:30 ` Katsumi Yamaoka 0 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2004-11-12 3:57 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding > I rebuilt Emacs and found the following case causes the `t' error. > (defalias 'foo (lambda (s) (message "%s" s))) > (defun bar (s) (inline (foo s))) Hmm...indeed. I think I've fixed it now, Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-12 3:57 ` Stefan Monnier @ 2004-11-12 4:30 ` Katsumi Yamaoka 2004-11-13 23:03 ` Stefan 0 siblings, 1 reply; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-12 4:30 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding >>>>> In <871xezbtyh.fsf-monnier+emacs@gnu.org> Stefan Monnier wrote: >> I rebuilt Emacs and found the following case causes the `t' error. >> (defalias 'foo (lambda (s) (message "%s" s))) >> (defun bar (s) (inline (foo s))) > Hmm...indeed. I think I've fixed it now, It does the trick. Thanks. Though it may not be a real problem, the compiler warns with the following forms: (if (fboundp 'message) (defalias 'foo 'message)) (defun bar () (foo "Hello World")) In end of data: test5.el:2:1:Warning: the function `foo' is not known to be defined. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-12 4:30 ` Katsumi Yamaoka @ 2004-11-13 23:03 ` Stefan 2004-11-14 0:14 ` Katsumi Yamaoka 0 siblings, 1 reply; 28+ messages in thread From: Stefan @ 2004-11-13 23:03 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding > It does the trick. Thanks. Though it may not be a real > problem, the compiler warns with the following forms: > (if (fboundp 'message) (defalias 'foo 'message)) > (defun bar () (foo "Hello World")) > In end of data: > test5.el:2:1:Warning: the function `foo' is not known to be defined. That's normal and correct. If `message' is not bound, then `foo' won't be bound either, so `foo' is not guaranteed to be defined. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-13 23:03 ` Stefan @ 2004-11-14 0:14 ` Katsumi Yamaoka 2004-11-14 5:21 ` Stefan 0 siblings, 1 reply; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-14 0:14 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding >>>>> In <m11xex1hhh.fsf-monnier+emacs@gnu.org> >>>>> Stefan <monnier@iro.umontreal.ca> wrote: >> (if (fboundp 'message) (defalias 'foo 'message)) >> (defun bar () (foo "Hello World")) >> In end of data: >> test5.el:2:1:Warning: the function `foo' is not known to be defined. > That's normal and correct. > If `message' is not bound, then `foo' won't be bound either, so `foo' is not > guaranteed to be defined. Is also the following case normal and correct? (if (fboundp 'message) (defalias 'foo 'message) (defalias 'foo 'ignore)) (defun bar () (foo "Hello World")) In end of data: test6.el:4:1:Warning: the function `foo' is not known to be defined. If it is normal, we will have to use `eval-and-compile' to surround similar `defalias' forms in many places. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 0:14 ` Katsumi Yamaoka @ 2004-11-14 5:21 ` Stefan 2004-11-14 6:10 ` Katsumi Yamaoka 0 siblings, 1 reply; 28+ messages in thread From: Stefan @ 2004-11-14 5:21 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding > (if (fboundp 'message) > (defalias 'foo 'message) > (defalias 'foo 'ignore)) (defalias 'foo (if (fboundp 'message) 'message 'ignore)) > If it is normal, we will have to use `eval-and-compile' to > surround similar `defalias' forms in many places. Yuck. Why do people feel like it's better to use ugly hacks than to get a few warnings ? Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 5:21 ` Stefan @ 2004-11-14 6:10 ` Katsumi Yamaoka 2004-11-14 6:36 ` Stefan 2004-11-14 17:29 ` Luc Teirlinck 0 siblings, 2 replies; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-14 6:10 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding >>>>> In <m1lld5xb07.fsf-monnier+emacs@gnu.org> >>>>> Stefan <monnier@iro.umontreal.ca> wrote: >> (if (fboundp 'message) >> (defalias 'foo 'message) >> (defalias 'foo 'ignore)) > (defalias 'foo > (if (fboundp 'message) 'message 'ignore)) That's okay. >> If it is normal, we will have to use `eval-and-compile' to >> surround similar `defalias' forms in many places. > Yuck. Why do people feel like it's better to use ugly hacks than to get > a few warnings ? Because it will grow up to be not a few numbers of warnings if we don't take any countermeasure. It makes it hard to find important messages from such chaos. Gnus was made not to issue such negligible warnings until now. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 6:10 ` Katsumi Yamaoka @ 2004-11-14 6:36 ` Stefan 2004-11-14 13:44 ` Katsumi Yamaoka 2004-11-14 17:29 ` Luc Teirlinck 1 sibling, 1 reply; 28+ messages in thread From: Stefan @ 2004-11-14 6:36 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding >>> (if (fboundp 'message) >>> (defalias 'foo 'message) >>> (defalias 'foo 'ignore)) >> (defalias 'foo >> (if (fboundp 'message) 'message 'ignore)) > That's okay. I'm not sure you realize that my code is not just shorter but it gets you rid of the warning (if you use a recent enough version of Emacs-CVS). Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 6:36 ` Stefan @ 2004-11-14 13:44 ` Katsumi Yamaoka 0 siblings, 0 replies; 28+ messages in thread From: Katsumi Yamaoka @ 2004-11-14 13:44 UTC (permalink / raw) Cc: emacs-pretest-bug, Luc Teirlinck, ding >>>>> In <m1y8h5vsy6.fsf-monnier+emacs@gnu.org> >>>>> Stefan <monnier@iro.umontreal.ca> wrote: > I'm not sure you realize that my code is not just shorter but it gets you > rid of the warning (if you use a recent enough version of Emacs-CVS). Yes, I know we get a lot of warnings to Gnus modules while bootstrapping Emacs CVS. Even though there's a serious problem, it will be buried into them. OTOH, Gnus CVS filters those negligible warnings carefully using dgnushack.el and lpath.el. It is useful to finding something wrong when performing `make'. >>> (defalias 'foo >>> (if (fboundp 'message) 'message 'ignore)) >> That's okay. That I wrote `okay' means that we will have to modify them in Gnus if it is really necessity (i.e., the case where it is unable to silence bytecomp). ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 6:10 ` Katsumi Yamaoka 2004-11-14 6:36 ` Stefan @ 2004-11-14 17:29 ` Luc Teirlinck 2004-11-14 19:17 ` Stefan Monnier 2004-11-16 16:49 ` Richard Stallman 1 sibling, 2 replies; 28+ messages in thread From: Luc Teirlinck @ 2004-11-14 17:29 UTC (permalink / raw) Cc: emacs-pretest-bug, monnier, ding Katsumi Yamaoka wrote: Because it will grow up to be not a few numbers of warnings if we don't take any countermeasure. It makes it hard to find important messages from such chaos. In Emacs, the situation is already hopeless. I redirected make bootstrap's error messages to a file. That file is 8155 lines long. Not all these lines are compiler warnings but a lot of them are. `(elisp)Coding Conventions' says to avoid compiler warnings, but many authors ignore this. In fact, it seems obvious that many authors not only do not worry about silencing compiler warnings, they do not even look at them. Many authors seem to believe that _all_ compiler warnings are bogus anyway and act accordingly. In fact, I have seen people silence compiler warnings them without even checking whether they are bogus or not. Most warnings are of the "function may not be defined at runtime" or "assignment to free variable" type. There are such an enormous amount of them that we have, practically speaking, no choice but to assume that they are bogus until proven non-bogus. Most "function from cl package called at runtime" seem to involve situations where loading the .el file loads cl, but loading the .elc does not. I believe that this is acceptable, in which case most of these warnings are bogus. Most "obsolete variable" warnings are not bogus, but fixing them does not seem urgent. Most of the new "designed for interactive use" warnings are probably not bogus, but they have to be looked at individually. Every single "assigning to a constant" warning seemed to be non-bogus. These are actually real non-trivial bugs, because reloading the file will erase all changes made in the Emacs session. I will discuss these separately. Sincerely, Luc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 17:29 ` Luc Teirlinck @ 2004-11-14 19:17 ` Stefan Monnier 2004-11-15 14:00 ` Richard Stallman 2004-11-16 16:49 ` Richard Stallman 1 sibling, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2004-11-14 19:17 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, ding > In Emacs, the situation is already hopeless. I redirected make > bootstrap's error messages to a file. That file is 8155 lines long. > Not all these lines are compiler warnings but a lot of them are. Elisp compilation warnings are basically useless to anyone else than the author. To fix this part is currently hopeless. To the elisp author, OTOH they can be very handy if she chooses to pay attention to them. > `(elisp)Coding Conventions' says to avoid compiler warnings, but many > authors ignore this. I think there's a whole range of cases: 1 - the author never byte compiles her files. 2 - she byte-compiles occasionally but just ignores all the warnings. 3 - she'd like to pay attention to the warnings, but there's so many that she's discouraged before even starting (anybody who's taken a look at Calc knows what I'm talking about). 4 - she'd pays attention to the warnings but several of them can't be fixed without ugly workarounds. For vars the (defvar foo) form is a godsent, but for functions, there's nothing equivalent (yet). The recently proposed (defun foo) form would be extremely helpful. 5 - ... > Most "function from cl package called at runtime" seem to involve > situations where loading the .el file loads cl, but loading the .elc > does not. I believe that this is acceptable, in which case most of > these warnings are bogus. Many of those warnings are bogus. One of the most common case of "bogus" is when a CL function is used in a macro and this macro is only used inside the file, so it's only used during byte-compilation and never at runtime. The warning is "bogus" is the sense that it's harmless but it is real in the sense that loading the resulting .elc file will define a macro which will burp if you try to use it without first loading CL. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 19:17 ` Stefan Monnier @ 2004-11-15 14:00 ` Richard Stallman 2004-11-15 15:36 ` Stefan Monnier 2004-11-15 23:57 ` Luc Teirlinck 0 siblings, 2 replies; 28+ messages in thread From: Richard Stallman @ 2004-11-15 14:00 UTC (permalink / raw) Cc: teirllm, emacs-pretest-bug, yamaoka, ding > Most "function from cl package called at runtime" seem to involve > situations where loading the .el file loads cl, but loading the .elc > does not. I am not sure how that would happen--would you please give one example? I believe that this is acceptable, in which case most of > these warnings are bogus. Many of those warnings are bogus. Perhaps the ones that remain are bogus, but that's because I fixed many real ones that used to occur. One of the most common case of "bogus" is when a CL function is used in a macro and this macro is only used inside the file, so it's only used during byte-compilation and never at runtime. I think the right fix for that is with-no-warnings. However, it could be that the code that generates this warning can be improved. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 14:00 ` Richard Stallman @ 2004-11-15 15:36 ` Stefan Monnier 2004-11-15 23:22 ` Miles Bader 2004-11-15 23:57 ` Luc Teirlinck 1 sibling, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2004-11-15 15:36 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, teirllm, ding > Many of those warnings are bogus. > Perhaps the ones that remain are bogus, but that's because I fixed > many real ones that used to occur. Indeed. I find the warning very useful. > One of the most common case of "bogus" is when a CL function is used > in a macro and this macro is only used inside the file, so it's only > used during byte-compilation and never at runtime. > I think the right fix for that is with-no-warnings. However, it could be > that the code that generates this warning can be improved. Yes, I have no good idea how to improve it, but hopefully an idea will show up at some point. In the mean time with-no-warning is the best we have. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 15:36 ` Stefan Monnier @ 2004-11-15 23:22 ` Miles Bader 2004-11-15 23:28 ` Stefan Monnier 0 siblings, 1 reply; 28+ messages in thread From: Miles Bader @ 2004-11-15 23:22 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, teirllm, ding On Mon, Nov 15, 2004 at 10:36:52AM -0500, Stefan Monnier wrote: > > One of the most common case of "bogus" is when a CL function is used > > in a macro and this macro is only used inside the file, so it's only > > used during byte-compilation and never at runtime. > > > I think the right fix for that is with-no-warnings. However, it could be > > that the code that generates this warning can be improved. > > Yes, I have no good idea how to improve it, but hopefully an idea will show > up at some point. In the mean time with-no-warning is the best we have. Couldn't such macros be wrapped in `eval-when-compile' (I forgot the exact name, but ...)? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 23:22 ` Miles Bader @ 2004-11-15 23:28 ` Stefan Monnier 2004-11-15 23:38 ` Miles Bader 0 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2004-11-15 23:28 UTC (permalink / raw) Cc: rms, emacs-pretest-bug, yamaoka, teirllm, ding > Couldn't such macros be wrapped in `eval-when-compile' (I forgot the exact > name, but ...)? Some are wrapped. Some could be. But those like the setf methods generated by `defstruct' can't. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 23:28 ` Stefan Monnier @ 2004-11-15 23:38 ` Miles Bader 2004-11-15 23:44 ` Stefan Monnier 0 siblings, 1 reply; 28+ messages in thread From: Miles Bader @ 2004-11-15 23:38 UTC (permalink / raw) Cc: teirllm, emacs-pretest-bug, ding, yamaoka On Mon, Nov 15, 2004 at 06:28:58PM -0500, Stefan Monnier wrote: > > Couldn't such macros be wrapped in `eval-when-compile' (I forgot the exact > > name, but ...)? > > Some are wrapped. Some could be. But those like the setf methods generated > by `defstruct' can't. Hmmm. Well, I'd say just rewrite defstruct to not use cl functions (I'm sure cl fans will bitch about how horrible that is, but cl is a part of emacs, it should cater to Emacs' idiosyncrasies where possible). Anyway, wouldn't such wrapping address at least majority of such cases? The reason I'm going on about this is that I think it's a much more understandable way of fixing such warnings (in that it directly shows what's going on) than using `with-no-warnings' (which is a pretty blunt tool). -Miles -- 80% of success is just showing up. --Woody Allen ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 23:38 ` Miles Bader @ 2004-11-15 23:44 ` Stefan Monnier 0 siblings, 0 replies; 28+ messages in thread From: Stefan Monnier @ 2004-11-15 23:44 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, teirllm, ding > Hmmm. Well, I'd say just rewrite defstruct to not use cl functions. That might be an option, indeed. > Anyway, wouldn't such wrapping address at least majority of such cases? The > reason I'm going on about this is that I think it's a much more > understandable way of fixing such warnings (in that it directly shows what's > going on) than using `with-no-warnings' (which is a pretty blunt tool). Agreed. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 14:00 ` Richard Stallman 2004-11-15 15:36 ` Stefan Monnier @ 2004-11-15 23:57 ` Luc Teirlinck 2004-11-16 1:29 ` Nick Roberts 1 sibling, 1 reply; 28+ messages in thread From: Luc Teirlinck @ 2004-11-15 23:57 UTC (permalink / raw) Cc: monnier, emacs-pretest-bug, yamaoka, ding Richard Stallman wrote: > Most "function from cl package called at runtime" seem to involve > situations where loading the .el file loads cl, but loading the .elc > does not. Do `emacs -q'. ELISP> (load "winner") t ELISP> (featurep 'cl) nil ELISP> (load "winner.el") t ELISP> (featurep 'cl) t That will always happen when the file contains: (eval-when-compile (require 'cl)) because the `(require cl)' is executed when the source file is loaded, as it should be. However, that was _not_ the cause of the compiler warning, as I mistakenly thought. Here is the compiler warning: Compiling file /home/teirllm/emacscvsdir/emacs/lisp/winner.el at Mon Nov 15 17:27:42 2004 Entering directory `/home/teirllm/emacscvsdir/emacs/lisp/' winner.el:53:10:Warning: Function `gensym' from cl package called at runtime This warning is bogus. `gensym' can indeed be called at runtime, but only if `setf' is called first, which requires cl to be loaded anyway. Adding `with-no-warnings' as below definitely gets rid of the winner warning. I do not know whether better solutions currently being discussed apply to this case, nor when such better solutions would be available. (with-no-warnings (defsetf winner-active-region () (store) (if (fboundp 'zmacs-activate-region) `(if ,store (zmacs-activate-region) (zmacs-deactivate-region)) `(setq mark-active ,store)))) One better, currently available, solution might be to put the `with-no-warnings' around the call to `gensym' in `defsetf'. That would seem to get rid of all similar bogus warnings. Sincerely, Luc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-15 23:57 ` Luc Teirlinck @ 2004-11-16 1:29 ` Nick Roberts 2004-11-16 1:49 ` Luc Teirlinck 2004-11-16 2:19 ` Luc Teirlinck 0 siblings, 2 replies; 28+ messages in thread From: Nick Roberts @ 2004-11-16 1:29 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, ding, monnier > Here is the compiler warning: > > Compiling file /home/teirllm/emacscvsdir/emacs/lisp/winner.el at Mon > Nov 15 17:27:42 2004 > Entering directory `/home/teirllm/emacscvsdir/emacs/lisp/' > winner.el:53:10:Warning: Function `gensym' from cl package called at runtime > > This warning is bogus. `gensym' can indeed be called at runtime, but > only if `setf' is called first, which requires cl to be loaded anyway. I don't think this is bogus. setf is a macro and is not needed at runtime because it has been expanded and compiled into winner.elc (I think you might mean defsetf but that is also a macro, so the same applies). gensym, on the other hand, is a function, so Emacs will need to know where to find it when it is called. The warning is presumably there to help the person writing the code decide if cl needs to be loaded. Without it, it may be the user who discovers the problem at runtime. Once the the coder decides its not a problem, then putting with-no-warnings around the call would, indeed, appear to be the right thing to do. Nick ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-16 1:29 ` Nick Roberts @ 2004-11-16 1:49 ` Luc Teirlinck 2004-11-16 2:19 ` Luc Teirlinck 1 sibling, 0 replies; 28+ messages in thread From: Luc Teirlinck @ 2004-11-16 1:49 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, monnier, ding Nick Robert wrote: > This warning is bogus. `gensym' can indeed be called at runtime, but > only if `setf' is called first, which requires cl to be loaded anyway. I don't think this is bogus. setf is a macro and is not needed at runtime because it has been expanded and compiled into winner.elc (I think you might mean defsetf but that is also a macro, so the same applies). gensym, on the other hand, is a function, so Emacs will need to know where to find it when it is called. I do not believe so. The only purpose of defsetf is to tell setf what to do. The expansion of the defsetf macro will only be called if setf is called first, which requires cl to be loaded. _No_ cl function used inside the defsetf expansion will ever load cl, when called from there. Sincerely, Luc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-16 1:29 ` Nick Roberts 2004-11-16 1:49 ` Luc Teirlinck @ 2004-11-16 2:19 ` Luc Teirlinck 1 sibling, 0 replies; 28+ messages in thread From: Luc Teirlinck @ 2004-11-16 2:19 UTC (permalink / raw) Cc: emacs-pretest-bug, yamaoka, monnier, ding >From my previous message: _No_ cl function used inside the defsetf expansion will ever load cl, when called from there. I have to correct this: (defmacro defsetf (func arg1 &rest args) Calls to `gensym' in args definitely could load cl at runtime. But not the code in defsetf that is only used to compute the `setf' expansion. This applies to the involved calls to `gensym'. Sincerely, Luc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Change in bytecomp.el breaks Gnus 2004-11-14 17:29 ` Luc Teirlinck 2004-11-14 19:17 ` Stefan Monnier @ 2004-11-16 16:49 ` Richard Stallman 1 sibling, 0 replies; 28+ messages in thread From: Richard Stallman @ 2004-11-16 16:49 UTC (permalink / raw) Cc: yamaoka, emacs-pretest-bug, monnier, ding Most warnings are of the "function may not be defined at runtime" or "assignment to free variable" type. There are such an enormous amount of them that we have, practically speaking, no choice but to assume that they are bogus until proven non-bogus. I have been eliminating the "free variable" warnings from many files over the past couple of years. I have not tried to to so in calc or rmail, because calc is big and I don't know it, and rmail is being to a large extent rewritten. Would others like to carry on with this work? ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2004-11-16 16:49 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <877jouepy8.fsf@telia.com> [not found] ` <b9yd5ymkq11.fsf@jpl.org> 2004-11-11 7:40 ` Change in bytecomp.el breaks Gnus Katsumi Yamaoka 2004-11-11 11:18 ` Katsumi Yamaoka 2004-11-11 17:45 ` Luc Teirlinck 2004-11-11 21:55 ` Stefan 2004-11-11 22:41 ` Luc Teirlinck 2004-11-11 22:54 ` Luc Teirlinck 2004-11-12 0:22 ` Katsumi Yamaoka 2004-11-12 3:57 ` Stefan Monnier 2004-11-12 4:30 ` Katsumi Yamaoka 2004-11-13 23:03 ` Stefan 2004-11-14 0:14 ` Katsumi Yamaoka 2004-11-14 5:21 ` Stefan 2004-11-14 6:10 ` Katsumi Yamaoka 2004-11-14 6:36 ` Stefan 2004-11-14 13:44 ` Katsumi Yamaoka 2004-11-14 17:29 ` Luc Teirlinck 2004-11-14 19:17 ` Stefan Monnier 2004-11-15 14:00 ` Richard Stallman 2004-11-15 15:36 ` Stefan Monnier 2004-11-15 23:22 ` Miles Bader 2004-11-15 23:28 ` Stefan Monnier 2004-11-15 23:38 ` Miles Bader 2004-11-15 23:44 ` Stefan Monnier 2004-11-15 23:57 ` Luc Teirlinck 2004-11-16 1:29 ` Nick Roberts 2004-11-16 1:49 ` Luc Teirlinck 2004-11-16 2:19 ` Luc Teirlinck 2004-11-16 16:49 ` Richard Stallman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).