From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.devel Subject: Re: Emacs ffi Date: Sun, 18 Aug 2024 16:26:57 +0300 Message-ID: <1749.91752007685$1723987666@news.gmane.org> References: <87a5hi0yts.fsf@valhala.localdomain> <86y152ge0b.fsf@gnu.org> <86jzgjfwqp.fsf@gnu.org> <87sev78arx.fsf@gmail.com> <86le0z89u1.fsf@gnu.org> <87o75v87n1.fsf@gmail.com> <86frr786k7.fsf@gnu.org> <86frr66s0o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34491"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Andrea Corallo , suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org, Eli Zaretskii To: Christopher Dimech Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 18 15:27:40 2024 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 1sffwZ-0008s3-UD for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Aug 2024 15:27:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sffw1-0002ag-Pz; Sun, 18 Aug 2024 09:27:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sffvz-0002aR-Pb for emacs-devel@gnu.org; Sun, 18 Aug 2024 09:27:04 -0400 Original-Received: from thaodan.de ([2a03:4000:4f:f15::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sffvx-00070y-CK; Sun, 18 Aug 2024 09:27:03 -0400 Original-Received: from odin (dsl-trebng12-50dc75-154.dhcp.inet.fi [80.220.117.154]) by thaodan.de (Postfix) with ESMTPSA id 044DBD0004C; Sun, 18 Aug 2024 16:26:57 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1723987618; bh=bR5lRdHR6ubXv+LImsN5+7eRs3VE/zDrAa3J4DAN9Y8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=VMeWsUzhg3nNhABFNK0ponqiVb+1hXdLbvmkwku3bNaP98LrNDU+MN8QEmn3yp6dt aJTL4852bs8MOCG7ShyYLgV3qF1r4CKtgkKOnT+diWXBGBVCkqvTwccABY0xdf7ZHo PV1nRcRwaqt3qUh3zNPdYA0Br0GsoT+O6HrCU/Lj2cXgGTMiyStmJoz7JGb6asBGuM NgI5MitaJWYw7geGIFMvRvt7qK2fB0TjpchxojuMrqMNP57OxQA1tYmM1owVJJ1hq0 BD/KQhz0aQG4+GvWv7tRjDZpTuq3bXyBGsaMjC9s1A2xsuP5wk6Jx6tUT0NOMfi69y pgdtnte6te2CNVQjkzbhnCp/JtYFeXvTkABI/ee0JABetcZQReAIEnrWZ8VuDdr7Jy /RldJSbcHia8AUGGbmcDZ2+bjt/AyTPYfgVjGTI4auc/1SXpUa1vnn4c0XjEt0elm5 vZ17Ubce2VBRaq192+9PxMoeeuF05K6TVPYLKk3A9KK6Qe9znObqZEjtLTfT6HyOF6 5P4U3l2gSSfyfSwl5nU1WqUI0zz4LQT2qNIP6w0XeRObV3VBQJ7z3QMo0rYNTfzWBd xeIPaNP/wF53w+Y6iDlO+wYkMF6nJzRJijaFXh6FZ9HfHulfdk3WdPub4Uw58csp0e SqNi1p/SF7LXX0WYLigpr5Fc= In-Reply-To: (Christopher Dimech's message of "Fri, 16 Aug 2024 23:21:48 +0200") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH Received-SPF: pass client-ip=2a03:4000:4f:f15::1; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, INVALID_MSGID=0.568, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322890 Archived-At: Christopher Dimech writes: >> Sent: Saturday, August 17, 2024 at 8:07 AM >> From: "Andrea Corallo" >> To: "Christopher Dimech" >> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net= , arthur.miller@live.com, emacs-devel@gnu.org, "Eli Zaretskii" >> Subject: Re: Emacs ffi >> >> Christopher Dimech writes: >>=20 >> >> Sent: Friday, August 16, 2024 at 8:32 AM >> >> From: "Andrea Corallo" >> >> To: "Eli Zaretskii" >> >> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.= net, arthur.miller@live.com, emacs-devel@gnu.org >> >> Subject: Re: Emacs ffi >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> From: Andrea Corallo >> >> >> Cc: Suhail Singh , gerd.moellmann@gmail= .com, >> >> >> nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org >> >> >> Date: Thu, 15 Aug 2024 05:31:49 -0400 >> >> >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> >> > The way we do it when loading modules requires the _loaded_ libr= ary to >> >> >> > declare itself compatible, by exporting a symbol of a certain na= me. >> >> >> > That is an action by the library we load, not by the Lisp program >> >> >> > which loads it. >> >> >> >> >> >> But we could do the same for our hypothetical ffi machinery, that = is: >> >> >> `define-ffi-library' could fail if the shared library is not expor= ting >> >> >> the predetermined symbol we expect no? >> >> > >> >> > Of course. But how many such libraries do that? >> >> >> >> Dunno, ATM very few if not zero I guess. >> > >> > If there are no existing libraries that export the required symbol, it >> > raises legitimate concerns about the feasibility and utility of the >> > approach. Essentially, if the mechanism put in place is not supported = by >> > any available libraries, then the mechanism is ineffective and overly >> > idealistic. >> > >> > There exists a large disconnect between theoretical compliance and >> > practical usability. If the requirements for compliance are so stringe= nt >> > or specific that no existing libraries can meet them, then it could be >> > argued that the approach is not grounded in the reality of software >> > development. >>=20 >> I disagree, this is normal evolution for software ex: every time a new >> programming language is created (or a new feature is added to it) >> compilers implement the related support, even if no programs are using >> that language or that new extension at present. Is this a large >> disconnect between theoretical compliance and practical usability? No, >> is just that users will come later. >>=20 >> If Emacs requires the symbol maybe compatible libraries will just export >> it afterwards (given the cost is close to zero). - Andrea > > It is imposing an additional requirement that isn't typically necessary=20 > in most other environments. > > Typically, mathematical libraries are designed to be widely applicable > and used across various platforms and applications. Requiring these > libraries to export a specific symbol or be designed with editor > compatibility in mind is an unnecessary hurdle. Developers of libraries > do not prioritize compatibility with editors like Emacs. > To overcome the hurdle that Emacs is bringing upon itself, of requiring > GPL compliance for mathematical libraries, it should provide its own > built-in library as suggested by E. Berg. It is the pragmatic way to do > it. I disagreed with Berg initially, but I can now understand his > frustrations with the whole emacs design. > Some free software simply cannot be used with GPL-licensed software like= =20 > Emacs without violating the terms of one or both licenses. Requiring GPL= =20 > compliance for integration is banal. Particularly when Emacs is not the= =20 > one providing the library. It will be the user who will be using. One=20 > simply cannot accuse a user to breaking any license if the library is not > GPL compliant. The landscape of free software licenses is diverse, with= =20 > many different licenses with many not compatible with each other. You=E2= =80=99d=20 > have to put every teenager in the world in jail, and you can=E2=80=99t do= that !=20 I think GPL compliance could be checked but I agree we can't require external libraries where Emacs is the minority to impose such requirements. Well technically we can but who will honor them? Does the FFI interface have a system for such things? I think a warning or a "do you really want this" would be the least intrusive way. Similarly to spoiler warnings in media when there's graphic depections of violence: Do you really want to enable this, the libraries could restrict your freedom or similar.=20 I think the XEmacs implementation of FFI would be a good start to look how such an interface could be added. > But this message does not resonate within the minds of the core emacs mai= ntainers,=20 > with the trend continuing for many years to come. Some believe that ever= ybody=20 > in the world doesn=E2=80=99t get it about free software, and even that ev= erybody in the=20 > world is a crook and that everybody in the world is trying to steal free = software=20 > and make bad use of it. I do not approve of such ideas. Many think they= know > everything about copyright infringement, but never been thrown out of cou= rt on=20 > a motion to dismiss.=20=20 I don't really want to go into the politics besides that I have seen worse on this list from user or maintainer such as to tell user to not use gender neutral pronouns if they so chose to do so. > It's always the same, you'll get prima donna maintainers who are at the s= ame=20 > level of priests, who preach a lot about licensing scenarios. But have n= ever=20 > been there, never done it, but preaching a lot about what others can do a= nd what=20 > they cannot do. Too much coercion was surely not what we wanted to apply. > > As customary I get "Your message was deemed inappropriate by the moderato= r." > from emacs-devel-owner@gnu.org. I wonder who it is. Actually I wonder w= hy > I wonder. > > We need to understand how that working together purposively brings us to = the=20 > point where everyone is not afraid of free software anymore and we are no= t=20 > worried about their complying anymore. We are just all engaging and lead= ing=20 > the task of making free software. I had this experience in the past too where some judge first and then read. I.e. the recent discussion about OAuth2 where there was a compliant that we shouldn't implement support for non-free platforms even thou that wasn't really the point. Sometimes it would be better if the more experienced contributors would try to be more welcoming or helping when it comes to new contributors.