From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1589 invoked by alias); 23 Nov 2005 08:36:34 -0000 Received: (qmail 1579 invoked by uid 22791); 23 Nov 2005 08:36:33 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Nov 2005 08:36:31 +0000 Received: from kahikatea.snap.net.nz (p17-tnt2.snap.net.nz [202.124.108.17]) by viper.snap.net.nz (Postfix) with ESMTP id 6EECB688A12; Wed, 23 Nov 2005 21:36:22 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 3C7008425; Wed, 23 Nov 2005 21:36:23 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17284.10758.341185.874368@kahikatea.snap.net.nz> Date: Wed, 23 Nov 2005 09:31:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI: asynchronous operation details In-Reply-To: <200511230931.50438.ghost@cs.msu.su> References: <200511221711.58694.ghost@cs.msu.su> <17283.31813.149904.894253@kahikatea.snap.net.nz> <200511230931.50438.ghost@cs.msu.su> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00522.txt.bz2 [in future, please cc the list] > > Rather than discuss the possible benefits of asynchronous operation in an > > abstract manner, I suggest that you integrate as much of MI into your > > front-end (kdevelop?) to find out the limitations. These limitations > > can then be discussed within a context. > > So, this amount to saying "you need to convert all of KDevelop to MI to > understand how anynchronous operation is good"? I'm saying that if you only look for perceived flaws in MI and are not prepared to write any code that uses it, then you're wasting other people's time. > Sorry, I'm not happy with > this idea -- if "anynchronous operation" is one of selling points of MI, and > there's no clear list of advantages of anynchronous operation, I'm rather > worried. AFAIK no-one is selling anything. Currently anynchronous operation is not really even part of MI. If you choose to use MI and contribute to its development, that is welcome. If you decide not to use it, thats your choice. > Speaking about limitations -- KDevelop already has a debugger, writted before > me, and it works mostly fine. There are no grave limitations I want to fix. > The reasons I'm trying MI are just: > > - Simplify parsing of responses. > - Easily determine if command has failed or not. > > > In Emacs, Richard Stallman has stated that any front-end fro GDB must keep > > the GUD buffer. This is used to enter CLI commands. I have found that the > > best way to get CLI commands to work well with MI is through asynchronous > > operation. > > Why? It decouples the input, CLI or MI, from the output. There might be other ways and it might be partly fortuitous, because all the MI commands that control execution: -exec-run, -exec-next, -exec-finish etc, are really CLI commands in disguise, but it works. Also, thats the path taken by Apple who have a lot of experience in this area with Project Builder and Xcode. Thats enough to convince me. > ...Large number of commands are meaningless while inferiour is running -- no > matter if those commands are CLI ones. > Look, I'm not trying to say asynchronous operation is useless, or something. > I'm trying to understand if I'll be missing something by ignoring it, and if > I should design to use asynchronous operation. > > > Apple have already done this with their version of GDB and you > > can see it in action by installing a copy of Opendarwin. > > To begin with, I don't have OSX anywhere to try Opendarwin. You don't need OSX. You can download Opendarwin from: http://www.opendarwin.org and install it on a partition. The version that I have (OpenDarwin 7.2.1) is all comand line and came on a CD.