From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Sun, 18 Jan 2015 11:00:35 +0100 Message-ID: <87r3usbe7w.fsf@fencepost.gnu.org> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> <54B456C8.6010506@gmail.com> <8761cbhvhb.fsf@fencepost.gnu.org> <54B5AA10.7080606@gmail.com> <54B6F8EF.7020401@gmail.com> <54B8326B.90804@gmail.com> <54B889CC.9030401@gmail.com> <878uh3dquk.fsf@fencepost.gnu.org> <54B9BA40.2070104@gmail.com> <87d26ddi4z.fsf@fencepost.gnu.org> <54BB2B40.4040508@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421575293 14459 80.91.229.3 (18 Jan 2015 10:01:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Jan 2015 10:01:33 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Jacob Bachmeyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 18 11:01:32 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YCmfk-0001N6-2G for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 11:01:32 +0100 Original-Received: from localhost ([::1]:33115 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCmfj-0007Vz-F9 for ged-emacs-devel@m.gmane.org; Sun, 18 Jan 2015 05:01:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCmfX-0007Vs-9u for emacs-devel@gnu.org; Sun, 18 Jan 2015 05:01:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCmfV-00017r-Nx for emacs-devel@gnu.org; Sun, 18 Jan 2015 05:01:19 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCmfV-00017l-KU for emacs-devel@gnu.org; Sun, 18 Jan 2015 05:01:17 -0500 Original-Received: from localhost ([127.0.0.1]:35865 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCmfO-0006fJ-PJ; Sun, 18 Jan 2015 05:01:11 -0500 Original-Received: by lola (Postfix, from userid 1000) id 0D246DF318; Sun, 18 Jan 2015 11:00:35 +0100 (CET) In-Reply-To: <54BB2B40.4040508@gmail.com> (Jacob Bachmeyer's message of "Sat, 17 Jan 2015 21:40:48 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181398 Archived-At: Jacob Bachmeyer writes: > David Kastrup wrote: >> Jacob Bachmeyer writes >>> >>> What stops nonfree software from doing that is that the mechanism used >>> to get access to internals of GCC is very low-level (using ptrace(2) >>> to directly access GCC's memory would not be out of the question) and >>> transfers GCC internal structures over the link, which are interpreted >>> within the Emacs process. According to the GPL FAQ: "Using shared >>> memory to communicate with complex data structures is pretty much >>> equivalent to dynamic >>> linking."() >>> I expect that GCC's internal trees qualify as "complex data >>> structures". There is certainly not a nice, readable, text AST dump >>> involved at any point. > >> At any rate, does not sound like an interface one could keep steady >> across different GCC versions. To make that the case, you need >> something describing the internals' meaning, akin to how debug >> information describes memory layout. Once you have that kind of "my raw >> memory means $x" description, this constitutes an interface. Possibly >> an awkward interface, but that's not legally significant. > > That's the point--the interface between the underlying processes is > not stable across GCC versions and the "description" of the internals' > meaning comes in the form of a C DSO that Emacs can load to get Emacs > Lisp bindings to GCC's own API for accessing these structures. The > "description" is a program component that must be combined with any > program that uses it. So what? You do that with a minimal program you license under the GPL and then dump the AST in a generically useful form. Then you get a sanely usable dump of generally useful information you and other proprietary programs can use conveniently while any program from the GNU project has to go through a binary mess by decree. We are shooting ourselves much more in the foot that way than anybody else. > Reverse engineering one version of the interface would allow non-free > software to use that version of GCC, yes, but doing that repeatedly as > GCC changes, without it ever becoming a derived work, would quickly > become more expensive than simply writing a new parser. Especially > since the two halves of the link plugin are only required to talk to > each other, and are built together, so they can change easily. The > link protocol could even be made polymorphic in some way, so that > every pair of binaries built would have a subtly different link > protocol. So any version of Emacs will work only with a particular version of GCC? Remind me: whose life were we trying to make harder? >> And our limited and distributed resources and skills as free software >> developers mean that our success depends on interoperation within >> free software. We can't afford this process every time we want >> something to work together. >> > > We are at a point where continued inaction will eventually make GNU > irrelevant, the right action will put GNU far ahead of all the others > for the foreseeable future, Reality check: with regard to interoperation we will not be "far ahead of all the others" period. And that has never been much of a focus for the GNU project anyway. If we ever wanted to get "far ahead" in that category, talking about interfaces that are not robust or generic enough to be considered an interface (because once there is a proper interface, it can be used by non-free applications) is like discussing what plate armor is best for ballet dancing. > and the wrong action will... well, extending the metaphor about the > defensive wall around our city that RMS has used, the wrong action > could destroy our defensive wall entirely. At the current point, we have a defensive wall around our armory and can't get in. > It is very important that we find and carry out the right action. I think we missed the point of time where that would have been very important. We dropped the ball quite thoroughly already. But since this is a principal problem, it will come up again. And again. And the real danger is that we continue to fumble and drop every time. It is my personal conviction that in the area of interfacing, the kind of micromanaging that would be required to manage GCC/Emacs plugins let alone an integration will not work. If we need to have this kind of discussion everytime some GNU components want to operate closer, this cannot work. GNU is designed and intended to work as one, and if we need to micromanage every step where it does that, we will not be getting anywhere. This issue and the associated decisions will not disappear overnight. There is no urgency for action: both damage and benefits of a particular decision will be accumulative for a long time. But what we need is a long-term strategy here. We can't muddle through like that forever, pissing everyone off in the process. Richard needs to come to a basic yes/no decision regarding whether he wants to see independent GNU applications to be combined in new manners without micromanaging each instance (and I am very unconvinced that this is even possible, for legal, technical, and social reasons) or not. A "yes" will very likely imply that this kind of combination cannot be barred from being done with non-free independent components. A "no" will mean that the GNU universe as a whole will permanently be disadvantaged regarding regarding interoperation compared to a more permissively managed infrastructure. Having certainty about that will make it possible for people to choose which projects under which guidance to participate in without wasting their time and emotions on things they are powerless to change. We need a strategic decision, and that's Richard's responsibility. For the issue at hand, smart completion and possibly refactoring tools based on a combination of Emacs and Gcc, it may come too late to make much of a difference any more, at least regarding those people who wanted to volunteer this time. That's possibly a waste and a shame but it may be that the pieces of clockwork are now too broken to pick them up. But there is no point in having that kind of waste occur again and again and again. The strategy "wait until the issue occurs next time and then repeat what we did last time until it goes away" is undignified. -- David Kastrup