GNU bug report logs - #2061
23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2061 in the body.
You can then email your comments to 2061 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Brent Goodrick <bgoodr <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file
Date: Sun, 25 Jan 2009 18:19:27 -0800

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug <at> gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

The load function will load a .elc file even if the .el file is newer
than the .elc file.  There are warnings issued, but it is likely that
the message is lost in the ton of messages that usually are emitted,
especially during Emacs invocation.

When would the user ever prefer to load the .elc file after having
modified the .el file?

My suggestion is to add a customizable preference variable called,
say, load-prefer-newer-lisp-files (that needs a better name), that is
recognized by the load function (defined in C code). When
load-prefer-newer-lisp-files is non-nil, and when there is a .el and
.elc file, and when the .el file is newer than the .elc file, it loads
the .el file and not the .elc file (and possibly emits a warning of
this action).

Having it be a customizable preference variable avoids surprising
other users who are used to the existing behavior.

I could hack around this by fset'ing `load' to be my own function that
removes the .elc file when the .el file is found to be newer, but that
is an expensive operation involving calling such functions such as
locate-file-internal to find both .el and .elc files, testing their
modification date-time stamps, etc., operations that the `load' C
function performs already.  Hence, why I think it is best to change
the load function to allow for both approaches via a preference
variable.

Thanks!
Brent


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/home/brentg/emacs_from_source/install/share/emacs/23.0.60/etc/DEBUG for instructions.


In GNU Emacs 23.0.60.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.11)
 of 2009-01-25 on hungover
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--with-x-toolkit' '--prefix=/home/brentg/emacs_from_source/install''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-netsplit-mode: t
  desktop-save-mode: t
  iswitchb-mode: t
  erc-ring-mode: t
  erc-services-mode: t
  erc-networks-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  display-time-mode: t
  shell-dirtrack-mode: t
  delete-selection-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: 1
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
C-p C-p C-p C-p M-f M-f SPC f o r m C-e M-b M-f SPC 
t h e SPC . e l SPC f i l e SPC i n t o SPC a SPC . 
e l c SPC f i l e C-d C-a M-q C-n C-n C-n C-n C-n C-n 
C-n C-n C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-n 
C-n C-n C-e C-b SPC f o r SPC d e m o n s t r a t i 
o n SPC p u r o <backspace> p o <backspace> o s e s 
C-a C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n M-f M-f M-f M-f M-f M-f 
M-f M-f M-f M-f M-f M-f M-b M-b M-b M-b f o r SPC M-f 
M-f M-q M-f M-f C-b , SPC w h i c h SPC i s SPC SPC 
<backspace> a SPC l i C-SPC M-b M-b M-b w r o n g SPC 
b e c a u s e SPC t h e SPC . e l c SPC f i l e SPC 
d o e s SPC i n e <backspace> d e e d SPC e x i s t 
M-q C-a C-n C-n C-n C-n C-n C-n M-f M-f M-f M-f M-f 
M-f M-f M-f M-f M-f C-n C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p 
C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-p C-c 
C-c y e s <return> <down-mouse-1> <mouse-1> M-SPC <return> 
<return> M-x r e p p o r t M-P <return>

Recent messages:
/home/brentg/.authin: 100% (398/398)
334 VXNlcm5hbWU6
334 UGFzc3dvcmQ6
235 2.7.0 Accepted
250 2.1.0 OK k41sm12274699rvb.3
250 2.1.5 OK k41sm12274699rvb.3
354  Go ahead k41sm12274699rvb.3
250 2.0.0 OK 1232907223 k41sm12274699rvb.3
221 2.0.0 closing connection k41sm12274699rvb.3
Sending...done

Message #10 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Brent Goodrick <bgoodr <at> gmail.com>, 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60;	Add preference to force load of Elisp files when they are newer	than corresponding byte-compiled file
Date: Mon, 26 Jan 2009 06:08:43 +0200

> From: Brent Goodrick <bgoodr <at> gmail.com>
> Date: Sun, 25 Jan 2009 18:19:27 -0800
> Cc: 
> 
> When would the user ever prefer to load the .elc file after having
> modified the .el file?

When you are working on the .el file and it is not ready yet, or
buggy.

> My suggestion is to add a customizable preference variable called,
> say, load-prefer-newer-lisp-files (that needs a better name), that is
> recognized by the load function (defined in C code). When
> load-prefer-newer-lisp-files is non-nil, and when there is a .el and
> .elc file, and when the .el file is newer than the .elc file, it loads
> the .el file and not the .elc file (and possibly emits a warning of
> this action).

Yes, but please not now, not before Emacs 23.1 is released.  We are in
feature freeze.

Message #15 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Brent Goodrick <bgoodr <at> gmail.com>
Cc: 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files 
	when they are newer than corresponding byte-compiled file
Date: Mon, 26 Jan 2009 09:45:50 +0100

On Mon, Jan 26, 2009 at 03:19, Brent Goodrick <bgoodr <at> gmail.com> wrote:

> When would the user ever prefer to load the .elc file after having
> modified the .el file?

Whenever he saves the .el file, but the modifications aren't finished
(perhaps they don't even compile).

In general, if Emacs loads the .el file when it is newer, you lose the
ability to decide whether you want the .el or the .elc. If Emacs
always loads the .elc (if present), you can decide you want the new
code loaded, by compiling the .el.

> I could hack around this by fset'ing `load' to be my own function that
> removes the .elc file when the .el file is found to be newer, but that
> is an expensive operation involving calling such functions such as
> locate-file-internal to find both .el and .elc files, testing their
> modification date-time stamps, etc., operations that the `load' C
> function performs already.

Isn't easier just to compile the .el file? If you're developing or
modifying a package, and want to try it at once, create a macro to
compile it as soon as you save it...

    Juanma

Message #22 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard M Stallman <rms <at> gnu.org>
To: Brent Goodrick <bgoodr <at> gmail.com>, 2061 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org, bug-submit-list <at> donarmstrong.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2061: 23.0.60;
	Add preference to force load of Elisp files when they are newer
	than corresponding byte-compiled file
Date: Mon, 26 Jan 2009 11:31:24 -0500

    When would the user ever prefer to load the .elc file after having
    modified the .el file?

If you have written changes which are incomplete and not ready
to be executed.

This feature gives you control over when to start running your
changes: you control it by when you compile the files.  It is
important and it is easy to use.

Message #37 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Brent Goodrick <bgoodr <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Brent Goodrick <bgoodr <at> gmail.com>, 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60;	Add preference to force load of Elisp files when they are newer	than corresponding byte-compiled file
Date: Tue, 27 Jan 2009 07:08:59 -0800

Eli Zaretskii writes:
 > Yes, but please not now, not before Emacs 23.1 is released.  We are in
 > feature freeze.

Agreed. I was unaware of the release schedule.

Brent

Message #42 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Brent Goodrick <bgoodr <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Brent Goodrick <bgoodr <at> gmail.com>, 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files 
	when they are newer than corresponding byte-compiled file
Date: Tue, 27 Jan 2009 07:54:09 -0800

Juanma Barranquero writes:
 > On Mon, Jan 26, 2009 at 03:19, Brent Goodrick <bgoodr <at> gmail.com> wrote:
 > 
 > > When would the user ever prefer to load the .elc file after having
 > > modified the .el file?
 > 
 > Whenever he saves the .el file, but the modifications aren't finished
 > (perhaps they don't even compile).
 > 
 > In general, if Emacs loads the .el file when it is newer, you lose the
 > ability to decide whether you want the .el or the .elc. If Emacs
 > always loads the .elc (if present), you can decide you want the new
 > code loaded, by compiling the .el.

The problem relates to when and how to notify the user that the stale
.elc file is the one being loaded.  During development, I just
`eval-buffer' repeatedly on a .el file, always unaware that there is a
stale .elc file lying in wait to confuse me the next time I reload the
entire Emacs process/session. At init time, I only get a warning,
among a ton of other benign warnings and messages, and that one
critical warning is therefore not seen (of course, it is impractical
to ask the user to read all of those messages). So, since that warning
is not seen, effectively I lose the ability to decide which file, .el
or .elc, to load.

