From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: Re: asynchronous MI output commands
Date: Wed, 10 May 2006 12:43:00 -0000 [thread overview]
Message-ID: <e3s3tb$mpc$1@sea.gmane.org> (raw)
In-Reply-To: <20060507211356.GA18033@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Sun, May 07, 2006 at 11:09:51PM +0200, Bjarke Viksoe wrote:
>> 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 <token> 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.
>
> If I were writing a front-end, I would have an arbitration layer which
> sent questions to GDB and received answers. The answers will come back
> one at a time, in the same order the questions were asked. If you send
> two -var-evaluate-expression commands, you'll get back two answers, in
> that same order.
>
> Am I missing something? Is there a reason that this isn't enough?
For the record, that's basically what I have in KDevelop. There's command
queue, and commands are sent to gdb one-at-a-time, and responses come
exactly in the same order. Remembering the last issued command (i.e.
instance of GDBCommand class internal to KDevelop) makes it possible to
route the response back to the original command.
I'm don't quite understand the problems being discussed in this thread. It's
not apparent why one has to know the type of the last command while
parsing, and if so, why remembering the last command is bad idea.
It's hard to believe that response from MI can be useful without knowing the
last issued command. Say, response from -data-evaluate-expression is
useless if you don't know what part of frontend wants that data --
evaluating expression is used in many use cases. So, you need to associate
extra data with commands anyway.
- Volodya
next prev parent reply other threads:[~2006-05-10 7:15 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1147034156.28828.ezmlm@sourceware.org>
2006-05-07 21:27 ` Bjarke Viksoe
2006-05-07 21:41 ` Daniel Jacobowitz
2006-05-10 12:43 ` Vladimir Prus [this message]
2006-05-12 0:19 Alain Magloire
-- strict thread matches above, loose matches on Subject: below --
2006-05-11 15:02 Alain Magloire
2006-05-11 15:42 ` Bob Rossi
2006-05-11 16:40 ` Jim Ingham
2006-05-11 17:03 ` Daniel Jacobowitz
2006-05-11 17:35 ` Jim Ingham
2006-05-11 19:24 ` Bob Rossi
2006-05-11 19:25 ` Jim Ingham
2006-05-10 22:15 Alain Magloire
2006-05-11 3:41 ` Bob Rossi
2006-05-11 8:58 ` Vladimir Prus
2006-05-11 10:48 ` Bob Rossi
2006-05-11 10:52 ` Vladimir Prus
2006-05-11 11:14 ` Bob Rossi
2006-05-11 12:50 ` Vladimir Prus
2006-05-11 14:50 ` Bob Rossi
2006-05-09 9:46 Alain Magloire
2006-05-07 22:30 Bjarke Viksoe
2006-05-07 22:50 ` Daniel Jacobowitz
2006-05-08 0:36 ` Bjarke Viksoe
2006-05-08 1:52 ` Daniel Jacobowitz
2006-05-06 1:26 Bob Rossi
2006-05-06 1:59 ` Daniel Jacobowitz
2006-05-06 2:48 ` Bob Rossi
2006-05-06 3:37 ` Nick Roberts
2006-05-06 15:20 ` Bob Rossi
2006-05-06 4:06 ` Daniel Jacobowitz
2006-05-06 4:05 ` Daniel Jacobowitz
2006-05-06 11:53 ` Bob Rossi
2006-05-06 12:06 ` Bob Rossi
2006-05-06 3:14 ` Bob Rossi
2006-05-06 4:04 ` Nick Roberts
2006-05-06 11:49 ` Daniel Jacobowitz
2006-05-06 11:50 ` Bob Rossi
2006-05-06 16:52 ` Daniel Jacobowitz
2006-05-06 19:45 ` Bob Rossi
2006-05-06 20:37 ` Daniel Jacobowitz
2006-05-07 0:44 ` Bob Rossi
2006-05-07 20:35 ` Daniel Jacobowitz
2006-05-07 20:42 ` Bob Rossi
2006-05-07 22:01 ` Daniel Jacobowitz
2006-05-08 1:22 ` Bob Rossi
2006-05-08 2:03 ` Daniel Jacobowitz
2006-05-09 21:48 ` Bob Rossi
2006-05-08 6:38 ` Nick Roberts
2006-05-08 11:28 ` Bob Rossi
2006-05-08 1:26 ` Bob Rossi
2006-05-06 11:51 ` Bob Rossi
2006-05-06 3:27 ` Nick Roberts
2006-05-06 16:40 ` Bob Rossi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='e3s3tb$mpc$1@sea.gmane.org' \
--to=ghost@cs.msu.su \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox