From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: Minor gdb-ui patches to make it a bit more robust Date: Wed, 20 Feb 2008 12:48:16 +1300 Message-ID: <18363.27328.477290.549149@kahikatea.snap.net.nz> References: <18362.728.368749.836476@kahikatea.snap.net.nz> <18362.43848.977271.737049@kahikatea.snap.net.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1203464969 29438 80.91.229.12 (19 Feb 2008 23:49:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Feb 2008 23:49:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 00:49:52 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JRcDe-0004Ry-5B for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 00:49:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRcD9-0001FV-Ei for ged-emacs-devel@m.gmane.org; Tue, 19 Feb 2008 18:49:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRcCd-0000lu-Fs for emacs-devel@gnu.org; Tue, 19 Feb 2008 18:48:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRcCb-0000j8-FR for emacs-devel@gnu.org; Tue, 19 Feb 2008 18:48:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRcCb-0000iv-43 for emacs-devel@gnu.org; Tue, 19 Feb 2008 18:48:45 -0500 Original-Received: from viper.snap.net.nz ([202.37.101.8]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRcCa-000484-8c for emacs-devel@gnu.org; Tue, 19 Feb 2008 18:48:44 -0500 Original-Received: from kahikatea.snap.net.nz (165.62.255.123.dynamic.snap.net.nz [123.255.62.165]) by viper.snap.net.nz (Postfix) with ESMTP id 8D36A3DB2F0; Wed, 20 Feb 2008 12:48:31 +1300 (NZDT) Original-Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 576C88FC6D; Wed, 20 Feb 2008 12:48:17 +1300 (NZDT) In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.1.90.4 X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:89619 Archived-At: 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