From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: Compiled code in Emacs-26 will fail in Emacs-25 if use pcase [was: Add new bytecode op `switch' for implementing branch tables.] Date: Sat, 2 Jul 2022 16:31:35 -0400 Message-ID: References: <1b07c68a-873e-83c8-246d-423bc83a3881@gmail.com> <83y3xg4ldw.fsf@gnu.org> Reply-To: rswgnu@gmail.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003c4a0305e2d865a9" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26046"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Kaushal Modi , cpitclaudel@gmail.com, Emacs developers , Eli Zaretskii , Vibhav Pant , Tino Calancha To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 02 22:32:52 2022 Return-path: Envelope-to: ged-emacs-devel@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 1o7jnQ-0006fb-Ii for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jul 2022 22:32:52 +0200 Original-Received: from localhost ([::1]:58134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7jnP-0004o9-39 for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jul 2022 16:32:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44966) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7jmg-00045Y-Qa for emacs-devel@gnu.org; Sat, 02 Jul 2022 16:32:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53906) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7jmg-0007Ng-Dy for emacs-devel@gnu.org; Sat, 02 Jul 2022 16:32:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=To:Subject:Date:From:In-Reply-To:References: MIME-Version; bh=1CZYX+FwiBOCzQG5vWgtM28q3y5pVonOZl0yhYwATSg=; b=XAhmfPTj7nNV gPcdcwhyjjVaRk1dg083ou5A9TA/dsisZMLtQLZuXaZVRxeC7Oc18bqaA1FpZYNO1lUoZYW6XX4OB hiF3fKNN7gaCJ2MMvoTQevtwLrRzhozStFHD50IKLRpXrTJ3pW2roB2cEmq36S1zCf1flPbvilzM6 mAfbf+AWd50ehu7Hv/7anDaAunuAkjYSzId6aJJxW1ais6Fayr6p7q0h4092UWu7FUheX1J4cUsq2 n8NutOSQXzROZBsUyRd7DpnlhBCPr8yJZl4hJm4zORxSXK18a9DL0pUyoHPJS87BBkWTgjOL/uAwn lf/8+4PunmwVc/Kfuwc1Bg==; Original-Received: from mail-yw1-f176.google.com ([209.85.128.176]:45786) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o7jmd-0006Jg-BC; Sat, 02 Jul 2022 16:32:03 -0400 Original-Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-31bf3656517so51911277b3.12; Sat, 02 Jul 2022 13:32:03 -0700 (PDT) X-Gm-Message-State: AJIora86bo8EO3hSk4+upouwteSj3u93gihD8uQt8iJ2ewjiNRoX5jsB OdZ8EHUX0anNZGZusxbZ8y/p9yY4BoE19TgoM90= X-Google-Smtp-Source: AGRyM1v+oV9hIMHbb2zT3yvQ4ZcDGl39tODFTzCqpD/IH2BTD0jwENBV//5fqkPp2ma5wla3LXLEvqJcQZk/A11w9Ok= X-Received: by 2002:a0d:c547:0:b0:31b:d6fa:c05c with SMTP id h68-20020a0dc547000000b0031bd6fac05cmr24942673ywd.105.1656793922815; Sat, 02 Jul 2022 13:32:02 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291802 Archived-At: --0000000000003c4a0305e2d865a9 Content-Type: text/plain; charset="UTF-8" Hi Stefan: I'm with you on your thoughts about removing the need for users to often have to deal with byte-code or native-code compilation differences when running different major versions of Emacs. But it is now 2022 and the situation seems to be much worse than it was five years ago. Say you use Emacs 27, 28 and 29, some with native compilation and some not. But you want to keep the same set of packages in use across all these installations. You can set your user package directory so you get different package installs per Emacs version but we don't have a way to synchronize the set so that any missing or removed ones are updated as you move from version to version. I just wanted to start some conversation on this and get people thinking about how to make this easier on users of multiple Emacs versions. It is also an issue for package developers who want to test their package compatibility across major versions. On Thu, Feb 23, 2017 at 10:11 AM Stefan Monnier wrote: > > I have this in my emacs config for a while now. > > It works pretty well. It also allows you to use an older emacs version > > without have to mess up the compiled elpa dir of the current version. The > > only side-effect is that when switching major versions the package > > updates/installs will happen independently. > > > > (setq package-user-dir (format "%selpa_%s/" > > user-emacs-directory emacs-major-version)) > > If it works for you, that's great. Personally I'd find it annoying to > have a different set of installed packages per Emacs version. > > I hope Emacs can slowly move toward a model where Elisp is byte-compiled > automatically and kept in a version-specific place (call it a cache) so > users don't have to know about bytecode compatibility issues. > > > Stefan > > --0000000000003c4a0305e2d865a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stefan:

I'm with you on your thoughts about remo= ving the need for users to often have to deal with byte-code or native-code= compilation differences when running different major versions of Emacs.=C2= =A0 But it is now 2022 and the situation seems to be much worse than it was= five years ago.=C2=A0 Say you use Emacs 27, 28 and 29, some with native co= mpilation and some not.=C2=A0 But you want to keep the same set of packages= in use across all these installations.=C2=A0 You can set your user package= directory so you get different package installs per Emacs version but we d= on't have a way to synchronize the set so that any missing or removed o= nes are updated as you move from version=C2=A0to version.

I just w= anted to start some conversation on this and get people thinking about how = to make this easier on users of multiple Emacs versions.=C2=A0 It is also a= n issue for package developers who want to test their package compatibility= across major versions.


On Thu, Feb 23, 2017 at 10:11 AM Stefan = Monnier <monnier@iro.umontre= al.ca> wrote:
> I have this in my emacs config for a while now.
> It works pretty well. It also allows you to use an older emacs version=
> without have to mess up the compiled elpa dir of the current version. = The
> only side-effect is that when switching major versions the package
> updates/installs will happen independently.
>
> (setq package-user-dir (format "%selpa_%s/"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 user-emacs-directory emacs-major-= version))

If it works for you, that's great.=C2=A0 Personally I'd find it ann= oying to
have a different set of installed packages per Emacs version.

I hope Emacs can slowly move toward a model where Elisp is byte-compiled automatically and kept in a version-specific place (call it a cache) so
users don't have to know about bytecode compatibility issues.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--0000000000003c4a0305e2d865a9--