From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Derek Peschel Newsgroups: gmane.lisp.guile.devel Subject: Re: Evaluating (exit) in the debugger Date: Thu, 20 Nov 2008 16:48:32 -0800 Message-ID: <20081120164832.A7356@eskimo.com> References: <20081119165343.A29659@eskimo.com> <49dd78620811201609v272c7487i72840fdafe80588f@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1227228620 29358 80.91.229.12 (21 Nov 2008 00:50:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Nov 2008 00:50:20 +0000 (UTC) Cc: guile-devel@gnu.org To: Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 21 01:51:23 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1L3KF0-0000Rq-3A for guile-devel@m.gmane.org; Fri, 21 Nov 2008 01:51:22 +0100 Original-Received: from localhost ([127.0.0.1]:44897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3KDr-0000WT-AG for guile-devel@m.gmane.org; Thu, 20 Nov 2008 19:50:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3KCM-0008Ku-3Q for guile-devel@gnu.org; Thu, 20 Nov 2008 19:48:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3KCK-0008IO-8s for guile-devel@gnu.org; Thu, 20 Nov 2008 19:48:37 -0500 Original-Received: from [199.232.76.173] (port=58867 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3KCK-0008IG-3g for guile-devel@gnu.org; Thu, 20 Nov 2008 19:48:36 -0500 Original-Received: from ultra5.eskimo.com ([204.122.16.68]:57702) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L3KCJ-0001Vm-LE for guile-devel@gnu.org; Thu, 20 Nov 2008 19:48:35 -0500 Original-Received: from eskimo.com (eskimo.com [204.122.16.13]) by ultra5.eskimo.com (8.14.3/8.14.0) with ESMTP id mAL0mWkH007043; Thu, 20 Nov 2008 16:48:32 -0800 Original-Received: (from dpeschel@localhost) by eskimo.com (8.9.1a/8.9.1) id QAA08844; Thu, 20 Nov 2008 16:48:32 -0800 (PST) Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <49dd78620811201609v272c7487i72840fdafe80588f@mail.gmail.com>; from neiljerram@googlemail.com on Fri, Nov 21, 2008 at 12:09:18AM +0000 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7878 Archived-At: On Fri, Nov 21, 2008 at 12:09:18AM +0000, Neil Jerram wrote: > I'm afraid I don't understand. What do you want to happen when you > type "e (exit)"? I want Guile to exit, just as normally happens when you call (exit). Also return codes should be supported in the debugger as in the REPL, e.g. "e (exit 5)" should return 5 to the calling UNIX process. The principle is that the debugger should not interfere with the actions of code it's debugging, which to me includes "e"'d code. > Agree that it does at the moment, but I'm not sure this is strictly > needed. The debugger "e" command is mostly intended for variable > values and simple expressions - so normally there could not be a > backtrace of much interest. Obviously I'm abusing it then. :) Seriously, if you did evaluate a complex expression, or were confused about environment lookup (since the expression is evaluated in the context of the current stack frame as chosen by the up/down/frame commands, right?) the backtrace would be useful. This gets into issues like recursive debugging, which is a feature I confess I haven't used much yet, however nice it may be in theory. > The lazy-catch handler can also set a variable (global or lexical), can't it? It certainly should be able to. That might lead to a workable solution. Suppressing error messages is another necessary part of the solution (at least IMO). > Just had a quick look at eval-handler in (ice-9 debugger commands)... > did you notice that it ends with (throw 'continue) - and hence that > the default lazy-catch rethrowing isn't actually happening? Is it > possible that (throw 'continue) is the cause of the problem? I will have to look at the code and my experiments later, when I've finished the things I'm supposed to be doing. However I know for a fact that at least one level of handler gets the "unhandled quit exception" I described, with nothing related to continue that I've seen. And I need to work out how many levels of handler are running when the evaluation happens. I wonder if Guile can tell me that? -- Derek