From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23318 invoked by alias); 7 May 2006 21:09:59 -0000 Received: (qmail 23310 invoked by uid 22791); 7 May 2006 21:09:58 -0000 X-Spam-Check-By: sourceware.org Received: from bay111-f12.bay111.hotmail.com (HELO hotmail.com) (64.4.17.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 07 May 2006 21:09:54 +0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 May 2006 14:09:52 -0700 Message-ID: Received: from 64.4.17.200 by by111fd.bay111.hotmail.msn.com with HTTP; Sun, 07 May 2006 21:09:51 GMT X-Sender: bviksoe@hotmail.com In-Reply-To: <1147034156.28828.ezmlm@sourceware.org> From: "Bjarke Viksoe" To: gdb@sourceware.org Bcc: Subject: Re: asynchronous MI output commands Date: Sun, 07 May 2006 21:27:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed 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: 2006-05/txt/msg00065.txt.bz2 >From: Bob Rossi > > > You can easily categorize a ^done or ^error response as synchronous. > > Other responses are more difficult to associate with a command, because > > they weren't directly issued as the response to a command. > > > > > It could output > > > > > > -file-list-exec-source-file > > > %-file-list-exec-source-file > > > >^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c" > > > (gdb) > > > > Accomplishing what? This is synchronous. It's a response to the > > previously issued command. The front end knows exactly what its > > previously issued command was, I hope. > >Hmmm. That's interesting, I was hoping to not need to know what the >input command was in order to parse and build an ADT for the output. In >general, I think it would be appropriate if the MI output described >itself well enough that no other information was needed to understand >it, including the MI intput command. > >... > >Thanks, >Bob Rossi When I started using the MI a long time ago I assumed the same - that the MI output would define to some extent what was asked. This would make the front-end much more state-less and easy to do. Unfortunately it does not appear to be the case. I think the general suggestion is to make use of the part of the command syntax to allow you to match the answer with the question - leaving it up to you to keep track of input-parameters, commands and context. In my case I wish to submit several commands at once and slowly digest the answer (over a remote line where the network round-trip is slow). Using the is clumsy and doesn't solve the problem of having enough information to process the answer without keeping track of the question. Since separate components handle the output autonomously, I had to give up tracking a command-list, and instead had to make sure only 1 question was lingering - thus making the entire solution run much slower than otherwise needed. I found that commands that return "^value" result-records (such as -var-evaluate-expression and -data-evaluate-expression) doesn't carry enough information. I don't think a model where the entire command is repeated in the output is a desirable design, but at least identifying the question-type and its crucial parameters would suffice. regards bjarke