From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jacob Bachmeyer Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Thu, 15 Jan 2015 16:01:13 -0600 Message-ID: <54B838A9.2080503@gmail.com> References: <54B1B97E.9070204@gmail.com> <87fvbhk4ha.fsf@fencepost.gnu.org> <54B456C8.6010506@gmail.com> <8761cbhvhb.fsf@fencepost.gnu.org> <54B5AA10.7080606@gmail.com> <87iog9f5x5.fsf@fencepost.gnu.org> <87egqwflys.fsf@fencepost.gnu.org> Reply-To: jcb62281@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1421359291 511 80.91.229.3 (15 Jan 2015 22:01:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2015 22:01:31 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 15 23:01:26 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 1YBsTm-0005wc-5M for ged-emacs-devel@m.gmane.org; Thu, 15 Jan 2015 23:01:26 +0100 Original-Received: from localhost ([::1]:53075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBsTl-0001Ld-NA for ged-emacs-devel@m.gmane.org; Thu, 15 Jan 2015 17:01:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBsTi-0001LY-Lh for emacs-devel@gnu.org; Thu, 15 Jan 2015 17:01:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBsTh-0007GU-Qk for emacs-devel@gnu.org; Thu, 15 Jan 2015 17:01:22 -0500 Original-Received: from mail-ob0-x234.google.com ([2607:f8b0:4003:c01::234]:44981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBsTc-0007Ep-73; Thu, 15 Jan 2015 17:01:16 -0500 Original-Received: by mail-ob0-f180.google.com with SMTP id uz6so391614obc.11; Thu, 15 Jan 2015 14:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gaZS8zcQuw+/W41e9fqUAOqSCsvYZJ8igq1MGoiG2lA=; b=lG35bAgHcTfAkWlkAmYoM4IT1ODSFe9bJn03Bj0NrvPskGvRGYCpp6eZtpE1cPGe+2 XhUNFCXPCCnVy4n8WHY80+nlzqZKoeSCOROy/3Z1LtrxPp7NrAZZnPZSicF87D20csh+ d/4XJMMPjbNJc+ZT+qK+93StsAC34HwoRhEQ4Slah5orvmp2XG09ArxAjN2f/Mb29BmN iUKfRi1Yfx8WXwWsAUjVdxidXD+eCti8GVo6hP9OuXFBZCUpFo5GVEYH3XHeAZP7i9Qu Iim7mlcOjdNvrL/9zfDvER//NemojUnxiyFOdimBAFbFK3UNcZUoQlV6dxiP5mV28yal olrQ== X-Received: by 10.182.234.15 with SMTP id ua15mr7240639obc.77.1421359275661; Thu, 15 Jan 2015 14:01:15 -0800 (PST) Original-Received: from [192.168.2.42] (adsl-70-133-148-241.dsl.ablntx.sbcglobal.net. [70.133.148.241]) by mx.google.com with ESMTPSA id y201sm1264384oie.9.2015.01.15.14.01.14 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Jan 2015 14:01:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 In-Reply-To: <87egqwflys.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4003:c01::234 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:181308 Archived-At: David Kastrup wrote: > Any way we find for combining Emacs with GCC will be usable > as a way for combining GCC with proprietary applications without the > proprietary applications falling under the GPL. > I do not think that that is necessarily so. For example, adapting GCC to be usable as a library would allow Emacs (and other Free software) to use GCC in a way that would remain barred to proprietary applications. I am less sure than I initially was about the "two plugins" solution I proposed earlier, but I will clarify it here. The "two plugins" interim solution: Implement a pair of plugins, one uses the existing GCC plugin interface, the other uses a to-be-developed Emacs extension interface. The to-be-developed Emacs extension interface essentially allows subrs to be added to a running Emacs. It is not useful aside from extending an Emacs Lisp interpreter. The pair of plugins is an inseparable whole. The need for two plugins is simply an artifact of GCC's current architecture, which precludes directly loading GCC into the Emacs process. The end result is Emacs Lisp bindings to GCC's internal API for its internal AST. Since these internal APIs in GCC are somewhat stable, even though the underlying structures may not be stable, Emacs gets workable access to the AST. Since the link plugin (the pair is a technical artifact--it is really one plugin using both interfaces and IPC to tie the processes together) would be GPL, nonfree software would not be able to use it. Since the plugin would be Emacs Lisp bindings to GCC's internal API, it would logically be a part of GCC. The IPC link within the plugin is a technical artifact and the overall function of the plugin is to make (part of) GCC available as a library to Emacs. If the bindings are well-designed, the future GCC/Guile may be able to reuse the interface with a less-complex implementation that does not need IPC. This would mean less work when porting Emacs to Guile, since only the process of loading the API would change. On a technical note, could a single shared object be both a valid GCC plugin and a valid Emacs plugin? That would eliminate even the appearance of separability, which seems to be the concern with this approach. Maybe we need a new GCC extension for runtime binding of symbols to allow symbols to be undefined as long as they are not used? Or should we just let the plugin code be a mess, with many calls to libdl, as a reminder that this is supposed to be a temporary solution?