From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Newsgroups: gmane.emacs.bugs Subject: bug#41242: Port feature/native-comp to Windows Date: Sat, 16 May 2020 13:12:20 -0300 Message-ID: References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000074214705a5c632c0" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="102028"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41242@debbugs.gnu.org, Andrea Corallo To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 16 18:13: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 1jZzQz-000QQi-ME for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 18:13:09 +0200 Original-Received: from localhost ([::1]:51058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZzQy-0006Nd-Ff for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 12:13:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZzQs-0006Kj-CU for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 12:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58241) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZzQs-0000dA-20 for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 12:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZzQr-0000g2-T7 for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 12:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 May 2020 16:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41242 X-GNU-PR-Package: emacs Original-Received: via spool by 41242-submit@debbugs.gnu.org id=B41242.15896455602574 (code B ref 41242); Sat, 16 May 2020 16:13:01 +0000 Original-Received: (at 41242) by debbugs.gnu.org; 16 May 2020 16:12:40 +0000 Original-Received: from localhost ([127.0.0.1]:41554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzQV-0000fS-KH for submit@debbugs.gnu.org; Sat, 16 May 2020 12:12:40 -0400 Original-Received: from mail-oo1-f48.google.com ([209.85.161.48]:44886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZzQT-0000fF-T3 for 41242@debbugs.gnu.org; Sat, 16 May 2020 12:12:38 -0400 Original-Received: by mail-oo1-f48.google.com with SMTP id p67so1125518ooa.11 for <41242@debbugs.gnu.org>; Sat, 16 May 2020 09:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ixCBxUESAjUOcbwKZl+wX2S7R6xrzFNHIVAyFSlZIAI=; b=ePJqmBEkpoWoNZgE0mPZKu54ks2Xyy0VIlbWZUnJDZRjKhlmGhd/NkYtMWznsTqZRG Jo5SnSZ0Cc9yiePdSjZkp0botN+/7Zu3a4OBx676h7UCsy+4+0V5qinrgQSQNlmPr/lM y+HYX5T+J+4mIIGWQXBOwEgx2U+czY6TcDR/9mhd2izNfpdlgbs3o16ae9GC6qeY5skX BKLKuQVGjLTcGo0oZ7x9yuP/RTGa1MZA0lUkvfcsM+HnTBvuYZ/H/Y8JL8EThMaa6GAD J55wtpeOpdjhneaWeRDtWdyz4ng8A/OKzI0T5SEFWUiZGZd4OqdFCLFBSwMvDiaoW5Z9 2umQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ixCBxUESAjUOcbwKZl+wX2S7R6xrzFNHIVAyFSlZIAI=; b=fn+emfJLXx7cZ9JnxuyX62CKkovjKOs3dOL7Rv+x6X2i6x/19/IE/nuCWdU/I4/sRb ogH46cJs4EPRbUBRsGki1/HqEADW+wcPljQACtk10nqEVbej9mafqmpqPlBwyRjSV8Gn A4ATcjIL59PfuzL3Qwvz4R1WDvnd94QLDmsu1GvIjcDpgouVvCZIESyloj0YAHDuNT+R P8X4e6BghBnuzjLATMVvPpIeh5jqBEjHui+vzhXxnwLlcBmCunLVBA69DIMfA98RwLNg BmxHMB2l8mrLrDpzjEbSLcB+psh78o6cALxmLXx/oW4DUAAq5ULg8eWMZUWBm0MeysPl kuBQ== X-Gm-Message-State: AOAM532UPDZ/uexgbi+XJZpXwUSsa5wncVmkQycorlhDnxptXSuR7HUY YwTVHKJzdc6FNqBACv8jeYJlAHkYpLu/GDKWWc/DXLfRHxbKkA== X-Google-Smtp-Source: ABdhPJwoMo9WLB2izJuRoEJNqJ3zV16x656SjhMShnMaqj6uSZpleJ1qYrlglsv9Etx94IaUl6jmZiBYVDlc6uRjcQo= X-Received: by 2002:a4a:b389:: with SMTP id p9mr6808189ooo.84.1589645552131; Sat, 16 May 2020 09:12:32 -0700 (PDT) In-Reply-To: <837dxcv1po.fsf@gnu.org> 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:180393 Archived-At: --00000000000074214705a5c632c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I'm not sure I understand why we are talking only about package.el. > Wouldn't the same problem happen if the user recompiles a .el file for > which a .eln file already exists and is loaded into the session? True, right now the .eln would not be removed. Not even in Posix. Therefore it will continue to be loaded unless `load-prefer-newer` is true. > And > similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN" Help me understand. Are you referring to the case where a developer changes an .el file for which an .eln file (now outdated) already exists? I think fixing the case above will fix this one. El s=C3=A1b., 16 may. 2020 a las 3:22, Eli Zaretskii () escri= bi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Fri, 15 May 2020 16:44:04 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > To summarize: > > > > The best idea seems to be to rename the .eln file when removing the > package or > > recompiling. We need to reach a consensus on where to put the old .eln > file, > > though. > > > > There are two options: > > > > - Put it in the same folder as the original .eln file. This means that > > `package-delete` will not be able to delete the directory. > Additionally, it > > will be tricky to handle left over files from an instance of Emacs th= at > > crashes. > > > > - Another option is to move them to `package-user-dir`. This option > means that > > `package-delete` will be able to delete the directory. > > > > What option do you prefer? > > I'm not sure I understand why we are talking only about package.el. > Wouldn't the same problem happen if the user recompiles a .el file for > which a .eln file already exists and is loaded into the session? And > similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN"? > > I think the solution should handle all of these use cases, not just > that of package.el upgrading a package. Do you agree? > > > - `package-delete` iterates over the .eln files in the package > directory. It > > tries to delete it, if it fails it is moved to somewhere (see point > above). > > > > - When Emacs GCs a native compilation unit it should check if it has be= en > > renamed (need to check if GetModuleFileNameA is fit for this). If it > has, it > > tries to delete it. If it fails, then some other Emacs instance must > be using > > it. > > > > - The last step before calling exit() should FreeLibrary() all remainin= g > .eln > > files and run the equivalent of `rm $package_user_dir/*.eln.old`. > > Sounds OK to me, I don't think we came up with anything better during > the discussion till now. > --00000000000074214705a5c632c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I'm not sure I understand why we are talking only= about package.el.
> Wouldn't the same problem happen if the user= recompiles a .el file for
> which a .eln file already exists and is loaded into the session?=C2=A0=

