From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Watchpoints for emacs lisp. Date: Tue, 11 May 2010 21:53:17 -0400 Message-ID: References: <8371144.1993831273586052309.JavaMail.www@wwinf4619> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1273629220 24339 80.91.229.12 (12 May 2010 01:53:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 12 May 2010 01:53:40 +0000 (UTC) Cc: "Emacs Dev \[emacs-devel\]" To: alinsoar@voila.fr Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 12 03:53:39 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OC18j-0003Yq-V6 for ged-emacs-devel@m.gmane.org; Wed, 12 May 2010 03:53:38 +0200 Original-Received: from localhost ([127.0.0.1]:34978 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC18j-0002vJ-Bj for ged-emacs-devel@m.gmane.org; Tue, 11 May 2010 21:53:37 -0400 Original-Received: from [140.186.70.92] (port=59803 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC18e-0002vC-AY for emacs-devel@gnu.org; Tue, 11 May 2010 21:53:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OC18c-0002y7-Eu for emacs-devel@gnu.org; Tue, 11 May 2010 21:53:32 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:50030 helo=raeburn.org) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OC18R-0002vG-Ez for emacs-devel@gnu.org; Tue, 11 May 2010 21:53:30 -0400 Original-Received: from squish.raeburn.org (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id o4C1rHjc019845; Tue, 11 May 2010 21:53:18 -0400 (EDT) In-Reply-To: <8371144.1993831273586052309.JavaMail.www@wwinf4619> X-Mailer: Apple Mail (2.1078) X-detected-operating-system: by eggs.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:124711 Archived-At: On May 11, 2010, at 09:54, A. Soare wrote: >>> I insert to the struct Lisp_Symbol a field :watched: . >>=20 >> So, no support for watching for an element of an array or pair to be = changed, or part of a string? >=20 > Hm... I thought only to symbols, true. Not to arrays, not to numbers. >=20 > Can you use the change of an array if a symbol does not point to it? = Probably yes. There exist lambda function (functions without name), but = probably one can debug also the change of an array without name. The 'aset' function can change an element of a vector or string (or = certain other objects), in place. So any existing references to the = containing vector/string/whatever will now see the new element. = Similarly, setcar and setcdr can change the values contained within a = cell that may be referred to elsewhere, and the change will be visible. = This isn't the case with numbers, as numbers can't act as containers or = references for other values. >> What about changes to the property list, or function value, of a = symbol? >>=20 >=20 > Can you figure an algorithm for checking very fast (O (0)) whether a = symbol has a given property ? I don't think that matters. You could have the flag on the symbol = indicate that the handler should be called if *any* of the slots are = changed (function, value, plist, aliasing, becoming buffer-local, etc). = The property list may be changed by changing the 'plist' field in the C = structure, which would be noticed by the above mechanism, or it can be = changed by altering elements of the list stored in the 'plist' field. = If you make it possible to watch for changes to a cons cell, though, = that could be applied to the (original) property list itself. (Managing = that and figuring out when to stop watching those cells could be tricky, = but the fundamentals would be there.) However, I don't think there's any spare room in a cons cell allocation = at the moment. Doing this efficiently, and ideally without getting too = intimate with the garbage collection system, could be difficult... = perhaps watching symbols would suffice for a first cut, and cons cells = could be worked on later if desired. (But I'd still suggest you have = the watchpoint trigger for changes to *any* field of a symbol, not just = the 'value' field.) Ken=