From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#40688: 28.0.50; Advice And ByteCompile Behavior Change Date: Sun, 03 May 2020 23:03:02 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="63657"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 40688@debbugs.gnu.org To: "T.V Raman" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 04 05:04:10 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jVROs-000GSb-4s for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 May 2020 05:04:10 +0200 Original-Received: from localhost ([::1]:37580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVROr-0000q0-13 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 03 May 2020 23:04:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVROk-0000pp-RT for bug-gnu-emacs@gnu.org; Sun, 03 May 2020 23:04:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47160) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVROk-0006sN-Gy for bug-gnu-emacs@gnu.org; Sun, 03 May 2020 23:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jVROk-0002Hg-By for bug-gnu-emacs@gnu.org; Sun, 03 May 2020 23:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 May 2020 03:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40688 X-GNU-PR-Package: emacs Original-Received: via spool by 40688-submit@debbugs.gnu.org id=B40688.15885613938717 (code B ref 40688); Mon, 04 May 2020 03:04:02 +0000 Original-Received: (at 40688) by debbugs.gnu.org; 4 May 2020 03:03:13 +0000 Original-Received: from localhost ([127.0.0.1]:58704 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVRNx-0002GX-9B for submit@debbugs.gnu.org; Sun, 03 May 2020 23:03:13 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVRNv-0002GJ-PD for 40688@debbugs.gnu.org; Sun, 03 May 2020 23:03:12 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 174394508C2; Sun, 3 May 2020 23:03:06 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5F5A04508AD; Sun, 3 May 2020 23:03:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1588561384; bh=8xkAzmuWOH9fsPjtyCLZhfUc7+HyCSiyhAGZqzFYJOc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pG6Bo1GkUcDOhVH+6Ur60K3kxGVvPdU4i0B4Xa1Yv5tW41CLi5xGTTpQW6NSThctd SNn2WVO3so2+WMpD3U/SPKdSgpp/qFCoNftXOo3cRN6f+mqmvzI2Jy/s3zy1yVceTy DjjUd6NDGVmYjtELZRS1FDQHgAcmzF57YheHJbnU+wvnh/ctYs9cKZp/bz0aU6bIjK aJwqmtsKBSK+ZbxJog5Uf6vh+3B+guh3fYAEt60VBQU9EsgTsgOPWddnU5+8MC7Izf Ke1uIDS3bU2wgTE89Vdrr2xDkpl2EHTKy8pNujPoZ0M4Zwr2J3B23FRPn1YbAtlsUV x/z33p8Wgy9/Q== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 14D1612078C; Sun, 3 May 2020 23:03:04 -0400 (EDT) In-Reply-To: (T. V. Raman's message of "Sun, 03 May 2020 17:26:19 -0700") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179654 Archived-At: > .el files are not generated by Makefile rules. > > Again, conjecture: perhaps I'm hitting this because: > > 1. Emacspeak uses advice far more than emacs does? Could be. Might be linked to the use `defadvice` (which has a funny/broken behavior w.r.t macro expansion), but I can't think of a good scenario where that would play a role. Digging into the `symbol-function` value (and/or Edebugging) is the only way I can imagine we will be able to track it down. Stefan > >> I didn't mean the -j bit in building emacs, conjecture is that emacspeak >>> breaks if -j is used. >> >> I was pointing out that Emacs's own use of `-j` to build the `lisp` >> subdir indicates that it's OK to have missing dependencies on the `.elc` >> files (and hence sometimes the .el file is loaded and sometimes the >> `.elc`, depending on the compilation order; or even the `.el` file is >> loaded while the corresponding `.elc` file is being generated). >> >> Of course, if your `.el` files are generated by makefile rules that's >> a completely different question. >> >> >> Stefan >> >> >>>>> 4. As mentioned in this bug report at the outset I started seeing >>>>> strange behavior (that also appeared non-deterministic across builds) >>>>> where it felt like some of the advice was not defined (incidentally when >>>>> the bug bit yesterday, C-h o still indicated the functions were >>>>> adviced). >>>> >>>> If it bites again, could you try and post (to the extent possible, >>>> obviously) the function name, the output of (symbol-function >>>> ) along with as much as possible a concrete and detailed >>>> description of an actual call's behavior on that function where we see >>>> that the advice wasn't called? >>>> >>>>> So wild conjecture: Given make -j (the Makefile does impose some >>>>> dependency order but not all) >>>>> is it possible that things go south if something that is needed during >>>>> the build of module-a.el gets byte-compiled *after* module-a.el? >>>> >>>> In theory, no. I (and many other people) build Emacs's `lisp` subdir in >>>> parallel, and there are basically no dependencies in the makefile to try >>>> and make sure files get compiled before they're used. We've had some >>>> corner case problems with it, but all the ones I know have been fixed. >>>> >>>> >>>> Stefan >>>> >>>> >>>>> Stefan Monnier writes: >>>>> >>>>>> IIUC after recompiling everything the problem disappeared. If you >>>>>> can't reproduce it any more, than I guess we can only close this >>>>>> bug. >>>>>> >>>>>>> As an example, Module emacspeak-advice.el advices vc-next-action --- and >>>>>>> this module (emacspeak-advice) is loaded early on during emacspeak >>>>>>> initialization. >>>>>>> >>>>>>> When I later call vc-next-action during an emacs session and the >>>>>>> autoload pulls in vc.el, the advice definition loaded earlier is not >>>>>>> activated -- I have to explicitly reload module emacspeak-advice. >>>>>> >>>>>> In case you can still reproduce the problem, please show us what >>>>>> `C-h o vc-next-action` tells you when you think it should have the >>>>>> advice applied yet its behavior doesn't seem to be affected. >>>>>> >>>>>> >>>>>> Stefan >>>>>> >>>> >>