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 14:09:54 -0300 Message-ID: References: <834ksi60zn.fsf@gnu.org> <83k11e4a0s.fsf@gnu.org> <83blmp4tob.fsf@gnu.org> <83o8qp1hfr.fsf@gnu.org> <837dxcv1po.fsf@gnu.org> <83imgvdf94.fsf@gnu.org> <83eerjde6k.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000055792005a5c700fb" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="79917"; 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 19:11:13 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 1ja0L9-000Kga-Rm for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 19:11:11 +0200 Original-Received: from localhost ([::1]:49480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ja0L8-00042H-R0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 May 2020 13:11:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja0L0-00041j-Ix for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 13:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58331) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ja0L0-0007GV-9m for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 13:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ja0L0-0002ZW-3H for bug-gnu-emacs@gnu.org; Sat, 16 May 2020 13:11:02 -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 17:11:02 +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.15896490139818 (code B ref 41242); Sat, 16 May 2020 17:11:02 +0000 Original-Received: (at 41242) by debbugs.gnu.org; 16 May 2020 17:10:13 +0000 Original-Received: from localhost ([127.0.0.1]:41642 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja0KC-0002YD-Te for submit@debbugs.gnu.org; Sat, 16 May 2020 13:10:13 -0400 Original-Received: from mail-ot1-f53.google.com ([209.85.210.53]:44316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ja0KB-0002Xz-R7 for 41242@debbugs.gnu.org; Sat, 16 May 2020 13:10:12 -0400 Original-Received: by mail-ot1-f53.google.com with SMTP id f18so442905otq.11 for <41242@debbugs.gnu.org>; Sat, 16 May 2020 10:10:11 -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=yO0SIUU0YKTzjl1zlCQWsySzA0Gh6hvn9zkDNI+h718=; b=gUZ8sGarEbMtAuoH9S36R8/n1GnW++tk+rRKHtfe/vBMDrdfWtzpQMmB1WuFfIgRsn 0K3j52j9RogLgBX04QsHylYkDqHh3XOe5QynuxmaxFiiXloNImbVDpsLmg+YMSG46IE0 QKF8HSyXbhSKu8pi4KMFoTuiBKI1eETfXMoj6ha8AU3rVHm02MIV5MNvvRN+hzhV+jTY y0rXfCegtE9KQiSJoz554E8p5TphvDwAtd8P/pgoKT/bEDQTHGyt+9UgHrOe7+gD1wrI 5WcMA+3+8XrSx3m8I50RopAbaYU87Pdz4zUtujH8lC/2DiioIIS5H992mMYWCXwAPwJa X7hQ== 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=yO0SIUU0YKTzjl1zlCQWsySzA0Gh6hvn9zkDNI+h718=; b=rJ3Pt9TVVv1RWMD7BKR3HGoMAXXmKwObcwvz5rRVdIj2Js9B968KoARaAd/I1p4rnt TB1rpIRAI8HCWgfsaT1wmLtqY8Kt9jT+ZxhmfRdr/zayUSE80HLUTUwq8GpG8/jwxI/T SWM4OVuScwkEYUkYTEcJ1XFjrzH9IdRuwAGv5DVGRlVDtbqinc5ifxOkmb0FvKLOecfy PkZgSRePczq6OEeflUtrMUQh1UGqD69vtx4CTuB80vJrUObzK8bT17sL+FZacuhUtTo3 /A6EL6nsawcuJ744NbViTgvNW4zQ88AzWACLz/SvtrfGK3cahdpXeULapffm7er6lk8u XY/Q== X-Gm-Message-State: AOAM530F70AQWJRXG9bMA0HJQ5DgWUDk+fdW6RBlGE/MwtNvU4vEzxLi 62+sxYp6xwn+7c6sPMBz0ewuz7dGcVcGwV9l3RU= X-Google-Smtp-Source: ABdhPJyYLvM08QsAysalUIWcKYd2jLv7doYKbAipHcSWyna6xL1aZxxGYiOuOBYlsSuqIzxvSHe1Eog00iGc7Wunjgc= X-Received: by 2002:a9d:3988:: with SMTP id y8mr6102802otb.352.1589649006228; Sat, 16 May 2020 10:10:06 -0700 (PDT) In-Reply-To: <83eerjde6k.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:180403 Archived-At: --00000000000055792005a5c700fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I'm not sure I understand what check did you have in mind. I misunderstood your first message. I thought you were talking about deleting the .eln file when it no longer is up to date after the .el file changes. If we want that we will have to add it to `auto-compile.el`. El s=C3=A1b., 16 may. 2020 a las 13:42, Eli Zaretskii () escr= ibi=C3=B3: > > From: Nicolas B=C3=A9rtolo > > Date: Sat, 16 May 2020 13:31:41 -0300 > > Cc: Andrea Corallo , 41242@debbugs.gnu.org > > > > > No, on Posix systems we can delete the file, and it will be actually > > > deleted when its last handle is closed. I believe this works with > > > shared libraries as well. > > > > Do we actually do it? I don't think so. I don't even know where exactly > > that check should be. Maybe `eval-buffer`? > > I'm not sure I understand what check did you have in mind. > > > > It's the same problem, yes. Just a slightly different use case, whic= h > > > could therefore have different probabilities for some aspects. For > > > example, the probability of the same .el file being recompiled from > > > two separate sessions is relatively small, except when you consider > > > the "make -jN" use case. > > > > The probability of two Emacs recompiling the same file in the "make -jN= " > case is > > 0. > > Sorry, I meant the probability of one session compiling a file while > another uses it. > > > The case of two Emacs sessions recompiling the same file at the same > time is > > actually a problem. > > > > We could implement the following algorithm: > > > > - Have libgccjit write the .eln to a temporary name in the destination > folder. > > > > - While "foo.eln" exists: > > - Rename it to "foo.eln.oldN". > > - Move the new .eln file to "foo.eln" > > Something like that, yes. > --00000000000055792005a5c700fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> I'm not sure I understand what check did you have= in mind.