However, your concern is duly noted. Perhaps it is better not to
change that hardcoded behavior in the way I suggested earlier.  How
about this (I'm not stuck on this nomenclature; modify to taste): Add
the following logic to the C `load' function: 

  Before loading either the .el or .elc file, test for the condition
  where the .el file is newer than the .elc file. If it is, then do
  the following:

    See if the `load-hook-stale-byte-compile-handlers' hook variable
    is set to non-nil. When it is non-nil, run the hook variable with
    `run-hook-with-args-until-success'. Each function the user has
    added to that hook variable would do any logic s/he wishes,
    including in my case to popup a minibuffer prompt asking what to
    do. When the hook function thus called returns a 'prefer-el-file
    symbol, `load' then loads the .el file and ignores the .elc
    file. Likewise, when the hook function returns the
    'prefer-elc-file symbol, then load the .elc file but give no
    warning message and ignore the .el file. When nil is returned from
    the `run-hook-with-args-until-success' function, just load the
    .elc file and produce the stale file warning message as is done
    today (i.e., preserve existing behavior).

In my case, I would actually allow the third case in the prompt, which
is to byte compile the file and then return 'prefer-elc-file so that
the newly byte compiled file is then loaded. That way, I don't pay the
byte-compile-upon-every-save penalty as indicated below.
  
 > 
 > > I could hack around this by fset'ing `load' to be my own function that
 > > removes the .elc file when the .el file is found to be newer, but that
 > > is an expensive operation involving calling such functions such as
 > > locate-file-internal to find both .el and .elc files, testing their
 > > modification date-time stamps, etc., operations that the `load' C
 > > function performs already.
 > 
 > Isn't easier just to compile the .el file? If you're developing or
 > modifying a package, and want to try it at once, create a macro to
 > compile it as soon as you save it...

I have tried doing that, but found it unworkable in practice, as
byte-compiling upon each save ended up chewing up too much time during
development (the byte-compile-upon-every-save penalty). Consider that
I save frequently. :)

A cheaper/dirtier arrangement that I have in place now is an
after-save hook that simply deletes the associated .elc file if it
exists. But that is a hack, so I am now trying to get the root problem
addressed in the C code where it exists.

Brent

Message #47 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Brent Goodrick <bgoodr <at> gmail.com>
To: rms <at> gnu.org
Cc: Brent Goodrick <bgoodr <at> gmail.com>, 2061 <at> debbugs.gnu.org,
        emacs-pretest-bug <at> gnu.org, bug-submit-list <at> donarmstrong.com,
        bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2061: 23.0.60;
	Add preference to force load of Elisp files when they are newer
	than corresponding byte-compiled file
Date: Tue, 27 Jan 2009 07:56:15 -0800

Richard M Stallman writes:
 >     When would the user ever prefer to load the .elc file after having
 >     modified the .el file?
 > 
 > If you have written changes which are incomplete and not ready
 > to be executed.
 > 
 > This feature gives you control over when to start running your
 > changes: you control it by when you compile the files.  It is
 > important and it is easy to use.

See a new proposal I just emailed to this thread which I think
addresses the problem a bit better than just changing the default
`load' behavior as I originally suggested.

Brent

Message #62 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Brent Goodrick <bgoodr <at> gmail.com>
Cc: 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files 
	when they are newer than corresponding byte-compiled file
Date: Wed, 28 Jan 2009 03:06:13 +0100

On Tue, Jan 27, 2009 at 16:54, Brent Goodrick <bgoodr <at> gmail.com> wrote:

> The problem relates to when and how to notify the user that the stale
> .elc file is the one being loaded.  During development, I just
> `eval-buffer' repeatedly on a .el file, always unaware that there is a
> stale .elc file lying in wait to confuse me the next time I reload the
> entire Emacs process/session.

If you're going to modify/test the package with eval-buffer, you
should make sure there's no .elc sitting around.

> At init time, I only get a warning,
> among a ton of other benign warnings and messages, and that one
> critical warning is therefore not seen (of course, it is impractical
> to ask the user to read all of those messages).

As you know, that's trivially fixed:

(add-hook 'emacs-startup-hook
          (lambda ()
            (with-current-buffer (get-buffer "*Messages*")
              (goto-char (point-min))
              (while (re-search-forward "[Ss]ource file .*? newer" nil t)
                (warn "%s" (buffer-substring (line-beginning-position)
                                             (line-end-position)))))))


> Add the following logic to the C `load' function:
>
>  Before loading either the .el or .elc file, test for the condition
>  where the .el file is newer than the .elc file. If it is, then do
>  the following:
>
>    See if the `load-hook-stale-byte-compile-handlers' hook variable
>    is set to non-nil. When it is non-nil, run the hook variable with
>    `run-hook-with-args-until-success'. Each function the user has
>    added to that hook variable would do any logic s/he wishes,
>    including in my case to popup a minibuffer prompt asking what to
>    do. When the hook function thus called returns a 'prefer-el-file
>    symbol, `load' then loads the .el file and ignores the .elc
>    file. Likewise, when the hook function returns the
>    'prefer-elc-file symbol, then load the .elc file but give no
>    warning message and ignore the .el file. When nil is returned from
>    the `run-hook-with-args-until-success' function, just load the
>    .elc file and produce the stale file warning message as is done
>    today (i.e., preserve existing behavior).

That would work, but it is IMHO too much (interface, not code)
complexity for little gain. In most cases, having a .elc older than
its corresponding .el is a bug (or, let's call it, a temporary
situation), so getting a warning to remind the user about fixing it
seems much more economical.

That said, sometimes I would've liked to have a hook that runs when a
file is loaded; or the ability to defadvice Fload (you can, except
that Fload is also called from C code, for example for autoloads).

> I have tried doing that, but found it unworkable in practice, as
> byte-compiling upon each save ended up chewing up too much time during
> development (the byte-compile-upon-every-save penalty). Consider that
> I save frequently. :)

