From: Stephen Berman <Stephen.Berman@gmx.net>
Subject: Re: erroneous byte-compilation during build process?
Date: Tue, 02 May 2006 23:56:40 +0200 [thread overview]
Message-ID: <874q08oztz.fsf@escher.local.home> (raw)
In-Reply-To: 34798.128.165.123.132.1146599207.squirrel@webmail.lanl.gov
On Tue, 2 May 2006 12:46:47 -0700 (PDT) "Stuart D. Herring"
<herring@lanl.gov> wrote:
>> The two recentf.elc files -- the one made by the build process and
>> the one I byte-compiled from source -- differ in almost every line,
>> as shown by diff -a, but I don't know what the differences mean: as
>> far as I can tell, they only differ in cons cells like this:
>>
>> 19c19
>> < (defvar recentf-list nil (#$ . 677))
>> ---
>> > (defvar recentf-list nil (#$ . 671))
>
> If these are the only changes, they're entirely irrelevant; the numbers
> just indicate the places in the file where the documentation can be found.
> The difference is probably a difference in the length of the file name
> given in the comment block at the top. Check for other differences, or
> make the file/path names the same length for testing.
Thanks for the pointer. Now the diff -a output is much smaller, and
it was easy to spot the differences; in fact, the very first diff of
byte-compiled functions is the function where the error arises:
2c2
< ;;; Compiled by steve@escher.local.home on Sun Apr 16 17:30:57 2006
---
> ;;; Compiled by steve@escher.local.home on Tue May 2 23:06:58 2006
426c426
< (defalias 'recentf-open-files #[(&optional files buffer-name) "\b\204\f\0 \204\f\0\306\307!\210r\310\n\206\x16\0\311\312\v\"!q\210\313\314 \x1c\x1d\315\316\f@\"\210\315\316\fA\"\210\317 \210*\320 \210\321\322\x0e.\203<\0\323\202=\0\324\325\326$\210\327\211\x1e/\x0e\x1a\205N\0\x0e\x1a\330H\230\204b\0\331\332!\210\333\334\335\"\211\x16\x1a\330\x0e/I\210)\336\337\340\341\342\343\344\345\b\206p\0 !BBBBB\"\210\337\346\347\350\351$\210\352\353!\210\354 \210\355p!)\207" [files recentf-list buffer-name recentf-menu-title ol inhibit-read-only error "There is no recent file to open" get-buffer-create format "*%s*" t overlay-lists mapc delete-overlay erase-buffer recentf-dialog-mode widget-insert "Click on a file" ", or type the corresponding digit key," "" " to open it.\n" "Click on Cancel or type `q' to cancel.\n" "folder" 0 make-local-variable tree-widget--theme make-vector 4 nil apply widget-create group :indent 2 :format "\n%v\n" recentf-open-files-items push-button :notify recentf-cancel-dialog "Cancel" recentf-dialog-goto-first link widget-setup switch-to-buffer recentf-show-file-shortcuts-flag name] 10 (#$ . 43202) nil])
---
> (defalias 'recentf-open-files #[(&optional files buffer-name) "\b\204\f\0 \204\f\0\306\307!\210r\310\n\206\x16\0\311\312\v\"!q\210\313\314 \x1c\x1d\315\316\f@\"\210\315\316\fA\"\210\317 \210*\320 \210\321\322\x0e)\203<\0\323\202=\0\324\325\326$\210\327\330!\210\331\332\333\334\335\336\337\340\b\206R\0 !BBBBB\"\210\332\341\342\343\344$\210\345\346!\210\347 \210\350p!)\207" [files recentf-list buffer-name recentf-menu-title ol inhibit-read-only error "There is no recent file to open" get-buffer-create format "*%s*" t overlay-lists mapc delete-overlay erase-buffer recentf-dialog-mode widget-insert "Click on a file" ", or type the corresponding digit key," "" " to open it.\n" "Click on Cancel or type `q' to cancel.\n" tree-widget-set-theme "folder" apply widget-create group :indent 2 :format "\n%v\n" recentf-open-files-items push-button :notify recentf-cancel-dialog "Cancel" recentf-dialog-goto-first link widget-setup switch-to-buffer recentf-show-file-shortcuts-flag] 9 (#$ . 43202) nil])
These differ only in the last few hundred characters, specifically
here:
< "folder" 0 make-local-variable tree-widget--theme make-vector 4 nil
---
> tree-widget-set-theme "folder"
and here:
< recentf-show-file-shortcuts-flag name] 10
---
> recentf-show-file-shortcuts-flag] 9
(Subsequent differences in the diff -a output are only in the
documentation cons cells, evidently due to the differing lengths of
the above pieces of byte compiled code.) In fact, the first
difference shows the reason for error I was getting (a missing call to
tree-widget-set-theme). So this seems to prove that the original
byte-compilation of recentf.el, produced by the build process, is
erroneous. The question remains, how did this happen? Why did the
Emacs build process yield an erroneous byte compilation, while my byte
compilation of the same source yielded a correct one?
Steve Berman
next prev parent reply other threads:[~2006-05-02 21:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-02 19:29 erroneous byte-compilation during build process? Stephen Berman
2006-05-02 19:46 ` Stuart D. Herring
2006-05-02 21:56 ` Stephen Berman [this message]
2006-12-27 3:00 ` Richard Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874q08oztz.fsf@escher.local.home \
--to=stephen.berman@gmx.net \
/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 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.