From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Sat, 30 Aug 2008 21:51:01 +0200 Message-ID: <87myiub7tm.fsf@ambire.localdomain> References: <20080818210927.GD2615@muc.de> <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> <87ljytkwpk.fsf@rattlesnake.com> <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp> <87vdxp27z6.fsf@uwakimon.sk.tsukuba.ac.jp> <87prnxe5hc.fsf@rattlesnake.com> <873aktck5d.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5e5dsvq.fsf@rattlesnake.com> <48B44802.1080302@emf.net> <87ej4atczj.fsf@gmail.com> <48B78A75.8080103@emf.net> <803akoyrqy.fsf@tiny.isode.net> <48B7F59B.5060705@gmail.com> <48B84CA8.7080908@emf.net> <87zlmvd1xl.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1220126067 6210 80.91.229.12 (30 Aug 2008 19:54:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2008 19:54:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 30 21:55:21 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KZWXZ-0007L1-0h for ged-emacs-devel@m.gmane.org; Sat, 30 Aug 2008 21:55:21 +0200 Original-Received: from localhost ([127.0.0.1]:55324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZWWa-0006Ok-Fd for ged-emacs-devel@m.gmane.org; Sat, 30 Aug 2008 15:54:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZWWX-0006OZ-IT for emacs-devel@gnu.org; Sat, 30 Aug 2008 15:54:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZWWU-0006O9-Vs for emacs-devel@gnu.org; Sat, 30 Aug 2008 15:54:16 -0400 Original-Received: from [199.232.76.173] (port=35507 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZWWU-0006O5-NY for emacs-devel@gnu.org; Sat, 30 Aug 2008 15:54:14 -0400 Original-Received: from [151.61.142.244] (port=47078 helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZWWU-0003Qo-7d for emacs-devel@gnu.org; Sat, 30 Aug 2008 15:54:14 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1KZWTN-0004AR-MB; Sat, 30 Aug 2008 21:51:01 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 29 Aug 2008 16:20:09 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103273 Archived-At: () Stefan Monnier () Fri, 29 Aug 2008 16:20:09 -0400 I'm not sure I understand what you mean. In the case of something like Semantic, if parsing in Elisp is too expensive or if you want to use some existing C code to do the parsing, the bottleneck you'll have to handle is that the external process can't directly access the buffer's text, In the common case, that text is a file on the filesystem (which the subprocess can access independently). I would design things so that the subprocess persists for the Emacs session and maintains its own state, such as various project-specific symbol tables and a copy of the buffer. Commands from Emacs would be along the lines of "sync-with-file", "query-symbol", "query-parse-state", and so forth. Results from the query-FOO commands should typically be very low bandwidth. So no, i don't think the bottleneck would be the buffer access (for this design), because the subprocess does not really need to access the buffer. Changes to the buffer that have not yet hit the filesystem can be communicated by publishing some portion of `buffer-undo-list' (which is also relatively lightweight). and it can be very costly to pass that text to the subprocess and then process the returned value (which may look like a list of text properties to add to various parts of the text). Well... A DLL could be significantly more efficient. The difference can be as large as "on-the-fly" vs "batch". ...i suppose i'll have to agree that all these "could be" scenarios are possible. My view is that given the requirement of external symbol tables (and other state), the biggest win for both performance and maintainability is to go asynchronous. If you want async from a subprocess, no worries, but if you want async in-process, you need to either design (and debug and maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads or phase-of-the-moon-threads or whathaveyou. Then, you need to make sure every visitor treats your program counter w/ the respect it deserves. That's a lot of thankless and brutish police work. thi