I didn't mean to byte-compile on saving, I meant to byte-compile on
eval-buffer (or whatever method you use to test your code).

> But that is a hack, so I am now trying to get the root problem
> addressed in the C code where it exists.

I agree that greater control over the loading process could sometimes
be useful; but I don't think this is a compelling use case.

    Juanma

Message #67 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#2061: 23.0.60;   Add preference to force load of Elisp files
 when they are newer   than corresponding byte-compiled file
Date: Wed, 28 Jan 2009 01:29:37 -0700

Juanma Barranquero wrote:
> On Tue, Jan 27, 2009 at 16:54, Brent Goodrick <bgoodr <at> gmail.com> wrote:
...
>> Add the following logic to the C `load' function:
>>
>>  Before loading either the .el or .elc file, test for the condition
>>  where the .el file is newer than the .elc file. If it is, then do
>>  the following:
>>
>>    See if the `load-hook-stale-byte-compile-handlers' hook variable
>>    is set to non-nil. When it is non-nil, run the hook variable with
>>    `run-hook-with-args-until-success'. Each function the user has
>>    added to that hook variable would do any logic s/he wishes,
>>    including in my case to popup a minibuffer prompt asking what to
>>    do. When the hook function thus called returns a 'prefer-el-file
>>    symbol, `load' then loads the .el file and ignores the .elc
>>    file. Likewise, when the hook function returns the
>>    'prefer-elc-file symbol, then load the .elc file but give no
>>    warning message and ignore the .el file. When nil is returned from
>>    the `run-hook-with-args-until-success' function, just load the
>>    .elc file and produce the stale file warning message as is done
>>    today (i.e., preserve existing behavior).
> 
> That would work, but it is IMHO too much (interface, not code)
> complexity for little gain. In most cases, having a .elc older than
> its corresponding .el is a bug (or, let's call it, a temporary
> situation), so getting a warning to remind the user about fixing it
> seems much more economical.
> 
> That said, sometimes I would've liked to have a hook that runs when a
> file is loaded; or the ability to defadvice Fload (you can, except
> that Fload is also called from C code, for example for autoloads).

Yes, before-load-hook and after-load-hook would be generally useful
if load-file-name were set to load's FILE argument when they're run.

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #72 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Brent Goodrick <bgoodr <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files 
	when they are newer than corresponding byte-compiled file
Date: Mon, 2 Feb 2009 08:07:02 -0800

I won't pursue this any further.  You all have given me some useful
workarounds that I will explore further.

Thanks
Brent

On 1/27/09, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> On Tue, Jan 27, 2009 at 16:54, Brent Goodrick <bgoodr <at> gmail.com> wrote:
>
>> The problem relates to when and how to notify the user that the stale
>> .elc file is the one being loaded.  During development, I just
>> `eval-buffer' repeatedly on a .el file, always unaware that there is a
>> stale .elc file lying in wait to confuse me the next time I reload the
>> entire Emacs process/session.
>
> If you're going to modify/test the package with eval-buffer, you
> should make sure there's no .elc sitting around.
>
>> At init time, I only get a warning,
>> among a ton of other benign warnings and messages, and that one
>> critical warning is therefore not seen (of course, it is impractical
>> to ask the user to read all of those messages).
>
> As you know, that's trivially fixed:
>
> (add-hook 'emacs-startup-hook
>           (lambda ()
>             (with-current-buffer (get-buffer "*Messages*")
>               (goto-char (point-min))
>               (while (re-search-forward "[Ss]ource file .*? newer" nil t)
>                 (warn "%s" (buffer-substring (line-beginning-position)
>                                              (line-end-position)))))))
>
>
>> Add the following logic to the C `load' function:
>>
>>  Before loading either the .el or .elc file, test for the condition
>>  where the .el file is newer than the .elc file. If it is, then do
>>  the following:
>>
>>    See if the `load-hook-stale-byte-compile-handlers' hook variable
>>    is set to non-nil. When it is non-nil, run the hook variable with
>>    `run-hook-with-args-until-success'. Each function the user has
>>    added to that hook variable would do any logic s/he wishes,
>>    including in my case to popup a minibuffer prompt asking what to
>>    do. When the hook function thus called returns a 'prefer-el-file
>>    symbol, `load' then loads the .el file and ignores the .elc
>>    file. Likewise, when the hook function returns the
>>    'prefer-elc-file symbol, then load the .elc file but give no
>>    warning message and ignore the .el file. When nil is returned from
>>    the `run-hook-with-args-until-success' function, just load the
>>    .elc file and produce the stale file warning message as is done
>>    today (i.e., preserve existing behavior).
>
> That would work, but it is IMHO too much (interface, not code)
> complexity for little gain. In most cases, having a .elc older than
> its corresponding .el is a bug (or, let's call it, a temporary
> situation), so getting a warning to remind the user about fixing it
> seems much more economical.
>
> That said, sometimes I would've liked to have a hook that runs when a
> file is loaded; or the ability to defadvice Fload (you can, except
> that Fload is also called from C code, for example for autoloads).
>
>> I have tried doing that, but found it unworkable in practice, as
>> byte-compiling upon each save ended up chewing up too much time during
>> development (the byte-compile-upon-every-save penalty). Consider that
>> I save frequently. :)
>
> I didn't mean to byte-compile on saving, I meant to byte-compile on
> eval-buffer (or whatever method you use to test your code).
>
>> But that is a hack, so I am now trying to get the root problem
>> addressed in the C code where it exists.
>
> I agree that greater control over the loading process could sometimes
> be useful; but I don't think this is a compelling use case.
>
>     Juanma
>

Message #77 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 2061 <at> debbugs.gnu.org, Brent Goodrick <bgoodr <at> gmail.com>
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file
Date: Mon, 26 Jan 2009 19:49:20 -0500

> Isn't easier just to compile the .el file? If you're developing or
> modifying a package, and want to try it at once, create a macro to
> compile it as soon as you save it...

A common case for me is "bzr pull" or "cvs update" or "tla star-merge"
to bring in new changes.  I don't look at all the Elisp files brought in
so byte-compile-file is not convenient, and byte-compilation often leads
to odd results because the `require's read the old .elc files.


        Stefan

