* cl-byte-compile-compiler-macro
@ 2006-03-22 21:02 Kim F. Storm
2006-03-23 23:52 ` cl-byte-compile-compiler-macro Glenn Morris
0 siblings, 1 reply; 30+ messages in thread
From: Kim F. Storm @ 2006-03-22 21:02 UTC (permalink / raw)
>From time to time, I see this error pop up in a "*Compile Log*" buffer:
Error: Symbol's function definition is void: cl-byte-compile-compiler-macro
Latest when I did C-x v g on an emacs source file.
Have anybody else seen this?
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-22 21:02 cl-byte-compile-compiler-macro Kim F. Storm @ 2006-03-23 23:52 ` Glenn Morris 2006-03-24 23:25 ` cl-byte-compile-compiler-macro Richard Stallman 0 siblings, 1 reply; 30+ messages in thread From: Glenn Morris @ 2006-03-23 23:52 UTC (permalink / raw) Cc: emacs-devel Kim F. Storm wrote: > From time to time, I see this error pop up in a "*Compile Log*" buffer: > > Error: Symbol's function definition is void: cl-byte-compile-compiler-macro > > > Latest when I did C-x v g on an emacs source file. > > Have anybody else seen this? Yes, I see this the first time (in any emacs session) I use C-x v = on a file under CVS control. I don't see it with `emacs -q' though. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-23 23:52 ` cl-byte-compile-compiler-macro Glenn Morris @ 2006-03-24 23:25 ` Richard Stallman 2006-03-25 2:52 ` cl-byte-compile-compiler-macro Glenn Morris 0 siblings, 1 reply; 30+ messages in thread From: Richard Stallman @ 2006-03-24 23:25 UTC (permalink / raw) Cc: emacs-devel, storm Yes, I see this the first time (in any emacs session) I use C-x v = on a file under CVS control. I don't see it with `emacs -q' though. Can you track down which customization causes it? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-24 23:25 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-03-25 2:52 ` Glenn Morris 2006-03-25 9:43 ` cl-byte-compile-compiler-macro Glenn Morris ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Glenn Morris @ 2006-03-25 2:52 UTC (permalink / raw) Cc: emacs-devel, storm Richard Stallman wrote: > Yes, I see this the first time (in any emacs session) I use C-x v = on > a file under CVS control. I don't see it with `emacs -q' though. > > Can you track down which customization causes it? For me, commenting out the line "(require 'tramp)" in my .emacs stops this error appearing on my first call to vc-diff. If I start emacs with -q, require tramp, and then use vc-diff, I don't see the error, however; so it's not quite that simple. tramp.elc does at least contain "cl-byte-compile-compiler-macro". ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-25 2:52 ` cl-byte-compile-compiler-macro Glenn Morris @ 2006-03-25 9:43 ` Glenn Morris 2006-03-25 14:20 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-25 15:26 ` cl-byte-compile-compiler-macro Richard Stallman 2 siblings, 0 replies; 30+ messages in thread From: Glenn Morris @ 2006-03-25 9:43 UTC (permalink / raw) Cc: emacs-devel, storm I have reduced it to this (confusing) recipe: emacs -q --no-site-file -l foo.el changed_file_under_CVS C-x v = where foo.el contains: (add-to-list 'load-path "/usr/share/emacs21/site-lisp") (add-to-list 'load-path "/usr/share/emacs21/site-lisp/auctex") (require 'font-latex) (require 'tramp) This is on an up-to-date Debian testing system, where font-latex is provided by the Debian auctex package. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-25 2:52 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 9:43 ` cl-byte-compile-compiler-macro Glenn Morris @ 2006-03-25 14:20 ` Andreas Schwab 2006-03-28 6:39 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 15:26 ` cl-byte-compile-compiler-macro Richard Stallman 2 siblings, 1 reply; 30+ messages in thread From: Andreas Schwab @ 2006-03-25 14:20 UTC (permalink / raw) Cc: tramp-devel, emacs-devel, storm Glenn Morris <rgm@gnu.org> writes: > Richard Stallman wrote: > >> Yes, I see this the first time (in any emacs session) I use C-x v = on >> a file under CVS control. I don't see it with `emacs -q' though. >> >> Can you track down which customization causes it? > > For me, commenting out the line "(require 'tramp)" in my .emacs stops > this error appearing on my first call to vc-diff. If I start emacs > with -q, require tramp, and then use vc-diff, I don't see the error, > however; so it's not quite that simple. tramp.elc does at least > contain "cl-byte-compile-compiler-macro". I think the problem is that (defstruct tramp-file-name) needs to be moved before its first use (in with-parsed-tramp-file-name). Can you still reproduce it when you apply this patch? --- lisp/net/tramp.el.~1.89.~ 2006-02-13 11:08:07.000000000 +0100 +++ lisp/net/tramp.el 2006-03-25 15:17:34.000000000 +0100 @@ -1995,6 +1995,8 @@ own implementation." ((fboundp 'point-at-eol) (funcall (symbol-function 'point-at-eol))) (t (save-excursion (end-of-line) (point))))) +(defstruct tramp-file-name multi-method method user host localname) + (defmacro with-parsed-tramp-file-name (filename var &rest body) "Parse a Tramp filename and make components available in the body. @@ -6866,8 +6868,6 @@ Not actually used. Use `(format \"%o\" ;; internal data structure. Convenience functions for internal ;; data structure. -(defstruct tramp-file-name multi-method method user host localname) - (defun tramp-tramp-file-p (name) "Return t iff NAME is a tramp file." (save-match-data Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-25 14:20 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-03-28 6:39 ` Glenn Morris 0 siblings, 0 replies; 30+ messages in thread From: Glenn Morris @ 2006-03-28 6:39 UTC (permalink / raw) Cc: tramp-devel, storm, rms, emacs-devel Andreas Schwab wrote: > I think the problem is that (defstruct tramp-file-name) needs to be moved > before its first use (in with-parsed-tramp-file-name). > > Can you still reproduce it when you apply this patch? I'm afraid that yes, I can (ie the patch seems to have no effect). ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-25 2:52 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 9:43 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 14:20 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-03-25 15:26 ` Richard Stallman 2006-03-25 20:55 ` cl-byte-compile-compiler-macro Kim F. Storm 2 siblings, 1 reply; 30+ messages in thread From: Richard Stallman @ 2006-03-25 15:26 UTC (permalink / raw) Cc: emacs-devel, storm If I start emacs with -q, require tramp, and then use vc-diff, I don't see the error, however; so it's not quite that simple. tramp.elc does at least contain "cl-byte-compile-compiler-macro". That sounds like a bug in tramp--or in CL. Can you see what generates the call to it? I think cl-byte-compile-compiler-macro is supposed to be called during byte compilation. I don't think a call to it should be in tramp.elc. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-25 15:26 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-03-25 20:55 ` Kim F. Storm 2006-03-26 11:21 ` cl-byte-compile-compiler-macro Richard Stallman 0 siblings, 1 reply; 30+ messages in thread From: Kim F. Storm @ 2006-03-25 20:55 UTC (permalink / raw) Cc: Glenn Morris, emacs-devel Richard Stallman <rms@gnu.org> writes: > If I start emacs > with -q, require tramp, and then use vc-diff, I don't see the error, > however; so it's not quite that simple. tramp.elc does at least > contain "cl-byte-compile-compiler-macro". > > That sounds like a bug in tramp--or in CL. Can you see what generates > the call to it? I think cl-byte-compile-compiler-macro is supposed > to be called during byte compilation. I don't think a call to it > should be in tramp.elc. > If cl-byte-compile-compiler-macro shouldn't be in tramp.elc, it probably shouldn't be in any other *.elc files either. However, grepping for cl-byte-compile-compiler-macro in all *.elc files yields this result: Binary file ./gnus/nnmaildir.elc matches Binary file ./erc/erc-backend.elc matches Binary file ./erc/erc.elc matches Binary file ./emacs-lisp/bytecomp.elc matches Binary file ./emacs-lisp/cl-macs.elc matches Binary file ./emacs-lisp/ewoc.elc matches Binary file ./net/tramp.elc matches Binary file ./progmodes/ebrowse.elc matches Binary file ./progmodes/flymake.elc matches Binary file ./textmodes/sgml-mode.elc matches Binary file ./textmodes/tex-mode.elc matches Binary file ./cvs-status.elc matches Binary file ./pcvs-info.elc matches Binary file ./pcvs-util.elc matches Binary file ./uniquify.elc matches Except for bytecomp.elc and cl-macs.elc, this looks suspicious. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-25 20:55 ` cl-byte-compile-compiler-macro Kim F. Storm @ 2006-03-26 11:21 ` Richard Stallman 2006-03-26 14:10 ` cl-byte-compile-compiler-macro Andreas Schwab 0 siblings, 1 reply; 30+ messages in thread From: Richard Stallman @ 2006-03-26 11:21 UTC (permalink / raw) Cc: rgm, emacs-devel However, grepping for cl-byte-compile-compiler-macro in all *.elc files yields this result: I agree it is suspicious. On the other hand, it occurs to me that maybe it is not a bug--maybe this is how defstruct accessor macros are implemented. Could that be it? If so, then (1) that needs to be documented, and (2) maybe the function needs to be moved to subr.el. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-26 11:21 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-03-26 14:10 ` Andreas Schwab 2006-03-27 2:07 ` cl-byte-compile-compiler-macro Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Andreas Schwab @ 2006-03-26 14:10 UTC (permalink / raw) Cc: rgm, emacs-devel, Kim F. Storm Richard Stallman <rms@gnu.org> writes: > However, grepping for cl-byte-compile-compiler-macro in all *.elc > files yields this result: > > I agree it is suspicious. On the other hand, it occurs to me that > maybe it is not a bug--maybe this is how defstruct accessor macros > are implemented. Could that be it? The symbol is only used as a constant. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-26 14:10 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-03-27 2:07 ` Stefan Monnier 2006-03-27 9:34 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-27 22:29 ` cl-byte-compile-compiler-macro Richard Stallman 0 siblings, 2 replies; 30+ messages in thread From: Stefan Monnier @ 2006-03-27 2:07 UTC (permalink / raw) Cc: rgm, Kim F. Storm, rms, emacs-devel >> However, grepping for cl-byte-compile-compiler-macro in all *.elc >> files yields this result: >> >> I agree it is suspicious. On the other hand, it occurs to me that >> maybe it is not a bug--maybe this is how defstruct accessor macros >> are implemented. Could that be it? > The symbol is only used as a constant. AFAIK the symbol is a used as a symbol property. It tells the byte-compiler that a function call to the function bound to the corresponding symbol can be optimized in some cases and that the way to optimize it to to pass it to the cl-byte-compile-compiler-macro property value (it's a so-called "compiler macro"). It's used for example to turn a call to (list* a b c) into (cons a (cons b c)), i.e. in this case a mix of inlining and unrolling. And yes, it's quite likely that defstruct accessors define compiler macros (I believe that CL's defsubst* are implemented using this same mechanism). Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-27 2:07 ` cl-byte-compile-compiler-macro Stefan Monnier @ 2006-03-27 9:34 ` Andreas Schwab 2006-03-27 22:29 ` cl-byte-compile-compiler-macro Richard Stallman 1 sibling, 0 replies; 30+ messages in thread From: Andreas Schwab @ 2006-03-27 9:34 UTC (permalink / raw) Cc: rgm, Kim F. Storm, rms, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > AFAIK the symbol is a used as a symbol property. It tells the byte-compiler > that a function call to the function bound to the corresponding symbol can > be optimized in some cases and that the way to optimize it to to pass it to > the cl-byte-compile-compiler-macro property value (it's a so-called > "compiler macro"). As I already explained, there is a used-before-defined issue in tramp.el that appears to trigger the byte-compiler during runtime. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-27 2:07 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-03-27 9:34 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-03-27 22:29 ` Richard Stallman 2006-03-27 23:44 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-28 6:52 ` cl-byte-compile-compiler-macro Glenn Morris 1 sibling, 2 replies; 30+ messages in thread From: Richard Stallman @ 2006-03-27 22:29 UTC (permalink / raw) Cc: schwab, emacs-devel, storm, rgm AFAIK the symbol is a used as a symbol property. It tells the byte-compiler that a function call to the function bound to the corresponding symbol can be optimized in some cases and that the way to optimize it to to pass it to the cl-byte-compile-compiler-macro property value (it's a so-called "compiler macro"). Right. So compiling a call to that macro will crash unless cl is loaded. I think we should move compiler-macroexpand and cl-byte-compile-compiler-macro from cl-macs.el into subr.el. It looks like that will make the compilation of these macro calls work properly, and it is rather painless. But these functions need to get doc strings that explain what they do, and perhaps some comments as well. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-27 22:29 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-03-27 23:44 ` Andreas Schwab 2006-03-28 19:33 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-04 19:57 ` cl-byte-compile-compiler-macro Richard Stallman 2006-03-28 6:52 ` cl-byte-compile-compiler-macro Glenn Morris 1 sibling, 2 replies; 30+ messages in thread From: Andreas Schwab @ 2006-03-27 23:44 UTC (permalink / raw) Cc: rgm, storm, Stefan Monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > AFAIK the symbol is a used as a symbol property. It tells the byte-compiler > that a function call to the function bound to the corresponding symbol can > be optimized in some cases and that the way to optimize it to to pass it to > the cl-byte-compile-compiler-macro property value (it's a so-called > "compiler macro"). > > Right. So compiling a call to that macro will crash unless cl is > loaded. You need to load cl anyway when byte compiling a call to defstruct, and then cl-macs (which defines byte-compile-compiler-macro) is autoloaded. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-27 23:44 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-03-28 19:33 ` Richard Stallman 2006-04-04 19:57 ` cl-byte-compile-compiler-macro Richard Stallman 1 sibling, 0 replies; 30+ messages in thread From: Richard Stallman @ 2006-03-28 19:33 UTC (permalink / raw) Cc: rgm, storm, monnier, emacs-devel You need to load cl anyway when byte compiling a call to defstruct, and then cl-macs (which defines byte-compile-compiler-macro) is autoloaded. It could be a problem that compiling a call to these macros loads CL. I am not sure; it is on the borderline. Does interpreting a call to these defstruct accessor macros also load CL? That would definitely be a problem. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-27 23:44 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-28 19:33 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-04-04 19:57 ` Richard Stallman 2006-04-04 20:37 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-04-04 20:50 ` cl-byte-compile-compiler-macro Stefan Monnier 1 sibling, 2 replies; 30+ messages in thread From: Richard Stallman @ 2006-04-04 19:57 UTC (permalink / raw) Cc: rgm, storm, monnier, emacs-devel [I sent this message a week ago but did not get a response. Could we get the discussion moving again?] You need to load cl anyway when byte compiling a call to defstruct, and then cl-macs (which defines byte-compile-compiler-macro) is autoloaded. It could be a problem that compiling a call to these macros loads CL. I am not sure; it is on the borderline. Does interpreting a call to these defstruct accessor macros also load CL? That would definitely be a problem. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-04 19:57 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-04-04 20:37 ` Andreas Schwab 2006-04-05 3:47 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-04 20:50 ` cl-byte-compile-compiler-macro Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: Andreas Schwab @ 2006-04-04 20:37 UTC (permalink / raw) Cc: rgm, storm, monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > It could be a problem that compiling a call to these macros loads CL. > I am not sure; it is on the borderline. > > Does interpreting a call to these defstruct accessor macros also load CL? defstruct is defined in cl-macs, so you can't use it without loading cl. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-04 20:37 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-04-05 3:47 ` Richard Stallman 2006-04-05 9:27 ` cl-byte-compile-compiler-macro Andreas Schwab 0 siblings, 1 reply; 30+ messages in thread From: Richard Stallman @ 2006-04-05 3:47 UTC (permalink / raw) Cc: rgm, emacs-devel, monnier, storm > It could be a problem that compiling a call to these macros loads CL. > I am not sure; it is on the borderline. > > Does interpreting a call to these defstruct accessor macros also load CL? defstruct is defined in cl-macs, so you can't use it without loading cl. We are miscommunicating. We have a file foo.el that uses defstruct and defines an accessor, foo-bar. Loading foo.elc will load the compiled definition of foo-bar. If another file, quux.el, does (require 'foo), it will load the compiled definition of foo-bar. So there are two questions: When I load quux.el, and run it interpreted, does it need to load CL in order to process the call to foo-bar? (Stefan says no.) When I compile quux.el, does that need CL to be loaded? (Assume quux.el does not load CL itself.) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 3:47 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-04-05 9:27 ` Andreas Schwab 2006-04-05 13:04 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-05 19:06 ` cl-byte-compile-compiler-macro Richard Stallman 0 siblings, 2 replies; 30+ messages in thread From: Andreas Schwab @ 2006-04-05 9:27 UTC (permalink / raw) Cc: rgm, emacs-devel, monnier, storm Richard Stallman <rms@gnu.org> writes: > When I load quux.el, and run it interpreted, does it need to load > CL in order to process the call to foo-bar? (Stefan says no.) I agree with Stefan. > When I compile quux.el, does that need CL to be loaded? > (Assume quux.el does not load CL itself.) I think it does, since the accessor function has a byte-compile property that points to function in cl-macs (cl-byte-compile-compiler-macro). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 9:27 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-04-05 13:04 ` Stefan Monnier 2006-04-05 19:06 ` cl-byte-compile-compiler-macro Richard Stallman 1 sibling, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2006-04-05 13:04 UTC (permalink / raw) Cc: rgm, emacs-devel, rms, storm >> When I compile quux.el, does that need CL to be loaded? >> (Assume quux.el does not load CL itself.) > I think it does, since the accessor function has a byte-compile property > that points to function in cl-macs (cl-byte-compile-compiler-macro). In that case it's a bug in CL (either in one of the cl*.el files or in the bytecomp.el file where we have the hook for CL's compiler-macros). Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 9:27 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-04-05 13:04 ` cl-byte-compile-compiler-macro Stefan Monnier @ 2006-04-05 19:06 ` Richard Stallman 2006-04-05 19:32 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-05 21:23 ` cl-byte-compile-compiler-macro Andreas Schwab 1 sibling, 2 replies; 30+ messages in thread From: Richard Stallman @ 2006-04-05 19:06 UTC (permalink / raw) Cc: rgm, emacs-devel, monnier, storm > When I compile quux.el, does that need CL to be loaded? > (Assume quux.el does not load CL itself.) I think it does, since the accessor function has a byte-compile property that points to function in cl-macs (cl-byte-compile-compiler-macro). I think it should be possible to compile quux.el without loading CL. I proposed moving that function and its subroutine to subr.el. Will that achieve the goal? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 19:06 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-04-05 19:32 ` Stefan Monnier 2006-04-05 19:39 ` cl-byte-compile-compiler-macro David Kastrup 2006-04-06 3:58 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-05 21:23 ` cl-byte-compile-compiler-macro Andreas Schwab 1 sibling, 2 replies; 30+ messages in thread From: Stefan Monnier @ 2006-04-05 19:32 UTC (permalink / raw) Cc: Andreas Schwab, storm, emacs-devel, rgm >> When I compile quux.el, does that need CL to be loaded? >> (Assume quux.el does not load CL itself.) > I think it does, since the accessor function has a byte-compile property > that points to function in cl-macs (cl-byte-compile-compiler-macro). > I think it should be possible to compile quux.el without loading CL. > I proposed moving that function and its subroutine to subr.el. > Will that achieve the goal? An alternative solution might be the following which just ignores the cl-byte-compile-compiler-macro value unless that function is indeed defined. Since compiler-macros are supposed to only provide optimizations but no change in semantics, no running them should always be harmless. Please install it if you think it's right. Stefan Index: bytecomp.el =================================================================== RCS file: /sources/emacs/emacs/lisp/emacs-lisp/bytecomp.el,v retrieving revision 2.181 diff -u -u -b -r2.181 bytecomp.el --- bytecomp.el 13 Jan 2006 09:54:33 -0000 2.181 +++ bytecomp.el 5 Apr 2006 19:30:00 -0000 @@ -429,8 +429,7 @@ ;; (apply 'byte-compiler-options-handler forms))) (eval-when-compile . (lambda (&rest body) (list 'quote - (byte-compile-eval (byte-compile-top-level - (cons 'progn body)))))) + (byte-compile-eval (cons 'progn body))))) (eval-and-compile . (lambda (&rest body) (byte-compile-eval-before-compile (cons 'progn body)) (cons 'progn body)))) @@ -2765,6 +2764,11 @@ (byte-compile-warn "`%s' used from Lisp code\n\ That command is designed for interactive use only" fn)) (if (and handler + ;; Make sure that function exists. This is important + ;; for CL compiler macros since the symbol may be + ;; `cl-byte-compile-compiler-macro' but if CL isn't + ;; loaded, this function doesn't exist. + (fboundp handler) (or (not (byte-compile-version-cond byte-compile-compatibility)) (not (get (get fn 'byte-opcode) 'emacs19-opcode)))) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 19:32 ` cl-byte-compile-compiler-macro Stefan Monnier @ 2006-04-05 19:39 ` David Kastrup 2006-04-05 20:12 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-06 3:58 ` cl-byte-compile-compiler-macro Richard Stallman 1 sibling, 1 reply; 30+ messages in thread From: David Kastrup @ 2006-04-05 19:39 UTC (permalink / raw) Cc: Andreas Schwab, emacs-devel, rms, rgm, storm Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> When I compile quux.el, does that need CL to be loaded? >>> (Assume quux.el does not load CL itself.) > >> I think it does, since the accessor function has a byte-compile property >> that points to function in cl-macs (cl-byte-compile-compiler-macro). > >> I think it should be possible to compile quux.el without loading CL. > >> I proposed moving that function and its subroutine to subr.el. >> Will that achieve the goal? > > An alternative solution might be the following which just ignores the > cl-byte-compile-compiler-macro value unless that function is indeed defined. > Since compiler-macros are supposed to only provide optimizations but no > change in semantics, no running them should always be harmless. > Please install it if you think it's right. Uh, what? Am I just confused about the terminology you use? defmacro most certainly does not provide optional stuff to the compiler. defsubst would, but is the result of that called a "compiler macro" while the result of "defmacro" isn't? Anyway, I don't even think that a defsubst which might or might not be executed is a good idea: if the programmer wants to achieve a certain effect with an optimization, failing to do so should not go unnoticed. It appears that the current behavior makes it hard to track down the problem. I think the solution should be to create better diagnostics for pinpointing the problem instead of removing them completely. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 19:39 ` cl-byte-compile-compiler-macro David Kastrup @ 2006-04-05 20:12 ` Stefan Monnier 0 siblings, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2006-04-05 20:12 UTC (permalink / raw) Cc: Andreas Schwab, storm, rms, rgm, emacs-devel > Uh, what? Am I just confused about the terminology you use? Yes. > defmacro most certainly does not provide optional stuff to the compiler. We're not talking about macros but about compiler-macros. > defsubst would, but is the result of that called a "compiler macro" while > the result of "defmacro" isn't? Yes. A compiler-macro, contrary to a macro, is only expanded by the compiler but not by the interpreter, so you can't rely on it being expanded. Also it's not expanded if the function is called indirectly. > It appears that the current behavior makes it hard to track down the > problem. I think the solution should be to create better diagnostics > for pinpointing the problem instead of removing them completely. OK, here's the same but with a diagnostic. Stefan Index: bytecomp.el =================================================================== RCS file: /sources/emacs/emacs/lisp/emacs-lisp/bytecomp.el,v retrieving revision 2.181 diff -u -u -b -r2.181 bytecomp.el --- bytecomp.el 13 Jan 2006 09:54:33 -0000 2.181 +++ bytecomp.el 5 Apr 2006 20:11:50 -0000 @@ -2765,6 +2764,14 @@ (byte-compile-warn "`%s' used from Lisp code\n\ That command is designed for interactive use only" fn)) (if (and handler + ;; Make sure that function exists. This is important + ;; for CL compiler macros since the symbol may be + ;; `cl-byte-compile-compiler-macro' but if CL isn't + ;; loaded, this function doesn't exist. + (or (fboundp handler) + (progn (byte-compile-warn + "Ignoring byte-compiler handler `%S'" handler) + nil)) (or (not (byte-compile-version-cond byte-compile-compatibility)) (not (get (get fn 'byte-opcode) 'emacs19-opcode)))) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 19:32 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-05 19:39 ` cl-byte-compile-compiler-macro David Kastrup @ 2006-04-06 3:58 ` Richard Stallman 2006-04-08 15:09 ` cl-byte-compile-compiler-macro Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: Richard Stallman @ 2006-04-06 3:58 UTC (permalink / raw) Cc: schwab, emacs-devel, rgm, storm (eval-when-compile . (lambda (&rest body) (list 'quote - (byte-compile-eval (byte-compile-top-level - (cons 'progn body)))))) + (byte-compile-eval (cons 'progn body))))) What is the reason for removing byte-compile-top-level? Was the call superfluous before? + (or (fboundp handler) + (progn (byte-compile-warn + "Ignoring byte-compiler handler `%S'" handler) + nil)) I don't think this should warn. This warning would be generated whenever you compile calls to these functions and CL is not loaded. The warning isn't useful, because it describes a circumstance which does not mean anything is wrong. So please don't add the warning. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-06 3:58 ` cl-byte-compile-compiler-macro Richard Stallman @ 2006-04-08 15:09 ` Stefan Monnier 0 siblings, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2006-04-08 15:09 UTC (permalink / raw) Cc: schwab, storm, rgm, emacs-devel > (eval-when-compile . (lambda (&rest body) > (list 'quote > - (byte-compile-eval (byte-compile-top-level > - (cons 'progn body)))))) > + (byte-compile-eval (cons 'progn body))))) > What is the reason for removing byte-compile-top-level? Sorry, this part of the patch was a mistake (it's a local change that I failed to remove before sending the email). > Was the call superfluous before? Yes, I think it's superfluous, and more importantly it can introduce "bugs" if the code is too large to be byte-compiled (causes too deep a recursion). I bumped into this at some point where I had a defconst whose (constant) value was built with a deep backquoted expression: the byte-compiler would choke on it, so I figured "well it's a constant anyway, so let's eval it before byte-compiling", but wrapping it in eval-when-compile didn't make a difference because the content is byte-compiled anyway. > + (or (fboundp handler) > + (progn (byte-compile-warn > + "Ignoring byte-compiler handler `%S'" handler) > + nil)) > I don't think this should warn. This warning would be generated > whenever you compile calls to these functions and CL is not loaded. > The warning isn't useful, because it describes a circumstance which > does not mean anything is wrong. > So please don't add the warning. OK, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-05 19:06 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-05 19:32 ` cl-byte-compile-compiler-macro Stefan Monnier @ 2006-04-05 21:23 ` Andreas Schwab 1 sibling, 0 replies; 30+ messages in thread From: Andreas Schwab @ 2006-04-05 21:23 UTC (permalink / raw) Cc: rgm, emacs-devel, monnier, storm Richard Stallman <rms@gnu.org> writes: > I proposed moving that function and its subroutine to subr.el. > Will that achieve the goal? cl-byte-compile-compiler-macro provides only the hook into the byte compiler. The actual macro expansion is performed by applying the cl-compiler-macro property. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-04-04 19:57 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-04 20:37 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-04-04 20:50 ` Stefan Monnier 1 sibling, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2006-04-04 20:50 UTC (permalink / raw) Cc: Andreas Schwab, emacs-devel, storm, rgm > Does interpreting a call to these defstruct accessor macros also load CL? It definitely doesn't load CL. Some uses may require CL to be loaded for them to work, but I think all such uses are pretty obvious (e.g. when using `setf'). Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: cl-byte-compile-compiler-macro 2006-03-27 22:29 ` cl-byte-compile-compiler-macro Richard Stallman 2006-03-27 23:44 ` cl-byte-compile-compiler-macro Andreas Schwab @ 2006-03-28 6:52 ` Glenn Morris 1 sibling, 0 replies; 30+ messages in thread From: Glenn Morris @ 2006-03-28 6:52 UTC (permalink / raw) Cc: schwab, storm, Stefan Monnier, emacs-devel Richard Stallman wrote: > Right. So compiling a call to that macro will crash unless cl is > loaded. When I explicitly (require 'cl), there is no error. > I think we should move compiler-macroexpand and > cl-byte-compile-compiler-macro from cl-macs.el into subr.el. It looks > like that will make the compilation of these macro calls work properly, > and it is rather painless. I tried that. I got a new Compile-Log error, this time about cl-defsubst-expand. So I moved that too. Then I got an error about cl-simple-exprs-p. Then I gave up. :) ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2006-04-08 15:09 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-03-22 21:02 cl-byte-compile-compiler-macro Kim F. Storm 2006-03-23 23:52 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-24 23:25 ` cl-byte-compile-compiler-macro Richard Stallman 2006-03-25 2:52 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 9:43 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 14:20 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-28 6:39 ` cl-byte-compile-compiler-macro Glenn Morris 2006-03-25 15:26 ` cl-byte-compile-compiler-macro Richard Stallman 2006-03-25 20:55 ` cl-byte-compile-compiler-macro Kim F. Storm 2006-03-26 11:21 ` cl-byte-compile-compiler-macro Richard Stallman 2006-03-26 14:10 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-27 2:07 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-03-27 9:34 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-27 22:29 ` cl-byte-compile-compiler-macro Richard Stallman 2006-03-27 23:44 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-03-28 19:33 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-04 19:57 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-04 20:37 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-04-05 3:47 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-05 9:27 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-04-05 13:04 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-05 19:06 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-05 19:32 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-05 19:39 ` cl-byte-compile-compiler-macro David Kastrup 2006-04-05 20:12 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-06 3:58 ` cl-byte-compile-compiler-macro Richard Stallman 2006-04-08 15:09 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-04-05 21:23 ` cl-byte-compile-compiler-macro Andreas Schwab 2006-04-04 20:50 ` cl-byte-compile-compiler-macro Stefan Monnier 2006-03-28 6:52 ` cl-byte-compile-compiler-macro Glenn Morris
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.