From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.devel Subject: Re: Lisp watchpoints Date: Sun, 29 Nov 2015 15:35:24 -0500 Message-ID: References: <83wpt922dn.fsf@gnu.org> <83egf8oiwt.fsf@gnu.org> <834mg4oa3l.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1448829342 13475 80.91.229.3 (29 Nov 2015 20:35:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Nov 2015 20:35:42 +0000 (UTC) Cc: John Wiegley , Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 29 21:35:37 2015 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 1a38h7-0006dE-2v for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2015 21:35:37 +0100 Original-Received: from localhost ([::1]:37633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a38hB-0004QH-3C for ged-emacs-devel@m.gmane.org; Sun, 29 Nov 2015 15:35:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a38gy-0004Q1-S6 for emacs-devel@gnu.org; Sun, 29 Nov 2015 15:35:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a38gx-0002qs-O5 for emacs-devel@gnu.org; Sun, 29 Nov 2015 15:35:28 -0500 Original-Received: from mail-ig0-x230.google.com ([2607:f8b0:4001:c05::230]:32869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a38gv-0002qd-He; Sun, 29 Nov 2015 15:35:25 -0500 Original-Received: by igcmv3 with SMTP id mv3so57970921igc.0; Sun, 29 Nov 2015 12:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LoXK0WC0ONm1lqhUdpajExEpbOlHPy0qOxDfsCWRpwg=; b=pTjUW3zwaBMdq9xkJIaylge/+2NRbi2pTL4HejMkqlU68L96cxF7k8xdEX4uv83S1q df6+BaBlFlw989t5bK97RzSRNkAWQ2sBqttB9H3dDsBaOY2ePhC/Bu3crBlu8m+bNHMH qFvXXpsW4sKjP9649grRuq0qBDnr6eczt+m0cvPFYisqR3lSwYJlkIkvQqTvBQBQlx8P lwgKwD1NXT8AZfIw5fboQK7w4flY3bi0eZ3FXgTMxVNGYttRJUqCqZa5VuBBiccDRCjD ns9pMh7JxX19CJQz7i0Kal8CzX17TMCHc+rXQZ0+rqsW9ng/Ho571cJzSSG80kSuC9vd gElA== X-Received: by 10.50.17.38 with SMTP id l6mr6723070igd.58.1448829324783; Sun, 29 Nov 2015 12:35:24 -0800 (PST) Original-Received: by 10.79.119.2 with HTTP; Sun, 29 Nov 2015 12:35:24 -0800 (PST) In-Reply-To: <834mg4oa3l.fsf@gnu.org> X-Google-Sender-Auth: iSMVdnRFzbtfBlKCwr3-Ssv4G24 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::230 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:195569 Archived-At: On Sun, Nov 29, 2015 at 2:54 PM, Eli Zaretskii wrote: >> Date: Sun, 29 Nov 2015 14:40:57 -0500 >> From: Noam Postavsky >> Cc: Stefan Monnier , John Wiegley , emacs-devel@gnu.org >> >> > The call to ARRAYELTS should be outside of the loop (for those poor >> > souls who run unoptimized builds most of the time). >> >> Compiling the following shows gcc folds the constants even with -O0 >> (also, notify_variable_watchers() should only be called for a few >> selected symbols so I don't think it would really slow things down >> very much). > > That depends om your GCC version, and then there are -fFOO switches > that can control each specific optimizations. And seeing that in the > code simply looks wrong, regardless. So let's move it out, please. Since ARRAYELTS is a compile-time constant, to me it looks completely redundant to move it out of the loop. Would it help if I added a WATCHER_NUMBER_LIMIT to the enum after WATCHER_NUMBER_SET_REDISPLAY and used that instead? > >> >> + DEFVAR_INT ("set-redisplay-internal-watcher-number", >> >> + Vset_redisplay_internal_watcher_number, >> >> + doc: /* Internal watch function constant. */); >> >> + Vset_redisplay_internal_watcher_number = WATCHER_NUMBER_SET_REDISPLAY; >> >> + make_symbol_constant (intern_c_string ("set-redisplay-internal-watcher-number")); >> > >> > I'd prefer if all this were moved to window.c. data.c has no business >> > with display-related issues. >> >> Hmm, then how should we make the connection between watcher numbers >> and C function pointers? I think data.c should be in charge of that. > > What connection? I'm afraid I'm not following. The watchers_table holds all of the C functions that can be used as watchers. I think it makes sense to have this table in data.c. Lisp code that wants to add a watcher to a variable needs to know which number to use (0 for set_redisplay, because it's the 1st (and only) entry in the table). Since data.c has the table, I figured it makes sense that it would be in charge of exporting the number->Cpointer mapping to lisp. Hence, set-redisplay-internal-watcher-number is defined in data.c. If window.c would be in charge of defining set-redisplay-internal-watcher-number, then it would need to know the right number, which would probably mean moving the WATCHER_NUMBER_SET_REDISPLAY definition to a header file away from the watcher_table definition, which would be suboptimal, I think. Or I guess we could just hard code the number 0 with a comment to look in data.c; is that too dirty?