Message #82 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 2061 <at> debbugs.gnu.org, Brent Goodrick <bgoodr <at> gmail.com>
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files 
	when they are newer than corresponding byte-compiled file
Date: Mon, 2 Feb 2009 19:56:44 +0100

On Tue, Jan 27, 2009 at 01:49, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> A common case for me is "bzr pull" or "cvs update" or "tla star-merge"
> to bring in new changes.  I don't look at all the Elisp files brought in
> so byte-compile-file is not convenient, and byte-compilation often leads
> to odd results because the `require's read the old .elc files.

I'm used to do "make cvs-update" just about after every "cvs update".

    Juanma

Message #87 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard M Stallman <rms <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 2061 <at> debbugs.gnu.org
Cc: lekktu <at> gmail.com, 2061 <at> debbugs.gnu.org, bgoodr <at> gmail.com
Subject: Re: bug#2061: 23.0.60;
	Add preference to force load of Elisp files when they are newer
	than corresponding byte-compiled file
Date: Tue, 03 Feb 2009 04:59:21 -0500

    A common case for me is "bzr pull" or "cvs update" or "tla star-merge"
    to bring in new changes.  I don't look at all the Elisp files brought in
    so byte-compile-file is not convenient, and byte-compilation often leads
    to odd results because the `require's read the old .elc files.

