From: Nick Roberts <nickrob@snap.net.nz>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Minor gdb-ui patches to make it a bit more robust
Date: Wed, 20 Feb 2008 12:48:16 +1300 [thread overview]
Message-ID: <18363.27328.477290.549149@kahikatea.snap.net.nz> (raw)
In-Reply-To: <jwv3arpnduo.fsf-monnier+emacs@gnu.org>
Stefan Monnier writes:
> > The flexibility of the command line means that there are always ways round
> > these types of checks. For example, the prompt can be changed, e.g when
>
> Of course, I'm not deluding myself: these are nothing more than sanity
> checks, but they can come *real* handy to the user. I wasted a good 10
> minutes trying to understand why my GDB was not responsive.
It's a reliability issue in't it? Even if your patch works for 99% of users,
it still means the other 1% will be exasperated and go round saying that
gdb-ui is buggy.
> >> Also I think a good way to make it more reliable would be to make
> >> it work with several gud buffers by moving most global vars to
> >> process properties, so they're necessarily correctly initialized, and
> >> we'd be forced to think a bit harder about what's going on where.
>
> > I'm not familar with process properties but I trust your judgement to
> > make these changes.
>
> Process properties are nothing magical: they're just a property-list
> attached to processes, that you can set and read via process-put and
> process-get. Handy for variables which are really per-process
> (e.g. the yet-to-be-processed process output that needs to be passed
> from one invocation of the process filter to the next).
OK, I'm still not sure how it would all work. Perhaps, if, on the trunk,
you initialise one or two variables this way I can do the rest by following
the idiom.
> > Bear in mind, though, that the (long term) plan is to move away from
> > annotations and fully use GDB/MI.
>
> I don't see in what way that would make any difference: global variables
> will still be a source of bugs (and will still prevent the co-existence
> of multiple gdb-ui processes in the same Emacs instance).
I just mean that there will be a lot of churn, at some stage, so I didn't
want to anyone to waste energy on the annotation side of things.
> >> PS: Is there any hope for GDB to accept a command that puts it in
> >> annotate=3 mode, rather than having to tweak the command line for it?
> >> That would solve a lot of those problems.
>
> > Yes, if you mean "set annotate 3".
>
> So is there any hope to make gdb-ui rely on that rather than
> on --annotate=3?
Yes. I guess that is another possible way to solve the initialisation
problems (and keep text command mode available to M-x gdb).
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2008-02-19 23:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-18 21:08 Minor gdb-ui patches to make it a bit more robust Stefan Monnier
2008-02-18 22:12 ` Nick Roberts
2008-02-19 2:42 ` Stefan Monnier
2008-02-19 9:42 ` Andreas Schwab
2008-02-19 10:11 ` Nick Roberts
2008-02-19 15:57 ` Stefan Monnier
2008-02-19 23:48 ` Nick Roberts [this message]
2008-02-20 22:00 ` Stefan Monnier
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18363.27328.477290.549149@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).