From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28151 invoked by alias); 5 Apr 2003 17:59:24 -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 28144 invoked from network); 5 Apr 2003 17:59:23 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 5 Apr 2003 17:59:23 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h35HxN3h004393 for ; Sat, 5 Apr 2003 09:59:23 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 5 Apr 2003 09:59:22 -0800 Received: from apple.com (vpn-scv-x3-39.apple.com [17.219.194.39]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h35HxLbN015066; Sat, 5 Apr 2003 09:59:22 -0800 (PST) Date: Sat, 05 Apr 2003 17:59:00 -0000 Subject: Re: Add fullname to breakpoint output Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: gdb@sources.redhat.com To: Andrew Cagney From: Jim Ingham In-Reply-To: <3E8F124E.2010807@redhat.com> Message-Id: <540DA746-6790-11D7-958C-000A277A8808@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00057.txt.bz2 On Saturday, April 5, 2003, at 09:28 AM, Andrew Cagney wrote: > >> In my view, the CLI should aim at minimalism, since a human being is >> scanning it and too much information would be confusing. The MI is >> intended to be scanned by a program, so we should feel free to cram >> in whatever might be useful - within reason of course... For this >> reason, when we found PB needed an extra bit of data which might not >> be so useful to the CLI user, we would just add it to the MI only. >> This is a little unsatisfying in implementation, since it means you >> have >> if (ui_out_is_mi_like (uiout)) >> { >> } >> scattered through non-interpreter specific code. But this is better >> than cluttering up the CLI output for stuff that is more interesting >> to a front-end... > > Just FYI, the current intermingling of CLI and MI code is short term - > get something working. Medium to long term, the two need to be more > cleanly separated. Related to this is separating more of the CLI from > core GDB. > Yes, this is a desirable goal. Have you thought about how to do this? The best way I can think of is to have a new ui_out that builds up an intermediate representation for results that is easy to access randomly - making up real lists & dictionaries from the ui_out_field_xxx and list & table stuff. Then we could banish ui_out_text & friends to the CLI commands to take the whole result, pull bits out in the order they expected, and annotate them with text, newlines, etc, in order to make a nice display. In practice, this will be gnarly to get right, but you could do it incrementally by getting the intermediate rep. ui_out working, then fix the CLI commands one by one by swapping in the new ui_out for those commands you had fixed, and using the old CLI one for the commands you hadn't gotten working... Idle Saturday speculation, maybe... Jim _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb