From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Wojciech Meyer Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Sat, 04 Aug 2012 00:11:03 +0100 Message-ID: References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> <501B8C48.3000704@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344035711 6808 80.91.229.3 (3 Aug 2012 23:15:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Aug 2012 23:15:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 04 01:15:12 2012 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 1SxR5M-0005sM-Ad for ged-emacs-devel@m.gmane.org; Sat, 04 Aug 2012 01:15:12 +0200 Original-Received: from localhost ([::1]:59717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxR5L-0001pC-H5 for ged-emacs-devel@m.gmane.org; Fri, 03 Aug 2012 19:15:11 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxR5J-0001oc-5I for emacs-devel@gnu.org; Fri, 03 Aug 2012 19:15:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SxR5I-0004t4-7m for emacs-devel@gnu.org; Fri, 03 Aug 2012 19:15:09 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:45958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxR5I-0004sd-0e for emacs-devel@gnu.org; Fri, 03 Aug 2012 19:15:08 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SxR5D-0005pL-P8 for emacs-devel@gnu.org; Sat, 04 Aug 2012 01:15:03 +0200 Original-Received: from cpc1-cmbg12-0-0-cust201.5-4.cable.virginmedia.com ([86.9.116.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Aug 2012 01:15:03 +0200 Original-Received: from wojciech.meyer by cpc1-cmbg12-0-0-cust201.5-4.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Aug 2012 01:15:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 27 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpc1-cmbg12-0-0-cust201.5-4.cable.virginmedia.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) Cancel-Lock: sha1:xdvmv+kt/eO0MfilyjJbL1ubqEY= 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:152159 Archived-At: Stefan Monnier writes: >>>> the barrier (just one such a store is fatal for the collector). Next, >>>> when we will know that the collector invariant is never broken, it's >>>> possible to replace these obfuscated FVAR (x, y) back to x->y. >>> You can use coccinelle to automatically turn the x->y into an rvalue >>> FVAR (x,y) while debugging. And such a script should be kept around and >>> run every once in a while to check that new code follows the >>> SETFVAR convention. >>> But I don't want the trunk's code obfuscated just for some temporary >>> debugging needs. >> Have you tried to use coccinelle? As I have said, it's not a silver bullet >> (yet), and it's just impossible to handle such a stuff in fully automated >> mode. There are special cases that should be handled manually, and doing >> them over and over again is much worse than even an endless merging. > > If we want to use "foo->bar" in the end code, then we will need to solve > this problem anyway (since, as mentioned, we'll need to check every once > in a while that "foo->bar" is only used for rvalues). How about using MELT or Clang to rewrite the relevant AST patterns into something you want at the compile time? Alternatively you could use some other frontend like CIL, or just do the source to source transformation similarly to what you have done already with coccinelle. -- Wojciech