From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26124 invoked by alias); 20 May 2005 14:30:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25216 invoked from network); 20 May 2005 14:29:39 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 20 May 2005 14:29:39 -0000 Received: from zaretski (IGLD-83-130-247-87.inter.net.il [83.130.247.87]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id BGY83420 (AUTH halo1); Fri, 20 May 2005 17:29:34 +0300 (IDT) Date: Fri, 20 May 2005 14:30:00 -0000 From: "Eli Zaretskii" To: gdb@sources.redhat.com Message-ID: <01c55d48$Blat.v2.4$04221c60@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050520130342.GA25206@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 20 May 2005 09:03:42 -0400) Subject: Re: [discuss] Support for reverse-execution Reply-to: Eli Zaretskii References: <00c601c55747$860a3e80$aaa56b80@msnyder8600> <01c55783$Blat.v2.4$d6ab25c0@zahav.net.il> <20050519134150.GB15632@nevyn.them.org> <01c55d2a$Blat.v2.4$0a36cba0@zahav.net.il> <20050520130342.GA25206@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00216.txt.bz2 > Date: Fri, 20 May 2005 09:03:42 -0400 > From: Daniel Jacobowitz > Cc: Michael Snyder , gdb@sources.redhat.com > > > > The program doesn't have a persistant direction. > > > > I envision that adding this could be a natural extension. Using > > "backwards" rather than "reverse" will save us from the ambiguity if > > we ever add such a feature. > > I really don't think that we should have such a feature. It seems like > a crummy interface - a resume command which goes either forwards or > backwards in time depending on some global state? I actually don't hate the idea so much, but let's not argue about hypothetical features. > > > "back-continue" and "back-next" just don't sound right. > > > > Neither does "reverse-next". Perhaps we should use "prev" instead. > > It seems to me that if we give them unique names, the logical parallel > with existing commands may be lost. I'd rather lose parallel based on literal similarity, than introduce commands whose names contain an internal contradiction, like back-next or reverse-next. To me, "next" implicitly means "forward", similar to your interpretation of "reverse" to mean "backward". > But perhaps not. Let's try for > the full set: > continue reverse-continue > step reverse-step > next reverse-next > stepi reverse-stepi > nexti reverse-nexti > until reverse-until > advance reverse-advance > finish reverse-finish > > I think that's the full set of reversible commands. Which of them > don't work? I agree that reverse-next is a little weak, but everything > else seems OK. reverse-nexti is like reverse-next, reverse-advance has similar problems, and reverse-finish is also awkward (since we don't ``finish'' anything, we get to the beginning, not the end). > We could use r-prefixed commands. I don't think that helps much, since > we're already planning to offer abbreviations like "rs" and "rni", but > they're my second-favorite choice: > rcontinue, rstep, rnext, rstepi, rnexti, runtil, radvance, rfinish These are better, since the single `r' doesn't produce the kind of contradictions that "reverse" does. > This one's kind of nice, we could use suffixes instead. But > next-backwards is very awkward: > continue-backwards, step-backwards, next-backwards, stepi-backwards, > nexti-backwards, until-backwards, advance-backwards, finish-backwards These are okay from the mnemonic point of view, but they have a big disadvantage for a CLI junky such as myself: they make "next" etc. ambiguous, and you need to type a long string to disambiguate the commands that today have very short unambiguous abbreviations. So it seems that, unless someone else comes up with a better idea, rnext, rstep, etc. is the best compromise.