True, right now the .eln would not be remove= d. Not even in Posix.
Therefore it will continue to be loaded unl= ess `load-prefer-newer` is true.

>=20 And
> similarly when Emacs is being built and all the *.el files are being > compiled or recompiled, sometimes by several Emacs processes running > in parallel via "make -jN"

Help me = understand. Are you referring to the case where a developer changes
an .el file for which an .eln file (now outdated) already exists? I thin= k fixing the
case above will fix this one.


El s=C3=A1b., 16 may. 2020 a las 3:22, Eli Zaretskii (<eliz@gnu.org>) escribi=C3=B3:
> From: Nicolas B=C3=A9rtolo <= nicolasbertol= o@gmail.com>
> Date: Fri, 15 May 2020 16:44:04 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> To summarize:
>
> The best idea seems to be to rename the .eln file when removing the pa= ckage or
> recompiling. We need to reach a consensus on where to put the old .eln= file,
> though.
>
> There are two options:
>
> - Put it in the same folder as the original .eln file. This means that=
>=C2=A0 =C2=A0`package-delete` will not be able to delete the directory.= Additionally, it
>=C2=A0 =C2=A0will be tricky to handle left over files from an instance = of Emacs that
>=C2=A0 =C2=A0crashes.
>
> - Another option is to move them to `package-user-dir`. This option me= ans that
>=C2=A0 =C2=A0`package-delete` will be able to delete the directory.
>
> What option do you prefer?

I'm not sure I understand why we are talking only about package.el.
Wouldn't the same problem happen if the user recompiles a .el file for<= br> which a .eln file already exists and is loaded into the session?=C2=A0 And<= br> similarly when Emacs is being built and all the *.el files are being
compiled or recompiled, sometimes by several Emacs processes running
in parallel via "make -jN"?

I think the solution should handle all of these use cases, not just
that of package.el upgrading a package.=C2=A0 Do you agree?

> - `package-delete` iterates over the .eln files in the package directo= ry. It
>=C2=A0 =C2=A0tries to delete it, if it fails it is moved to somewhere (= see point above).
>
> - When Emacs GCs a native compilation unit it should check if it has b= een
>=C2=A0 =C2=A0renamed (need to check if GetModuleFileNameA is fit for th= is). If it has, it
>=C2=A0 =C2=A0tries to delete it. If it fails, then some other Emacs ins= tance must be using
>=C2=A0 =C2=A0it.
>
> - The last step before calling exit() should FreeLibrary() all remaini= ng .eln
>=C2=A0 =C2=A0files and run the equivalent of `rm $package_user_dir/*.el= n.old`.

Sounds OK to me, I don't think we came up with anything better during the discussion till now.
--00000000000074214705a5c632c0--