Are you saying that in this case you would want to load the .el files
instead?

If so, I wonder if the right solution is to do something special when loading
a file for `require' in compilation.  Perhaps offer to compile them?

Message #92 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: rms <at> gnu.org
Cc: 2061 <at> debbugs.gnu.org, lekktu <at> gmail.com, bgoodr <at> gmail.com
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files when they are newer than corresponding byte-compiled file
Date: Tue, 03 Feb 2009 16:07:32 -0500

> If so, I wonder if the right solution is to do something special when loading
> a file for `require' in compilation.

Indeed, that's what I do in my local branch, where the bytecompiler's
handling of require gives precedence to the .el files over the .elc files.

> Perhaps offer to compile them?

It needs to work in batch mode.  And byte-compiling them can easily fall
into circularities.


        Stefan

Message #97 received at 2061 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 2061 <at> debbugs.gnu.org, Brent Goodrick <bgoodr <at> gmail.com>
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files
Date: Tue, 03 Feb 2009 16:08:46 -0500

>> A common case for me is "bzr pull" or "cvs update" or "tla star-merge"
>> to bring in new changes.  I don't look at all the Elisp files brought in
>> so byte-compile-file is not convenient, and byte-compilation often leads
>> to odd results because the `require's read the old .elc files.

> I'm used to do "make cvs-update" just about after every "cvs update".

I use revisiton control tools for several Elisp packages outside
of Emacs.  I don't want to reinvent the same Makefile rules for each one
of them.


        Stefan

Message #106 received at 2061-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 2061-done <at> debbugs.gnu.org
Subject: Re: bug#2061: 23.0.60; Add preference to force load of Elisp files
Date: Tue, 17 Dec 2013 22:24:10 -0500

Version: 24.4

Added option `load-prefer-newer'.

