From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Minor gdb-ui patches to make it a bit more robust Date: Wed, 20 Feb 2008 17:00:01 -0500 Message-ID: References: <18362.728.368749.836476@kahikatea.snap.net.nz> <18362.43848.977271.737049@kahikatea.snap.net.nz> <18363.27328.477290.549149@kahikatea.snap.net.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1203544864 799 80.91.229.12 (20 Feb 2008 22:01:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Feb 2008 22:01:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nick Roberts Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 20 23:01:28 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 1JRwzx-0000us-T4 for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 23:01:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRwzT-00032I-3d for ged-emacs-devel@m.gmane.org; Wed, 20 Feb 2008 17:00:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JRwyz-0002q3-Fp for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:00:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JRwyy-0002pD-8n for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:00:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JRwyy-0002p8-5X for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:00:04 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JRwyx-0007kz-Nn for emacs-devel@gnu.org; Wed, 20 Feb 2008 17:00:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHMxvEfO+J2cdGdsb2JhbACQXAEwn1yBAg X-IronPort-AV: E=Sophos;i="4.25,382,1199682000"; d="scan'208";a="14769592" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 20 Feb 2008 17:00:02 -0500 Original-Received: from pastel.home ([206.248.157.156]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id AYU52702; Wed, 20 Feb 2008 17:00:02 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id F2BCF7F48; Wed, 20 Feb 2008 17:00:01 -0500 (EST) In-Reply-To: <18363.27328.477290.549149@kahikatea.snap.net.nz> (Nick Roberts's message of "Wed, 20 Feb 2008 12:48:16 +1300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:89740 Archived-At: >> > 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. No, it's not a reliability issue. It's a convenience issue. Similar to the check we add to detect "you've loaded an old version of CUA-mode": it won't catch all cases, but will help most victims of the change figure out quickly what's going on. So it's perfectly OK to only catch 99% of the cases. As I said, we may prefer to signal an error (or even just a (loud) message) rather than fallback automatically to the old gud-gdb code. > 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. I'll see if I find time to do it. Basically, you want to replace (setq gdb-foo bar) with (process-put 'foo bar) and gdb-foo with (process-get 'foo) Of course, at first this will be very awkward because is not immediately available, so you'll need (get-buffer-process (current-buffer)) or somesuch. And worse yet, some of the code is not always run in the *gud* buffer, so we'll need (with-current-buffer (get-buffer-process (current-buffer))). We may also prefer to move some of the global vars to buffer-local rather than process-local. In that case some of the code will stay as is, and other will need some (with-current-buffer ...) wrappers. >> 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. That makes sense, indeed. >> >> 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). Then, I strongly encourage you to make such a change to gdb-ui. If you could make a similar change to gud-gdb (so it sends "set annotate 2" I guess), that would be great. Stefan