From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: problems with vc-arch.el during byte-compilation Date: Thu, 03 Jun 2004 06:12:57 +0900 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87brk1ackm.fsf@tc-1-100.kawasaki.gol.ne.jp> Reply-To: Miles Bader NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1086210834 8733 80.91.224.253 (2 Jun 2004 21:13:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Jun 2004 21:13:54 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jun 02 23:13:43 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BVd3O-0003C2-00 for ; Wed, 02 Jun 2004 23:13:42 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BVd3O-0002Yz-00 for ; Wed, 02 Jun 2004 23:13:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVd3h-0003Gy-6b for emacs-devel@quimby.gnus.org; Wed, 02 Jun 2004 17:14:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BVd3Y-0003FH-Dj for emacs-devel@gnu.org; Wed, 02 Jun 2004 17:13:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BVd3V-0003E8-2c for emacs-devel@gnu.org; Wed, 02 Jun 2004 17:13:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BVd3U-0003E5-Ve for emacs-devel@gnu.org; Wed, 02 Jun 2004 17:13:49 -0400 Original-Received: from [203.216.5.132] (helo=smtp02.fields.gol.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BVd2i-0004WY-OU; Wed, 02 Jun 2004 17:13:01 -0400 Original-Received: from filter01.fields.gol.com ([203.216.5.148] helo=localhost) by smtp02.fields.gol.com with esmtp (Magnetic Fields) id 1BVd2h-0007gl-TM; Thu, 03 Jun 2004 06:12:59 +0900 Original-Received: from yokohama2-61-203-152-140.ap.0038.net ([61.203.152.140] helo=tc-1-100.kawasaki.gol.ne.jp) by smtp02.fields.gol.com with asmtp (Magnetic Fields) id 1BVd2g-0007gi-VT; Thu, 03 Jun 2004 06:12:59 +0900 Original-Received: by tc-1-100.kawasaki.gol.ne.jp (Postfix, from userid 1000) id 980D92FB3; Thu, 3 Jun 2004 06:12:57 +0900 (JST) Original-To: emacs-devel@gnu.org System-Type: i686-pc-linux-gnu Original-Lines: 107 X-Virus-Scanned: by AMaViS GOL X-Abuse-Complaints: abuse@gol.com X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24428 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24428 If you remember, some users were having problems where the initial byte-compilation of the .el files was failing in a checkout made using tla (arch). There seemed to be two problems: (1) vc-arch.el[c] was somehow getting loaded during byte-compilation (2) vc-arch would sometimes cause a crash, I suppose trying to figure out info about where a file was. This only seemed to happen in certain cases, e.g., one user reported that it depended on the length of the source directory name. I used gdb to figure out why vc-arch was getting loaded, and it looks [see appended gdb session output] like it's because `lisp/eshell/esh-module.el' is calling `find-file-noselect' while being compiled (!), and this causes the vc machinery to run. I guess that the `fault' lies with eshell, and that it should do something to suppress the various file-visiting hooks when it does this odd thing; does anyone think that something more general should be changed (e.g., changing file-visiting behavior when using the -batch option)? I still haven't figured out why vc-arch is failing though. BTW, I notice that ~/.abbrev_defs is getting loaded also -- surely this should be suppressed when the -batch or -q options are specified? Thanks, -Miles GDB session: (gdb) info breakpoint 4 4 breakpoint keep y 0x0819ca41 in Fload at /usr/local/src/emacs/src/lread.c:675 (gdb) command 4 print file xstring end (gdb) run .... Breakpoint 4, Fload (file=136666451, noerror=138506257, nomessage=138506257, nosuffix=-1, must_suffix=138506257) at /usr/local/src/emacs/src/lread.c:675 675 int count = SPECPDL_INDEX (); $461 = 136666451 $462 = (struct Lisp_String *) 0x8255d50 "vc-arch" (gdb) xback "load" "progn" "if" "let" "vc-arch-registered" "apply" "vc-call-backend" 0x82d005c PVEC_COMPILED "mapcar" "byte-code" "vc-registered" "vc-backend" "vc-find-file-hook" "run-hooks" "after-find-file" "find-file-noselect-1" "find-file-noselect" "set-buffer" "save-current-buffer" "with-current-buffer" "eshell-load-defgroups" "let*" "progn" "if" "when" "progn" "eval-when-compile" "eval-buffer" "load-with-code-conversion" "require" "byte-code" "require" "eval-buffer" "load-with-code-conversion" "require" "byte-code" "eval" "byte-compile-eval" "list" 0x85cab15 Lisp type 5 "macroexpand" "byte-compile-file-form" 0x862556c PVEC_COMPILED "funcall" "byte-compile-from-buffer" "byte-compile-file" "batch-byte-compile-file" "batch-byte-compile" "command-line-1" "command-line" "normal-top-level" -- `The suburb is an obsolete and contradictory form of human settlement'