From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22742 invoked by alias); 14 Oct 2013 14:30:47 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 22711 invoked by uid 89); 14 Oct 2013 14:30:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com From: Tom Tromey To: Phil Muldoon Cc: archer@sourceware.org, jan.kratochvil@redhat.com Subject: Re: tromey/python non-trivial merge notification References: <525BBB9C.2030006@redhat.com> Date: Mon, 14 Oct 2013 14:30:00 -0000 In-Reply-To: <525BBB9C.2030006@redhat.com> (Phil Muldoon's message of "Mon, 14 Oct 2013 10:38:36 +0100") Message-ID: <87wqlg2add.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-q4/txt/msg00002.txt.bz2 Phil> Then we thought about using current_interp_command_loop instead. This Phil> would work fine, but it would be MI incompatible. I could not think Phil> of a reason why gdb.cli() would be invoked from MI. (It does not make Phil> a whole lot of sense to do so, but someone might prove me wrong ;) ) Yeah. The intended use for this feature was to be able to start gdb without a CLI, using "gdb -P"; then later give the user a CLI if "something happened". There's no reason to do this kind of thing in MI. Tom