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: Mon, 24 Feb 2014 23:37:59 +0100 Organization: Organization?!? Message-ID: <87eh2s9lx4.fsf@fencepost.gnu.org> References: <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87mwhjdq32.fsf@fencepost.gnu.org> <530BA09C.70802@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393281508 27531 80.91.229.3 (24 Feb 2014 22:38:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2014 22:38:28 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 24 23:38:35 2014 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 1WI4AV-0001N6-8t for ged-emacs-devel@m.gmane.org; Mon, 24 Feb 2014 23:38:35 +0100 Original-Received: from localhost ([::1]:60034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI4AU-0007Yx-Ty for ged-emacs-devel@m.gmane.org; Mon, 24 Feb 2014 17:38:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI4AM-0007Yr-He for emacs-devel@gnu.org; Mon, 24 Feb 2014 17:38:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WI4AG-00064h-8z for emacs-devel@gnu.org; Mon, 24 Feb 2014 17:38:26 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:37902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WI4AG-00064E-2c for emacs-devel@gnu.org; Mon, 24 Feb 2014 17:38:20 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WI4AB-0000CJ-V3 for emacs-devel@gnu.org; Mon, 24 Feb 2014 23:38:15 +0100 Original-Received: from x2f51cea.dyn.telefonica.de ([2.245.28.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Feb 2014 23:38:15 +0100 Original-Received: from dak by x2f51cea.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Feb 2014 23:38:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 50 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f51cea.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:04IXVaMToYbcwEkkWk87L0y12ac= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:169852 Archived-At: Dmitry Gutov writes: > On 24.02.2014 19:33, Richard Stallman wrote: >> The lookup and completion features that people want can be implemented >> by making GCC answer questions sent to it, as Aspell does for M-$. >> That change would be welcome. I think it could be implemented using >> GCC's existing plug-in mechanism, but it would be better to put >> the code into GCC itself. > > Could it support a "daemon" mode? > > The current situation in Clang is, its executable only supports the > simplest mode of operation: one process call per completion. This way, > it has to parse all relevant files (headers, etc) each time completion > is requested. That leaves something to be desired. > But the completion information is available via libclang, and there > are a few projects that build on it to spin up a persistent server, > which only processes different files anew when they've changed since > the last time (or at least that's the intention). These projects also > support different build systems and extract the necessary dependency > information, include paths, etc. > > I don't really see GCC itself doing that (at least, the last part). > It would require quite a bit of work that might be better left to > third-party developers. The one thing that the basic approach "output the annotated parse tree" or whatever other cooked summary output via plugin or whatever else has over "stay resident after compilation and answer queries" is that a daemon in a separate process that will first read the respective data and then answer queries about it allows the actual parser process to terminate and shed all the memory and temporary data and parsing tables it needed for arriving at the parse tree. That means that the part staying resident and answering queries will not have its memory fragmented by lots of stuff that is no longer needed. The "cooked summary" could include a list of processed source files so that the daemon can reexec the parser and possibly itself whenever it finds that a file changed between queries. So a process and program boundary seems to make a lot of sense. Whether the data between processes/programs is passed via file/pipe/shared memory is a different consideration. -- David Kastrup