I misunderstood your first message. I thought you were tal= king about deleting
the .eln file when it no longer is up to date after = the .el file changes.

If we want that we will have to add it to `aut= o-compile.el`.

El s=C3=A1b., 16 may. 2020 a las 13:42, Eli Zaretskii (&l= t;eliz@gnu.org>) escribi=C3=B3:
<= /div>
> From: Nicolas B= =C3=A9rtolo <nicolasbertolo@gmail.com>
> Date: Sat, 16 May 2020 13:31:41 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@debbugs.gnu.org
>
> > No, on Posix systems we can delete the file, and it will be actua= lly
> > deleted when its last handle is closed.=C2=A0 I believe this work= s with
> > shared libraries as well.
>
> Do we actually do it? I don't think so. I don't even know wher= e exactly
> that check should be. Maybe `eval-buffer`?

I'm not sure I understand what check did you have in mind.

> > It's the same problem, yes.=C2=A0 Just a slightly different u= se case, which
> > could therefore have different probabilities for some aspects.=C2= =A0 For
> > example, the probability of the same .el file being recompiled fr= om
> > two separate sessions is relatively small, except when you consid= er
> > the "make -jN" use case.
>
> The probability of two Emacs recompiling the same file in the "ma= ke -jN" case is
> 0.

Sorry, I meant the probability of one session compiling a file while
another uses it.

> The case of two Emacs sessions recompiling the same file at the same t= ime is
> actually a problem.
>
> We could implement the following algorithm:
>
> - Have libgccjit write the .eln to a temporary name in the destination= folder.
>
> - While "foo.eln" exists:
>=C2=A0 =C2=A0- Rename it to "foo.eln.oldN".
>=C2=A0 =C2=A0- Move the new .eln file to "foo.eln"

Something like that, yes.
--00000000000055792005a5c700fb--