Message #115 received at 2061 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: 2061 <at> debbugs.gnu.org
Subject: Fwd: Loading .el when newer than .elc
Date: Tue, 11 Feb 2014 12:48:42 +0000

[Message part 1 (text/plain, inline)]

I just got annoyed enough about missing a warning that an .el file is newer
than an .elc file to want to file a bug report, and sure enough found this
issue has already been discussed.

To summarize the discussion so far, the following reasons have been
advanced for not wanting automatically to prefer a newer .el over an older
.elc:

1. One might be working on the .el file, and not want to load it yet.

2. This is a bug, which should be fixed by recompiling the .el.

Several workarounds have been proposed for those who want to use the newest
version of the .el; they all involve recompiling the file (which some
people complained slowed things down too much, and others pointed out could
lead to loops when working on a large project), and all involve taking
action for specific files, e.g. per-project, or per-file, or per-directory.

I think it's worth looking at those objections again in a modern context:

1. We don't work on deployed code any more (or shouldn't!). We use version
control systems, we run tests before deploying. When I fiddle with a file,
I always want my changes to take effect instantly: either I'm working on
code I'm developing, or I'm trying a fix on a deployed file (and am willing
to keep the bits if it breaks!).

2. GNU distributions go to some lengths to ensure that all system-installed
.el files are compiled and up-to-date. el-get does the same for
user-installed packages. There's little else.

