From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86836 invoked by alias); 5 Nov 2019 10:17:51 -0000 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 Received: (qmail 86792 invoked by uid 89); 5 Nov 2019 10:17:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,KAM_TK,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy= X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Nov 2019 10:17:49 +0000 Received: by mail-wr1-f68.google.com with SMTP id l10so20640974wrb.2 for ; Tue, 05 Nov 2019 02:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=w1T0gp5KXYUB8U1TA/NfkQMSl5UnUKPZwTGTKnJf+ro=; b=MSPyHLws90lN74BeMgzjLETlWFxsGT3fp4WkL6DKOYz0OO2SD7Xy1HfnguIfhuCqRM GQdUOFvzhcLOXijVw4IvD28Yk3r/4f22Ku4wuKnztOBzRe/jfgjgEWZu6+8ph1b5P6DV wRC2VkOXlzNceKY28kUZ2CjImNWCUV72iHyVeB2V9H8MntJkoFEfcIbwD9V9CHFBMIEE DRZI4Bhzyy7bSlk0vKM6gsrFDqNBN9Ct5hGcReEKglMsRRUZoUb+T2mZsmpQKWe8XtIc 09hMPoQpDjjuw0GYEfeBqvGGKxpNPZtJowDP9vbsrbTcgtzYYFug+82Rx4LEZ2txjWQn Kfbw== Return-Path: Received: from localhost (cust64-dsl91-135-5.idnet.net. [91.135.5.64]) by smtp.gmail.com with ESMTPSA id j14sm25235637wrj.35.2019.11.05.02.17.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Nov 2019 02:17:46 -0800 (PST) Date: Tue, 05 Nov 2019 10:17:00 -0000 From: Andrew Burgess To: Marco Barisione Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v2] Add a way to preserve overridden GDB commands for later invocation Message-ID: <20191105101745.GC11037@embecosm.com> References: <20191028133234.319-1-mbarisione@undo.io> <20191101085449.28493-1-mbarisione@undo.io> <87wocj1k3y.fsf@tromey.com> <2E9BBFD2-6643-4958-AF6B-FFC974FFF479@undo.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2E9BBFD2-6643-4958-AF6B-FFC974FFF479@undo.io> X-Fortune: There is no such thing as fortune. Try again. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00115.txt.bz2 * Marco Barisione [2019-11-01 21:01:18 +0000]: > On 1 Nov 2019, at 19:18, Tom Tromey wrote: > >>>>>> "Marco" == Marco Barisione writes: > > Could you say what unexpected behavioural changes you would anticipate? > > I tend to think it would be clearer if all commands were treated > > identically. > > > > Is there some implementation difficulty doing it? Or was it just that > > you didn't think it was useful? > > I was mainly worried about changing the behaviour in ways which could be > unexpected. For instance, an instance of gdb.Command may end up living longer > than expected. > Another thing is that a command which was written before this patch may not be > using the original implementation just because it was not possible before, so > block a further command from accessing it as well. See the example later in > the email. > > If you don't think these are problems I'm happy to simplify the code. > > > In this model, if a Python command overrides a built-in command, and > > then is itself overridden, can the new command still access the > > underlying built-in command? > > Let's say you override delete. Let's call the first class overriding it > DeleteCommand1 and the second DeleteCommand2. > > If DeleteCommand1 didn't use preserve_when_overridden then > DeleteCommand2.invoke_overridden will just call the original delete. > > If DeleteCommand1 was preserved, then DeleteCommand2.invoke_overridden > will call DeleteCommand1.invoke. At this point DeleteCommand1 may just do > whatever it needs on its own, or call its own invoke_overridden method > which will call the original delete command. > DeleteCommand2 has not way to invoke the original delete command directly. > This is partly because I'm not sure how I would expose this in a nice way, > but mainly because I don't want commands to accidentally skip some > previous implementation by accident. For instance, if we had an > invoke_original method, then DeleteCommand2 could call that and skip > DeleteCommand1. I too have sometimes wondered about providing override type behaviour. I wonder, instead of having 'invoke_overridden' and/or 'invoke_original', if we could/should look to TCL for inspiration, specifically it's uplevel command[1]. If we consider your 'delete' example, the builtin delete would be considered to be at level 0, then we define DeleteCommand1, this would be level 1, and then comes DeleteCommand2 which would be at level 2. Inside DeleteCommand1 we can do: DeleteCommand1.invoke_uplevel (-1, args) this would invoke the command one level down the stack, so in this case the builtin delete. In DeleteCommand2 we can do: DeleteCommand2.invoke_uplevel (-1, args) again, this invokes the command one level down the stack, so in this case DeleteCommand1. However, we could also use: DeleteCommand2.invoke_uplevel (0, args) In this case the level argument 0 indicates we want to directly access the instance of the command at level 0. Where I would find this idea really interesting is that we could easily provide access to this functionality from the command line. This might be useful in two ways I think, first, if a Python script has overridden a command and a user wants to quickly bypass that for some reason they can just do: (gdb) uplevel 0 delete args... in order to get the base version of the command. Second, with some extra work we could make the existing hook mechanism redundant, and possibly provide something more flexible (maybe?), consider: define delete echo Basically a pre-hook here\n uplevel -1 delete $argv echo Basically a post-hook here\n end Notice I just invented '$argv' on the fly there - this doesn't exist currently, but I'm imagining that this would expand to all of the arguments passed to the newly defined 'delete' command. Anyway, I don't think all of the ideas mentioned above would need to be implemented in one go, but I thought it might be worth mentioning some of the thoughts I'd had in this area. Thanks, Andrew [1] https://www.tcl.tk/man/tcl8.4/TclCmd/uplevel.htm