From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: & requires l-value Date: Tue, 21 May 2002 05:03:42 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020521090847.8B44.LEKTU@terra.es> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1021971957 25721 127.0.0.1 (21 May 2002 09:05:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 21 May 2002 09:05:57 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17A5af-0006gk-00 for ; Tue, 21 May 2002 11:05:57 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17A5p1-0008V2-00 for ; Tue, 21 May 2002 11:20:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17A5ax-0005ts-00; Tue, 21 May 2002 05:06:15 -0400 Original-Received: from 146-115-123-35.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([146.115.123.35] helo=raeburn.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17A5YY-0005hs-00 for ; Tue, 21 May 2002 05:03:46 -0400 Original-Received: from kal-el.raeburn.org (mail@kal-el.raeburn.org [18.101.0.230]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g4L93hB06604; Tue, 21 May 2002 05:03:43 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17A5YU-0002kj-00; Tue, 21 May 2002 05:03:42 -0400 Original-To: Juanma Barranquero In-Reply-To: <20020521090847.8B44.LEKTU@terra.es> (Juanma Barranquero's message of "Tue, 21 May 2002 09:11:17 +0200") Original-Lines: 40 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4231 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4231 Juanma Barranquero writes: > Perhaps the problem is related to recent changes by Ken Raeburn? Yes. With my changes to buffer.c, the UNIX/X11 code (the only part I can test) seems to be good about treating the car/cdr slots as read-only except in alloc.c (creation and GC) and certain macros in lisp.h (setcar/setcdr). This is one step in isolating the Lisp engine implementation from the rest of the Emacs code, making modification of that Lisp engine (such as changing object representations or GC strategies) more practical. We want the capability of implementing write barriers when an object is modified, so object fields should not be written except through a clearly defined set of macros or functions where the write barrier can be implemented. Miles Bader writes: > I guess it could use XCDR_AS_LVALUE instead of XCDR. It could, but that would be counterproductive in the long run. Undoing my change to LISP_MAKE_RVALUE would make things build again on Windows, but if that's done, *please* make it conditionalized for Windows, and commented as a temporary workaround until the Windows code is fixed. And maybe make the change in w32fns.c instead of lisp.h. I don't recommend any of this though. > That code seems kind of dodgy to me though; it seems cleaner to just > make the `tail' field in enumfont_t a normal Lisp_Object that points to > either Qnil or a cons cell, and do the list splicing doing XSETCDR (it > has a pointer to the head of the list anyway, so the nil case isn't a > problem). This is the better approach, even though it requires a little work. Much like the changes I had to make in buffer.c -- which were a bit more tedious, perhaps, since three list-element pointers were being juggled at once. Ken