From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12698 invoked by alias); 25 Jul 2012 14:44:07 -0000 Received: (qmail 12680 invoked by uid 22791); 25 Jul 2012 14:44:05 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jul 2012 14:43:43 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6PEhdSV032697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jul 2012 10:43:40 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6PEhcn8026930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2012 10:43:39 -0400 From: Tom Tromey To: Yao Qi Cc: Subject: Re: [PATCH 1/6] new observer command_option_changed. References: <1343146252-22558-1-git-send-email-yao@codesourcery.com> <1343146252-22558-2-git-send-email-yao@codesourcery.com> <87394gopwj.fsf@fleche.redhat.com> <1452365.122ECxjKta@qiyao.dyndns.org> Date: Wed, 25 Jul 2012 14:44:00 -0000 In-Reply-To: <1452365.122ECxjKta@qiyao.dyndns.org> (Yao Qi's message of "Wed, 25 Jul 2012 11:56:29 +0800") Message-ID: <87hasvlx45.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00532.txt.bz2 >>>>> "Yao" == Yao Qi writes: Yao> The general goal of my work is that "when the internal state of GDB Yao> is changed, and MI frontend and/or telnet session is not aware of Yao> the change, notify them to keep their display up to date". I'm fully on board with this plan. Yao> What do you mean by "add a Python hook"? Sorry, I wasn't clear. Suppose we want to add a new Python event so that Python code can also detect parameter changes. My supposition is that in this case we'd want to not filter, and just watch them all. Yao> In terms of bandwidth, every "=option-changed" is sent once user Yao> types command in console, user can't enter many commands at one Yao> moment (one command per second and ten commands at most, I think). Yao> This notification should not occupy much bandwidth. In that case, why not just report them all? I agree with your thinking here, that the rate is going to be quite low. I'm not sure why I didn't realize that yesterday :) Reporting them all means simpler code on the gdb side and also lets us avoid the new set/show constructors. I don't see a downside. Tom> What happens in the case where an option has a validation function that Tom> fails? IIRC gdb has an internal design flaw here. Yao> If I understand you correctly, "validation function" means cli/cli- Yao> setshow.c:parse_binary_operation and cli/cli- Yao> setshow.c:parse_auto_binary_operation. When validation fails, an error is Yao> thrown out, and observer is not called. Sorry again for the lack of clarity. I mean the call to c->func at the end of do_setshow_command. There are various spots in gdb that use a hidden variable to keep the "real" setting in case setting the value here fails. For example, try "set input-radix 1". This is an error, but I think with your patch the MI client will see a notification saying that it was changed to "1". The design flaw here is that "set" functions do their validation after the setting has been made, not before. One approach to this would be to fix this design flaw. That's likely to be a lot of work... Another approach might be to move the observer notification later. Tom