From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: persistent data feature Date: Thu, 16 Dec 2021 10:00:38 +0200 Message-ID: <834k79htcp.fsf@gnu.org> References: <87tufmjyai.fsf@gnus.org> <5640724.eMgT8BFyco@galex-713.eu> <3033334.WKCauyjc8d@galex-713.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38866"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, tom@logand.com, rms@gnu.org To: Alexandre Garreau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 16 09:02:31 2021 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 1mxlig-0009xQ-N3 for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Dec 2021 09:02:30 +0100 Original-Received: from localhost ([::1]:55500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxlif-0004ku-Fm for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Dec 2021 03:02:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxlhL-0003IA-68 for emacs-devel@gnu.org; Thu, 16 Dec 2021 03:01:07 -0500 Original-Received: from [2001:470:142:3::e] (port=53284 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxlhK-0007IM-6z; Thu, 16 Dec 2021 03:01:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=kI4BJqboNbvwvu2gS/JQ7qZRF8q1HbEhbQBzT6X9zu4=; b=lFLJ9w+PmJpUoJpwdqX1 aV2DJHvhqTviprMX0Ny37NEY5KtpSzYozImhp2k84mZC7+wP26xpIziihV4S+cOUg7G65keWv3DPa dKAvayrVJe6qqTxO6/bTQDOA6EMTlQYq6Y0wBuMR4yV9p08FelKiqQLDWqGlNf4wXf2lOyHoQUeB/ dtu/Yu+Tn+aLoWaJHMtYTDStMokk5YgZy4ByTCinle3myAe4OxI8S5AUQBUXWy9tPi4D8v1Cq86h4 stbDfcpRCbV8th2l9UTRixau6YRG6wKsLgNXyQbQT+305XHyXUAsj2BFB2HPbqJMfLk1Awo1BQwng exU+93ambEMoSA==; Original-Received: from [87.69.77.57] (port=2760 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxlhB-0003zj-D0; Thu, 16 Dec 2021 03:00:58 -0500 In-Reply-To: <3033334.WKCauyjc8d@galex-713.eu> (message from Alexandre Garreau on Thu, 16 Dec 2021 06:10:30 +0100) 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:282128 Archived-At: > From: Alexandre Garreau > Cc: Eli Zaretskii , rms@gnu.org, luangruo@yahoo.com, tom@logand.com, emacs-devel@gnu.org > Date: Thu, 16 Dec 2021 06:10:30 +0100 > > Le merkredo, 15-a de decembro 2021, 17-a horo kaj 44:09 CET Stefan Monnier > a écrit : > > > That would be cool. That would make “canonical” extensions more akin > > > to users’ one, and would reduce the gap between user hacking and > > > standard development (akin to the “absence of keywords” of lisp, and > > > to the fact users’ extensions can look like core features), encourage > > > hacking, and equality of emacs’ hackers. > > > > > > Plus I like the idea you can install libraries separatly from the end > > > software, before or after, and remove them at wish. > > > > That was my original intention when I pushed for the addition of > > loadable modules. I suspect we need to significantly improve our > > loadable module support before it can become reality. > > > > In the mean time, maybe we could try and make the non-w32 world use > > a similar approach to the one used in the w32 code, so support for > > sqlite/gnutls/whathaveyou is compiled-in but Emacs still works > > properly if the .so is missing at run-time. > > oh yes indeed it would be very cool! plus doesn’t gnu and especially emacs > has some sort of policy saying we shouldn’t support some feature on > proprietary systems and not on free ones? granted here it’s minor (because > we already have fully working package managers on free systems while > windows more need this as it doesn’t, but still, that’s a robustness > characteristic) I don't object to make the shared-library loading be dynamic, of course. It should be easy to do so by utilizing the existing WINDOWSNT code with minimal changes. However, please note that doing this on Posix systems is much less useful than on MS-Windows, for 2 main reasons: . unlike MS-Windows, on Posix systems Emacs will start with no problems when an optional shared library is missing; it is only when some function from the library is called that you'll have trouble (Emacs will segfault); . unlike on MS-Windows, users of Posix systems who don't build their own Emacs generally install a prepackaged binary distribution, and that always makes sure the dependencies, in the form of those optional shared libraries, are also installed So the gains are much smaller, and basically, AFAICT, are only of the aesthetic nature, because the Emacs memory footprint is unaffected by the optional library either way, unless the user uses stuff like LD_PRELOAD. This is why we didn't do on Unix what we do for w32. It could be that just arranging for the relevant FOO-available-p function to return nil on Posix systems would be enough to prevent the crashes when the library is missing, which is currently the only real, albeit rare, problem with this. That said, if someone submits patches for using the dynamic loading on Unix and GNU systems, I won't object, of course.