unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 11847@debbugs.gnu.org
Subject: bug#11847: 24.1.50; Error: Don't know how to compile #[nil "..."]
Date: Mon, 16 Jul 2012 22:50:16 -0700	[thread overview]
Message-ID: <01718D4EC241409DB101092AB41EAFA9@us.oracle.com> (raw)
In-Reply-To: <D308D3D320F44A018795C085CD1013FE@us.oracle.com>

> > Byte-compilation is not done within quoted forms (i.e. forms 
> > that start with '), so byte-compilation normally is not done
> > on the code passed to eval-after-load since that code is
> > usually quoted.
> 
> That's what I thought.  Which means that I still need that 
> code to let Icicles users optionally byte-compile the defuns
> in the `eval-after-load' contexts.

Or maybe not?  In the latest Windows build, from today (7/16), I'm seeing these
(new) messages during loading:

Function icicle-bookmark-a-file is already compiled
Function icicle-tag-a-file is already compiled
Function icicle-untag-a-file is already compiled
Function icicle-find-file-tagged is already compiled
etc.

Those are the functions that I was worried would not be compiled and so called
explicitly for their compilation.  Now I wonder.

So I guess I'm still not understanding.  I byte-compile the source file, which
has this kind of thing:

(defun icicle-cmd2-after-load-bookmark+ ()
  (icicle-define-file-command icicle-bookmark-a-file ...)
  (icicle-maybe-byte-compile-after-load icicle-bookmark-a-file)
  ... ; more of the same: function defs followed by calls to compile
)
(eval-after-load "bookmark+" '(icicle-cmd2-after-load-bookmark+))

`icicle-define-file-command' is a macro defined in a file available at compile
time.  It expands to a defun (e.g. that defines function
`icicle-bookmark-a-file' here).

`icicle-maybe-byte-compile-after-load' is this simple macro:

(defmacro icicle-maybe-byte-compile-after-load (function)
  `(when (and icicle-byte-compile-eval-after-load-flag (fboundp ',function))
    (require 'bytecomp)
    (let ((byte-compile-warnings  ())
          (byte-compile-verbose   nil))
      (byte-compile ',function))))

(Now that I look at that again I notice that that macro could/should just be a
function.  Dunno why I made it a macro.)

Do those messages indicate that the functions in question were already compiled
in the .elc where they are defined inside `icicle-cmd2-after-load-bookmark+'?

Looking at your previous response, it seems to suggest only that the _call_ to
`icicle-cmd2-after-load-bookmark+' would not be byte-compiled, because it is
quoted.  But the defuns (via the macro) that are in the body of
`icicle-cmd2-after-load-bookmark+': are they byte-compiled in the .elc where
`icicle-cmd2-after-load-bookmark+' is defined?  I was afraid they would not be,
but the messages seem to indicate that they are.

IOW, given those messages, I'm wondering again whether I really need the
(user-optional) calls to `icicle-maybe-byte-compile-after-load'.  I was
supposing that I needed them because the definitions are inside an
`eval-after-load' (with a quoted sexp, as you mentioned).

> > > (and if so whether that is true in older Emacs versions also)
> > 
> > Yes, there has not been any change in this regard.  What has 
> > changed is that byte-compile now complains when it can't do
> > its job, whereas it used to silently just return nil without
> > doing anything.
> 
> I guess the bug has to do with why it thinks it cannot do its 
> job here.  Unless there is some bug in my code that makes compilation 
> impossible where it should otherwise be possible.  Can you tell by
> looking at the code I sent?  Or do you think there is a byte-compiler
> bug here?

Since the bug is no longer manifested, now I'm guessing that it was previously
complaining that it could not compile only because the target was already
compiled.  Is that the case?

I'd be glad to get rid of the micmac of using
`icicle-maybe-byte-compile-after-load', if I understood that it did not actually
do anything worthwhile.  Looking for some understanding of this.  Thx.






  parent reply	other threads:[~2012-07-17  5:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03  3:28 bug#11847: 24.1.50; Error: Don't know how to compile #[nil "..."] Drew Adams
2012-07-03  6:12 ` Drew Adams
2012-07-03  6:21   ` Drew Adams
2012-07-03 13:42 ` Stefan Monnier
2012-07-03 14:44   ` Drew Adams
2012-07-03 17:26     ` Stefan Monnier
2012-07-03 18:00       ` Drew Adams
2012-07-05 15:49         ` Drew Adams
2012-07-05 16:14           ` Stefan Monnier
2012-07-05 16:20             ` Drew Adams
2012-07-17  5:56               ` Drew Adams
2012-07-17  5:50         ` Drew Adams [this message]
2012-07-17  6:37           ` Stefan Monnier
2012-07-17  6:40             ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01718D4EC241409DB101092AB41EAFA9@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=11847@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).