From: Bob Rossi <bob_rossi@cox.net>
To: Jim Ingham <jingham@apple.com>
Cc: gdb@sources.redhat.com
Subject: Re: MI query questions
Date: Tue, 30 May 2006 20:46:00 -0000 [thread overview]
Message-ID: <20060530185446.GF31100@brasko.net> (raw)
In-Reply-To: <6FE49E5C-CD1C-45FC-B2FF-97E4B2FFA779@apple.com>
On Tue, May 30, 2006 at 11:40:51AM -0700, Jim Ingham wrote:
> Seems like having a callback in your parser to handle async messages
> from gdb represents cleanly what is going on. You haven't gotten a
> completed MI command yet, and you're not ready for another MI
> command. But gdb is asking on the side for more input. Seems like
> making the two cases look the same is more likely to cause trouble.
I undstand, and sort of agree with you. However, things get slightly
worse from my perspective. I've designed my FE thus far to behave like
this:
- It is always looking for data from GDB to assemble MI output records.
- It will send only a single GDB command at a time.
With that in mind, my FE assembles an MI output record, and then sends
it up the chain to be looked at more specifically. However, with this
callback-in-the-middle scenario, my FE will have to be retrained to
handle partially returned MI output records.
Does this seem acceptable to you?
For instance, the annotate=2 looks like this:
pre-prompt
(gdb)
prompt
b A::func
post-prompt
[0] cancel
[1] all
[2] A::func(float) at overloaded.cpp:8
[3] A::func(int) at overloaded.cpp:7
pre-overload-choice
>
overload-choice
I think the overload choice is as much a prompt as any other command. I'm
not exactly sure why you think it's a "special" input from the user.
I do see your point about the way your FE does this, however, do you see
my point here?
Thanks,
Bob Rossi
next prev parent reply other threads:[~2006-05-30 18:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-30 3:48 Bob Rossi
2006-05-30 8:20 ` Daniel Jacobowitz
2006-05-30 17:15 ` Jim Ingham
2006-05-30 17:41 ` Bob Rossi
2006-05-30 17:53 ` Jim Ingham
2006-05-30 17:55 ` Jim Ingham
2006-05-30 17:55 ` Bob Rossi
2006-05-30 18:12 ` Daniel Jacobowitz
2006-05-30 20:14 ` Jim Ingham
2006-05-30 18:27 ` Bob Rossi
2006-05-30 18:56 ` Jim Ingham
2006-05-30 20:46 ` Bob Rossi [this message]
2006-05-30 21:11 ` Jim Ingham
2006-05-30 21:15 ` Daniel Jacobowitz
2006-05-30 21:30 ` Jim Ingham
2006-05-31 9:38 ` Daniel Jacobowitz
2006-05-31 13:27 ` Bob Rossi
2006-05-30 17:00 ` Nick Roberts
2006-05-30 17:32 ` Bob Rossi
2006-05-31 10:29 ` Nick Roberts
2006-05-31 13:25 ` Bob Rossi
2006-06-01 0:58 ` Nick Roberts
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=20060530185446.GF31100@brasko.net \
--to=bob_rossi@cox.net \
--cc=gdb@sources.redhat.com \
--cc=jingham@apple.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