Meanwhile, the workarounds require almost as much effort to install and
maintain as simply remembering to byte-compile everything.

Personally, I have wasted hours by thinking I'm loading a new .el when I'm
loading an old .elc, plus going through various recompilation dances when I
do remember. The time that defaulting to .elc has saved me is minimal,
owing to Debian+el-get taking care of recompilation.

Hence, could we have a preference that reverses the behavior, i.e. when the
.el is newer, it is loaded, and a warning emitted? The default behavior
should of course remain the same. It's a simple, uniform, discoverable
solution. I'd happily work up a patch myself. The preference could be used
in .dir-locals.el by users who preferred to switch it on only for, say,
per-user site-lisp directories or project directories.

How about: load-el-when-newer (defaults to nil) ?

--
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #118 received at 2061 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc
Date: Tue, 11 Feb 2014 18:14:31 +0200

> Date: Tue, 11 Feb 2014 12:48:42 +0000
> From: Reuben Thomas <rrt <at> sc3d.org>
> 
> How about: load-el-when-newer (defaults to nil) ?

From etc/NEWS:

  ** New option `load-prefer-newer' affects how the `load' function chooses
  the file to load.  If this is non-nil, then when both .el and .elc
  versions of a file exist, and the caller did not explicitly specify
  which one to load, then the newer file is loaded.  The default, nil,
  means to always load the .elc file.

Message #121 received at 2061 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc
Date: Tue, 11 Feb 2014 16:37:29 +0000

[Message part 1 (text/plain, inline)]

On 11 February 2014 16:14, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Tue, 11 Feb 2014 12:48:42 +0000
> > From: Reuben Thomas <rrt <at> sc3d.org>
> >
> > How about: load-el-when-newer (defaults to nil) ?
>
> From etc/NEWS:
>
>   ** New option `load-prefer-newer' affects how the `load' function chooses
>   the file to load.  If this is non-nil, then when both .el and .elc
>   versions of a file exist, and the caller did not explicitly specify
>   which one to load, then the newer file is loaded.  The default, nil,
>   means to always load the .elc file.
>

Joy! I'm sorry my timing was bad, in that I looked into this after it had
been committed, but before it had been released. Thanks for the
intelligence.

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #126 received at 2061 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc
Date: Tue, 11 Feb 2014 12:03:25 -0500

Reuben Thomas wrote:

> Joy! I'm sorry my timing was bad, in that I looked into this after it had
> been committed, but before it had been released.

That's fine, but why not read the report, especially the close message,
before reopening it?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2061#106

seems clear to me.

Now the OP will wonder why his bug was opened and closed again.

Message #129 received at 2061 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 2061 <at> debbugs.gnu.org
Subject: Re: bug#2061: Fwd: Loading .el when newer than .elc
Date: Tue, 11 Feb 2014 17:15:26 +0000

[Message part 1 (text/plain, inline)]

On 11 February 2014 17:03, Glenn Morris <rgm <at> gnu.org> wrote:

> Reuben Thomas wrote:
>
> > Joy! I'm sorry my timing was bad, in that I looked into this after it had
> > been committed, but before it had been released.
>
> That's fine, but why not read the report, especially the close message,
> before reopening it?
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2061#106
>
> seems clear to me.
>

You're right, it is. However, I read the bug report on the mailing list
archive, and didn't find the close message there. The moral is to use the
debbugs interface for completeness.

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.